OUM 6.2 Full Method View

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
[EOCM] Organizational Change
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
Management
[TR] Training
[TS] Transition
[PS] Operations and Support
[AN] Analysis
[DS] Design
[IM] Implementation
[TE] Testing
[PT] Performance Management
[TA] Technical Architecture
[DO] Documentation
Management
[TR] Training
[TS] Transition
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
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
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
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
Strategy
Develop Workplan
PS WM.010 Develop Baseline Project Workplan Baseline Project Workplan Implementation Plan
Iteration Plan Summary
OUM Project Workplan
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
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
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
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
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.
PEC FM.040 Manage Project Finances Managed Project Finances Refer to the Task Overview for guidance.
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.
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.
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.
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
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
PEC IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Equipment Fault Record
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
Gain Acceptance
PC SM.050 Gain Acceptance Final Acceptance Certificate Acceptance Certificate
Project Acceptance Report
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
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
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
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
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
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
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
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.
ME EA.010.2 Review Architecture Principles,
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
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.
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
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.
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
Back to Top
IMPLEMENT FOCUS AREA - TASKS AND WORK PRODUCTS
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
B CV.063.1 Perform Conversion Component
Validation Test (Initial Load)
Validation-Tested Conversion Components (Initial
Load)
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)
C CV.063.2 Perform Conversion Component
Validation Test (Initial Load)
Load)
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
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
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
Rules
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
Recommendations
A OCM.130 Build Communication Strategy and
Change Management Roadmap
Communication Strategy and Change
Management Roadmap
Communication Strategy
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
Elaboration Phase
B OCM.150.2 Conduct Change Management
Events
B OCM.155.1 Monitor Change Management
Effectiveness
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
Events
C OCM.155.2 Monitor Change Management
Effectiveness
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
Events
D OCM.155.3 Monitor Change Management
Effectiveness
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
Events
E OCM.155.4 Monitor Change Management
Effectiveness
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
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
Transition Phase
D TR.100.2 Conduct User Learning Events Skilled Users User Learning Events Administration
Back to Top
[TS] Transition
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
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
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
OUM 6.2 Focus Area Overview
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
Validate Scope, Stakeholders, and Organization Change Management (OCM) Strategy
Develop Workplan
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 Communications and Organization Change Management (OCM) Plans
Project Closure Activities
Gain Acceptance
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
OUM 6.2 Phase Overview
[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
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
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
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
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
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
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
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
OUM 6.2 Activity Overview
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
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
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
PS.ACT.RBC Review Bid and Contract
Back to Top
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
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
Strategy
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
Bid Material
PS.ACT.RPAC Review Project Assets with Client
Back to Top
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
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 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
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
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
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
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
Back to Top
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
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
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
PS.ACT.DW Develop Workplan
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
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
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
IPM.030 Develop Issue and Problem Management System Issue and Problem Management System Issue Form
Issue Log
Problem Form
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
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
Back to Top
[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.
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
Back to Top
SM.030 Manage Scope Managed Scope Y Core
SM.040 Manage Acceptance Managed Acceptance Y Core
WM.050 Manage Approvals Managed Approvals Y Core
FM.040 Manage Project Finances Managed Project Finances Y Core
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
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
QM.040 Perform Quality Control Quality Control Y Core
QM.050 Perform Quality Assurance Managed Quality Assurance Y Core
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
IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Y Core
PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Y Core
Back to Top
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
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
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
SM.030 Manage Scope Managed Scope Change Request Form
Change Request Log
SM.040 Manage Acceptance Managed Acceptance Acceptance Criteria
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
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
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
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
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
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
Back to Top
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
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
Back to Top
APPROACH
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
Back to Top
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
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
Back to Top
APPROACH
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
Back to Top
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
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
Back to Top
APPROACH
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
Back to Top
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
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
Back to Top
APPROACH
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
Back to Top
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
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
Back to Top
APPROACH
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
Back to Top
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
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
Back to Top
APPROACH
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
Back to Top
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
IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Equipment Fault Record
Back to Top
ITERATIONS
Back to Top
APPROACH
Monitor Infrastructure Management activities using the processes, procedures, controls and metrics defined in the Infrastructure Management Plan.
Back to Top
PREREQUISITES
Back to Top
#TOP #TOP
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
PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Incoming Item Record
Rejection Note
Back to Top
ITERATIONS
Back to Top
APPROACH
Manage the procurement of goods and services based on the previously defined Procurement Strategy and Process.
Back to Top
PREREQUISITES
Back to Top
[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
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
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
Back to Top
Gain Acceptance
SM.030 Gain Acceptance Final Acceptance Certificate Y Core
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
CMM.040 Document Lessons Learned Lessons Learned Y Core
CMM.050 Turn Over Project Documentation Project Archives Y Core
Back to Top
Back to Top
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
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
SM.050 Gain Acceptance Final Acceptance Certificate Acceptance Certificate
Back to Top
ITERATIONS
Back to Top
APPROACH
Review the contract to make certain that all contractual obligations are met.
Ensure that all sign-offs have been received.
Back to Top
PREREQUISITES
Contract
Back to Top
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
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
Back to Top
APPROACH
Close processes and reports for each of the Project Management processes.
Close contract.
Establish follow-up procedures.
Back to Top
PREREQUISITES
Contract
PC.ACT.GA Gain Acceptance
Back to Top
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
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
Back to Top
APPROACH
Document Lessons Learned
Turn Over Project Documentation
Submit Final Reports
Back to Top
PREREQUISITES
Back to Top
OUM 6.2 Process Overview
[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
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
This section is not yet available.
Back to Top
OUM 6.2 Task Overview
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
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
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
Back to Top
WORK PRODUCT
Confirmed Business Case
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
BT020_CONFIRMED_BUSINESS_CASE.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Identified Project Stakeholders
Back to Top
TASK STEPS
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
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
15
Project Manager 85
Client Project Manager *
Back to Top
PREREQUISITES
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
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
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
Back to Top
WORK PRODUCT
Accepted Project Budget
Back to Top
TASK STEPS
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
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
Back to Top
WORK PRODUCT
Reviewed Contract
Back to Top
TASK STEPS
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
25
Project Manager 75
Back to Top
PREREQUISITES
Prerequisite Usage
Contract (Contract Preparation Process) This is the document that you need to review with the client.
Back to Top
TEMPLATES AND TOOLS
BT050_REVIEWED_CONTRACT.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Reviewed Project Approach
Back to Top
TASK STEPS
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
Back to Top
25
Project Manager 75
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
BT060_REVIEWED_PROJECT_APPROACH.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Project Management Framework
Back to Top
TASK STEPS
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
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
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
Back to Top
PREREQUISITES
Prerequisite Usage
Proposal (Bid Preparation/Bid Review Cycle)
Back to Top
TEMPLATES AND TOOLS
BT070_PROJECT_MANAGEMENT_FRAMEWORK.DOC MS WORD
BT070_ABBREVIATED_PROJECT_MANAGEMENT_FRAMEWORK.PPTX MS POWERPOINT
Back to Top
[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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
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
Back to Top
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
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
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
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
Cloud Roadmap
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.
Back to Top
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. *
Back to Top
PREREQUISITES
Prerequisite Usage
Confirmed Business Case (BT.020)
Project Management Framework (BT.070)
Back to Top
TECHNIQUES
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
SM010_VALIDATED_SCOPE.DOC MS WORD
Back to Top
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
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
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
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
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. *
Back to Top
PREREQUISITES
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
SM020_CHANGE_REQUEST_PROCESS.DOC MS WORD
SM020_SCOPE_CHANGE_MANGEMENT_CHECKLIST.DOC MS WORD
Back to Top
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
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
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. *
Back to Top
PREREQUISITES
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
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
SM030_CHANGE_REQUEST_FORM.DOC MS WORD
SM030_CHANGE_REQUEST_LOG.XLS MS EXCEL
Back to Top
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
Back to Top
WORK PRODUCT
Managed Acceptance
Back to Top
TASK 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
15
Project Manager 85
Back to Top
PREREQUISITES
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.
Oriented Team (STM.050)
Back to Top
TEMPLATES AND TOOLS
SM040_ACCEPTANCE_CRITERIA.DOC MS WORD
SM040_ACCEPTANCE_CERTIFICATE.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Final Acceptance Certificate
Back to Top
TASK STEPS
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.
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
15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
SM040_ACCEPTANCE_CERTIFICATE.DOC MS WORD
SM050_PROJECT_ACCEPTANCE_REPORT.DOC MS WORD
Back to Top
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
SM060_SCOPE_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Future System Enhancements
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
SM070_FUTURE_SYSTEM_ENHANCEMENTS.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
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
Back to Top
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
Back to Top
WORK PRODUCT
Approved Project Budget
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
Back to Top
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
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
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
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
15
Project Manager 85
Cient Project Sponsor *
Back to Top
PREREQUISITES
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
FM020_DEVELOP_FINANCIAL_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Time and Expense Tracking
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
FM030_EXPENSE_TRACKING_SPREADSHEET.XLS MS EXCEL
FM030_PROJECT_TEAM_TIME_SHEET.XLS MS EXCEL
Back to Top
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
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
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
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. *
Back to Top
PREREQUISITES
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
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
Back to Top
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
Back to Top
WORK PRODUCT
Closed Project Financials
Back to Top
TASK STEPS
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
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
15
Project Manager Make final updates to tracking documents and produce final reports. 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
FM050_FINANCIAL_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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.
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
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
Back to Top
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
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
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.
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
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.
Refer to Tailoring OUM for Your Project for an overview of the tailoring process in OUM.
Back to Top
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
Back to Top
PREREQUISITES
Prerequisite Usage
Work Breakdown Structure (WBS) (Bid Process)
Validated Scope (SM.010)
Back to Top
TECHNIQUES
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
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
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
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
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
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:
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.
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.
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.
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 Archival 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 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.
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
WM020_DEVELOP_WORK_MANAGEMENT_PROCESSES_AND_POLICIES.DOC MS WORD
Back to Top
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 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:
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
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
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
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.
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
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
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.
Refer to Tailoring OUM for Your Project for an overview of the tailoring process in OUM.
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
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.
Oriented Team (STM.050) Oriented Team members (resources) are assigned to tasks in the Project Workplan.
Back to Top
TECHNIQUES
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
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
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
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
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. *
Back to Top
PREREQUISITES
Prerequisite Usage
(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
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
Back to Top
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
Back to Top
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
Back to Top
WORK PRODUCT
Closed Work Management
Back to Top
TASK STEPS
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
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
15
Project Manager Gather work products and create archives for each activity. 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
WM060_WORK_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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.
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
Back to Top
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
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
RKM010_RISK_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
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
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
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.
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
15
Project Manager 85
Back to Top
PREREQUISITES
Prerequisite Usage
Risk Management Review (Bid Review Process)
Back to Top
TEMPLATES AND TOOLS
RKM020_BASELINE_RISK_ASSESSMENT.DOC MS WORD
RKM020_RISK_MITIGATION.DOC MS WORD
Back to Top
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
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
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
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
Use Risk Form created/edited in RKM030
Use Risk Log created/edited in RKM030
Back to Top
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
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
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
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
Prerequisite Usage
These work products document the processes and system for monitoring and controlling risks during the project.
Back to Top
TEMPLATES AND TOOLS
Use Risk Form created/edited in RKM030
Use Risk Log created/edited in RKM030
Back to Top
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
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
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
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
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or 15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
RKM060_POST_PRODUCTION_RISK_ASSESSEMENT.DOC MS WORD
RKM060_RISK_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
During Start Up, establish both the Issue Management Strategy and the Problem Management Strategy as well as the Issue and Problem Management System
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
Back to Top
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
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
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
IPM010_ISSUE_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
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
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
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
5 Define roles and responsibilities. Roles and Responsibilities List any and all roles involved and describe the responsibilities.
Problem Management Strategy.
Approved Problem
Management Strategy
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
IPM020_PROBLEM_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
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
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
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
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
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
Back to Top
WORK PRODUCT
Closed Issue and Problem Log
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
IPM050_ISSUE_AND_PROBLEM_MANAGEMENT_LESSON_LEARNED.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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.
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
Back to Top
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
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
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
Cloud Roadmap
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
Prerequisite Usage
Validated Scope (SM.010
Back to Top
TEMPLATES AND TOOLS
STM010_PROJECT_TEAM_ORGANIZATION_CHART.DOC MS WORD
STM010_RESOURCE_PLAN.XLS MS EXCEL
Back to Top
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
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
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
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
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
Back to Top
PREREQUISITES
Prerequisite Usage
Resource Plan (STM.010) Use the Resource Plan to determine resource requirements.
Back to Top
TEMPLATES AND TOOLS
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
STM.030 - STAFF PROJECT
Staffing the project addresses the issues that influence getting the right people for the project.
ACTIVITY
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
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
Back to Top
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
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
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
Work Management - Project organization, Time and Expense Reporting Guidelines, Work Rules, Project Workplan and timeline, Key Risk Management Work
Products
Staff Management
Communication Management - Communication Plan
Configuration Management Infrastructure 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
15
Project Manager 85
Back to Top
PREREQUISITES
Prerequisite Usage
SM.010 Validated Scope (SM.010)
Scope Change Management Processes (SM.020)
Financial Management Plan (FM.020)
Work Management Plan (WM.020)
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)
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
STM040_PREPARE_ORIENTATION_GUIDE.DOC MS WORD
Back to Top
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
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
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
Prerequisite Usage
Orientation Guide (STM.040) Use the Orientation Guide to help structure the meeting and plan presentations.
Back to Top
TECHNIQUES
Technique Comments
Service Architecture Review this technique as input into this task.
Back to Top
TEMPLATES AND TOOLS
STM050_PROJECT_KICKOFF_ORIENTATION.PPTX POWERPOINT
Back to Top
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
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
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
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
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
15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
Back to Top
[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
Back to Top
APPROACH
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
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
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
Back to Top
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
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
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
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. *
Back to Top
PREREQUISITES
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
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
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
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
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
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
15
Project Manager Write Project Team Communication Plan. 85
Client Project Manager Approve Project Team Communication Plan. *
Back to Top
PREREQUISITES
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
CMM020_PROJECT_TEAM_COMMUNICATION_PLAN.DOC MS WORD
CMM020_CLIENT_PROFILE_SHEET.DOC MS WORD
CMM020_STEERING_COMMITTEE_PRESENTATION.PPTX POWERPOINT
Back to Top
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
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
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 Manager Approve changes to Project Team Communication Plan. Publish summary reports, distribute and file. *
Back to Top
PREREQUISITES
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
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
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
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.
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.
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 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.
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.
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.
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.
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.
Back to Top
Back to Top
10
Project Manager Prepare Lessons Learned Report. 65
Team Members Participate and share views on what worked and what could be improved. 25
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
CMM040_LESSONS_LEARNED.DOC MS WORD
Back to Top
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
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
15
Project Manager Turn over archives to client. 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
Back to Top
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
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
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
15
Project Manager Prepare Final Reports. 85
Back to Top
PREREQUISITES
Prerequisite Usage
All Prior Project Reports (Project Archives)
Back to Top
TEMPLATES AND TOOLS
CMM060_PROJECT_CLOSURE.DOC MS WORD
CMM060_END_REPORT.DOC MS WORD
CMM060_ENGAGEMENT_SUMMARY.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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.
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
Back to Top
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
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
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
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
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.
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 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
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
Back to Top
PREREQUISITES
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
QM010_QUALITY_MANAGEMENT_PLAN.DOC MS WORD
QM010_QUALITY_MANAGEMENT_PROCEDURES.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
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
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
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
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
Work Management
Quality Management
Risk Management
Issue/Problem Management
Staff Management
Communication Management
Infrastructure 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
Back to Top
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
Back to Top
PREREQUISITES
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
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
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
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
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
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
Back to Top
PREREQUISITES
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
QM030_PROJECT_TEAM_QUALITY_MANAGEMENT_ORIENTATION.PPTX POWERPOINT
Back to Top
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
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
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.
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
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
Back to Top
PREREQUISITES
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
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
QM040_REVIEW_COMMENTS_LIST.DOC MS WORD
QM040_REVIEW_LEADER_FORM.DOC MS WORD
Back to Top
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.
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
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.
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
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
Back to Top
PREREQUISITES
Prerequisite Usage
Quality Management Plan (QM.010) Execute the Quality Assurance Process documented in the Quality Management Plan.
Back to Top
TEMPLATES AND TOOLS
QM050_AUDIT_ACTION_REPORT.DOC
QM050_AUDIT_REPORT.DOC
QM050_QUALITY_REPORT.DOC
Back to Top
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
Back to Top
WORK PRODUCT
Post-Production Quality Review
Back to Top
TASK STEPS
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
15
Project Manager Depending on your project, you may have a designated quality manager in this role that reports to the project manager. 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
QM060_CLIENT_SATISFACTION_REPORT.DOC MS WORD
QM060_PROJECT_HEALTHCHECK_CHECKLIST.DOC MS WORD
QM060_METRICS_REPORT.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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.
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
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
Back to Top
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
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
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
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
Back to Top
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.
*
Back to Top
PREREQUISITES
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
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
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
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
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
Back to Top
5
Technical Leads This role is filled by technical project team members (e.g., developer, designer, system architect) providing needed technical
information.
80
Back to Top
PREREQUISITES
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
Back to Top
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
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
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
12 Distribute and communicate the Documentation Management Plan. Documentation
Management
Plan
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
15
Back to Top
PREREQUISITES
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
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
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
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
6 Define any control processes that relate to software
configuration management.
Control Processes Document any control processes that relate to software
configuration management.
Software Configuration Management Plan.
Approved Software
Plan
8 Distribute and communicate the Software Configuration
Management Plan.
Software Configuration
Management Plan
9 Execute the Software Configuration Management Plan.
Back to Top
APPROACH
Examples of Software configuration items include:
Reports
Database configuration or parameters
"Wrapper" installation scripts
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
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
15
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.
*
Back to Top
PREREQUISITES
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
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
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
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:
Reports
Database configurations
"Wrapper" installation scripts
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
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
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
7 Distribute and communicate the Software Release Management
Plan.
Software Release
Management Plan
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
Back to Top
15
capacity.
*
advisory capacity.
*
Back to Top
PREREQUISITES
Prerequisite Usage
(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
Technique Comments
SOA Release Planning For SOA engagements, this technique defines leading practices for SOA release planning.
Back to Top
TEMPLATES AND TOOLS
CM050_SOFTWARE_RELEASE_MANAGEMENT_PLAN.DOC MS WORD
CM050_RELEASE_NOTE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
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
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
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.
Environment and Patch Management Plan.
Approved Environment and
Patch Management Plan
11 Distribute and communicate the Environment and Patch
Management Plan.
Environment and Patch
Management Plan
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
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 Manager Review and approve the Environment and Patch Management Plan. *
Back to Top
PREREQUISITES
Prerequisite Usage
Configuration Management Plan and Processes (CM.010)
Back to Top
TEMPLATES AND TOOLS
CM060_ENVIRONMENT_AND_PATCH_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
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
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
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 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.
Configuration Management Control Plan.
Approved Configuration
Management Control Plan
9 Distribute and communicate the Configuration
Management Control Plan.
Control Plan
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
the collection effort is manual.
Back to Top
Back to Top
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
capacity.
*
advisory capacity.
*
Client Project Manager Review and Approve the Configuration Management Control Plan. *
Back to Top
PREREQUISITES
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
CM070_CONFIGURATION_MANAGEMENT_CONTROL_PLAN.DOC MS WORD
Back to Top
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
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
1 Record current version of documentation and configuration items. Finalized Documentation of
Configuration Items
Document current version of documentation and
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
5
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) providing needed technical
information.
50
Back to Top
PREREQUISITES
Prerequisite Usage
(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
CM080_CONFIGURATION_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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.
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
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.
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
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
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
Role
ID
Name Responsibility
PAD Project
Administrator
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
Back to Top
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
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
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
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
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. *
Back to Top
PREREQUISITES
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
IFM010_INFRASTRUCTURE_MANAGEMENT_PLAN.DOC MS WORD
IFM010_INSTALLATION_AND_RECORD.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
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
Back to Top
WORK PRODUCT
Team Work Environment
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
Back to Top
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
Back to Top
WORK PRODUCT
Established Technical Infrastructure
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
IFM030_PHYSICAL_RESOURCE_PLAN.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
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.
ACTIVITY
PEC.ACT.MMI Manage and Maintain Infrastructure
Back to Top
WORK PRODUCT
Maintained Infrastructure
Back to Top
TASK STEPS
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
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
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
IFM040_EQUIPMENT_FAULT_RECORD.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Closed Infrastructure
Back to Top
TASK STEPS
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
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
Back to Top
[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
Back to Top
APPROACH
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
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
Back to Top
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
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
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
5 Distribute and communicate the Procurement Strategy
and Process.
Procurement Strategy and
Process
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
PCM010_PROCUREMENT_STRATEGY_AND_PROCESS.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Service Orders
Back to Top
TASK STEPS
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
Back to Top
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
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
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
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
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
PCM.040 - CLOSE CONTRACT
During Project Closure, all services and goods are inspected and verified to be acceptable. All necessary records are updated.
ACTIVITY
Back to Top
WORK PRODUCT
Closed Contract
Back to Top
TASK STEPS
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
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
PCM040_SUPPLIER_ASSESSMENT_RECORD.DOC MS WORD
Back to Top
[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
Back to Top
APPROACH
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
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.
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
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
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
Back to Top
Role
ID
Name Responsibility
PAD Project
Administrator
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
Back to Top
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
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
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
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
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
OCHM010_CLIENTS_ORGANIZATIONAL_CHANGE_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
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
Back to Top
WORK PRODUCT
Change Management Warning Signs
Back to Top
TASK STEPS
Component
Description
1 Flag quickly any deviation in the Client's Organizational Change Management Strategy and
raise it to the stakeholders as a risk.
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
15
Project Manager 85
Back to Top
PREREQUISITES
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
OCHM020_CHANGE_MANAGEMENT_WARNING_SIGNS.DOC MS WORD
Back to Top
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
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
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
Back to Top
PREREQUISITES
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
Back to Top
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
Back to Top
WORK PRODUCT
Follow-Up Process
Back to Top
TASK STEPS
Back to Top
APPROACH
Back to Top
15
Project Manager 85
Back to Top
PREREQUISITES
Prerequisite Usage
Client's Organizational Change Management Strategy (OCHM.010)
Back to Top
TEMPLATES AND TOOLS
Back to Top
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.
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
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
[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
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
Back to Top
TIPS AND TECHNIQUES
Back to Top
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.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.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
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
Back to Top
MANAGING RISK
Back to Top
Back to Top
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
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
PS.ACT.RBAC Review Bid and Contract
Back to Top
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
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
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
INIT.ACT.PEF Prepare Envision Foundation
Back to Top
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
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
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
INIT.ACT.PD Prepare for Discovery
Back to Top
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
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
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
Back to Top
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
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
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
INIT.ACT.CEAWE Conduct Executive Alignment Workshop - Envision
INIT.ACT.DMCEC Define and Maintain Common Enterprise Concepts
Back to Top
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
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
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
Back to Top
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
ID Task Name
ER.140 Share Product Strategies with Enterprise
ER.150 Review Discovery Findings
Back to Top
ITERATIONS
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
Back to Top
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
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
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
Back to Top
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
ID Task Name
ER.190 Review Business Feedback and identify Opportunities
ER.200 Prepare for Transition to Sales or Services
Back to Top
ITERATIONS
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
INIT.ACT.DSPC Develop Solution and Present to Client
Back to Top
[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
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-
Back to Top
OBJECTIVES
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 maintain enterprise artifacts that result from software implementation projects within the enterprise.
Maintain an IT Portfolio applying additions and changes.
Respond to critical business needs or pain points as an ongoing process, and by initiating enterprise-level projects as needed by the business.
Collect and evolve a set of leading practices around Enterprise Business Analysis, Enterprise Architecture, IT Strategy and IT Portfolio Management.
Back to Top
PROCESSES
Envision Roadmap (ER)
Enterprise Business Analysis (BA)
Enterprise Architecture (EA)
IT Portfolio Management (IP)
Governance (GV)
Back to Top
KEY WORK PRODUCTS
Back to Top
TIPS AND TECHNIQUES
Back to Top
Envision includes the following tasks:
#TOP #TOP
Envision Roadmap
ER.210 Monitor Current Situation and Pursue Relevant Updates Monitored Current Situation
Enterprise Business Analysis
BA.100 Maintain Enterprise Business Models Maintained Enterprise Business Models
BA.110 Maintain Business Rules Maintained Business Rules
EA.210 Maintain Enterprise Architectural Models Maintained Enterprise Architectural Models
IT Portfolio Management
IP.070 Execute and Maintain IT Portfolio and Programs Maintained IT Portfolio and Programs
IP.080 Maintain Repository of Artifacts Maintained Repository of Artifacts
Governance
GV.110 Monitor and Analyze Governance Processes Governance Implementation Improvement Proposal
Back to Top
The Maintain and Evolve phase is made up of only one ongoing activity the Maintain and Evolve activity. The tasks in this activity and phase are performed as needed.
Back to Top
MANAGING RISK
Back to Top
Back to Top
ME.ACT.ME - MAINTAIN AND EVOLVE
The focus of this activity is to maintain enterprise artifacts that result from software implementation projects within the enterprise.
Back to Top
OBJECTIVES
The objective for this activity is to ensure up-to-date enterprise artifacts.
Back to Top
TASKS
ID Task Name
BA.017.2 Determine Metrics Collection and Reporting Strategy
BA.018.2 Establish Current Baseline Metrics
BA.100 Maintain Enterprise Business Models
BA.110 Maintain Business Rules
BA.030.2 Develop Enterprise Glossary
EA.010.2 Review Architecture Principles, Guidelines and Standards
GV.020.2 Determine Regulatory and Business Mandates
GV.030.2 Discover or Define Policies
GV.050.2 Define Policy Implementation Processes
GV.060.2 Define Policy Implementation Tooling
GV.070.2 Define Policy Metrics
GV.080.2 Define Policy Monitoring Processes
GV.090.2 Determine Funding Model
GV.100.2 Implement Governance
GV.110 Monitor and Analyze Governance Processes
IP.080 Maintain Repository of Artifacts
ER.120.2 Identify and Mitigate Future State Risks
ER.130.2 Product MoSCoW Improvement List
EA.210 Maintain Enterprise Architecture Models
IP.050.2 Prioritize Projects
IP.070 Execute and Maintain IT Portfolio and Programs
ER.210 Monitor Current Situation and Pursue Relevant Updates
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 update the appropriate enterprise artifacts, as appropriate. This could involve updating models and maintaining the Enterprise
Repository or simply maintaining spreadsheets.
Back to Top
PREREQUISITES
Back to Top
[ER] ENVISION ROADMAP
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 to ensure a successful completion of a project using Oracle technology.The overall focus is on
definition and validation of business objectives and matching those objectives into recommended solutions possibly using the Oracle Suite of products where appropriate.
This process overview is written from the perspective of a Full Method View, utilizing ALL of the activities and tasks in this process. Therefore, all of the following
Middleware Architecture View), not everything in this overview may be appropriate for your project. Please keep this in mind, especially when reviewing the Key Work
Products and Tasks and Work Products 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
PROCESS FLOW
This process flow for this process follows:
Back to Top
APPROACH
Back to Top
Initiate Phase
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.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
ER.210 Monitor Current Situation and Pursue Relevant Updates Monitored Current Situation
Back to Top
OBJECTIVES
Back to Top
KEY WORK PRODUCTS
Back to Top
Back to Top
Back to Top
ER.010 - CREATE BUSINESS CASE FOR ENVISION
ENGAGEMENT
The purpose of this task is to evaluate/qualify a potential customer Envision engagement before it is formally approved and proposed to the customer. Therefore, this is
largely an Oracle internal exercise but may also include Oracle Partners with knowledge of the targeted customer or their competitors.
ACTIVITY
Back to Top
WORK PRODUCT
Customer Envision Engagement Strategy - The Customer Envision Engagement Strategy contains a detailed summary of the customer investigation findings.
Back to Top
TASK STEPS
1 Perform Strategic Analysis Strategic Analysis The Strategic Analysis details the high-level business strategies the customer is looking to
implement in the coming years.
2 Perform Value Analysis. Value Analysis The Value Analysis details the specific business value themes around which Oracle could
potentially engage with the customer.
3 Create Customer Benefits Hypothesis. Customer Benefits
Hypothesis
The Customer Benefits Hypothesis is a hypothesis statement to convince the customer to
engage with Oracle.
4 Perform architecture opportunity
research.
Architecture Opportunity
Matrix
The Architecture Opportunity Matrix provides potential opportunities with the customer that
have not been explored in the past.
5 Review the customer relationship
network.
Customer Relationship
Network
The Customer Relationship Network details customer relationships with partners and vendors.
6 Review vendor landscape. Vendor Landscape The Vendor Landscape details the software vendor landscape within the customer IT
architecture.
7 Review customer IT organization
maturity.
Customer IT Organization
Maturity
The Customer IT Organization Maturity is a high-level assessment of the IT organization.
8 Perform business and risk lifecycle
assessment.
Business and Risk
Lifecycle Hypothesis
The Business and Risk Lifecycle Hypothesis details the risks of the customer's current IT
strategy and provides a hypothesis for mitigating those risks.
9 Perform a value improvement
assessment.
Value Improvement
Hypothesis
The Value Improvement Hypothesis details the value/innovation that Oracle could bring to the
customer and provides a hypothesis.
10 Define Customer Engagement Plan. Customer Engagement
Plan
The Customer Engagement Plan is a high-level plan describing the customer engagement
approach for all Envision phases.
11 Gather information and present
investigation summary to team.
Customer Envision
Engagement Strategy
The Customer Envision Engagement Strategy organizes all the components into a single work
product to be presented back to the Oracle team.
Back to Top
APPROACH
The task is normally initiated by the lead account manager within the customer account. The exercise will include the following key components:
Strategic Analysis - Review the high level business strategies the customer is looking to implement in the coming years (that is, information found on Customer
Web Site, Annual Reports, Market analysis, etc.). Review the potential value (measurable/immeasurable) to the customer of implementing those strategies.
Value Analysis - Review the specific business value themes around which Oracle could potentially engage with the customer (for example, using Value
Assessments, analysis of key competitors in the market etc.).
Customer Benefits Hypothesis - Create a high-level business/benefits hypothesis that would show to the customer the benefits in executing an Envision
engagement.
Architecture Opportunity Matrix - Review potential opportunities within the customer base (taking into account both Pillar Technology and Applications
opportunities). Consider reference architectures. Refer to task EA.002, Review External Reference Architectures.
Customer Relationship Network - Review key customer relationships (e.g., internal to customer, with partners, vendors etc.). Select possible coaches and
stakeholders for a possible Oracle engagement.
Vendor Landscape - Review software vendor landscape within the customer IT architecture (that is, gather information on technologies, applications and
information on these systems, etc.).
Customer IT Organization Maturity - Perform a high-level maturity assessment of the IT organization (for example, business linkage, governance of technical
standards, success of EA Group etc.).
Business and Risk Lifecycle Hypothesis - Review risks associated with the customer continuing with the existing IT strategy and create a hypothesis for helping to
mitigate that risk.
Value Improvement Hypothesis - Create a high-level hypothesis as to what value/innovation Oracle could bring to the organization (that is, key value messaging,
for example, reduction in TCO of infrastructure platform etc.).
Customer Engagement Plan - Create a high-level plan describing the customer engagement approach for all Envision/Insight phases.
Customer Envision Engagement Strategy - Gather all information into a single report that is presented back to the Oracle Account Team and Partner Network.
Based on final account team presentation, the lead account manager would decide on the most appropriate engagement approach with the customer.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Provide architectural knowledge to the process, e.g., Architecture Opportunity Matrix, Vendor Landscape, etc. Provide
knowledge about the enterprise industry, for example, trends, benchmark data, etc.
80
Sales Manager Manage information about the client, for example, the business strategies, relationship network, etc. 20
Client Stakeholders Provide information about the enterprise and business. *
Back to Top
PREREQUISITES
Prerequisite Usage
High-Level Enterprise
Strategic Information
Use information found on Customer Web Site, Annual Reports, Market analysis, etc. to review the potential value
(measurable/immeasurable) to the customer of implementing the engagement.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
SOA Architecture Resources SOA Architecture Resources contain additional information that can be useful in completing this task.
Enterprise Architecture Resources Enterprise Architecture Resources contain additional information that can be useful in completing this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
The Customer Envision Engagement Strategy really serves as the basis for deciding upon the type of engagement Oracle will propose to the customer. An Envision
engagement must be balanced in terms of opportunities, customer relationship, investment and potential benefits for Oracle and the customer. An Envision engagement
provides the client with a specific value, and as such, it should be considered different from a sales initiative and Oracle might suggest a certain level of customer funding.
The Customer Envision Engagement Strategy work product is used by the account team to exchange customer critical information. The account manager may use the
work product or extracts from it in dialogues with his management. It serves as a valuable reference throughout the Envision engagement. Sections of it may move to
downstream work products in the Envision process that are shared with the customer.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
Have all sources of information been explored?
Have all key resources, e.g., solution architects, consultants, project managers, account team, etc, provided information?
Have all task steps been explored?
Has the account team reviewed and agreed on the final strategy?
Back to Top
ER.015 - CONDUCT ENTERPRISE MATURITY ASSESSMENT
This task is aimed at assessing the maturity of the enterprise related to a predefined area, for example, to assess the enterprise architecture maturity or the SOA maturity.
The assessment would either be conducted directly with the enterprise, internally within the implementing organization (e.g., Oracle) by the account team, or as a self
assessment by the enterprise.
ACTIVITY
Back to Top
WORK PRODUCT
Maturity Analysis and Recommendations Report - The Maturity Analysis and Recommendations Report highlights the enterprises maturity in various dimensions and
provides an overall rating with a detailed description of the rating in each major category as well as the implementing organization's (e.g., Oracle) recommendation for a
follow up engagement.
Back to Top
TASK STEPS
1 Define rationale for
conducting the
enterprise
maturity
assessment.
None
2 Prepare scope of
the assessment.
Scope The Scope defines the scope of the assessment, e.g., line of business versus the entire enterprise.
3 Agree on the
assessment
methodology.
Methodology The Methodology defines the selected basis of the assessment, for example, an Oracle or Industry-Standard Maturity
methodology.
4 Secure enterprise
stakeholder
sponsorship.
Enterprise
Stakeholder
Sponsorship

5 Conduct
assessment.
Maturity Analysis
and
Recommendations
Report
The Maturity Analysis and Recommendations Report highlights the enterprises maturity in the predefined areas and
provides an overall rating with a detailed description of the rating in each major category as well as the implementing
organization's (e.g., Oracle) recommendation for a follow up engagement. For an Enterprise Architecture Maturity
Assessment, the Open Groups TOGAF Maturity Model is recommended as the basis of the maturity assessment.
6 Present Maturity
Analysis and
Recommendations
Report to
enterprise.
Maturity Analysis
Presentation

7 Agree on follow up
engagement with
enterprise.
None
Back to Top
APPROACH
The goal of this task is to:
Ensure that any following engagement (e.g., Insight) is aware of the enterprises maturity using either Oracle specific (e.g., SOA Maturity Model) or Industry
Standard (e.g., TOGAF Maturity Model) architecture maturity models. The resulting insight from the maturity assessment will help inform the discovery and
delivery phases of any follow on Oracle engagement with the enterprise. It will help to ensure that:
More relevant questions are asked in any follow on discovery tasks.
A more relevant articulation of a solution proposition (i.e., the end work product is presented at the appropriate level of depth/complexity).
The enterprises context is better understood.
Oracle has a better understanding of how it can assist the enterprise in moving to its target situation and/or implementing their strategy.
Help the enterprise better understand their overall maturity based on industry defined or recognized levels of maturity (i.e., defined by Industry Standards bodies
such as the Open Group) that would:
Help compare the enterprise against their peers.
Help them understand how they could move to a higher level of maturity (as relevant).
Help them understand how a follow up Oracle engagement could better help them achieve their target level of maturity.
Enterprise Architecture Maturity Assessment
If the maturity assessment is an Enterprise Architecture Assessment, an assessment would normally cover the following dimensions of enterprise maturity:
IT Architecture Process
IT Architecture Development
Business-IT Linkage
Senior Management Involvement
Line of Business participation (in development of the EA)
Architecture Communication (IT Groups success in communicating the value of EA to the business)
IT Security
Architecture Governance
IT Investment and Acquisition Strategy (i.e., the impact on the EA organization)
Service-Oriented Architecture (SOA) Maturity Assessment
For SOA, the maturity assessments are based on a SOA Maturity Model. The model defines various SOA domains, for example:
Business and Strategy
Organization
Governance
Projects, Portfolio and Services
Operations, Administration and Management
Information
Infrastructure
Architecture
The typical approach is to have stakeholders from the enterprise answer questions for the various SOA domains and rate the answers against a maturity matrix in order to
identify areas for SOA improvement. A typical SOA Maturity Model includes domain definitions, questions relevant for each domain and the maturity matrix. There are
many organizations, including Oracle, that have defined SOA Maturity Models and offer SOA readiness assessments as Services. For Oracle, SOA readiness
assessments are conducted by an Oracle professional assisting the enterprise in understanding SOA from a strategic perspective.
Back to Top
BPM Project Engineering
This task has supplemental guidance that should be considered if you are executing a service based on the BPM Project Engineering view. Use the following to access
the task-specific supplemental guidance. To access all BPM Project Engineering supplemental information, use the BPM Project Engineering Supplemental Guide.
BPM Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Business Process Management (BPM) Roadmap service
offering. Use the following to access the task-specific supplemental guidance. To access all BPM Roadmap supplemental information, use the BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Roadmap service
offering. Use the following to access the task-specific supplemental guidance. To access all SOA Roadmap supplemental information, use the SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Lead the assessment. 100
Client Stakeholders Participate in the assessment. *
Back to Top
PREREQUISITES
Prerequisite Usage
Customer Envision Engagement
Strategy (ER.010)
Use this work product to determine additional available material that could be an input for the Maturity Assessment (other
than the prerequisites mentioned here).
Existing Reference Material (ER.080) Use this work product to determine additional available material that could be an input for the Maturity Assessment (other
than the prerequisites mentioned here).
Business Strategy (BA.010) Use the Business Strategy to score questions regarding the strategy.
Enterprise Stakeholder Inventory
(BA.015)
Use the Enterprise Stakeholder Inventory to determine the key stakeholders that should be involved in the Maturity
Assessment.
Enterprise Function or Process Model
(BA.040)
Use these work products to score questions regarding the current state of the organization's key business functions or
business processes.
Current Enterprise Architecture
(EA.030)
Use this work product to score questions regarding the enterprise architecture.
Enterprise Software Development
Process (EA.095)
Use this work product to score questions regarding the organization's software development lifecycle (SDLC).
IT Application Portfolio (IP.012) Use this work product to score questions regarding the organization's application capabilities.
Current Governance Model (GV.015) Use this work product to score questions regarding the organization's current state of Governance.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Capability Maturity Models Integration Use this link to learn more about Capability Maturity Models Integration (CMMI).
SOA Architecture Resources SOA Architecture Resources contain additional information that can be useful in completing this task.
Back to Top
Back to Top
QUALITY CRITERIA
Have you agreed on the maturity model to use for this assessment?
Has the scope of the assessment been agreed on?
Have all dimensions included in the assessment been completed?
Has the organization been allocated to a specific maturity model?
Has the enterprise agreed to the assessment of their maturity level?
Back to Top
ER.020 - DETERMINE ENVISION ENGAGEMENT STRATEGY
During this task, you validate that a particular engagement or approach will be a good fit for the target organization, or you actually determine which approach will be the
most suitable. Use this information to determine the strategy for Envision. This should include, in detail, what kind of engagement this is. This could be anything from a
smaller engagement to explore the use of a specific technology, through a larger Envision engagement to determine the strategies of the enterprise around several
business areas and technologies to a full-blown Envision engagement to determine the strategies of the entire enterprise. Determine which method processes and which
tasks in each process should be included, and what work products should be produced. You should also determine the scope of the area that should be covered, for
example, should it cover the complete enterprise, or just a few departments.
In Envision we talk about performing a sales plan or an engagement, using a specific approach.
The term, roadmap may reflect a high-level approach and plan of engagement for the Envision engagement or may refer to the high-level sales process, which
may also be referred to as a roadmap.
An engagement is an agreed on set of activities that should be performed. This could be activities predefined in a sales plan, or it could be any given set of
activities that you agree to perform with the client, independent of any sales plan.
The approach explains how you want to perform the engagement. If you use a sales plan as a basis, often an approach is already suggested, but sometimes
multiple approaches are suggested that you could choose among. If you do not use a sales plan, you should determine how you want to perform the engagement.
Decisions you need to make may for example be when (for which tasks) and how many workshops you want to use, whether you plan to use multiple iterations,
and so on.
During this task, you determine the approach on a high-level, while you produce the detailed plan as part of the Set and Agree on Plan for Envision Engagement task
(ER.030).
ACTIVITY
Back to Top
WORK PRODUCT
Envision Engagement Strategy - The Envision Engagement Strategy documents how you plan to perform Envision. This includes the scope and the approach. It
documents in detail what kind of engagement this is, which method processes should be included, what work products should be produced as well as the parts of the
enterprise that will be involved.
Back to Top
TASK STEPS
1 Review (Joint) account
plan(s) and other
customer-specific
material.
None
2 Review current
relationship between
Oracle and customer.
None
3 Determine customer
characteristics.
Customer
Characteristics
The Customer Characteristics component lists a number of customer characteristics that make a customer more or less
suitable for a specific engagement. For each characteristic it shows how important the characteristic is to determine
suitability. The list is used as a means to determine the suitability for the client at hand.
4 Document suitability. Customer
Suitability
The Customer Suitability component is documentation of the customer characteristics (determined in the step above)
against the customer at hand. For each characteristic it is documented with a reasoning how the rating has been done. It
also contains a final suitability.
5 Determine suitable
approach.
Envision
Engagement
Strategy
The Envision Engagement Strategy component shows how you plan to perform Envision. It includes sections for the
scope of the engagement and the chosen approach. It documents which method processes are included, and what work
products should be produced.
6 Obtain approval for
chosen approach.
Approved
Envision
Engagement
The Approved Envision Engagement Strategy is the Envision Engagement Strategy as it has been approved internally
and by the client.
Strategy
Back to Top
APPROACH
Review (Joint) Account Plan(s) and Other Customer-Specific Material
Review the account plan(s), if available, or any other customer-specific material to get an initial understanding of the customer and the customer situation. Normally an
account plan contains the following type of information: customer business overview, customer IT overview, customer influence map, Oracle applications/technology
footprint, known customer business/IT drivers and strategic plan, and account team sales objectives.
Review Current Relationship Between Oracle and Customer
Perform a review of the current relationship between Oracle and the customer to better understand what kind of engagement may be the most appropriate. Do we
already have a relationship with the customer, and if so, on what level, and is it a positive relationship? Do we want to improve or change the relationship with the
customer?
Determine Customer Characteristics
Certain customer characteristics make them more or less suitable for a specific engagement. If you are considering an approach that is based upon a specific sales plan,
then review the guidelines of the sales plan to validate whether the customer fits the characteristics described for the sales plan.
Assess Suitability
Depending upon how well a customer fits into the specific characteristics for a specific sales plan or other kind of engagement, make a decision on what kind of
engagement or approach is the most appropriate. If you are looking at a specific sales plan engagement, review the plan to find positive and negative factors relating to
the characteristics reviewed under the previous step.
Determine Suitable Approach
Determine the approach to take for the engagement. Review the method processes and determine which processes should be covered as part of the engagement.
Review the customer situation to determine which activities, tasks and work products you will include.
Envision can be performed in multiple iterations or increments, for example, in one iteration you can focus on a specific process or business area, and you can expand or
add detail in following iterations. Consider whether it is appropriate to suggest an iterative or incremental approach. Often, it is less risky to cover smaller areas first, and
expand when you know the customer situation better, or when the client has become more used to the process.
If the approach is to perform a sales plan, choose the most appropriate sales plan type for the client situation. It should be a good fit for the customer and allow for more
options with which to go forward. For example, some approaches have different sales plan options depending upon how much the client can participate during the
process. Get the required internal approvals for the chosen sales plan type.
Obtain Approval for Chosen Approach
You should obtain both internal approval and client approval to continue with the chosen approach.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Work with the sales manager, project manager and client stakeholders to create an Envision Engagement Strategy that sets
goals and defines the approach to the engagement.
80
Sales Manager Assist with creating the Envision Engagement Strategy. 20
Project Manager Assist with creating the Envision Engagement Strategy. *
Client Stakeholder Provide input for the Envision Engagement Strategy. *
Back to Top
PREREQUISITES
Prerequisite Usage
(Joint) Account Plans and other Customer-Specific Material Use this material to gain an understanding of the customer and customer situation.
Back to Top
TECHNIQUES
Technique Comments
Motivational Modeling
Business Scope Definition
Functional or Process Modeling
Enterprise Domain Model - Data Ownership Approach
Enterprise Domain Model - Data Relationship Approach
Service Modeling
Review these techniques as input into this task for a SOA Modeling Planning engagement.
Back to Top
TEMPLATES AND TOOLS
ER-020_ENVISION_ENGAGEMENT_STRATEGY.DOC MS WORD
Back to Top
The Envision Engagement Strategy is used in the following ways:
to provide background on the customer characteristics that help set an initial direction for the engagement
to documents the characteristics and business drivers that are triggering the engagement between Oracle and the customer
to provide the Customer and Oracle with a documented approach for the Envision engagement
Distribute the Envision Engagement Strategy as follows:
to key stakeholders from senior management for both the IT and the business areas of the customer
to key stakeholders from Oracle Consulting and Oracle Development as appropriate
Back to Top
QUALITY CRITERIA
Have client characteristics been defined to a level of understanding so that initial business drivers can be developed?
Have the suitability of technology and approach been assessed and the results documented?
Has a plan been described to a level of detail for moving forward with an Envision engagement either through a sales plan, a strategy, or Expert Services?
Back to Top
ER.025 - EDUCATE ENTERPRISE ON AREA OF FOCUS
During this task, you educate the enterprise on the scope and the expected benefits of the area under consideration. Use this to level-set everyone on what the
engagement as a whole entails, what it is meant to provide to the enterprise, what participation is needed and what to expect as a result of the engagement. You should
take time to ensure that everyone involved understands the implementing organization's vision and value proposition on the area of focus. It is also important to provide
an understanding of the concepts and terms are relevant to the area of focus.
ACTIVITY
Back to Top
WORK PRODUCT
Educated Enterprise - An Educated Enterprise understands what the engagement entails, the concepts and terms, and if relevant, the implementing organization's vision
and value proposition for the area of focus.
Back to Top
TASK STEPS
1 Identify primary components of the
area of focus.
Area of
Focus
Description
The Area of Focus Description provides the title and description and use relevance for the area of focus.
2 Detail terms and definitions. Key Terms The Key Terms is a list of the key terms and their definitions that has been prepared for the area under
consideration. You may want to include materials such as analyst reports, case studies and white papers in the
definitions.
3 Depending on the area of focus,
provide relevant diagrams or
models, descriptions and
examples of use.
Diagrams
and Models
The Diagrams and Models are images of the components and how they relate to support the area under
consideration. If the focus area is a specific technology, you would typically provide architecture diagrams. You
may want to include materials such as analyst reports, case studies and white papers in the descriptions and
examples of usage.
4 If relevant, provide a list of legal
issues and standards.
Legal Issues
and
Standards
The Legal Issues and Standards is a list of the legal issues and/or standards that are supported by using the area
under consideration.
5 Prepare a presentation. Presentation In this step, you compile the information in the previous steps and prepare a presentation.
6 Follow up on any open questions. None
Back to Top
APPROACH
Provide Education Foundation
As we educate the enterprise on the scope and the expected benefits related to the area of focus, we begin to learn more about the enterprise's attitude and
expectations. This education process allows a foundation for collaboration. The objective is to arrive at a common understanding of terms and concepts that will be
referenced in later phases. Ideally, the enterprise will have a better understanding of the area of focus (e.g., a specific type of technology) and its importance to their
industry and to their specific business. Thus, executing this task serves as a foundation and reference point for all of the enterprise-facing activities that follow.
This is an optional task and is only done if a basic education or overview of the area under consideration is required. This may be an ongoing exercise while the
engagement is in progress and may be repeated to level-set the enterprise again on other areas of focus that may come up later in the engagement. This early education
about the area under consideration is useful if you are working with a client who has a limited awareness of the area of focus and needs to understand it better in order to
participate fully. However, it may also be useful when the enterprise is experienced in the area in order to agree on terminology and concepts as there may be different
understandings of terms and concepts. This limits misunderstandings later in the engagement.
Back to Top
Back to Top
Enterprise Architect Set the scope, key terms and legal content. Deliver the final presentation. 10
Solution Architect Contribute relevant diagrams, models and concepts for the area of focus. 90
Client Stakeholders Attend the presentation. *
Back to Top
PREREQUISITES
Prerequisite Usage
Envision Engagement Strategy
(ER.020)
The Envision Engagement Strategy contains the initial list of the technologies (areas of focus) under consideration for this
engagement.
Back to Top
TEMPLATES AND TOOLS
ER-025_AREA_OF_FOCUS_FOUNDATION.DOC MS WORD
Tool Comments
Oracle Enterprise Software Framework
Overview
The Oracle Enterprise Software Framework (ESF) is a framework for software classification.
Enterprise Architecture Resources The Enterprise Architecture Resources provides links to additional resources that may be useful in completing this
task.
Back to Top
Educated stakeholders are an important part of an Envision engagement.
This is an important communication for the Envision stakeholders, and lays the foundation for subsequent activities
Back to Top
QUALITY CRITERIA
Has the presentation been provided to stakeholders who will be involved in the Envision engagement?
Does the client have a basic understanding of the areas under consideration?
Back to Top
ER.030 - SET AND AGREE ON PLAN FOR ENVISION
ENGAGEMENT
During this task, you make a plan on how the Envision engagement should be performed following the chosen approach.
Envision can be performed in multiple iterations or increments, for example, in one iteration you can focus on a specific process or business area, and you can expand or
add detail in following iterations. If you know up front that you will perform multiple iterations, make an overall plan covering the objectives for each iteration or increment.
However, normally you only detail the plan for the current iteration or increment. When the first iteration/increment reaches its end, revisit this task, and plan the next
iteration in detail.
The Envision Plan may also need updating throughout the Envision process. As more details will be known, there may become a need for changes.
ACTIVITY
Back to Top
WORK PRODUCT
Envision Engagement Plan - The Envision Engagement Plan provides a plan for accomplishing the Envision phase. It includes, objectives, tasks and activities, and
resources.
Back to Top
TASK STEPS
1 Determine objectives for
Envision engagement.
Envision
Objectives
The Envision Objectives component is a list of objectives that are expected to be achieved as a result of the
engagement.
2 Produce the actual plan for the
engagement.
Envision
Engagement
Plan
The Envision Engagement Plan shows all the tasks and activities laid out in a timeline as they are expected to be
performed. All important meetings and workshops are included as early as possible.
3 Determine required resources
and expected level of effort.
Envision
Resource
Plan
The Envision Resource Plan shows all the resources, both Oracle and client, that will be required during the
Envision effort, and in what kind of tasks and activities they are required.
Back to Top
APPROACH
Determine Objectives for Envision Engagement
Review the Envision Engagement Strategy (ER.020), Business Strategy (BA.010) and Business Scope (BA.012) to determine the objectives for the Envision engagement
and make sure that they the objectives are applicable to the business scope as identified. If you plan to perform the engagement in multiple increments, the business
objectives may be different for each increment. Your engage objectives may be similar or different for each increment.
If you perform the engagement in multiple iterations, the business objectives for each iteration will probably be the same, but you may have a different focus, and thereby
different kind of engagement objectives per iteration. It is important that you determine which business objectives should be the drivers for the iteration/increment and as
well as the engagement objectives.
An example of a business objective is:
to decrease level of customer complaints with a minimum of 40% within the next two years
Examples of engagement objectives are:
to explore the 3 most important key business processes and identify possible improvement options for these
to identify only main flows for each enterprise process (this could typically be the first iteration, while further detailing comes in secondary iterations)
Produce the Actual Plan for the Engagement
Use the processes, activities and tasks that you have decided for the engagement, and determine when they should be performed. Consider which tasks should be
performed in parallel, which require input from other tasks (dependencies), for which you decide to use workshops, and which you intend to iterate.
Outline the tasks in time.
Determine Required Resources and Expected Level of Effort
Determine the type of resources and how much you will need to perform the tasks of the engagement plan. Consider both client and Oracle resources.
You may want to revisit this task after you have collected some Enterprise Research Findings (ER.040), especially when looking at objectives and the resources you need
for the engagement.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Use the Envision Engagement Strategy (ER.020) and create a concrete plan defining phases, objectives and resources. This
results in a proposal to the client.
100
Project Manager Assist with creating the Envision Engagement Plan. *
Back to Top
PREREQUISITES
Prerequisite Usage
Envision Engagement Strategy (ER.020) Follow the Envision Engagement Strategy when planning the engagement.
Business Strategy (BA.010) Ensure that the plan reflects the Business Strategy.
Business Scope (BA.012) Make sure the objectives identified are applicable to the Business Scope.
Enterprise Research Findings (ER.040) This information may be useful to planning the engagement.
Back to Top
TECHNIQUES
Technique Comments
Business Scope Definition
Enterprise Domain Model - Data Ownership Approach
Enterprise Domain Model - Data Relationship Approach
Service Modeling
Review these techniques as input into this task for a SOA Modeling Planning engagement.
Back to Top
TEMPLATES AND TOOLS
ER-030_ENVISION_ENGAGEMENT_PLAN.DOC MS WORD
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.040 - RESEARCH ENTERPRISE
During this task, you look through the enterprise situation to learn more about the enterprise in order to determine who are the influential persons and to better
understand the enterprise strategy, their business situation and their industry position. A lot of the content for this task has been determined in other tasks, so this may be
a task where the various content is collected as one set of diagnostic information.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Research Findings - The Enterprise Research Findings includes various diagnostic information regarding the enterprises business strategy, business
situation, industry position and current environment as well as influential persons.
Back to Top
TASK STEPS
1 Review (joint) account plan(s).
2 Create Initial Influence Map. Initial Influence Map
3 Research enterprise business strategy. Discovery Map
4 Research enterprise business situation and industry position. Discovery Map
5 Research enterprise's current environment. Discovery Map or current environment
Back to Top
APPROACH
Review (Joint) Account Plan(s)
Review the Account Plan, if available. In many cases, a strong joint account plan exists that provides an outline of the enterprises goals, interactions with the
implementing organization, and enterprise white space. However, if the account plan does not contain this information or the information is insufficient, this type of
information should be found as part of this task. Also, any ongoing or planned activity the implementing organization currently has with this enterprise that could be
relevant should be taken into consideration.
Create Initial Influence Map
Review the Enterprise Organization Structures (BA.020), and use this as an input to create an Initial Influence Map component. The Initial Influence Map shows actual
persons at the client site in various positions, what kind of role that person has in the organization, how large an influence that person has, what that persons preference
is related to the implementing organization, the degree of contact, and who at the implementing organization is responsible for the contact. This may differ from the actual
location a person has in the organization structure. Informal relations may be just as important as the formal ones. Consider capturing the roles that you have identified in
the Enterprise Stakeholder Inventory (BA.015). See the Capturing Stakeholder technique for more details.
Research Enterprise Business Strategy
Review the Business Strategy (BA.010) as it contains the current stated objectives of the enterprises executive management team. This provides an input to the goals
section of the Discovery Map component.
Research Enterprise Business Situation and Industry Position
Research the enterprises' business situation and industry position. Try to identify any challenges facing the enterprise and the industry. There often exists a lot of publicly
available available information about an organization that can be used to compare industry averages and to provide competitive information. Use this as an input to
identify tactical pains in the Discovery Map.
Research Enterprise's Current IT Environment
Research the enterprise's current IT environment as it relates to their the implementing organization's investments, their current middleware, database, reporting,
business intelligence, portal, security, hardware and storage footprint. This information can be validated and expanded upon meeting with the enterprise. This may also
be used to identify possible tactical pains for the Discovery Map.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Perform research. Create Influence Map and Discovery Map. 50
Sales Manager Provide information on past interactions with client, account plans, etc. Participate in creation of Influence Map
and Discovery Map.
50
Back to Top
PREREQUISITES
Prerequisite Usage
(Joint) Account Plans This information provides the enterprises goals, interactions with the implementing organization (e.g., Oracle), and
enterprise white space.
Business Strategy (BA.010) Use the Business Strategy to understand the business goals.
Enterprise Organization Structures
(BA.020)
This work product may provide information for the Initial Influence Map component.
Back to Top
TECHNIQUES
Technique Comments
Back to Top
TEMPLATES AND TOOLS
ER-
040_ENTERPRISE_RESEARCH_FINDINGS.DOC
MS WORD
ER-040_DISCOVERY_MAP.PPTX MS POWERPOINT
ER-040_INFLUENCE_MAP.PPTX MS POWERPOINT
ER.040_EXAMPLE_DISCOVERY_MAPS.VSD MS VISIO
Tool Comments
SOA Architecture Links SOA Architecture Links contain additional information that can be useful in completing this task.
Enterprise Architecture Links Enterprise Architecture Links contain additional information that can be useful in completing this task.
Back to Top
The output of this task should be available to any of the implementing organization team interacting with the enterprise, but is most relevant to license sales, consulting
sales, architects and any bid team members engaging with the enterprise.
This information is distributed at the discretion of the sales representative.
The Enterprise Research Findings is used to identify opportunities where the implementing organization (for example, Oracle) could help the enterprise. This is one of the
most important inputs to the identification of Current Architectural Challenges (EA.050) and Architectural Gaps and Improvement Options (EA.060), as well as to High-
Level Use Cases (BA.060).
Back to Top
QUALITY CRITERIA
Does the research at least contain information on important financial indicators, and comparisons to industry averages, market trends and competitors KPI values?
Does the Influence Map at least contain the senior executives that are relevant to the enterprise we are engaging (CEO, CIO, CFO, enterprise architects, business
unit managers, etc.) and the implementing organization staff having recent interactions with these?
Are the goals in the Discovery Map mapped to the goals in the enterprises Business Strategy (BA.010)?
Is there at least one key business requirement per goal in the Discovery Map, preferably two?
Back to Top
ER.045 - ESTABLISH EXECUTIVE SPONSORSHIP
During this task, you need to get the chief sponsor of the engagement to fully buy-in and commit to providing the time and resources of the necessary stakeholders of the
enterprise improvements.
At this stage, it is also critical to work with the sponsor to spell out the exact definition of success, both in the short and the long-term. A simple example of the definition of
success is lowering the data center maintenance cost by 10% or processing 10% more insurance claims per day. You may have to guide the executive so that his goals
are related to the areas agreed to for the engagement.
The scope can be both technical and functional in nature so that the results deliver both value to the business (e.g., cost savings, growth potential, better customer
service, etc.) but also provide some technical and architectural benefits while delivering that value (e.g., a service-oriented architecture platform for the future IT projects,
a web 2.0 collaboration environment for employees and customers, etc.).
ACTIVITY
Back to Top
WORK PRODUCT
Committed Executive Sponsorship - Committed Executive Sponsorship includes the buy-in and commitment from a customer executive to provide the time resources
and necessary stakeholders needed to make the agreed upon enterprise improvements.
Back to Top
TASK STEPS
1 Provide an executive overview of the business solution,
and how Oracle technology, domain knowledge and
enterprise architecture support the business benefits.
Executive
Overview
The Executive Overview is geared towards setting the right expectations of how Oracle
approaches developing, Business Solutions including, guidance on Oracle technology and
enterprise architecture recommendations as well as how the results provide benefit to the
business.
2 Explain at a high-level how and where Oracle would
start given the business strategy that the executive(s)
have already articulated.
None This step is for the executives to build some confidence that Oracle understands their
business model and can add value through the expertise and technology to improve and
support their business goals.
Back to Top
APPROACH
Present Enterprise Engagement Method and Value Proposition to Customer
Position the Envision engagement in a way that illustrates it as a process that helps them with their business transformation plans. This should not be positioned as a
method to simply do detailed discovery of their enterprise, since customers are usually more interested in knowing how they can implement the changes rather just doing
an inventory exercise.
Identify Some Entry Points for the Enterprise Engagement
From your knowledge and understanding of the Enterprise, we can often provide the to-be sponsor some example solutions based on industry leading practices or prior
enterprise engagements (e.g., Enterprise Architecture) to build rapport and credibility with the sponsor about the fact that we have the experience and skill to add
significant value to their enterprise architecture team.
Back to Top
Back to Top
Enterprise Architect Gain executive sponsor commitment. Set expectations correctly with sponsor. Provide executive-level overview of benefits and
business value of the engagement.
100
Sales Manager Provide any needed assistance. *
Back to Top
PREREQUISITES
Prerequisite Usage

Back to Top
TEMPLATES AND TOOLS
Tool Comments
Service-Oriented Architecture (SOA) Links The SOA Links contain additional information that can be useful in completing this task.
Enterprise Architecture Links The Enterprise Architecture Links contain additional information that can be useful in completing this task.
Back to Top
The Committed Executive Sponsorship is used in the following ways:
to confirm the enterprise engagement meets the chief sponsors expectations
to obtain buy-in and commitment from the chief sponsor of this engagement
Back to Top
QUALITY CRITERIA
Do you have a sponsorship agreement that has basic information on the customer, e.g. profile, industry, competitors, business drivers?
Is the Business Strategy understood?
Can you articulate the business value of this engagement?
Do you have some example solutions based on industry leading practices or prior enterprise architecture engagements?
Have you received feedback from key Oracle and customer stakeholders prior to the formal presentation for sponsorship?
Have you gained agreement on formal sponsorship and allocation of time and resources to support the Envision engagement?
Back to Top
ER.050 - VALIDATE AND AGREE ON ENVISION ENGAGEMENT
PLAN
During this task, you validate and agree on the suggested plan with the client. The intention is to secure the customer commitment. Depending on the client situation, this
can be completed during the meeting or it can be reached in a subsequent meeting with the customers executive sponsor.
ACTIVITY
Back to Top
WORK PRODUCT
Agreed on Envision Engagement Plan
Back to Top
TASK STEPS
1 Determine planning meeting format, agenda and participants. Agenda
Meeting Format
Meeting Objectives
List of Participants

2 Conduct planning meeting.
3 Set forth Communication Plan. Communication Plan
Back to Top
APPROACH
Determine Planning Meeting Format, Agenda and Participants
Determine how you want to validate and agree on the Envision Engagement Plan, dependent on how well-formed the plan has become. This task may be done iteratively
with the Set and Agree on Plan for Envision Engagement (ER.030) when the client is reviewing the plan, and you need to make changes because of the review. In other
cases, you may develop the plan together with the client, and therefore the review process may only be a formality.
Inform the client about the objectives of the meeting, the meeting format, the agenda and the required participants. If you have not yet agreed upon the resources you will
need from the client, then inform up-front what kind of resources will be required so that the client will have the time to find appropriate persons for the tasks.
Conduct Planning Meeting
Perform an initial walkthrough so the customers executive sponsor can have good insight into the process and where you can agree on the work products. When the
walkthrough is complete, gain agreement on the actual resources you need from the client. If a customer project leader has not yet been assigned, look for one who can
work with the Oracle project leader on a daily basis and who will be responsible for the successful execution of the engagement from a customer perspective. Jointly, the
customer project leader and the account team leader are responsible for:
Completion and maintenance of the scope document
Roles and responsibilities assignments
Risks, assumptions, constraints and issues
Resource requirements definitions and resources procurement
Engagement timeline and delivery date determination
Kickoff meeting Plan and Execution
Periodic checkpoints with the joint team
Set Forth Communication Plan
Determine how the communication should be accomplished during the engagement to inform all necessary parties about the engagement. Determine what kind of groups
and persons should be informed, what information should be communicated and in what kind of format.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Along with the project manager, finalize the Envision Engagement Plan including meeting schedules and communication plan. 100
Project Manager Assist with finalizing the Envision Engagement Plan. Obtain sign-off for the plan. *
Back to Top
PREREQUISITES
Prerequisite Usage
Envision Engagement Plan (ER.030) This is the plan which is validated and agreed to in this task.
Back to Top
TECHNIQUES
Technique Comments
The Workshop Techniques Handbook provides detailed descriptions of various techniques for delivering workshops during client
projects.
WORKSHOP_CHECKLISTS.DOC
MS WORD - This file contains several sample workshop checklists that can be tailored for delivering workshops during client
projects.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.070 - DEFINE MODELING STRATEGY FOR THE
ENTERPRISE
This task is used to define the most important models and notation standards (viewpoints) that the enterprise will use. Start by mapping the stakeholders concerns into
viewpoints that then define which models need to be implemented.
Note: For SOA projects or strategy engagements, a complete service modeling notation is available in OUM. Please refer to the Service Modeling technique for more
details.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Modeling Strategy - The Enterprise Modeling Strategy is made up of a Viewpoint Library and a Model Library. A viewpoint specifies which models are
required to answer the concerns of one or several stakeholders. The Viewpoint Library stores the viewpoints used by the enterprise so that they can be reused across
projects. The Model Library stores the various models created by projects so that they can be reused or used as templates for other projects.
Back to Top
TASK STEPS
1 Review the Business Scope
(BA.012) and the Enterprise
Stakeholder Inventory
(BA.015).
None
2 Capture stakeholder
concerns by category.
Stakeholder
Concerns
The Stakeholders Concerns component groups common concerns together and rationalizes them where there are
overlaps. Categories could include Business Value, Risk, Project Status, Software Design, etc. Categories may span
the entire scope of enterprise architecture and project delivery or be limited to a small subset of concerns, such as
those pertaining to a given initiative.
3 Propose models. Proposed
Models List
The Proposed Models List is a list of models by stakeholder concerns. The models represent a way to communicate
information to address those concerns.
4 Sort by model and formulate
viewpoints.
Candidate
Viewpoints
The Candidate Viewpoints is a suggested list of viewpoints to be developed to support the stakeholders concerns.
5 Formalize viewpoints. Viewpoint
Library
The Viewpoint Library Component contains information about each suggested viewpoint.
6 Define detailed model
specifications.
Model
Library
The Model Library contains information on each model, including the purpose of each model, for which stakeholders it is
relevant, how each model will be created, what notations should be used, what elements to include, etc.
7 Construct sample models. Sample
Models
The Sample Models are examples of the type of models in the Model Library.
Back to Top
APPROACH
Note: Review the definitions of the terms: viewpoint, architectural view, model and concern in the OUM Terms before executing this task.
This task may be executed either using a strategic approach or a tactical approach.
Taking a strategic approach to viewpoint definition, allows an organization to pre-populate their viewpoint library based on past project work. This has the strategic
advantage that upcoming projects will benefit from having a number of viewpoints on which to base their modeling efforts.
If an organization wants to take the tactical approach and thereby does not wish to devote this up front time to pre-populating their viewpoint library, then they will
have to develop ad hoc views for their projects to satisfy their current project need and at a later date consider whether a generalized form of the implicit viewpoint
should be defined explicitly and saved in the viewpoint library, so that it can be reused.
Viewpoint identification and definition is a challenging and subjective activity that requires a consistent approach. Otherwise, an organization will encounter viewpoint
sprawl whereby few projects will actually reuse the viewpoints available. This is very similar to the challenges that organizations commonly face for any type of reuse.
It is important to understand the benefits of modeling via a viewpoint approach compared to letting the architect develop the individual models. Here are some of the key
benefits:
Address Complexity and Scalability - A viewpoint approach allows the architect to break down a complex system into manageable models.
Improve Comprehension - Viewpoints are the vehicle for forming a modeling standard that enables better communication and comprehension between
stakeholders and minimizes the risk of misunderstanding the intent of a model.
Scope and Depth of the Models are Controlled - The only model elements added are the ones needed to address the stakeholder concerns. This is very
different in ad hoc modeling when the architect does not know when to stop or ignore elements that the stakeholders felt were not important.
A viewpoint may be considered a template or formal how-to for describing a particular aspect of the system (i.e., a view). This viewpoint is jointly defined and/or selected
in an iterative process by the architect and stakeholder together.
What are the relevant viewpoints depends on the enterprise, the domain, the stakeholders and the specific project goals and challenges. Models can serve many
purposes communication, education, analysis, etc.
The steps below describe the process when a strategic approach is chosen. Using a tactical approach you would start considering the viewpoints at the beginning of the
project (Implement, RD.003). However, if the enterprise has decided to build and maintain an Enterprise Viewpoint Library, the project should fee back their views to the
enterprise (Implement, RD.160), independently from the chosen approach: strategic or tactical.
Using the strategic approach, the first step is to identify viewpoints that address the concerns of the stakeholders identified in Enterprise Stakeholder Inventory (BA.015).
This approach should also attempt to benefit from modeling efforts from previous projects and experience of those involved in project delivery.
Review the Business Scope Definition and the Stakeholder Inventory
Review the Business Scope (BA.012) to see what kind of models and viewpoints may be the most relevant to detail the requirements within that scope. Review the
Enterprise Stakeholder Inventory (BA.015) to determine what kind of stakeholders will be involved in the various project tasks, and use that as an input to determine what
kind of models would be most feasible to use.
Capture Stakeholder Concerns by Category
Starting with the Enterprise Stakeholder Inventory, identify the different types of concerns that stakeholders have. The intention is to group common concerns together
and rationalize them where there are overlaps. Categories could include topics such as Business Value, Risk, Project Status, Software Design, etc. Categories may span
the entire scope of enterprise architecture and project delivery or be limited to a small subset of concerns, such as those pertaining to a given initiative.
An example Stakeholder Concerns (by categories) applied to an SOA initiative is shown below.
Propose Models
Once the concerns have been captured and categorized, a list of models is added. The models represent a way to communicate information to address the concerns. At
this point, you are only identifying types of models. Later, you will get into more specifics about the models. The intent is to keep the discussion moving at a high level in
order to avoid getting bogged down in technical details. On the other hand, to make it more real for all the people present, it usually helps to show some possible
examples, either drawn on a drawing board or some previous models from the enterprise. Just ensure people understand the examples are only here to give them a feel
of what we are looking for and not prescriptive: they can be detailed and modified in the next step.
If you have a number of models from past projects, review the type of models that have been produced to reflect what kind of stakeholder concerns they have and
consider reuse.
The following table lists typical model attributes.
Model Attribute Description
Name Unique name for the model
Description High-level description of the model
Level of Detail Examples include Overview, Intermediate and Detailed
Elements Description of the elements in the model
Notation(s) Approved notations that the model can be built with, i.e., UML, BPMN, etc.
Language Any specific language to which the model has to conform, e.g., UML and OCL
Modeling Techniques Any modeling techniques, patterns or analytical methods to be used in "constructing" and "validating" the model
Presentation Techniques Layout guidelines, for instance important actors in the center of the model while customers at the top
Tools List of approved tools to build the model (if any)
In some cases, a single model can address multiple concerns, while in other cases, it takes more than one model for a single concern. The example below shows a
Models column added to the previous Stakeholder Concerns example:
.
SAMPLE CATEGORIES OF CONCERNS
There may be cases where a model cannot be identified to address a specific concern. Those cases can be skipped over on this initial pass and handled later. The most
important concerns to address are those pertaining to the current IT initiative at hand that this modeling engagement is primarily meant to address.
The models may be described in ordinary modeling terms, such as Class Diagram, Use Case, etc., and may include a level of detail designation, such as Overview,
Intermediate, and Detailed. This step will identify business and technical models and therefore involve practitioners from both business and technical backgrounds. The
workshops to identify the models may not necessarily address both business and technical models at the same time so each may be lead by someone in the appropriate
stream.
Sort by Model and Formulate Viewpoints
Since concerns have been grouped by categories, the models should tend to group together as well. However, there will be cases where models address multiple
categories that are spaced apart in the spreadsheet. An easy way to rectify this is to sort the spreadsheet by the model column. This helps to group common models
together.
Once the Stakeholder Concerns are sorted by model, the concerns categories are no longer the primary focus. They will be replaced by viewpoint names that are more
aligned with the models. The reason for doing this is to make the viewpoints more granular and focused, which makes them more shareable and reusable. A stakeholder
can now map to one or more viewpoints, each of which addresses one or more concerns that might be shared by multiple stakeholders.
Viewpoints can further be organized into two groups: Enterprise-Level (or Program-Level) and Project-Level. Enterprise-Level Viewpoints pertain to concerns that span
multiple projects and portfolios, such as enterprise architecture and Enterprise-Level Roadmap. Project-Level Viewpoints address concerns of a single project, such as
data model and project management. Examples of these are shown below.
ENTERPRISE-LEVEL VIEWPOINTS EXAMPLE
PROJECT-LEVEL VIEWPOINTS EXAMPLE
Formalize Viewpoints
The final step is to formalize these viewpoints into a Viewpoint Library. The attributes of each viewpoint should be defined and captured. The following are the
recommended data elements that should be captured for a viewpoint:
Name
Description
Classification or Grouping
Concerns / Needs
Typical Stakeholder(s)
Rationale
Version
Revision History
Owner
Source
Status
Relationships with other viewpoints
Model(s)
Model Relationships
During the viewpoint definition and identification, a pragmatic and consistent viewpoint classification scheme is required to assist the architect in deciding which viewpoints
address the needs of the stakeholders. A viewpoint classification scheme assists architects and others in finding suitable viewpoints given their task at hand, i.e., the
purpose that a view must serve and the content it should display. With the help of this classification scheme, it is easier to find typical viewpoints that might be of help in a
given situation.
A viewpoint classification scheme gives a quick visual depiction of what a viewpoint addresses. This assists an architect in discovering what areas and concerns a
viewpoint addresses. A viewpoint classification becomes more important as a viewpoint library grows.
Define Detailed Model Specifications
Drive out the details of the models identified in the previous steps. It is purely a technical step with a strong emphasis on modeling techniques, standards, and tools.
One output from the previous steps is a list of models that are needed in order to address the concerns of key stakeholders. Though the models were identified, they were
not defined to a level of detail that would ensure consistency. This step and the following build on the previous steps by adding all the necessary detail.
Start with a workshop to define and capture detailed modeling specifications. For each model identified, the group will consider aspects such as how the models will be
created, what notations to use, what elements to include, etc. Essentially this activity is meant to capture information to complete the Model Attributes Table, which was
started as part of Viewpoint Modeling. The workshop presentation can also include an overview of the engagement and a summary of what has been completed in the
previous phase(s). At the end of the workshop, you should have completed a set of model specifications which will be stored in the Model Library.
Construct Sample Models
Samples provide a good way to visualize the specifications described in the Model Library. In most cases, samples will be available (or easily derived) from previous
work. Other cases may require the creation of a sample model to illustrate the specifications. This step can be achieved by assigning people from the customers
organization the responsibility to provide samples. All samples collected before the Model Library is completed will be included in the document. Samples should be
created using the standard tools approved by the customer. This will help to avoid introducing inconsistencies in notations, color schemes, fonts, etc.
This workshop can be an extension of the previous workshop on model specifications since the delivery team and customer participants will likely be the same. The
output is a set of Sample Models for the Model Library and/or list of people assigned to create or provide samples.
Relationship to Implement
This Envision work product is a prerequisite touch point to an OUM Implement task(s). You should review the corresponding Implement task(s), to determine information
required before the Implement task can begin. The work product produced by this task may become an artifact used by subsequent IT Portfolio Project Implementation
engagements.
Back to Top
Back to Top
Enterprise Architect Define the models and viewpoints to be developed during the engagement. 100
Client Enterprise Architect Assist with defining the models and viewpoints. *
Back to Top
PREREQUISITES
Prerequisite Usage
(ER.020)
Agreed on Envision Engagement
Plan (ER.050)

Business Scope (BA.012) The Business Scope determines the scope of the engagement and provides an input to determine what kind of models would be
most relevant to identify further requirements.
(BA.015)
The Enterprise Stakeholder Inventory for the identified Business Scope determines what kind of stakeholders are involved.
Back to Top
TECHNIQUES
Technique Comments
Service Modeling
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.080 - OBTAIN EXISTING REFERENCE MATERIAL
This task involves gathering all existing reference material or documentation that is related to the projects business objectives or that can be used in the development of
other work products. After reviewing the material, file and catalog any applicable material for future reference. Potential material includes the following:
methods and procedures
standards
guidelines
training material
charts
schedules
forms and reports
screen and report layouts
technical documentation
capacity plans
business plans
strategic plans
project plans
ACTIVITY
Back to Top
WORK PRODUCT
Existing Reference Material - The Existing Reference Material is composed of the actual material itself, and a catalog, organized by subject matter, of the reference
materials. The catalog should include the name or title and the location or source of the material. You might also want to include the following information:
author
date
description
any comments related to the material
Back to Top
TASK STEPS
1 Review the Business Objectives. None
2 Gather, (print or copy) all potential material or
documentation related to the business
objectives.
Existing
Reference
Material
The Existing Reference Material is the actual material itself.
3 Review and identify the related material or
documentation.
None
4 File and catalog the related material or
documentation.
Existing
Reference
Material Catalog
The Existing Reference Material Catalog provides an organization for the material and should
include the name or title of the material as well as the location or source of the material.
Back to Top
APPROACH
Gather, in any available format (print, copy, softcopy, etc.) any reference material. Use the Business Objectives to identify potential information areas. Review the
material. Organize the material in a logical manner (for example, by subject matter) and create a catalog of the material. The catalog should include the name or title and
the location or source of the material. You might also want to include the following information:
author
date
description
any comments related to the material
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Execute discovery of existing client materials and perform assessment of those materials. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Existing Reference Material
This is the material that is reviewed and, if applicable, files and catalog for future reference.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Enterprise Architecture Resources The Enterprise Architecture Resources provides links to additional resources that may be useful in completing this task.
Back to Top
The Existing Reference Material is used in the following ways:
as a reference for the development of work products
Distribute the Existing Reference Material as follows:
to all Envision engagement team members who require access for their assigned work products.
Back to Top
QUALITY CRITERIA
Has the reference material been organized and cataloged?
Are the project team members aware of what existing reference materials is available?
Back to Top
ER.090 - CONDUCT SOLUTION READINESS ASSESSMENT
If you have a specific approach or roadmap in mind, or the enterprise has a specific solution or technology in mind, you assess how ready the enterprise is for it in this
task.
In this task, you look into the enterprise situation in detail, and identify critical success factors for the chosen approach or thought technology and the given enterprise.
You always do this in cooperation with the enterprise, and at the end, present the result to the enterprise.
ACTIVITY
Back to Top
WORK PRODUCT
Solution Readiness Assessment - The Solution Readiness Assessment provides an assessment of various areas of the business in order to identify critical success
factors as well as the organizations readiness for the chosen approach or selected technology.
Back to Top
TASK STEPS
1 Determine
Readiness
Assessment
Approach.
Readiness
Assessment
Approach

2 Perform
readiness
assessment.
Scope and
Purpose
Executive
Summary
Describe the Scope and Purpose of the assessment, include Executive Summary that lists the high level goals discovered during
the assessment.
3 Describe
Findings.
Assessment
Findings
Strategic
Business
Objectives
Business
Issues and
Pain Points
Solution Map
and
Mitigation
Strategies
Summarize the Current Software Environment, Organizational Issues related to Development, Architecture, and other IT
concerns.
List 4-6 main Strategic Business Objectives discovered during the assessment Describe the Business Issues and Pain points that
have been uncovered.
Describe the Business Issues and Pain points faced by the organization. Provide a list of the main Tactical Issues (TI),
Consequential Impacts (CI) and their relationships to the Key Business Requirements (KBR).
Provide possible solution alternatives that would mitigate the Issues and could be used to resolve tactical issues,
thereby enabling the Key Business Requirements to be achieved. List the mitigation strategies for the issues that were
discovered. Describe the Mitigation Strategies in relation to the Key Business Requirements.
4 Interpret
assessment
results.
Critical
Success
Factors
Assessment
Summary
List the Critical Success Factors that will support adoption of the new technology, clear away obstacles to the successful
engagement of the technology by both the IT and the Business Organization.
Provide an Assessment Summary which may include things such as maturity mapping and scoring for the technologies being
considered.
5 Document
assessment
results.
Current
Software
Assets
Organizational
Structure
List or describe the Current Software Assets and Organizational Structure pertinent to this assessment.
#TOP #TOP
6 Prepare for
enterprise
presentation.
Findings
Document
and
Presentation
Prepare Recommendations for the technologies under consideration, detail Recommended Practices, and Current Technology
that could be used to achieve the Key Business Requirements.
In this section, include any findings or information that is pertinent in supporting the assessment results that you want to present
to the enterprise.
Prepare a Presentation where you summarize and describe the information provided in the components above.
7 Present
readiness
findings to
enterprise.

Back to Top
APPROACH
Determine Readiness Assessment Approach
If you decide to perform a readiness assessment, you need to determine how you are going to perform this assessment. If you are following a specific roadmap, some of
these have a predefined approach assessment approach. If the roadmap has one, use the approach as described in the guidelines for the roadmap. If you do not have a
predefined readiness assessment method, consider whether it is appropriate to perform such an assessment in your situation.
In most cases, it is a useful to look at the steps you plan to perform as part of your approach/roadmap, and related to that, identify critical success factors. Determine the
capability areas that are relevant for the specific approach, or technology. Some examples are:
Architecture
Delivery
Governance
Information
Infrastructure
Organization
Process
For each capability area, determine how the organization should be scored through a few questions. For example, for each question, determine five answers/statements
that may fit for an organization, where the answer with the lowest score (usually 1) shows the least fit, while the answer with the highest score (usually 5) shows a
complete readiness related to that capability area and question. Finally, determine how the individual scores should roll up in a total score for the organization.
Perform Readiness Assessment
The enterprise should take an active part in the assessment. Therefore, before starting the assessment, it is important that both you and the enterprise are well prepared,
and that the expectations are set up front. The enterprise must be informed that the assessment is informal and interactive, involving participants from across the
enterprise, and that the assessment is not meant to grade the organization, but to provide guidance on improvement. Try your best to gain access to the right audience,
to find the right blend of executives and informed participants. Keep the focus on the business throughout the exercise (and not only on IT). Use the Initial Influence Map
component of the Enterprise Research Findings (ER.040) as an input to determine who are the best people to participate. Talk to your internal coaches at the enterprise
site.
Rate the enterprise following the pre-defined capability outlined above.
Describe Findings
Document the findings as the assessment progresses. This should include analysis of the current environment and organization structures that helped to identify the key
business objectives and impediments. Discussion of the Key Business Requirements, the tactical issues and impacts that are identified.
Document Assessment Results
Provide details of the critical success factors, and the assessment summary information.
Interpreting Assessment Results
For each individual capability area, answer all the predefined questions to get an individual score for each capability area. Finally, you determine the overall score,
dependent on the result from the individual areas.
When you have answered all the questions and reached a score, you need to interpret that score to see what kind of steps are the most appropriate for your enterprise.
While doing this, you also identify Critical Success Factors.
Prepare Presentation
Start preparing the presentation for the enterprise by producing a document with your findings. Deliver this Findings Document to the enterprise in a presentation. The
better and more complete the results document, the easier it will be to create a solid presentation. Ensure that you invite the appropriate participants to the meeting. Use
the goals of the meeting below to invite the right people.
The Findings Document typically has sections for the following:
Overview of Readiness Assessment methodology employed
High-level overview of the chosen Maturity Model
Enterprise mapped into a specific level of the Maturity Model based on visible criteria
Discussion of implications of the specific level of the Maturity Model
Present Readiness Findings to Enterprise
When you have completed the assessment, present the prepared presentation to the enterprise during a meeting. The goal of the meeting is to:
Share your findings from the assessment.
Interpret the results for the enterprise.
Turn the results into actionable information.
Set the stage for brainstorming and project prioritization.
This step is an opportunity to share with the enterprise the findings vis--vis their maturity with regards to the chosen approach and their current capabilities. It is also an
ideal time to impart some knowledge regarding relative adoption rates in their particular industry and where the enterprise stands in comparison to their
peers/competition.
Back to Top
Enterprise Architect Perform maturity and readiness assessment for the chosen roadmap/approach. 100
Back to Top
PREREQUISITES
Prerequisite Usage
(ER.020)
Use the Envision Engagement Strategy to see what kind of approach is suggested for the enterprise. This is the approach for
which you validate the enterprise's readiness.
Agreed on Envision Engagement
Plan (ER.050)
Use the Agreed on Envision Engagement Plan to view the suggested plan.
Back to Top
TEMPLATES AND TOOLS
ER-090_SOLUTION_READINESS_ASSESSMENT.DOC MS WORD
Back to Top
The Organized Solution Recommendations is used in the following ways:
to determine key enterprise business objectives and requirements prior to consideration of technology solutions
to determine the ability of an organization to apply the possible solutions and recommended practices
Back to Top
QUALITY CRITERIA
Back to Top
ER.100 - DEFINE SUPPLEMENTAL ENTERPRISE
REQUIREMENTS
During this task, you define specific enterprise-level supplemental requirements, for example, for security, flexibility, scalability, availability, or performance. These are
often known as non-functional requirements, i.e., those that address certain characteristics of the architecture that are not actual business functional capabilities. Keep in
mind that the requirements should be on the enterprise level, but the requirements will in most situations feed into projects and at that point, are translated into project-
specific requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Supplemental Enterprise Requirements - The Supplemental Enterprise Requirements document the supplemental (non-functional) requirements that are relevant for
the enterprise. It also documents the business objectives that the requirements support.
Back to Top
TASK STEPS
1 Prepare Supplemental
Enterprise Requirements.
Workshop
Preparation
Notes
This component is the preparation document for the workshop. It includes the goal for the workshop, the schedule,
including the prepared questions, as well as workshop logistics. You may use the checklist provided in the
Approach section below.
2 Conduct Supplemental
Enterprise Requirements
Workshop.
None
3 Conclude Workshop. Workshop Notes This component is the finalized document that documents the result of the workshop.
4 Finalize Supplemental
Enterprise Requirements.
Supplemental
Enterprise
Requirements
The Supplemental Enterprise Requirements is a list of supplemental requirements that are relevant for the
enterprise. Each supplemental requirement references at a minimum one business objective documented in the
Business Strategy.
Back to Top
APPROACH
Obtain the Supplemental Requirements from the client. The input from the clients technical staff will include some specific requirements which are only relevant to the
hardware provider. Some supplemental requirements are related to the use of the software, including security and auditing.
The quality of Supplemental Requirements varies greatly. It is possible that, where such requirements are incomplete, they will need to be elaborated.
An example of a workshop preparation notes checklist is supplied below as the basis for checking the scope of the clients definition of Supplemental Requirements.
Area
Property Description
Critical Volumes and
Timings

Data Volumes Data volumes described in business terms (described in the Business Volumetrics Report, BA.067)
Operation
Frequency
Frequency, days and timings of the operation.
Transaction
Throughput
Transaction levels to be processed in a business cycle.
Business Service
Level Requirements
System
Availability &
The availability expectations, metrics and reporting requirements to meet the business processes.
Reliability
Response Times Response times for critical processes.
Performance
Constraints
Define no. of business units, locations and users catered for. Include peak periods. Define scalability.
Operational
Schedules
Define operational cycles, schedules and output deadlines.
Support
Requirements
Define the support hours / arrangements required to construct the SLA for the business process component.
Data Archiving Define retention period for archiving and retrieving key data (see also Legal and Regulatory Compliance.
Legal and
Regulatory
Compliance
Legal Control Define legal requirements applying to data and systems. This includes retention and non-retention.
Audit
Requirements
Define internal and external audit requirements on access, data content and integrity to manage risks.
Security and Control Access Control Define who does what based on their role.
Data and File
Protection
Define confidentiality requirements for key data fields and files.
Recovery and
Restarts
Define what processes can be restarted / recovered during the processing cycles and what are the conditions.
Internal and
External
Security
Define internal and external security policies that must be met.
Business Continuity Data
Contingency
Scope
Specify the requirements to operate the application to the defined SLR within the enterprise.
System
Recovery Scope
Define disaster tolerance, failover resilience to an alternative site in the case of a disaster recovery being declared at the
primary site. The recovery period to the secondary site should be within an acceptable business risk period.
Business
Continuity
Scope
Define the Business Continuity model to deployed in the absence of the availability of the normal place of work and/or IT
systems.(It is possible that the client has an existing Business Continuity Plan.)
Infrastructure
Requirements
Clients Specify the client requirements to operate the application to the defined SLR within the enterprise.
Servers Specify the client requirements to operate the application to the defined SLR within the enterprise. Include DR requirements.
Network Specify the Network bandwidth and resilience to operate the application to the defined SLR within the enterprise area and
external service provision. Include DR requirements.
Peripherals Define printing and other device requirements.
Web Services Define SLRs covering both internal and external requirement to support the development of the SLA.
Implementation
Constraints
Operating
System
Ensure that the operating system and release is compatible & compliant with the clients approved architecture.
Databases Ensure database are compatible & compliant with the clients approved architecture.
Standards Specify the network bandwidth resilience to operate the application to the defined SLR within the enterprise domain and
external service provision. Include DR requirements.
Interfaces Define interface touch-points and handoffs. Ensure adherence to data interface standards.
Retained System
Dependency
Define connections and dependency on retained systems and data.
Prepare Supplemental Enterprise Requirements Workshop
Review the Business Strategy to see what Business Objectives may be relevant for supplemental requirements. Use this as an input to the workshop preparations to
ensure that the focus will be adequate. Review the domain (BA.050) and process models (BA.040) to identify possible candidate supplemental requirements as a
preparation. Invite both business and technical resources. Prepare the goal for the workshop, the techniques and questions to use. Communicate the goal and agenda up
front to the participants so that they will be able to make necessary preparations.
Conduct Supplemental Enterprise Requirements Workshop
Perform the workshop as planned, and document the results.
You should work with project stakeholders to confirm the Supplemental Requirements and gain agreement as changes can impact implementation project scope.
Conclude Workshop
Finalize workshop documentation, and send back to workshop participants for comments.
Finalize Supplemental Enterprise Requirements
Document the Supplemental Enterprise Requirements based on the workshop results and comments returned from participants. Assess the requirements for consistency
and completeness. This may be against a previously prepared reference set of such requirements.
Whether by workshops or meetings, resolve any issues in the requirements.
engagements.
Back to Top
Enterprise Architect Lead and organize the workshop 50
Solution Architect Participate in the workshop. 50
Client Enterprise Architect Participate in the workshop. *
Client Stakeholders Participate in the workshop and review draft work product. Client participants should be drawn from the appropriate business
and operational areas, e.g., security.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business objectives.
Mandate Matrix (GV.020)
Enterprise Process Model (BA.040)
Enterprise Domain Model (BA.050)
Use these models to identify possible supplemental requirements.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
The Supplemental Enterprise Requirements is used in the following ways:
as the basis for developing the Technology Architecture (EA.130) based on the non-functional business requirements and policies and procedures contained
therein
for inclusion in the consideration of the Applications Architecture (EA.140)
Distribute the Supplemental Enterprise Requirements as follows:
to client staff responsible for the input into work product
to staff responsible for the development of the Technology Architecture (EA.130) and Applications Architecture (EA.140)
to hardware providers
Back to Top
QUALITY CRITERIA
Are the Supplemental Enterprise Requirements complete?
Are the Supplemental Enterprise Requirements consistent?
Back to Top
ER.110 - PERFORM BENEFIT ANALYSIS
During this task, you perform a benefit analysis in one of two situations: either for the identified architectural or process improvement options or for a candidate project as
a whole, which would typically include a set of already analyzed improvement options to be realized through the project. Gain an understanding of and be able to specify
the expected financial and productivity benefits of the suggested options or project as a whole. In many situations, it may be unrealistic to think that there will be sufficient
time to build an in-depth business case; however, in any situation, it is reasonable for the client to obtain a high-level view of the expected benefits of each
recommendation shared in the work product. It is an important to provide a recommendation of a future state that represents the highest benefit to the enterprise.
Ensure that you agree with the client up front on the level of detail of the benefit analysis as the level of effort is dependent of the level of detail.
ACTIVITY
ER.110.1
ER.110.2
Back to Top
WORK PRODUCT
Benefit Analysis - The Benefit Analysis contains for each identified improvement option or for a project as a whole, a list of potential benefits that is expected to be
obtained by realizing the improvement option or through the execution of the project.
Back to Top
TASK STEPS
1 Review the list with improvement
options and determine which
need benefit analysis.
None
2 Perform a high-level benefit
analysis.
High-Level
Benefit
Analysis
This component contains for each improvement option a list of potential benefits that is expected. For each benefit
it should be indicated how the financial impact would be (reduced cost, additional cash-flow), or any other positive
impact there would be.
3 Optionally, perform a detailed
benefit analysis.
Detailed
Benefit
Analysis
The Detailed Benefit Analysis contains more quantitative details about each benefit identified in the high-level
analysis.
4 Create an executive business
case for IT investment justification
Executive
Business
Case
This component should demonstrate quantitative justifications (e.g., ROI, NPV analysis, break-even points, etc.)
for the IT investment. As an alternative, the justification can be more qualitative in nature to justify the
investments (e.g., Competitive Differentiations, Productivity, etc.).
5 Review and validate business
case with LOB executives.
None None
Back to Top
APPROACH
For improvement options, this task is normally done iteratively together with the Future State Risks (ER.120) and MoSCoW Improvement List (ER.130). First an initial
prioritization is done, and then a smaller benefit and risk analysis is done for the highest prioritized options. This analysis is then again used to revisit the priorities. After
that has been done, the Benefit Analysis (ER.110) and Future State Risks (ER.120) are completed for the highest prioritized options. If there are surprises discovered
during that process, the priorities will be revisited again.
At a later point in time when the Candidate Projects (IP.040) have been identified to realize a given set of improvement options, another Benefit Analysis is executed to
determine the expected benefits from the project as a whole. The benefits already identified for the included improvement options would be used as an input, but
additional benefits may be identified.
Review Improvement Options
For Enterprise Architecture improvements you should review the Architectural Gaps and Improvement Options (EA.060) and the Process Improvement Options (BA.090)
to determine which need benefit analysis. Not all improvement options will need benefit analysis. Determine which will need benefit analysis to support the suggested
solution. The benefits identified could also be the enabling of other projects.
For IT Portfolio benefits analysis you should estimate the benefits in some quantitative measure. This should facilitate using the benefits analysis to revise the priorities.
The tactical and consequential pains from the Discovery Map (ER.040) and the goals for each of the Candidate Projects (IP.040) should contain some pointers on the
intended benefits of the projects.
Perform Initial Benefit Analysis
By filtering the musts from the wants in this work package, we will be able to position the benefits within the general constraints of costs, time and capability (or effort).
For example, a project requirement may mandate the implementation of a system by a given time period. To meet the required effort within the timelines, a project
manager would factor multiple resources into their plan and therefore impact costs. From a benefit analysis viewpoint, the same metrics can be used.
Costs
CAPEX (Capital Expenditure)
OPEX (Operational Expenditure) estimated over a depreciation or operational lifecycle. For example, operating solution X might be four times greater than solution
Y because of operational overheads.
Time
Customization, especially at a code level, generally complicates the overall nature of a solution and subsequent changes requires more effort to adapt for new
requirements. Configuration is preferable to customization.
The degree of distribution of components in a solution reflects on the complexity of integration and is impacted by the nature of the connectivity. Foe example, the
benefits of a Service Bus are targeted to improve the decoupling of component capabilities, promote reuse and increase the speed of integration.
Capability or Effort
A unique capability may be a crucial benefit for the business (especially if it improves its competitiveness);
availability may be a key requirement for Security The complexity of most distributed, multi-vendor solutions is often complex to implement and maintain.
efficiency and effectiveness characteristics
Use any tools available to identify and quantify benefits related to each improvement option. For many situations, expected benefits have been quantified through the use
of industry benchmarks, such as customer examples, or customer diagnostic tools. Consider benefits like expense or productivity savings, and revenue improvements,
but also other kind of less quantifiable improvements.
Benefit Analysis
Expected benefits have for many situations been quantified through the use of industry benchmarks, such as customer examples, and customer diagnostic tools
(OneSource is an example), and internally-developed benefits cards. Such Benefits cards fall under four main categories:
Expense savings
Labor productivity savings
Revenue improvements
Other improvements (e.g., compliance)
When combined with assumptions regarding the customers operational and financial benchmarks, the benefit cards can help the team estimate the expected financial
and productivity benefits that the customer could achieve from each recommendation. Review the appropriate sales roadmap for more information.
Perform Detailed Benefit Analysis
Optionally, consider the value of performing a detailed benefit analysis, and discuss the need and usage with the client. Consider the following when you determine to
make a detailed analysis that should be more quantitative:
A business case is mainly a selling tool, but not a silver bullet. However, keep in mind that the tool may also be a selling tool internally for the client.
A business case is not a substitute for the business pain that normally motivates change.
The business may not make a decision to change, even with a compelling business case. If the business stakeholders are not convinced with the high-level
analysis, it is not that likely the stakeholders will be convinced after a detailed analysis.
The business case has to be done for someone who will understand and care. Do not spend the effort if you get the feeling the business isn't interested in utilizing
this information.
Create Executive Business Case
This component should demonstrate quantitative justifications, and be stated as an executive summary. In some cases, the component may be more qualitative, and state
the business reasons/benefits that justify the improvements being proposed. In any case, it should be stated as an executive summary, and provide supporting materials
as needed.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Create the business case and the associated justification using data and projections from the LOB management. Work with the
client to perform the benefits analysis.
100
Client Enterprise Architect Provide information in order to estimate benefits. *
Client Project Manager Provide Project metrics, e.g., resources, in order to estimate benefits. *
Client Stakeholders Provide business metrics in order to estimate benefits. *
Back to Top
PREREQUISITES
Prerequisite Usage
Architectural Gaps and Improvement Options (EA.060) The benefit analysis is performed on the improvement options identified in this work product.
Process Improvement Options (BA.090) The benefit analysis is performed on the process improvement options identified in this work product.
MoSCoW Improvement List (ER.130) Use this list to prioritize the benefit analysis.
Candidate Projects (IP.040) The benefit analysis is performed on the Candidate Projects identified in this work product.
Prioritized Projects (IP.050) Use this list to prioritize the Candidate Projects benefit analysis.
Back to Top
TEMPLATES AND TOOLS
ER-110_BENEFIT_ANALYSIS.DOC MS WORD
Tool Comments
Overview
task.
Back to Top
The estimated benefits should be discussed with key stakeholders for verification. The benefits analysis should be used as input for preparing a business case for each
project. Later on the benefits are typically included in a combined solution and roadmap presentation to the stakeholders that combines material from several work
products. The benefits of a candidate project to key stakeholders must be communicated very clearly to gain support and commitment.
Back to Top
QUALITY CRITERIA
Are all benefits linked to one or more key stakeholders?
Are the benefits measurable?
Do all proposed projects have a positive business case?
Back to Top
ER.120 - IDENTIFY AND MITIGATE FUTURE STATE RISKS
During this task, you identify possible technology and business risks related to the future state you are assessing. This may be a list of identified architectural
improvement options or a list of candidate projects identified to realize the future state. It is important to provide a recommendation of a future state that represents the
lowest risk path to a lower cost infrastructure that improves the ability of IT to support the key business and technical requirements. Typically, you would first identify risks
related to a number of identified improvement options that then depending on the result of the risk and benefit analysis (ER.110) will be included in a number of candidate
projects to realize those improvement options. Second, you would perform a risk analysis for those candidate projects.
ACTIVITY
ER.120.1
ER.120.2
ME.ACT.ME Maintain and Evolve
Back to Top
WORK PRODUCT
Future State Risks - The Future State Risks contain for a predefined future state a list of potential risks for the enterprise as a result of implementing the future state. This
may be risks related to a given set of architectural or process improvement options, prior to the definition of any projects to realize the future state, or may be risks for
potential candidate projects to be executed to implement the future state. It also consist of a list with possible actions how to mitigate the identified risks.
Back to Top
TASK STEPS
1 Review the list of improvement options or
candidate projects and determine which
need risk analysis.
None
2 Perform risk analysis. Risks
For Enterprise Architecture, this component lists, per improvement option identified, risks that may be
relevant when implementing the option. It indicates the likeliness of whether the risk may occur, and
the impact if the risk occurs.
For IT Portfolio risks, this component lists, per program and project in the IT Portfolio, identified risks
that may be relevant when executing the programs/projects. It indicates the likeliness of whether the
risk may occur, and the impact if the risk occurs.
3 Identify risk mitigation options. Risk Mitigation
Options
This component lists a number of possible risk mitigation options for each risk identified.
4 Determine risk mitigation frequency. Risk Mitigation
Review Strategy

5 Update Risk Analysis and Risk
Mitigation.
Updated Risks
and Risk
Mitigation
Options
These are the updated components from step 2 and 3 above. Throughout the implementation lifecycle
new risks may be identified. If so, this is added to the risk analysis document, including risk mitigation
options.
Back to Top
APPROACH
The task is normally done iteratively together with the Benefit Analysis (ER.110) and MoSCoW Improvement List (ER.130) or the Prioritized Projects (IP.050). First, an
initial prioritization is done, and then an initial benefit and risk analysis is done for the highest prioritized options or projects. This analysis is then again used to revisit the
priorities. After that has been done, the Benefit Analysis (ER.110) and Future State Risks (ER.120) are completed for the highest prioritized options or projects. If there
are surprises discovered during that process, the priorities will be revisited again.
Review Improvement Options or Candidate Projects
Review the Architectural Gaps and Improvement Options (EA.060) and determine which need risk analysis. Not all improvement options will need risk analysis. Determine
which will need risk analysis to support the suggested solution. You might have done an initial prioritization between the improvement options (ER.130), and if so, you
would typically select from the highest prioritized improvement options.
For candidate projects, start with the highest Prioritized Projects (IP.050).
Perform Risk Analysis
For Enterprise Architecture or process improvements, you should perform an initial risk analysis for the improvement options you selected. You should search to identify
the largest risks at the enterprise level. What are the enterprise-level risks if you implement the improvement option at hand, and what are the enterprise-level risks if it is
NOT done? The latter may in some cases be the largest. Consider dependencies between improvement options, or other type of dependencies.
For IT Portfolio Analysis, perform an initial risk analysis to determine if the initial project priorities (IP.050) are correct. Perform the initial risk analysis for all the highest
prioritized projects using the list of Prioritized Projects (IP.050). You should search to identify the largest risks at the enterprise level. What are the enterprise level risks if
the project is done, and what are the enterprise level risks if it is NOT done? The latter may in some cases even be the largest. Consider dependencies between the
project and other projects, systems, or other type of dependencies. Also, be aware that there may be risks to consider that cross multiple projects. This may impact
priorities and therefore it is important that these are identified as early as possible.
When the priorities for the projects have been determined, extend the initial risk analysis to a more thorough analysis. Initially, only consider the highest prioritized
projects; however, you may decide to do more. Again, focus on the enterprise-level risks that may impact which items should be in the portfolio, and the order in which
they should be performed. Identify the major project risks (at a project level), but do not go into too low-level project risks. This should be done as part of the project
preparations.
Identify Risk Mitigation Options
For each risk, identify how the risk best can be mitigated.
Determine Risk Mitigation Frequency
On a regular basis, when projects have started, you should perform a review of the project to ensure that the risks are properly mitigated. Determine the frequency on
which to perform such a review and how to select projects to review. Typically, perform reviews more frequently on high-risk projects and projects that might set a
standard for future projects as opposed to low-risk projects.
For individual improvement options that are being implemented through one or more projects, determine the review frequency to ensure that the risks are properly
mitigated. Normally this is done as part of the project risk mitigation, but for some improvement options, you may want to adopt a tighter and more frequent risk mitigation
process.
Update Risk Analysis and Risk Mitigation
Update the components of the work product as necessary. This is an ongoing process that should happen periodically throughout the enterprise lifecycle based on the
determined risk mitigation frequency determined in the step above.
You should review the status of the risks, whether any new risks have been identified, whether there are any changes in the likeliness of the risks, and how the risk
mitigation works. If the risk has become too high for a given project, this may result in the project being put on hold, or even cancelled.
Back to Top
Back to Top
Enterprise Architect Identify risks and develop risk mitigation strategies for selected improvement options. 100
Client Enterprise Architect Assist the enterprise architect. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) The Business Strategy helps to identify the business related risks that might impact the IT Project Portfolio.
Architectural Gaps and Improvement
Options (EA.060)
The risk analysis is performed on the improvement options identified in this work product.
Process Improvement Options (BA.090) The risk analysis is performed on the process improvement options identified in this work product.
MoSCoW Improvement List (ER.130) Use this list to prioritize the risk analysis. Identify possible new risks for the MoSCoW Improvement List elements and
perform a continuous risk mitigation.
Candidate Projects (IP.040) The risk analysis is performed on the Candidate Projects identified in this work product.
Prioritized Projects (IP.050) Use this list to prioritize the Candidate Projects risk analysis.
Back to Top
TEMPLATES AND TOOLS
ER-120_FUTURE_STATE_RISKS.DOC MS WORD
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.130 - PRODUCE MOSCOW IMPROVEMENT LIST
During this task, you review all the identified improvement options (both architectural and process improvement options) and the discovered high-level use cases to
determine which should be included for further investigation and how they should be prioritized. This is an ongoing task as the priorities will change and additional
improvement options may be added throughout the lifecycle depending on the changes in the enterprise priorities and strategies. The priorities given should align with the
business objectives and motivation outlined in the Business Strategy (BA.010).
ACTIVITY
ER.130.1
ER.130.2
Back to Top
WORK PRODUCT
MoSCoW Improvement List - The MoSCoW Improvement List is a list with both architectural and process improvement options, and identified high-level use cases.
Each element is shown with a priority that represents the importance of implementing the element within the given timeframe of the MoSCoW List. The priorities are Must
Have, Should Have, Could Have or Won't Have, defined as follows:
Must Have - The Must Have elements are those that have been decided they are vital to the business, and should be implemented as soon as possible, and within
the timeframe defined for this MoSCoW list.
Should Have - The Should Have elements are those that are important and very desired to be implemented within the given timeframe. Each Should Have
element has been subprioritized to indicate which are the most important elements to implement first, after the Must Have projects have been executed.
Could Have - The Could Have elements are not important projects at this point of time. They are either "nice-to-have's" or not time-critical, but may become more
important at a later point in time. It is unlikely that they will be implemented within the given timeframe, but if there is a chance you should sub-prioritize these as
you did for the Should Haves.
Won't Have - The Won't Have elements are those that it has been decided it should not be performed at all within the given timeframe.
Back to Top
TASK STEPS
1 Determine relative
importance between the
elements that should be
prioritized.
None
2 Determine the timeline for
the MoSCoW Improvement
List.
MoSCoW
Improvement
List
The MoSCoW Improvement List shows the timeframe for which the MoSCoW list should be valid, and all the
improvements that possibly should be implemented within a given timeframe. Each improvement is shown with a
priority, Must Have, Should Have, Could Have and Won't Have. This step provides the timeline.
3 Determine the MoSCoW
Improvement List.
MoSCoW
Improvement
List
The MoSCoW Improvement List shows the timeframe for which the MoSCoW list should be valid, and all the
improvements that possibly should be implemented within a given timeframe. Each improvement is shown with a
priority, Must Have, Should Have, Could Have and Won't Have. This step provides the list of projects with their
priorities.
4 Update repository. Updated
Enterprise
Repository
The priorities are added to the relevant repository items.
Back to Top
APPROACH
The task is normally done iteratively together with the architectural Benefit Analysis (ER.110) and architectural Future State Risks (ER.120). First, an initial prioritization is
done, and then a smaller benefit and risk analysis is done for the highest prioritized options. This analysis is then again used to revisit the priorities. After that has been
done, the architectural Benefit Analysis (ER.110) and architectural Future State Risks (ER.120) are completed for the highest prioritized options. If there are surprises
discovered during that process, the priorities will be revisited again.
If enterprise function modeling or enterprise process modeling (BA.040) has been carried out, it is possible to prioritize business processes or functions using a scoring
system.
See the Process Prioritization technique for more details on using a scoring system.
If an enterprise repository is in place, business objectives can be managed as requirements with enterprise scope allowing to manage relationship to models, projects
and even implementations. In that case, the elements that need to go into the MoSCoW List can be extracted from the repository.
Determine Relative Importance Between Elements
Determine the relative importance between the elements that should be prioritized. For some elements, it may not be easy to determine a good mechanism to quantify the
importance. This should however have been done as part of the architectural Benefit Analysis (ER.110) and should be used as an input to determine the relative
importance between the elements at hand. Various techniques can be used to determine the relative importance between the elements, but you need to review the
Business Strategy (BA.010), the objectives and goals as a whole, and the identified benefits and risks for each option specifically. The chosen technique also depends on
how many should be prioritized. If the list is short, you should be able to decide by discussing through each option. Either way, it is often useful to gather the stakeholders
and decision makers in a workshop to make the process as efficient as possible.
Determine the Timeline for the MoSCoW Improvement List
You need to determine for how long into the future the MoSCoW Improvement List is valid. This does not mean that you will not be able to change the priorities within this
period, but it should indicate the period in which the priorities are given, as some options may be more important in one time span than another. The assumption is for
this MoSCoW Improvement List that all Must Have elements should be completed within the given time span.
Determine MoSCoW Improvement List
When you have identified the relative importance between the improvement options, and the timeline for the MoSCoW Improvement List, determine where the line goes
between the Must Have options and the Should Have options.
Indicate which options you must have completed before the given timeline ends. These options should be vital or very important to reach the business objectives defined
in the Business Strategy (BA.010) within the given timeframe. It is very unlikely that this will change unless the enterprise strategy changes. Having done this, all these
options that you have identified should be classified as Must Haves.
Then, identify those that also are important, but not as vital to the business. Classify these as Should Haves, and keep the individual relative importance as an indicator to
show which of the Should Haves are the most important. If there are any options left, then either classify them as Could Haves, or determine that they are not desired and
therefore become Wont Haves.
If an enterprise repository is used to manage business objectives, e.g., in the form of enterprise scoped requirements, update the repository by adding possible missing
objectives / requirements or updating the prioritization of an already registered requirement.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Provide advice and guidance to the client to enable them to prioritize the list of options within the timeline for improvements. 100
Client Enterprise Architect Prioritize the list of options and combine actions into IT projects. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010)
Benefit Analysis (ER.110)
Future State Risks (ER.120)
Use these work products to determine the correct priorities.
High-Level Use Cases
(BA.060)
Process Improvement
Options (BA.090)
Architectural Gaps and
Improvement Options
(EA.060)
Governance Policies
Catalog (GV.030)
These work products contain the elements to be prioritized.
Governance Implementation
(GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to
govern the enterprise requirements. In addition, ensure that the enterprise requirements are added/updated in the repository.
Back to Top
TECHNIQUES
Technique Comments
Process Prioritization
If Enterprise Functional Modeling or Enterprise Process Modeling (BA.040) has been carried out, it is possible to prioritize business
processes or functions using a scoring system defined in this technique.
Management
This technique provides assistance on how to manage requirements at the enterprise level.
Prioritization Use this technique to determine the relative priorities of various concerns.
Back to Top
TEMPLATES AND TOOLS
ER-130_MOSCOW_IMPROVEMENT_LIST.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.
Overview
Back to Top
The MoSCoW Improvement List is used in the following ways"
as detailed requirements are introduced during the engagement, they must be related to at least one of the requirements in the high-level baseline (If they cannot
be related to the baseline, they are out-of-scope, but may be placed in the Won't Have category.)
Distribute the MoSCoW List as follows:
to all project team members
to the visionary, project sponsor and other steering committee members
Back to Top
QUALITY CRITERIA
Have all of the currently identified improvement options been prioritized?
Have all the improvement options been assigned in collaboration with the stakeholders?
Are all the Must Have improvement options truly part of the minimal usable subset to meet the business objectives? (That is, if you remove just a single one of the
Must Have improvement options, the business objectives cannot be delivered.)
Back to Top
ER.140 - SHARE PRODUCT STRATEGIES WITH ENTERPRISE
During this task, you share information with the enterprise about the implementing organization's products, and strategies (for example, Oracle's). In many cases, it is of
interest to the enterprise to understand the direction of the implementing organization, and therefore it is valuable to formally share product direction and status with the
enterprise. There might also be specific products, or product suites that the enterprise does not know about, but that may be interesting to the enterprise. Share this
information with the enterprise using information or demo sessions. Typically, you may want to share the strategies in the following scenarios:
The current situation is highly competitive and product information is critical in retaining the enterprise and showing them our future.
The enterprise specifically requests information about product strategy and status.
The account team and/or the Envision team believe information sharing is required to improve enterprise satisfaction or build confidence in the implementing
organization.
The account team decides to showcase product direction during this phase to properly position our recommendations in the final work product.
Evaluate what kind of specific needs there may be at the client, and determine what and when you plan to share this with the enterprise.
ACTIVITY
INIT.ACT.EDF Execute Discovery - Finish
Back to Top
WORK PRODUCT
Informed Enterprise - The Informed Enterprise understands the implementing organizations products and strategies.
Back to Top
TASK STEPS
1 Review Improvement Options and Client Situation. Improvement Options
Enterprise Situation

2 Prepare Enterprise Presentation. Product Strategy Presentation
3 Conduct Enterprise Presentation.
Back to Top
APPROACH
Review Improvement Options and Client Situation
Review the MoSCoW Improvement List (ER.130) to determine what is most relevant for the enterprise and where to put the most focus during the Product Strategy
Presentation. This task should be done repeatedly as part of the implementing team's relationship with the enterprise. Also consider the enterprise situation on a regular
basis to verify whether new products or strategies may have become relevant for the enterprise.
Prepare Enterprise Presentation
Prepare the Product Strategy Presentation. Determine who are the relevant participants from the enterprise. The timing of the presentation is important. If it is delivered
too early in the process, the enterprise may focus on developing solutions to their problems instead of allowing the team to gather information effectively. Therefore, it is
recommended to hold off on the presentation until after the Gather Information and Brainstorm, Prioritize and Discover Entry Points activities have been performed.
Ensure the right level of detail for the information. Organizations are rarely impressed with high level marketing claims, yet presentations that are too technical may not be
appropriate. More technical presentations or technical demos may be suitable as follow ups, with a different kind of audience, if the client is interested. Use the
information that already has been gathered about the enterprise to determine the level of detail and the right amount of information required.
Match the presentation with the audience. If you are speaking to enterprise executives and line of business leaders, minimize the jargon and technical terms, while
focusing on the value and benefits of the implementing organization's solutions. If you have a technical breakout session, bit-level conversation may be fine, but do not
underestimate how much IT people care about the value to the business of our solutions.
Conduct Enterprise Presentation
Ensure the duration of the presentation is appropriate - given the small amount of time you have in front of the enterprise, the majority of the time should be spent
listening to them and drilling in for more details. Sharing an information presentation with the enterprise should be used to highlight current enterprise challenges
wherever possible. For example, an overview of a product or solution may spark enterprise conversation over existing initiatives where we may be able to help.
Back to Top
Enterprise Architect Discuss product areas of interest with client stakeholders. 30
Solution Architect(s) Provide roadmap and strategy information on products within their domain of expertise. 70
Client Enterprise Architect Provide assistance, as appropriate. *
Client Stakeholders Participate in discussions. *
Back to Top
PREREQUISITES
Prerequisite Usage
MoSCoW Improvement List (ER.130) Review the prioritized MoSCoW List to determine what is most relevant to share with the enterprise.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.150 - REVIEW DISCOVERY FINDINGS
During this task, you take a step back, and together with the customer review all the findings and improvement options defined up to this point to determine how to
proceed further. The task covers reviewing the overall business strategy, the business process models, the domain models and the high-level use cases being targeted
for improvement. The result of this review may trigger another iteration of information gathering, or identification of additional/alternative improvement options. Do these
reviews and findings should also provide the customer a sense of comfort and ownership in the solution development process, which can be useful when presenting to
the high-level executives in the solution presentation activity.
ACTIVITY
INIT.ACT.EDF Execute Discovery - Finish
Back to Top
WORK PRODUCT
Reviewed Discovery Findings - The Reviewed Discovery Findings is a list of all findings relevant for further solution development, including any relevant comments that
may be of importance for further preparations.
Back to Top
TASK STEPS
No.
Task
Step
Component Component Description
1 Plan for
review.
Findings List The Findings List is a list with all findings up until this point in time that are seen to be possibly relevant for further solution development.
This list is used as an input for the review, and are the elements under review. Always include an "Other" section to allow for possible non-
identified areas can come up during the review.
2 Perform
review.
None
3 Process
review
results.
Review
Results
The Review Results is the Findings List prepared in step 1, including the review comments for each item.
Back to Top
APPROACH
Review the Process Improvement options and the Architectural Improvement Options, you should consider projects in the IT Portfolio that have already been prioritized
within the Enterprise, in conjunction with the Findings List. This will give a preliminary assessment of priorities and assist in making sure the Findings List is
comprehensive.
If more information is required you may need to go back to the Process Improvement Options or Architectural Gaps and Improvement Options tasks and further detail the
findings.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Compile the work product and deliver the findings. 90
Sales Manager Factor in concerns and constraints into the outcomes of the recommendations made after the overview. 10
Client Project Sponsor Provide general business and IT concerns, strategies and constraints. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Function or Process Model (BA.040)
High-Level Use Cases (BA.060)
These work products are being reviewed.
Process Improvement Options (BA.090)
Architectural Gaps and Improvement Options (EA.060)
Used to summarize findings, and prepare for alternatives, or additional fact finding.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.160 - DEVELOP DESIRED FUTURE STATE
During this task, you define the desired future state. This task does not address architecture, but a desired future situation.
ACTIVITY
Back to Top
WORK PRODUCT
Desired Future State - The Desired Future State summarizes into an overview recommendations for the following:
improvement options for business processes
high-level use cases
process improvement
architecture improvement
Back to Top
TASK STEPS
1 Compile findings of Current state
and summarize them
Current
State
Provide a summary of the other work products prepared to document the current state of the enterprise, in
consideration of the existing business strategies, constraints, technologies, IT Portfolio Projects, and other work
products that may have been prepared as part of the Envision engagement.
2 Document recommendations for
the desired future
Documented
Future
State
Document recommendations for the desired future state based on the work products that were produced as part of
the Envision engagement.
3 Provide an overview of key
business drivers that support the
move to the future state
Business
Objectives
Document business impetus to change.
Back to Top
APPROACH
This task involves putting together the findings of the Envision engagement in preparation for the Future State Transition Plan (BA.097).
During this task, you work within the Envision team to pull together the findings and possible improvement options. Organize the materials so that the Business Objectives
and opportunities for business process improvement are highlighted. Provide information on how architectural changes or technology changes will support the business
move to the future state.
Work together with key stakeholders to prepare the summary of this information. This will be used as input to the Future State Transition Plan.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Prepare the information in a cohesive overview using the work products that were previously prepared. Summarize the future
state. Prepare a summary of how the architecture will support the desired future state.
50
Solution Architect Provide information about the components described in the future state overview 50
Client Solution Architect Provide assistance, as appropriate. *
Back to Top
PREREQUISITES
Prerequisite Usage
(BA.040)
The Enterprise Process Model is used to prepare a picture and description of proposed enhancements to business
processes.
High-Level Use Cases (BA.060) High-Level Use Cases are used to prepare a picture and description of the future business.
Process Improvement Options (BA.090) Process Improvement Options are used to reflect which option the Key stakeholders prefer, and can be
recommended to the business.
Architectural Gaps and Improvement Options
(EA.060)
Architectural Gaps and Improvement Options should also be considered during preparation of the desired future
state
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.165 - IDENTIFY CAPABILITY CHALLENGES
The purpose of this task is to identify constraints and gaps in the current situation for a given capability in order to meet the defined future state objectives and
requirements. The results of this task also provide a list of current pains that need to be addressed in the design of a desired future state.
During this task, you review the current situation, and identify the current deficiencies or working constraints related to that situation. In most situations, this view is on the
enterprise level, but the scope engagement might also be limited to a part of the enterprise. Ensure that your effort is in line with the given scope. Also, the scope may be
enterprise wide, but limited to a specific aspect of the business, or a specific aspect of the architecture. For example, it may be limited to a few business processes, or it
may be limited to map the architectural aspects related to data structures, or only to cover security aspects of the architecture.
ACTIVITY
Back to Top
WORK PRODUCT
Current Capability Challenges - The Current Capability Challenges contain a list of problem areas with which the enterprise is faced including the impact of each
challenge on the organization or the infrastructure/application(s)/services used in the enterprise.
Back to Top
TASK STEPS
1 Identify problem domains. Problem
Domains
This component includes the areas (domains) with the largest capability challenges, and therefore, the domains
that will be investigated further.
2 Identify outlier capabilities Outlier
Capabilities
This component describes the capabilities where there is a significant gap between how different parts of the
enterprise (projects, programs, division, cross division, enterprise) perform against the capabilities.
3 Identify lagging capabilities Lagging
Capabilities
The Lagging Capabilities component identifies any outlier capabilities well below the other parts of the
organization. These are capabilities that are done poorly and are candidates for corrective action.
4 Prepare for meeting or workshop. None
5 Walk through current architectural
situation and identify challenge
areas.
None
6 Conclude meeting or workshop and
isolate challenges.
Architectural
Challenges
The Architectural Challenges component is a list of architectural problem areas for the organization. In this step,
the initial list from step 2 is expanded to include the impact of each challenge on personnel or application(s).
Back to Top
APPROACH
Identify Problem Domains
The first step you do is to identify the domains that exhibit the largest challenges related to the capability you are investigating. Depending on the kind of capability you are
investigating, you may have executed a maturity assessment (ER.015). Comparing this with the customers future vision (ER.160) allows you to find the domains where
there are gaps between the current situation and the customers future vision. All domains where there is a larger gap between the current state and the future vision can
be defined as the problem domains.
The picture below visualizes an example of the gap between the current maturity on a number of domains. We can clearly see that there is a gap for all the domains, but
that there are two problem domains in particular, namely the Projects, Portfolios and Services and the Infrastructure domain.
If you have not performed a current situation analysis or defined a future vision, it is recommended that you do this prior to starting this task, unless you have similar kind
of information available. You will at least need some understanding of the current problems that the customer wants to challenge and what kind of objectives or goals
they have for the area.
Identify Outlier Capabilities
Investigating further the relevant domains, you should attempt to identify the outlier capabilities. These are the capabilities where there are large deviations on maturity
within the organization. Review each capability and investigate how mature parts of the organization are for that capability. For most capabilities, the organization has the
same maturity across projects, programs, divisions and so on.
There is a deviations in capability if there is one area of the organization that either has a significant higher or lower maturity than the other parts of the organization. The
picture below visualizes the result of such an analysis:
When you look at the Project Level, we can see that most of the investigated projects are at the ad-hoc level for all the capacities under investigation. However, there is
one project that shows a significant higher maturity for the Architecture capability. At the Division Level, we see that most divisions have either a systematic or
opportunistic maturity level for the departments that have been investigated. But again, there is one capability, Infrastructure, which has a significant lower maturity than
in the other levels.
When you do an analysis on the outlier capabilities, the identified capabilities should be investigated further. A capability that for one part of the organization is well above
the others indicates a capability that is done very well within a relatively small area of the organization. In the example above, there is a capability at the Systematic Level
of maturity done within a single project. Fostering greater adoption of this capability may provide an easy win, as there is no need to develop greater competency for this
capability within the organization since it already exists within the organization. Some training or mentoring can spread the ability more broadly within the organization.
An outlier capability well below the other parts of the organization indicates a capability that is done poorly. In the example above, there is a capability being done at a No
SOA Maturity Level across the entire division. Corrective action needs to be taken for this capability since if left uncorrected, it will inhibit (and probably already has
inhibited) the initiative at hand. These types of capabilities are investigated further in the next step.
Identify Lagging Capabilities
The capabilities that are done poorly within the whole or parts of the organization are candidates for further investigation. In the example above, these are the capabilities
that plot nearer the lower left corner in the scatter. However, it is important to point out that not all capabilities are of equal importance for a particular organization. In fact,
there may be capabilities that are deemed unimportant or even not applicable for a particular organization. Thus, it is necessary to review each capability with a low score
and determine whether it is a top priority, a low priority, or unimportant from the perspective of the future vision. If a capability is deemed unimportant for a particular
organization, it should not be considered a lagging capability. If you think a lagging capability is unimportant, you should always confirm that with the organization during
the meeting or workshop.
Prepare for Meeting or Workshop
Set up a meeting or workshop with the relevant participants from the organization to go through your findings. Prepare questions to verify your findings, and to go further
into detail in areas where more information is required or information is completely missing. The purpose of the meeting/workshop is to verify whether the organization
recognizes themselves in the findings, to identify primary pains that may be the reasons for the problems, and to determine if the situations can be improved with
changes.
Walk Through Current Situation and Identify Challenge Areas
During the meeting or workshop, walk through your findings and ask for feedback. Go through the additional questions you have prepared to complete the picture and to
identify/verify possible pains. Keep in mind, that you still are only gathering information at this stage. Do not be tempted to suggest solutions at this point in time, as you
might not yet have a good enough picture to make the best recommendations.
Conclude Meeting/Workshop
Walk through the results of the meeting and highlight the agreed on relevant challenges for the organization.
Back to Top
BPM Roadmap
Supplemental Guide.
SOA Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Roadmap. Use the
following to access the task-specific supplemental guidance. To access all SOA Roadmap supplemental information, use the SOA Roadmap Supplemental Guide.
Back to Top
Enterprise Architect Conduct capability challenges workshops with client stakeholders 100
Client Enterprise Architect Participate in workshop. Provide assistance, as appropriate. *
Client Stakeholders Participate in workshop. *
Back to Top
PREREQUISITES
Prerequisite Usage
Maturity Analysis and Recommendations Report
(ER.015)
Use the Maturity Analysis and Recommendations Report to determine the problem domains.
Desired Future State (ER.160) If available, use this as an input together with an analysis of the current situation to identify the problem
domains.
IT Project Portfolio (IP.010)
Current Architecture (EA.030)
Review these work products to understand the current situation in which you will identify architectural
challenges.
Use these models to identify possible challenges related to the business.
Supplemental Enterprise Requirements (ER.100) Review these requirements to help identify possible challenges.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Current Capability Challenges is used in the following ways:
as an input to determine what kind of activities are required to achieve the desired future state.
as an input to determine a desired future state
Distribute the Current Capability Challenges as follows:
to the enterprise personnel and resources that are responsible for defining a roadmap or transition plan to achieve the desired future state.
Back to Top
QUALITY CRITERIA
Is the scope of the capability challenges investigation clear, e.g., enterprise wide, departmental, or limited to one or a few capabilities?
Are the challenges well founded/explained?
Have decisions regarding outliers and lagging capabilities been documented thoroughly?
Back to Top
ER.167 - IDENTIFY REMEDIATION APPROACHES
During this task, you investigate current capability challenges and the ways in which it constrains the business, or obstructs the accomplishment of a goal statement.
Review the Current Capacity Challenges (ER.165) and determine possible remedies for improvement. In most situations, this view will be at an enterprise level, but the
scope engagement might also have been limited to a part of the enterprise. Ensure that your effort is in line with the given scope. Also, the scope may be enterprise wide,
but limited to a specific aspect of the business, or a specific aspect of the architecture. For example, it may be limited to a few business processes, or it may be limited to
map the architectural aspects related to data structures, or only to cover security aspects of the architecture.
The type of remediation approach depends on the enterprise situation, the problem domain, and how large the pain. However, you will often see approaches such as
defining necessary strategies, making decisions, and formulating directives, providing consistency across systems, ensuring compatibility between systems, use of
reference architectures, defining a common set of standards, guidelines, approaches and techniques. However, you should not be limited to overall aspects. It could also
be that some of the pains are very specific and related to a single or a few areas but that may result in a suggested overall remediation approach. Focus on identifying
the remediation approaches. After they have been identified, you should prioritize them using the MoSCoW Improvement List (ER.130).
ACTIVITY
Back to Top
WORK PRODUCT
Remediation Approaches - The Remediation Approaches is a list of identified approaches and suggested activities that can be done to improve the situation where there
are problems related to identified areas, or where there are large gaps between the current situation and where the organization wants to be within a given timeframe.
Back to Top
TASK STEPS
1 Review the existing situation. None
2 Review the Current Capabilities
Challenges (ER.165) and determine
possible remediation approaches.
Remediation
Approaches
This component lists possible approaches that may remedy the identified capability challenges. The list
contains a description of the improvement, what it impacts, a reasoning why this should be an
improvement, and a reference to relevant parts of the business strategy.
3 Identify pros and cons for the
approaches.

4 Determine final list of preferred
remediation approaches
Final
Remediation
Approaches
This is the updated list from step 2. During this step, the list is made final.
Back to Top
APPROACH
During this task, you may also consider doing some prototyping in order to determine whether an approach is feasible, or to see whether it covers the challenge it is
attempting to solve. Prototyping may also be done at a later point in time.
Note: This task should involve resources from the organization.
Review the Existing Situation
Review the existing situation related to the area(s) under investigation. You may have defined the current situation using a number of different methods depending on the
type of domain under investigation. You may have executed a customer maturity assessment (ER.015), and based on that defined a number of areas to investigate
further. You may have defined a Current Architecture (EA.030) related to the clients current infrastructure, and can use this as a basis to define any possible missing
pieces relevant to the defined current architecture. You may have created a process or function model of the current situation (BA.040), and can use these to identify
areas of improvement. Regardless of your starting point, you should carefully consider the existing situation in order to enhance your understanding of the current
situation, and therefore improve the quality of the suggested remedies.
Review Current Capability Challenges and Determine Possible Remediation
Approaches
Review the Current Capability Challenges (ER.165) and determine possible remedies related to each of the challenges identified. Review the challenges, and identify
possible remediation activities that will improve the situation. Keep in mind, the existing situation so that the activities will be realistic within a given timeframe. You may
identify multiple alternative remediation activities, but for some areas you may only identify a single solution option. This may be because there is one very obvious
option, or because the organization already has used similar options in other places. Do not spend unnecessary effort trying to find alternative solution options when
there is one obvious one that is expected to work well. However, the fact that the organization may have used a similar approach in the past may not be a reason for
using a similar option again. Ensure that you understand what kind of experience the organization has using that specific option before suggesting using a similar
approach again.
Identify Pros and Cons
For the areas where you have identified multiple alternative remedies, determine the pros and cons for the alternative options you have identified. This should not be a
complete benefit and risk analysis, but should preferably provide sufficient information to be able to choose a preferred alternative.
Determine Preferred Remediation Approaches
For each problem area or challenge, determine a preferred remediation approach by analyzing the pros and cons in the previous step. Describe the suggested
remediation activities and how that should impact the current situation.
Preferably, you should include the organization in this process, as they may immediately see a preferred alternative. If you dont have an organizational resource
available and you are uncertain about what option would be best, present the different alternatives as possible remedies, with their pros and cons, so that the
organization can choose the preferred alternative. When the final decisions regarding the approaches have been made, finalize the report.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
SOA Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Roadmap. Use the
following to access the task-specific supplemental guidance. To access all SOA Roadmap supplemental information, use the SOA Roadmap Supplemental Guide.
Back to Top
Enterprise Architect Along with the client enterprise architect, suggest remediation alternatives and evaluate the pros and cons. 100
Client Enterprise Architect Work with the enterprise architect suggesting remediation alternatives and evaluate the pros and cons. *
Back to Top
PREREQUISITES
Prerequisite Usage
Maturity Analysis and Recommendations
Report (ER.015)
If available and related to the scope of your task, use the Maturity Analysis and Recommendations Report to review the
current situation.
Current Architecture (EA.030) If available and related to the scope of your task, use the Current Architecture to investigate the current state
architecture to identify remediation approaches.
(BA.040)
If available and related to the scope of your task, use this work product to investigate the current processes/functions to
identify remediation approaches.
Current Capability Challenges (ER.165) Use the Current Capability Challenges to identify challenges for which you need to determine remediation approaches.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Remediation Approaches is used in the following ways:
to see what kind of remediation approaches are suggested for the current capacity challenges
to prioritize the remediation approaches
as input to the business case
to determine a roadmap with activities to implement the suggested remediation approaches
Note: There might be some iterations between business case and remediation approach discussion as customers may want to understand the business case impact of
different remediation approaches.
Distribute the Remediation Approaches as follows:
to the organization through a presentation with supporting documentation
to resources that need the documents as input for further work (business case, roadmap, etc.)
Back to Top
QUALITY CRITERIA
Have domain experts/architects been consulted to discuss and elaborate on different remediation approaches?
Is there a description of each suggested remediation approaches, including impacted areas (e.g., applications, systems or architectures) and a reasoning why this
is expected to be an improvement?
Does the work product include how the remediation approaches align to the Business Strategy, or more specifically, to a specific goal statement?
Have the Remediation Approaches been presented to the client and accepted as realistic remediation activities to improve on the current capacity challenges?
Does the work product clearly indicate the impacted current capability challenge for each remediation approach?
Back to Top
ER.170 - DEVELOP FUTURE STATE TRANSITION PLAN
During this task, you produce a plan on how to move from the current state to the desired future state, preferably in incremental transitions that map to the business
ambitions. At this point, you have a clear understanding of the customer's goals, requirements, and challenges, as well as the current state and future vision. During this
task, you develop and package recommendations on how to get to the desired future state.
How you do this depends partly on how far the organization has come in IT Portfolio planning. If the organization has an up to date IT Portfolio covering future candidate
projects, you would typically review the Prioritized Projects (IP.050) to determine which projects best can be used to implement the desired future state over time. On the
other hand, there might be a situation where either the Candidate Projects is not complete, or that the projects identified do not sufficiently cover the needs. In this
situation, you may need to identify new project candidates that should go into the list of candidate projects. Perform risk analysis for the transition steps as well as the
inverse of risk analysis, opportunity analysis, for example, re-platform (centralization on shared servers), decoupling integration and improving manageability with tooling.
In order to create a manageable level of scope, the Future State Transition Plan is not intended to include all aspects of the future vision. The focus should be limited to
core aspects, such as infrastructure plans and infrastructure components.
ACTIVITY
Back to Top
WORK PRODUCT
Future State Transition Plan - The Future State Transition Plan shows a suitable path for how the enterprise will move from the current architectural situation to the
Future State Architecture (EA.120). It shows all the elements that need to be in place for the Future State Architecture, the order in which they should be implemented
and their dependencies.
Back to Top
TASK STEPS
1 Prepare
recommendations.
Recommendations The Recommendations list the recommendations for ALL stakeholders who participated in the process.
2 Provide some reflection
of the current state.
Current State
Reflection
The Current State Reflection documents the parts of the current state that are relevant for the case with some
reflections on the parts that are included.
3 Provide some rationale
on selected
improvement options.
Future State
Rationale
The Future State Rationale documents the reasons why the improvement options are relevant for the cases that have
been selected.
4 Provide a transition
plan.
Transition Plan The Future State Transition Plan shows a recommendation for when all the elements in the future state are to be
implemented. It shows the steps that need to be performed, the dependencies to other elements, and possible
projects in which the elements can be implemented. This may be already identified projects (candidate or existing),
but may also be completely new candidate projects. Typically, it is in the form of incremental steps that outline a
Roadmap of how to get from the current state to the future state.
5 Provide any variations
to the proposed
transition approach
Alternative Plans The Alternative Plans contains one or more backup transition plans that ma be used if the timings suggested in the
primary plan do not fit, or if any of the identified risks occur.
6 Define a
retention/migration/new
application strategy.
Transition
Strategy
The Transition Strategy documents the strategy for the transition process. It covers a strategy for new application
implementation, retention of applications that should be retired and migration of existing applications to new
applications.
7 Review the proposed
Future State Transition
Plan with key
stakeholders, prior to
presenting to all.
reviewed Future
State Transition
Plan
The reviewed Future State Transition Plan has been reviewed by key stakeholders.
Back to Top
APPROACH
If an approach for transitioning to the future state has already been determined and documented, then the Future State Transition Plan should be developed accordingly.
Determine if the approach should provide incremental improvement for the customer or if the customer requires an evolutionary change to a particular area of the
business. Work with the stakeholders to develop a roadmap to the future state.
If the choice is for an incremental approach, then time should be spent on showing the benefits of automation, efficiency gains, and elimination of existing business
constraints caused by the current situation. The emphasis is to show a series of improvements through specific implementations of products and processes.
The approach suggested depends on whether a customer is willing to make a significant change, or needs to gradually implement change that will result in achieving the
future state. The emphasis is to create a series of proposed actions that will achieve the customer's business requirements. The proposed approach depends on
willingness, and expected response of an organization to be able to make change. It also depends on dependencies between those actions. Often, one improvement is a
prerequisite for a subsequent improvement, or improvements are impacting the same system and, therefore, cannot be executed in parallel. Constraints on the
availability of key customer staff can also impact the transition planning.
Assess the information that was gathered and the artifacts produced during the assessment of the current state. Develop solution recommendations, and package those
recommendations into a compelling presentation for the customer.
Prepare Recommendations
When preparing the recommendations, consider all the stakeholders that have participated in the process, and prepare recommendations for each stakeholder type.
Present the recommendations that consider ALL stakeholders who participated in the process.
Provide Reflections on the Current State
Show what about the current state is relevant for the case. Provide some reflection of the current state, including known problems and challenges. Later, as you present
the proposed solution, it is also important to demonstrate how to get from the current stated to the recommended future state.
Provide Rational on Selected Improvement Options
Explain which improvement options are included in the future state presented, and why these were selected (high-level benefits and business case). Preferably, this
should be related to the reflection given about the current state. The improvement options typically reflect the gaps between current reality and future vision.
Provide a Transition Plan
Identify a suitable path including building blocks to achieve the future state. Review the MoSCoW Improvement List priorities (ER.130), and if available the Current
Architectural Challenges (EA.050) to determine a strategy that should give a quick ROI. Review the Future State Risks (ER.120) for each alternative, and choose a path
with limited risks.
Review the Candidate Projects (IP.040) to identify candidate projects in which the elements can be implemented over time. If the list of candidate projects is not complete
or completely missing, or that the projects identified do not sufficiently cover the needs, then you may need to identify new project candidates that should go into the list of
candidate projects. Perform risk analysis for the transition steps and the inverse of this, which is opportunity analysis such as for example re-platform (centralization on
shared servers), decoupling integration and improving manageability with tooling.
There may also be some mileage in looking for opportunities in optimizing the delivery lifecycles in clients with multiple project based portfolios. For example, the
consolidation of development, and multiple test environments is a good use case. There are also opportunities for tooling like an enterprise repository to maintain artifacts
in a central repository.
When projects have been identified as candidates for the transition plan, it is recommended to follow up by interviewing the project manager and chief architect of each
project. That is, if they are identified. The goal is to determine what the project can contribute to and what the expected timeframe would be. Results can then be mapped
back to the Transition Plan
Finally, ensure that you map the needs or improvement options to the steps in the Transition Plan. This makes it easier to argument for each step in the plan, and is a
quality check that each step has been well thought through.
When creating the Transition Plan, focus on the logic and timing of the steps needed to get to the future state. The Roadmap is what many of the stakeholders are
perhaps most interested in seeing, and this may be the first chance they have had to see it presented in its entirety. Make sure that you provide the following
characteristics (at a minimum):
Present a clear set of dates, deliverables, and outcomes.
Prescribe a specific order of steps to be taken, using the OUM WBS.
In a presentation, this is best reflected in a single slide or graphic.
Provide any Variations to the Proposed Transition Approach
If there are many uncertainties, for example, risks that may materialize, or uncertainties on the reliability of the suggested timings, you may want have one or more
backup transition plans with another set of options or timings for the stakeholders to consider.
Define Retention/Migration/New Application Strategy
Define a retention/migration/new application strategy that supports the determined path, if relevant.
Review the Proposed Future State Transition Plan with Key Stakeholders
Let the key stakeholders involved in the engagement review the proposed Future State Transition Plan prior to presenting it to a larger audience. This is to ensure that
you have backup suggestions included, and to prevent suggestions that are not realistic from a business/organization perspective. This can be done using various
techniques, such as a walkthrough or workshop.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Prepare the Future State Transition Plan and present to customer. Provide insight into priorities and dependencies for the
enterprise.
60
Solution Architect Provide technical input and technical dependencies for the plan. Participate in the customer presentation. Provide solution-
specific insight into architecture components involved in the plan.
40
Back to Top
PREREQUISITES
Prerequisite Usage
Impact Study and List of Proposed Organizational Changes
(GV.040)
Put prerequisite governance in place to enable each improvement (just-in-time).
Future State Enterprise Architecture (EA.110) Keep in mind, the ultimate goal should be to help create intermediate states that lead to the desired
state.
Prioritized Projects (IP.050) Use timing information from Prioritized Projects in the Future State Transition Plan.
Future State RIsks (ER.120) Review the Future State Risks.
MoSCoW Improvement List (ER.130) Use the MoSCoW Improvement List to see which improvements are most important and should be
scheduled first.
Back to Top
TEMPLATES AND TOOLS
ER-170_FUTURE_STATE_TRANSITION_PLAN.DOC MS WORD
Tool Comments
Overview
Back to Top
The Future State Transition Plan is used in the following ways:
focus on the logic and timing of the steps needed to get to the future state
provide a Roadmap that was prepared with stakeholder participation and thus has their authority and acceptance
Distribute the Future State Transition Plan as follows:
to the customer as part of a recommendations presentation
Back to Top
QUALITY CRITERIA
Were ALL stakeholders who participated in the process considered in the transition planning?
Back to Top
ER.180 - PREPARE FOR AND PRESENT SOLUTION
RECOMMENDATIONS
During this task, you determine the scope of the presentation, and prepare for and conduct the final presentation where the suggested solution is shown to the customer.
This is a critical step during this phase and should provide the basis for any further engagements, either as further Envision effort, or one or multiple projects or programs.
Due to the tight collaboration with the customer and iterative approach to creating the final work product, the customer presentation is targeted more as a validation step
with the executive sponsors than an earth-shaking event. While there may be some minor surprises unveiled during the presentation, it should reflect your increased
understanding of the issues and challenges facing the customer. If you picture larger surprises, you should talk to and discuss the recommendation with the customer
coach before the presentation, rather than presenting a large surprise during the presentation. Keep in mind, this should provide a basis to work with the customer going
forward to help through their business challenges.
ACTIVITY
Back to Top
WORK PRODUCT
Solution Recommendations
Back to Top
TASK STEPS
1 Determine scope of presentation.
2 Prepare presentation. Solution Recommendations Presentation
3 Conduct presentation.
Back to Top
APPROACH
Determine Scope of Presentation
In many cases, the scope of the presentation is obvious, but even then, it is recommended that you spend some time clarifying the scope. Is it on enterprise level, on
program level, or project level? You may even have a mixed scope, suggesting a way forward that covers enterprise-level activities as well as starting a program or
number of projects.
Ensure that you have enough time available for the preparation of the presentation. The presentation of the recommendations is key: perception equals reality. Time and
energy should be spent ensuring that the participants recognize themselves in the findings. Before the executive presentation, first validate the presentation with a
customer champion. Also ensure that the client sponsor and customer coach are prepared for the meeting so that there will be no surprises to them. Ensure that the
proper audience from the client will be in attendance -- this is an executive level presentation. Also ensure that the appropriate subject matter experts attend the
presentation to support discussion around the recommendations, if it becomes necessary. Schedule a meeting of an appropriate duration; you often need about 1.5
hours, so allow for this even though it may be difficult.
When preparing the content for the presentation, try to leverage successful templates from the existing work of peers. Also consider the following:
Validate business value, goals, consequential- and tactical pains with internal coaches/sponsors. If you have not been able to do this up front, and are uncertain on
some areas of the suggested solution, consider having a backup with another set of options or timings for the customer to consider. However, it's best to validate
up front as you introduce a large risk if you have not been able to do so. Also review the identified risks for each improvement option so that you better understand
what kind of risk the customer takes for each alternative.
Prepare a presentation of findings and recommendations. The wording of the recommendations should be in the customers business language goals,
consequential pains and tactical pains. This helps ensure that the customer can link the recommended solutions to the business value as described under the
previous point.
Include the recommendations that consider ALL stakeholders who participated in the process. Do not focus only on the pains of those who have been deemed
most influential. Even though they seem the most influential, it is not always the case.
Include issues that must be considered if your recommendations are implemented. This provides credibility that you are not leaving any surprises hidden, and gives
the customer more value, as they need to take these aspects into consideration.
For the executives benefit, try to have the findings and recommendations laid out one of the first slides. Then go into detail on each solution with the slides that
follow. Do not go into too much detail, but have detailed slides at the end and hidden, in case it will be required to further elaborate on specific areas.
Always end with next steps. Start with some in the presentation and open it up to the customer to add more.
Conduct Presentation
During the presentation, allow enough time for the customer to ask questions and engage in feedback. It is important that you listen to the customer, and try to
understand their responses. When presenting the recommendations, evaluate the customers response / willingness to adopt the recommended solution. Afterwards,
evaluate the results by prioritizing a ny further efforts after this initiative, roadmap or engagement is complete. E nd the presentation with suggested next steps, and open
it up to the customer to add more. Also re-confirm points of contact for the next steps / action items.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Scope and prepare presentation. Construct attendee list with input from customer/Oracle stakeholders. Conduct presentation. 100
Client Stakeholders Attend presentation and agree on next steps. *
Back to Top
PREREQUISITES
Prerequisite Usage
Future State Risks (ER.120) Review the risks for each improvement option to ensure you understand the customer's risks.
MoSCoW Improvement List (ER.130) Review the prioritized improvements list to determine what solutions are most important to the customer.
Benefit Analysis (Candidate) (ER.110) Review the Benefit Analysis to understand the benefits to be gained by the customer by implementing the portfolio items.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
ER.190 - REVIEW BUSINESS FEEDBACK AND IDENTIFY
OPPORTUNITIES
During this task, you take a step back and evaluate all the feedback you have received from the enterprise during the Solution Recommendations presentation (ER.180)
but also during the process as a whole. Based on this evaluation, identify opportunities at the enterprise, both for services and sales.
In many cases, an immediate opportunity may not be the result of this effort. However, the benefit is on a more long-term basis; it is the deeper, broader understanding of
the enterprise's concerns and issues and also, hopefully, many ideas on how to help businesses over time with solutions. The enterprises, on the other hand, may get a
better understanding of their own situation, maybe just seen from a different angle, and they get a view into the implementing organization (e.g., Oracle) that they may not
otherwise have seenspecifically, a look into the future direction, which includes applications, technology, services and solutions.
Through this process, trusted advisor and strategic partnership relationships are created, and businesses can better learn about the implementing organization's (e.g.,
Oracle) strategic direction and holistic approach to solving business problems via integrating applications, technology, services and solutions.
Some recommendations lend themselves to immediate solution mapping for license and/or consulting solutions that may include immediate sales opportunities for
applications, technology, or services. Other recommendations provide the enterprise with information to make business or technology decisions. In some cases, more in-
depth solution mapping may be required, which may result in follow-up, targeted engagements to determine the best strategy for the enterprise.
ACTIVITY
INIT.ACT.PTI Plan Transition to Implementation
Back to Top
WORK PRODUCT
Opportunities Task List - The Opportunities Task List is intended to indicate the key tasks that will be planned as a result of either this Envision engagement or other
known sources of Envision or Strategy information that may be relevant. These tasks comprise the complete set of tasks including:
General recommendations/tasks that have arisen from the findings and recommendations from the Envision engagement.
Any activities that are required to be undertaken with the enterprise to progress the findings and recommendations from the Envision engagement.
The tasks required to transition the opportunity to the team(s) that will be performing the follow-on activities (for example the sales team pursuing the opportunity,
or the services organization that will perform the Implement processes to enact the vision), and the key activities that would be undertaken after the transition to
sales and services has occurred. This is a key input to the ER.200, Prepare for Transition to Sales or Services task.
Back to Top
TASK STEPS
1 Revisit engagement objectives.
2 Evaluate enterprise response.
3 Create task list. Opportunities Task List
4 Share the result of the engagement to new participants.
5 Communicate tasks to appropriate parties.
Back to Top
APPROACH
Revisit Engagement Objectives
Shortly after the Solution Recommendations Presentation, start to review the process. First, review the objectives of the initiative to determine if the team has achieved
the objectives. Either confirm that the team met the enterprises objectives, or explain why they have not been met.
Evaluate Enterprise Response
Evaluate how the enterprise responded to the suggested solution. Did the enterprise embrace the suggested solution? If not, what aspects were received positively, and
what caused that the suggested solution was not embraced?
Create Task List
Review the Next Steps that were agreed to at the end of the presentation and create an Opportunities Task List. Assign each task to the appropriate implementing
organization individuals (e.g., in license sales, consulting, and/or support organizations). Identify the appropriate people from the enterprise who will be the responsible
contact for each line item on the task list. This should also be verified during the presentation
Share the Result of the Engagement to New Participants
As new individuals are included in the process, share the results of the engagement to these individuals.
Communicate Tasks to Appropriate Parties
If the appropriate individual for the items in the Opportunities Task List has not been included in the process, communicate the opportunity to these individuals. Also for
the other responsible persons, recap the events.
Back to Top
Back to Top
Enterprise Architect Determine the key initiatives/gaps that were identified from the Enterprise Architecture [EA] and Business Architecture [BA]
processes and ensure that tasks that support these are incorporated into the Opportunities Task List. Ensure that the
Opportunities Task List results in a balanced view of the tasks that adequately capture all key findings from the Envision
engagement and will satisfy the needs of all of the key consumers of this work product.
80
Sales Manager Provide input from existing account planning/business insight activities that are relevant to the formulation of the Opportunities
Task List.
20
Note: The actual balance of resources required will vary depending upon the nature and composition of the Envision engagement. For example, one engagement may
have a higher focus on the EA tasks, in which case the involvement of the enterprise architect role would be commensurately higher.
Back to Top
PREREQUISITES
Prerequisite Usage
Envision Engagement Strategy (ER.020) Revisit the Envision Engagement Strategy to verify the results against the strategy.
Solution Recommendations (ER.180) Review feedback from the Solutions Recommendations presentation.
Back to Top
TEMPLATES AND TOOLS
ER-190_OPPORTUNITIES_TASK_LIST.DOC MS WORD
Tool Comments
Overview
task.
Back to Top
The Opportunities Task List is used in the following ways:
to document the key tasks that have arisen from the Envision engagement and that need to be planned to begin in order to realize the strategies and objectives
identified from the Envision engagement
as an input to the Opportunities Action Plan (ER.200)
as an input to the implementing organization stakeholders for the purpose of planning any future activities
Back to Top
QUALITY CRITERIA
Back to Top
ER.200 - PREPARE FOR TRANSITION TO SALES OR SERVICES
During this task, each person or team that has been allocated to a task in the Opportunities Task List (ER.190) evaluates the opportunity and develops a combined plan
on how to pursue that opportunity. This could be a sales team pursuing a specific (set of) product opportunity, a service team pursuing a project opportunity, or a
combination of both. One person should be appointed to be responsible for the customer program as a whole, and monitor the customer case after the plan has been
produced.
ACTIVITY
INIT.ACT.PTI Plan Transition to Implementation
Back to Top
WORK PRODUCT
Opportunities Action Plan - The Opportunities Action Plan is intended to provide a single location that captures the recommended future actions that are planned. The
plan is based on the list of tasks that were developed in the Opportunities Task List (ER.190).
Back to Top
TASK STEPS
1 Evaluate opportunity.
2 Produce action plan. Opportunity Action Plan A plan for pursuing an identified opportunity. All the individual plans make up the Opportunities Action Plan.
Back to Top
APPROACH
Evaluate Opportunity
A person or team has been allocated for each opportunity identified in the Opportunities Task List (ER.190). For each opportunity, review the available information and
feedback from the customer. Evaluate the likeliness of success and timeliness for each opportunity. Ask yourself questions like:
Was the customer receptive to the suggested solution on which the opportunity is based?
Was the customer comfortable with the depth and amount of information shared?
Has any follow up been agreed upon?
Were some areas more attractive to the customer than others, and is the opportunity among the most or least attractive alternatives?
Is this a priority for the customer?
Is it a near-term or a long-term opportunity?
For near-term opportunities do you know the long-term impacts?
Determine how to best pursue each opportunity. There are a lot of possible actions to take for an opportunity, dependent on the type of opportunity. Some opportunities
require a run through another roadmap for that specific area, others will require a sales cycle for selling a specific (set of products), some will require proof of concepts,
while others will result in a bid for a project.
Produce Action Plan
Based on the evaluation of the opportunities, produce an action plan for each opportunity. Put the individual Opportunity Action Plans into an overall Opportunities Action
Plan to ensure that the individual plans work together. Determine any dependencies between the opportunities so that the required prerequisites will be in place when
starting on a specific opportunity.
Back to Top
Back to Top
Enterprise Architect Work with the sales manager to determine Opportunities Action Plan. 70
Sales Manager Update account plan with Opportunities Action Plan. 30
Project Manager *
Back to Top
PREREQUISITES
Prerequisite Usage
Opportunities Task List (ER.190) This list includes the opportunities for which Opportunity Action Plans are being developed.
Back to Top
TEMPLATES AND TOOLS
ER-200_OPPORTUNITIES_ACTION_PLAN.DOC MS WORD
Back to Top
Back to Top
QUALITY CRITERIA
Have all of the tasks from the Opportunities Task List (ER.190) been incorporated into the Opportunities Action Plan?
Do all actions have an owner?
Back to Top
ER.210 - MONITOR CURRENT SITUATION AND PURSUE
RELEVANT UPDATES
During this task, you should review the current situation at the enterprise and consider whether there are requirements for making any changes or updates to the current
or planned products used at the enterprise, as well as if there are any requirements for making any updates to any agreed on roadmap. See if any new opportunities
have emerged that may support the Business Strategy or required business or IT capabilities in addition to what has already been planned.
This is an ongoing task that should be started as soon as a roadmap to a desired future state has been established, or when some other Envision initiative has been
completed establishing a desired situation. Refer to an existing Opportunities Action Plan (ER.200) to see if there are any opportunities for the enterprise that are planned
over time.
It is recommended that you review the current situation against the Opportunities Action Plan and against changes in the market, in particular for technology trends to
determine the potential relevance to the current situation or roadmap currently running. This should happen at six to twelve months intervals. This is critical to the
enterprise due to current unknown details that will be revealed over time.
In addition, such an update provides an opportunity to meet again with the enterprise stakeholders who were involved or consulted during the previous (e.g., roadmap)
engagement (internal and external to the enterprise) and to discuss any potential changes in their business and technology plans since the (roadmap) engagement was
conducted.
ACTIVITY
Back to Top
WORK PRODUCT
Monitored Current Situation - The Monitored Current Situation is one in which a current enterprise situation has been reviewed on a timely basis for changes or
updates. It is documented with a list of agreed upon updates that should be executed against the current situation or roadmap.
Back to Top
TASK STEPS
1 Monitor current situation and
identify potential updates.
Update
Candidates
The Update Candidates component consists of all potential updates to the current situation, current strategies
or current running roadmaps.
2 Investigate impact of change. Change Impact The Change Impact documents the expected impact and risks on the current situation or roadmap for each
update candidate.
3 Present suggestions. Suggestions
Presentation
The Suggestions Presentation provides the list of suggested updates to the current situation or roadmap along
with the expected benefits, including all identified impacts and risks.
4 Document agreed on updates. Updates The Updates are the agreed upon updates, how and when they should be executed and who is responsible.
Back to Top
APPROACH
Monitor Current Situation and Identify Potential Updates
One person should be responsible for ensuring that the result of the engagement/roadmap remains appropriate for the business as time passes. At a minimum, this
person should revisit the enterprise in regular intervals (typically, every 3, 6 or 12 months depending on the rate of change). However, this person is also responsible for
recognizing anything that may impact the enterprise's current situation or roadmap. This may be internal change in strategy or desired capabilities for the monitoring
organization, changes in the enterprise's market, or new technology trends or products.
Each time the situation is revisited, you should revisit the solution recommendations, and timings. Document potential changes or update candidates wherever appropriate
(e.g., recommendations, roadmaps) and include timelines.
or timings should be made, you document this as an update candidate.
This monitoring is also used as a checkpoint in tracking the enterprise's progress in following the roadmap or recommendations.
Investigate Impact of Change
For each update candidate, verify the impact on the enterprise. Verify with stakeholders within the enterprise, and relevant technology providers. Verify whether there are
any new business/technology initiatives, license purchases, implementations, etc. that may be relevant. Investigate what changes are required if the recommended
update is implemented. Also, investigate the benefits of each update candidate. Last determine the priorities for each update candidate.
Present Suggestions
Choose a presentation form based on the amount of updates and the level of impact. If the impact is medium to high, present the suggestions to the enterprise
executives, providing the justification for recommendation in business terms, what benefits are expected, how it impacts the schedule, and the risks both to implementing
or not implementing the updates.
Invite the key subject matter experts to this meeting, especially the resources who know of any relevant and significant changes since the prior establishing engagement.
At the end of the presentation, gain agreement on which updates should be implemented.
Document Agreed On Updates
Document the agreed on updates. Be sure to include the justification, who is responsible, when the update should be implemented, and the projected impact. Also,
include a list of updates that were not agreed on and the reason why the enterprise decided not to implement the updates for reference purposes at a later point of time,
when they may be revisited. Make the results available to all involved stakeholders.
Back to Top
Enterprise Architect Monitor situation and identify relevant updates. 100
Solution Architect Provide assistance, as appropriate. *
Back to Top
PREREQUISITES
Prerequisite Usage
Envision Engagement Strategy (ER.020) Revisit the Envision Engagement Strategy to verify the results against the strategy.
Solution Recommendations (ER.180) Review the Solutions Recommendations.
Opportunities Action Plan (ER.200) Use this plan to monitor the current situation.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Monitored Current Situation work product is used in the following ways:
as an input to update any active roadmaps to react to changes or new trends that have occurred after the initial roadmaps were produced
when no roadmap is in place, as an input to change the current situation as a result of changes or new trends
Distribute the Monitored Current Situation work product as follows:
to all individuals that were designed responsible for any agreed on update
to all other interested stakeholders
Back to Top
QUALITY CRITERIA
Has each update candidate been described with proper augmentation, founded in the Business Strategy or desired business or IT capabilities supporting the
strategy?
Have the impacts for each update been properly described, such as impact on architecture, capabilities, organization, schedule or costs?
Have all changes to be implemented been presented to all relevant stakeholders and executive management?
Has a responsible person been allocated to each agreed on update?
Have timelines been documented for each agreed on update?
Back to Top
[BA] ENTERPRISE BUSINESS ANALYSIS
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. It also provides other OUM processes with the
initial information on the business requirements in the areas of architecture availability, data and information protection, and the operating policies and procedures.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Back to Top
Initiate Phase
BA.100 Maintain Enterprise Business Models Maintained Enterprise Business Models
BA.110 Maintain Business Rules Maintained Business Rules
Back to Top
OBJECTIVES
Back to Top
KEY WORK PRODUCTS
Back to Top
Back to Top
Back to Top
BA.010 - IDENTIFY BUSINESS STRATEGY
During this task, you identify and gain understanding of the direction in which the organization is heading. Most organizations already have defined their strategy. So, this
task is not about defining the strategy itself, but about understanding the organization's strategy, their business principles, and making it specific for the engagement at
hand. You should understand the motivation behind the strategy in general, and the engagement in particular. You then work with enterprise stakeholders to identify what
part of the strategy you can make the strongest and most unique contribution to in terms of the prioritized strategic objectives.
ACTIVITY
Back to Top
WORK PRODUCT
Business Strategy - The Business Strategy documents the strategy for the business and the business principles as they are relevant for the engagement. It should also
reference any existing strategy documents. The document should include required explanations, and ideas on how to accomplish the elements in the strategy. The
Business Strategy document may also include a Motivational Model that is a formal description of the essence of why a particular course of action is taken or a specific
choice is made.
Back to Top
TASK STEPS
1 Gather and review existing strategy
material.
None
2 Prepare and conduct interviews or conduct
workshop with strategy owners.
None
3 Determine methodology, develop strategy
and build motivation.
Method This component names the methodology and provides a brief description (see Motivational
Modeling, Balanced Scorecard, Prioritization).
4 Identify Vision, Mission and/or Values. Vision, Mission and
Values
This component provides the Vision statement, Mission statement and Values statement.
5 Identify Business Principles. Business Principles This component provides a list of the Business Principles.
6 Obtain and review the Situational Analysis Situational Analysis The Situational Analysis provides the competitive environment and relevant strengths and
weaknesses of each.
7 Determine Goals, Objectives, Targets and
Initiatives.
Goals, Objectives,
Targets and Initiatives
This component is a list of each of the following: goals, vision, targets and initiatives.
8 Identify relevant business objectives. Business Objectives This component documents any business objectives that are relevant for the engagement at
hand.
9 Conclude the interviews/workshop and
provide feedback to stakeholders.
Business Strategy The Business Strategy documents the Business Strategy in a way relevant for the
engagement, including required explanations, or ideas on how to achieve this.
Back to Top
APPROACH
Gather and Review Existing Strategy Material
With the current increasing focus on fitness for business, and business agility, it becomes even more important to capture and retain the business drivers for the
engineering decisions behind the creation of software assets. In a traditional siloed enterprise development effort, software assets are acquired, created, and maintained
according to locally understood departmental needs. In such an environment the motivation for these assets are often expressed in narrow terms with little need for
enterprise-wide, or even industry standardized, semantics. Also look for any motivation behind the strategic directions.
Ideally you should be able to understand the enterprises vision as well as any goals, objectives and strategy that may have already been defined.
You should also identify the Business Principles, as these are key to understanding how decisions and alternatives are evaluated. The Business Strategy influences how
IT initiatives and investments can be linked to and evaluated in support of the Business Strategy, goals and objectives. Review the Business Principles with enterprise
stakeholders to understand any implications on how they affect meeting business objectives and setting business initiatives.
Given the changing nature of Enterprise Architecture towards a sharing infrastructure, or service orientation, the business justification for acquisition, development,
adaptation, or even continuation of these assets becomes far more complex, potentially crossing many organizational boundaries, involving different skills, practices, and
dialects. Capturing and assessing business drivers (motivation) becomes much more complicated in such an environment, while in the future we will need to trace,
compare, and re-evaluate past justifications.
Therefore, it is important to detail, and to get a better understanding of the motivation behind a particular course of action, or a specific choice that is relevant for the
engagement at hand. Dependent on what kind of information you have available, and in what format, you may therefore decide to create a motivational model for this
purpose.
The value of Motivation Modeling lies in both the justification of what has been chosen, and traceability. By establishing a standardized model and associated semantics
for describing business motivation the justification for example the creation of a service can be more clearly communicated. Such an evaluation of business drivers for a
given asset also has enduring value in the lifecycle of the asset, enabling traceability to original motivation when determining whether it should be improved, retired, etc.
Ultimately the process for evaluating motivation may be extended to develop specific performance indicators for use at the operational management end of the lifecycle.
Please refer to the motivational modeling technique listed below.
Ask for any material relevant for strategy identification. Most organizations have some strategic documentation available. Review the material, and make notes where you
need clarifications, or more in-depth information. Make notes on specific strategic directions that you may see as most relevant for your engagement. Be on the lookout
for aggressive and defensive strategies of the organization and their key competitors. You should come out of this exercise with specific knowledge about how the
organization ntends to gain share in the market either by adding value or decreasing costs by product or market served. Be especially sensitive to the relationship
between key business processes and competitive advantage or vulnerability (disadvantage in comparison to competitors). You should understand the motivation behind
the strategic direction.
Prepare and Conduct Interviews or Conduct Workshop with Strategy Owners
Try to gather all the stakeholders into the same meeting or workshop, however, this will not always be possible. Be aware that if you need to perform a number of
interviews, the process will be longer as you often will need to cross check as inconsistencies arise, or you realize that you have not gone into enough detail or missed a
direction for one interview when you perform another interview with another stakeholder. If you have them all gathered in the same room at the same time such
inconsistencies or misunderstandings can be solved immediately. In addition, you will not need to repeat feedback as all stakeholders have been present when the
decisions have been made.
The goal for the workshop is to have identified the key objectives for the enterprise, and to prioritize these in order to visualize which objectives are the most important
ones, or the ones that should be pursued first.
Prepare the interviews/workshop carefully. Use the strategy materials you previously gathered and reviewed as an input. Prepare the objectives for the workshop.
Discuss and verify these with the workshop owner. Communicate the objectives up-front to all participants. Ensure that you have identified the right stakeholders to
participate. Prepare accompanying questions that will aid the process to achieve the objectives for the workshop. Determine the techniques you will use for the various
parts of the workshop, and prepare the timings. If you are not well prepared, there is a large risk that you will loose credibility that will make the rest of the work very
difficult. Prepare a set of probe questions that ensure you are able to identify critical business processes and their relationship to the business strategy based on your
review of the previously discovered strategic documents. Prepare questions to determine the current degree of business process standardization and current degree of
business process integration. Examine the business objectives and determine if the degree of business process standardization needs to change or if the degree of
business process integration needs to change or if both need to change.
Also verify with the workshop owner to ensure that you have the backup you need. Which techniques are the best to use may be very dependent on the organization
culture and the politics within the organization.
Conduct the interviews/workshop following your plan. Ensure that the participants take part in the whole process, and that they should not be interrupted. This must also
be communicated up-front. Ideally, it should be held off site to minimize the possibilities for interruptions.
Prioritize the list of final objectives. This should be a last step in the workshop agenda. This output is important to understand the differences in importance or urgency of
the objectives, and will be an important input to other prioritizing tasks later during Envision.
Various techniques are available to assist with the prioritization of strategies, including the Prioritization technique.
Determine Methodology to Develop Strategy and Build Motivation
Determine how you plan to develop/identify the strategy, and how you plan to identify the motivation behind the strategic decisions, and the decisions or choices made
specific for this engagement. You may decide to create a Motivational Model based in the identified Business Vision. Please review the Motivational Modeling technique
on how to perform this task step.
Your decision should depend on:
1. The time you have for this step: if the overall engagement lasts only a few days, you cannot expect to spend most of this time understanding and defining the
enterprises strategy (unless of course this is exactly what the engagement is about). On the other hand, if this task is done at the beginning of a several months
project or program, it is clear you could spend the time to carry out a detailed motivational model.
2. How critical is it for the success of your initiative or engagement: in most cases all the engagements should be traceable back to the business strategy. However
some initiatives will be more closely linked to the business strategy, typically the ones that impact the business the most (any large program, a BPM or SOA
strategy, etc.)
3. The enterprises maturity in the definition of its Business Strategy. If the previous step uncovered a detail motivational model, and a well articulated IT strategy
clearly mapped to the business strategy, then the following steps might consist in only validating and ensuring your understanding existing material.
Conclude the Interviews/Workshop and Provide Feedback to Stakeholders
When the interviews are complete and/or the workshop is over, document the conclusions. This should be a document covering the parts of the Business Strategy that
are relevant for the engagement, including required explanations, or ideas on how to achieve this. Either present this to senior sponsors and executives or send this
summary document to all participants. Send a feedback to all participants, including what will be the next steps in your engagement and what is required from each
participant.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Along with the client enterprise architect, lead the definition of the Business Strategy. The enterprise architect needs to
possess an in-depth knowledge of the organization or the target industry.
100
Client Enterprise Architect Assist in leading the definition of the Business Strategy. *
Client Stakeholders This task requires input from key decision makers in the organization, including input from the C-level executives (CEO, CIO,
etc.), heads of the Lines of Business and senior management.
*
Back to Top
PREREQUISITES
If this task is performed prior to a project start up, the Business Strategy (BA.010) should be used as an input to determine the Business Case (BT.020)
The Business Strategy (BA.010), and in particular the Business Objectives section should be used as an input to determine the Business and System Objectives
(RD.001) for each engagement that falls within the scope of the strategy.
Prerequisite Usage
Enterprise Research Findings
(ER.040)
Use the Enterprise Research Findings to determine the correct persons to involve in the workshop, and to prepare yourself for the
enterprise situation.
Confirmed Business Case
(BT.020)
If available, use the Confirmed Business Case to identify project vision and goals.
Back to Top
TECHNIQUES
Technique Comments
This technique provides assistance preparing a Motivational Model. In the context of OUM, the Motivational Model is a document
or a chart highlighting the factors and assessments made in early stages of requirements gathering analysis.
Prioritization Use this technique to determine the relevant priorities of the various business strategies.
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
BA-010_BUSINESS_STRATEGY.DOC MS WORD
Tool Comments
Back to Top
The Business Strategy is used in the following ways:
to prepare for and plan next steps in the engagement
to document the key objectives of the enterprise for subsequent work
as an input to determine the Business Case (BT.020) if this task is performed prior to Project Start Up
as an input to determine the Business and System Objectives (RD.001) for each engagement that falls within the scope of the strategy (specifically the Business
Objectives section)
as an input for the justification of, and to prioritize requirements, needs or improvements
as an input to service justification when the project is a SOA project
as an input to benefit analysis
to measure the achievement of the engagement goals
Distribute the Business Strategy as follows:
to Enterprise stakeholders (all participants) who provided information and validated the strategy
to project team members who will work on subsequent activities during the Envision engagement
Back to Top
QUALITY CRITERIA
Has the Business Strategy been validated by all enterprise stakeholders?
Have the Business Strategy and the technology options been considered together in preparation for next steps of the Envision engagement?
Back to Top
BA.012 - DEFINE BUSINESS SCOPE
During this task, you identify the business scope that should be explored as part of this engagement. The goal is to define the scope in business terms to make sure that
the engagement has strategic meaning to the business.
Normally you will not focus on all areas of the enterprise at one time, but a subset. This task defines the scope of your engagement, either through an agreed on set of
business functions/processes, organization structures, applications, entities, or whatever is the most appropriate. It is important to define and agree upon the boundaries,
limits and constraints with the customer. So before any other effort is undertaken, the boundary and supporting documentation should be understood and then a high-
level picture of the business scope should be developed.
The Motivation Model established in the Business Strategy (BA.010) can can be an important input into this task. Alternatively, if the Motivation Model has not been
established at the enterprise level, it could be established for this business scope following this task.
In the Enterprise Business Context Diagram (BA.045), the enterprise context is visualized as a black box with outside actors and external interfaces. In this task, we show
what is inside the box, so in fact the Enterprise Business Context Diagram defines the environment of the business scope.
ACTIVITY
Back to Top
WORK PRODUCT
Business Scope - The Business Scope describes the business areas that are within the scope of the current engagement. This may be documented through different
means, but may include any of the following agreed on items:
business functions
business processes
organization structures
applications
business entities
or any combination of the above
Back to Top
TASK STEPS
1 Create
Business
Scope
description.
Business
Scope
Definition
Skeleton
Determine how the scope should be specified. In most cases you document the scope either through a set of agreed functions,
processes, organization structures, applications, entities or a combination of these.
The more of the following steps you do, the better clarification of the business scope and the less chance of misunderstanding.
Complete the following steps in any order as applicable and appropriate.
2 Identify
business
functions.
Business
Functions
If the enterprise already has a list of business functions, they may have been captured in the Enterprise Function or Process Model
(BA.040). In that case, use this list to identify those business functions that are included. Otherwise, see if you can identify a set of
business functions (name plus definition), but without going into details. If that is not feasible skip this step.
3 Identify
business
processes.
Business
Processes
If the enterprise already has a list of business processes, they may have been captured in the Enterprise Function or Process Model
(BA.040). In that case, use this list to identify those business processes that are included. Otherwise, see if you can identify a set of
business processes (name plus definition), but without going into details. If that is not feasible skip this step.
4 Identify
organization
structures.
Organization
Structures
If the enterprise already has a list of organization structures, they may have been captured in the Enterprise Organization Structures
(BA.020). In that case, use this list to identify those organization structures that are included. Otherwise, see if you can identify a set of
organization structures (name plus definition), but without going into details. If that is not feasible skip this step.
5 Identify
applications.
Applications If the enterprise already has a list of applications, they may have been captured in the IT Application Portfolio (IP.012). In that case, use
this list to identify those applications that are included. Otherwise, see if you can identify a set of applications (name plus definition), but
without going into details. If that is not feasible skip this step.
6 Identify
business
entities.
Entities If the enterprise already has a list of entities, they may have been captured in the Enterprise Domain Model (BA.050). In that case, use
this list to identify those entities that are included. Otherwise, see if you can identify a set of entities (name plus definition), but without
going into details. If that is not feasible skip this step.
If you find that the enterprise does not have a list of the functions, processes, organization structures, applications or entities with which you can describe the scope in
enough details, consider creating the Enterprise Function or Process Model (BA.040) first and then revisit this task.
Back to Top
APPROACH
Create Business Scope Definition
In this step, you initiate the business scoping activity.
You start by determining the high-level tentative scope of the activity in a few words. You can use the Motivation Model (BA.010), if available, to determine the best area
to focus on. In most cases, the customer will have a view as to the best area to concentrate on. You can guide him by providing a set of features the scope should ideally
have. These features depend on the actual engagement, for example for a governance engagement you will want to look at an organization unit where there is strong
top-down management, for an Enterprise Architecture where the architecture maturity might be the greatest. You can also focus to where the greatest pain points lies.
It is also in this step that you gather the existing enterprise functional model, organization charts, application catalog and enterprise domain model if they exist. You also
determine if the information you have is enough to define the scope in enough details or if you need to first analyze the business, for instance by creating the Enterprise
Functional or Process Model (BA.040).
Identify Business Functions
In this optional step, you define the scope by limiting the engagement to one or several business functions. See the Business Scope Definition technique for more details.
Identify Business Processes
In this optional step, you define the scope by limiting the engagement to one or several business processes. See the Business Scope Definition technique for more
details.
Identify Applications
In this optional step, you define the scope by limiting the engagement to a set of applications. See the Business Scope Definition technique for more details.
Identify Business Entities
In this optional step, you define the scope by limiting the engagement to a set of business entities. See the Business Scope Definition technique for more details.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Set the Business Scope of the Envision engagement along with client stakeholders. 100
Client Enterprise Architect Assist in setting the Business Scope. *
Client Stakeholders Provide information about the organization. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) The Business Strategy contains the Motivational Model. If available, use the Motivational Model to determine the motivation for the
engagement bound by the given domain definition.
Enterprise Organization
Structures (BA.020)
Use the Enterprise Organization Structures, if available, to identify organization units, and relevant locations that you may use in your
domain definition.
Enterprise Function or
Process Model (BA.040)
Use the Enterprise Function or Process Model, if available, to identify the processes that should be included in the domain definition.
Enterprise Business Context
Diagram (BA.045)
Use the Enterprise Business Context Diagram, if available, to view the boundaries of the Enterprise as a whole, to see what actors are
involved and what key information flows in and out of the organization.
Enterprise Domain Model
(BA.050)
Use the Enterprise Domain Model, if available, to identify the entities that should be included in the domain definition.
IT Application Portfolio
(IP.012)
Use the Application Portfolio, if available, to identify the applications that should be included in the domain definition.
Back to Top
TECHNIQUES
Technique Comments
Business Scope Definition This technique provides assistance in how to define the scope.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Business Scope is used in the following ways:
to limit the further efforts to an agreed on scope
Distribute the Business Scope as follows:
to all stakeholders
Back to Top
QUALITY CRITERIA
Is the Business Scope clearly defined with no ambiguity?
Does the Business Scope make a logical unit and not just a set of disparate areas?
Does the Business Scope fit the requirements of the engagement (e.g., is it defined in terms of business processes or functions in a process modeling
engagement)?
Is the size of the Business Scope neither too large as to make it very difficult to work with, nor too small as to make any work irrelevant to the wider enterprise? Use
your experience to determine whether the scope size is adequate given the level of granularity you want to achieve and the time at your disposal.
Back to Top
BA.015 - CONDUCT ENTERPRISE STAKEHOLDER
ASSESSMENT
Stakeholders are those entities (a person, group or organizational unit) whose interests and expectations need to be taken into account when making decisions or an
entity that has a vested interest in the Envision engagement or will be affected by its outcomes. The primary aim of the stakeholder identification is to capture the
stakeholders who could and should have a stake in the planning, management, realization and execution of a predefined initiative within the stated business scope.
In this task, the goal is to identify the enterprise stakeholders. You should determine their influence, concerns and interest and what information they would like to receive
and by what method of delivery. The list of stakeholders will vary depending on the defined business scope and may be significant. It is for this very reason that this
process builds a stakeholder library that each project can utilize to expedite the activity. The success of any enterprise program is not limited to day-to-day application
engineering activities, therefore, additional stakeholders who make long-term strategic decisions should also be considered. The stakeholder identification approach
initially focuses on roles within application engineering, service engineering and supporting organizations.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Stakeholder Inventory - The Enterprise Stakeholder Inventory documents the enterprise stakeholders, their influence and interest, and what information they
would like to receive and by what method of delivery.
Back to Top
TASK STEPS
1 Review previously
gathered information.
None None
2 Define or update
stakeholder library.
Stakeholder Library The Stakeholder Library contains information about each stakeholder within a domain and should be updated
whenever new information becomes available.
3 Identify key
stakeholders.
Stakeholders The Stakeholders table lists all key stakeholders or stakeholder groups.
4 Describe each
stakeholder,
determine the
stakeholder type and
status.
Stakeholders Detail -
Role Description,
Status and Stakeholder
Type Rows
For each stakeholder or stakeholder group, the Stakeholder Detail table includes the Role Description that
documents the role of a stakeholder relative to a project within the defined domain, the Status indicates whether
the stakeholder is active or inactive, and the Stakeholder Type indicates what type of stakeholder it is relative to a
given project.
5 Assess stakeholder
base concern, interest
and influence.
Base Concern and
Importance/Influence
Rows
For each stakeholder or stakeholder group, the Stakeholder Detail includes the Base Concern that indicates what
the stakeholder has specific interest or concern about, while the Importance/Influence describes the
importance/influence of the stakeholder or stakeholder group.
6 Assess the frequency
of reporting for each
stakeholder.
Frequency Rows
For each stakeholder or stakeholder group, the Stakeholder Detail includes the Frequency which details the
frequency of reporting for each stakeholder.
7 Determine
informational needs of
each stakeholder.
Information Desired
and Information Use
Rows
Using a table format to present the Enterprise Stakeholder Inventory, the Information Desired details what
information each stakeholder wishes to receive and the Information Use indicates how the stakeholder will use
the information they receive.
8 Determine the delivery
method for each
stakeholder.
Delivery Method Row
Using a table format to present the Enterprise Stakeholder Inventory, the Delivery Method column details the
preferred delivery channels, (e.g., email, newsletter, etc) for each stakeholder or stakeholder group.
9 Confirm and document
domain stakeholder
Confirmed Stakeholder
Details
The Confirmed Stakeholder Details have been confirmed with the customer.
#TOP
details.
Back to Top
APPROACH
Define or Update Stakeholder Library
If there is not Stakeholder Library available or if it is out-of-date, then a Stakeholder Library should be defined or refreshed.
Identify Key Stakeholders
The primary aim of stakeholder identification is to document the roles that could and should have a stake in the planning, management, realization and execution of an
initiative. The list of stakeholders will vary depending on the defined domain and may be significant. It is for this very reason that this process builds a Stakeholder Library
related to a given domain, so that every project executed within that domain can utilize this to expedite the activity. If the customer has already gone though a governance
effort to detail specific roles and responsibilities related to the given domain, then the customer will not need to go through a domain stakeholder identification effort again
and this step can be skipped.
Identify the specific groups and/or roles that will be directly affected or with interests by the proposed business scope and how they will interact with one another. Review
any pertinent information.
If a project plan is available for the engagement, start with a review of the project stakeholders that are already identified. Reviewing the software engineering
documentation (such as, architecture, design and testing documents) allows the identification of the individual stakeholders that have had a stake in each of the
activities/processes in the past. This assists in highlighting the interconnected groups and stakeholders that have an important stake in specific areas of the software
engineering processes. In effect, this approach documents the swim-lanes applied to the various software engineering processes. This activity assists in establishing a
set of stakeholders on which to base more collaborative discussions.
In order to assist and expedite this task, review the following additional documents if they are available:
Governance Model: Key stakeholders and their information and communication needs have probably already been documented.
Organization Chart: Can assist with stakeholder identification but focusing on the formal structure of the organization is not enough. It is also important to identify
informal and indirect relationships.
Assessment Results (e.g., SOA Assessment): Can assist with narrowing down the stakeholder focus area if there are some concerns that have been highlighted
and need addressing.
Begin with C level executives (CFO, CTO, CEO, etc.) but extend the assessment to cover all groups significant to the enterprise. Keep in mind that the success of and
enterprise engagement is not limited to day-to-day application engineering activities, therefore, additional stakeholders who make long-term strategic decisions must also
be considered.
Remember that stakeholders can be external to the enterprise.
Solicit input from the client project sponsor for the engagement, and from functional/business unit heads. Ask their views on the engagement's impact and the roles their
groups should play. Recognize that a stakeholder group's perception of the impact of the engagement and the significance of their role in the engagement can be
surprisingly different from the view of team's actually working on the engagement.
Describe Each Stakeholder (Type and Status)
Describe each of the identified stakeholders using a predefined template with stakeholder attributes. Determine the kind of stakeholder and the status of the stakeholder.
Refer to the Stakeholder Capturing technique for examples of stakeholder types and statuses.
Assess Stakeholder Base Concern, Interest and Influence
Typically, each stakeholder has interests in or concerns relative to a system and/or domain. Concerns are those interests that pertain to the applications development, its
operation or any other aspects that are critical or otherwise important to one or more stakeholders. Also, document the kind of influences the stakeholder has in the
organization.
Assess the Frequency of Reporting for Each Stakeholder
Based on the stakeholder concerns and influence, determine how often there should be any reporting to each stakeholder.
Determine the Informational Needs of Each Stakeholder
Based on the stakeholder concerns and influence, determine at a high-level, the informational needs for each stakeholder. This will be further detailed in the Enterprise
Modeling Strategy (ER.070) and specifically for a project during the identification of viewpoints (RD.003).
Determine the Delivery Method for Each Stakeholder
Based on the stakeholder concerns and influence, determine at a high-level, the delivery method for each stakeholder. This will be further detailed in the Enterprise
Modeling Strategy (ER.070) and specifically for a project during the identification of viewpoints (RD.003).
Confirm/Document Domain Stakeholder Details
All identified stakeholder details, including their information needs and delivery method, should be confirmed with the customer to make sure that there has been no
misinterpretation of the documentation.
Depending on the quality and completeness of the documentation, it might not be possible to get a complete list of stakeholders involved and their details. If this is the
case, then gaps in knowledge will need to be filled with the customer's assistance.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Identify, analyze and understand the influence of each enterprise stakeholder. 100
Client Stakeholders Work with the enterprise architect to identify enterprise stakeholders and their interests. *
Back to Top
PREREQUISITES
Prerequisite Usage
Project Stakeholder Analysis
(PJM.CMM.010)
When available, use the Project Stakeholder Analysis to retrieve an initial list of enterprise stakeholders for the
engagement.
Back to Top
TECHNIQUES
Technique Comments
Back to Top
TEMPLATES AND TOOLS
BA-015_ENTERPRISE_STAKEHOLDER_INVENTORY.DOC MS WORD
Back to Top
The Enterprise Stakeholder Inventory is used in the following ways:
as the starting point for identifying Stakeholders at the Enterprise level prior to an Implementation project
to identify and document the expectations of key stakeholders for the Envision engagement
Distribute the Enterprise Stakeholder Inventory as follows:
to stakeholders who participated in identification of stakeholders
to the project team
Back to Top
QUALITY CRITERIA
Have all stakeholders been identified as roles (rather than as specific persons or job names)?
Have expectations been validated with the stakeholders?
Have information needs been validated with the stakeholders?
Back to Top
BA.017 - DETERMINE METRICS COLLECTION AND REPORTING
STRATEGY
In this task, you review the enterprise vision and strategy to determine what areas of the business are relevant for metrics collection. Metrics collection should be used to verify whether the actual
situation is aligned with what is expected to be accomplished within a given area as indicated through the enterprise business vision, goals and objectives.
Metrics are also referred to as key performance indicators (KPIs). These are measures that provide the business with critical business performance information in order to understand how the
business performs and to identify areas for improvement. Therefore, KPIs should be tied to strategic goals to enable the enterprise to monitor the execution of the strategy.
Instrumentation, with respect to business and particularly IT has been around for a long time. However, it has not generally been utilized as a core component of the IT strategy. Quite often, it is
applied in project scenarios and in many cases it is introduced as an afterthought, or as a missed requirement. Many view the addition of instrumentation to be a bottleneck or unnecessary overhead.
This reasoning typically stems from those who have been forced to add instrumentation as a reactive measure after a project has been completed.
Instrumentation should be a core component of any IT Strategy. This task emphasizes instrumentation as a discipline that is required to more effectively implement the IT strategy. It includes, but is
not limited to projects and applications. By utilizing instrumentation as part of the IT strategy, ITs ability to support the business will become more natural. Further, the business understanding of the
benefits provided by IT will become more apparent as IT becomes more proficient in responding to business demands. This is only possible if IT utilizes instrumentation to measure and collect
performance data and then acts upon it to improve and mature as an organization.
ACTIVITY
BA.017.1
BA.017.2
Back to Top
WORK PRODUCT
Metrics Collection and Reporting Strategy - The Metrics Collection and Reporting Strategy details what metrics will be required to measure and report on the progress towards the enterprise vision
and strategy. It includes the underlying goals of each metric, as well as how each metric should be collected, reported and interpreted.
Back to Top
TASK STEPS
1 Review enterprise vision to determine
candidate measurement areas relevant
for metrics collection.
Candidate
Measurement
Areas
The Candidate Measurement Areas is a list of areas, including a description of what kind of benefits are expected to be obtained
through metrics collection for each area.
2 Identify pain points and finalize areas for
metrics collection.
Measurement
Areas
The Measurement Areas lists the actual measurement areas that have been chosen for metrics collection at this point of time. It also
includes a reason why these measurement areas have been selected. It should also include a priority for each candidate
measurement area, so the list can be reevaulated by these priorities.
3 Determine goals and sub-goals for each
area.
Goals The Goals component contains the goals and objectives for each measurement area.
4 Determine indicators and KPIs or
measures for each goal.
Indicators and
KPIs/Measures
The Indicators and KPIs/Measures contains all the actual indicators and required KPIs to measure against a given goal.
5 Determine metrics collection and
reporting strategy.
Metrics
Collection and
Reporting
Strategy
The Metrics Collection and Reporting Strategy describes the method and means for tracking progress toward goals, the actual
metrics required, how the result should be reported upon, and assistance on how the result should be interpreted.
6 Verify existing metrics for relevance. Existing Metrics
Verification
The Existing Metrics Verification contains an evaluation of the effectiveness of the existing metrics after they have been used for a
given period of time.
7 Add required metrics. New Metrics The New Metrics component is not a component on its own, but rather an updated version of the whole document, including all new
indicators, measures, metrics, etc.
Back to Top
APPROACH
This task is executed both in the Initiate and Maintain and Evolve phases of Envision. During Initiate, you execute steps 1 through 5 above. You execute the last two steps during Maintain and Evolve.
The task is a part of the process to align the enterprise to its visions, goals and objectives that hopefully will be achieved through one or multiple projects or programs.
Initiate
REVIEW ENTERPRISE VISION
During this step, you look into the enterprise vision and IT strategy to determine candidate measurement areas that are relevant for metrics collection, and thereby would become a part of their
instrumentation strategy. All the measurement areas should assist with monitoring and managing a core area of the IT strategy. Some examples of measurement areas are:
Engineering: Instrumentation of the engineering processes helps an organization become a more efficient and effective project factory.
Operations: Utilize instrumentation to solve challenging aspects, such as capacity planning and troubleshooting.
Maturity in a Specific Area included in the IT Strategy: Apply a variety of trend-based metrics to understand current and changing maturity levels.
Business Value: Link the underlying workings of IT to business value analysis so that a better understanding of how the IT strategy relates to business value can be attained. This can be used
to provide meaningful information used to guide future strategy changes.
You should note all the candidate measurement areas, including what kind of benefits are expected to be obtained through metrics collection for that area.
IDENTIFY EXISTING PAIN POINTS AND FINALIZE AREAS
When you have understood the enterprise vision and IT strategy, you should talk to the enterprise executives to pinpoint existing pain points in order to determine the final areas for metrics collection.
It may be that all areas eventually will be included for metrics collection, but that you need to prioritize where to begin based on the largest pain points.
Preferably, you should do this step using a brainstorming workshop with client executives representing each area. However, It might be difficult to find a time when all the required enterprise
executives are available at the same time. If you are able to use a workshop, make this the first step and then further elaborate into each area based on the agreed priorities. By doing this, you will not
lose momentum now that you have the required participants together in the same room.
DETERMINE GOALS AND SUB-GOALS
During this step, determine the goals and objectives that are relevant for the chosen areas for metrics collection. What is it that you want to measure, and what are the goals and objectives to measure
against?
Preferably, you should also execute this step using a workshop. This could be part of the same workshop as above, depending on the time available and how large the subjects.
As an aid for this step and the following steps, you may use the kind of traceability model as show in the picture below.
Determine the goals and how they relate to the vision for the metrics collection area. Discuss what the enterprise wants to achieve, and what they want to know as a result of the measurements.
Describe this as goals for the area.
For each goal, determine what needs to be done to achieve it, and formulate these as sub-goals. The sub-goals should be phrased and be at a level where it is possible to identify quantifiable
questions.
For example, if one of the goals is to increase customer satisfaction, a sub-goal can be to make the ordering procedure more effective. With this, it is possible to ask a quantifiable question, such as,
"How can we make the ordering procedure more effective?" The answer could be to respond to ordering calls within 15 seconds. However, when we look further into this example, we can see that the
question we just asked may not leave us with a quantifiable answer. We could also have answered to decrease the average respond time to ordering calls. Therefore, this maybe should have been
the actual sub-goal to leave for the next step. Instead, we should ask, What should the average response time be for ordering calls?, which requires a quantitative answer.
DETERMINE OBJECTIVES (KEY PERFORMANCE INDICATORS AND MEASURES)
When you have defined the goals and sub-goals for the measurement areas at hand, you should go even further and identify the objectives for each sub-goal. This could be a more time-consuming
effort and may also require other types of resources in order to get the objectives as definitive as possible. If possible, you should also execute this step using a workshop, preferably one workshop for
each area where you invite participants with in-depth knowledge of the subject (area) at hand.
During the workshop, determine the quantifiable questions and answers to those questions, that is, the indicators. Using the previous example, we discussed to which level we should detail the sub-
goals and that a question may be quantifiable or not depending on how you answer it. The first example question was How can we make the ordering procedure more effective?, while the actual
quantifiable question was What should the average respond time be for ordering calls?, which requires a quantitative answer.
Formulate the questions with How many.., How much, How long, etc. If this is not possible, you probably need to identify a next level of sub-goals. For example, using the same question,
How can we make the ordering procedure more effective? we said that the answer could be to respond to ordering calls within 15 seconds. However, additional sub-goals can be identified for this
question, such as to more frequently reuse/copy old orders for repeating customers with same/similar orders and to provide accurate information about delivery time to the customer.
When you have your quantifiable questions, it should be relatively easy to identify the actual measures you need for each question. A measure is what you actually need to measure to determine
whether you have reached the goals and objectives you have set. In our example above where we had the question What should the average response time be for ordering calls? we can easily see
that we need to measure response time, i.e., the time difference from the time that the call was initiated, until the time the call was answered. Therefore, the measure is response time.
DETERMINE METRICS COLLECTION AND REPORTING STRATEGY
When you have determined the goals, and what you should measure to determine whether the goals have been reached, or whether there is a positive trend towards reaching the goal, then you
should determine how the measures should be collected, and what kind of calculations are required, and how the results should be used and interpreted.
For each metric you should also determine how the result should be documented.
Please see examples for metrics, and metrics interpretation, in the technique guides listed in the technique guides section below.
Maintain and Evolve
During Maintain and Evolve, you execute the task somewhat different than you do during Initiate. However, you may get into the situation that you want to add a new area for which you need to define
some new metrics. If so, you will execute the same steps as you did for Initiate. The main objective for this task in Maintain and Evolve is to verify that the used metrics provide the results as desired,
and whether all the existing metrics still are relevant. If the result of existing metrics does not provide the answers you need, you would probably need to adjust the metrics. Maybe you will need some
new measures. Also, when you have reached a goal, and it has become a part of usual business, you may need to adjust the metric because it is outdated or you need to measure it against a higher
goal.
VERIFY EXISTING METRICS FOR RELEVANCE
When you have used the metrics for a while, it is time to evaluate the efficiency of the metrics. Once again, you should execute this step using a workshop.
Prepare for the workshop, so that all available information is on hand during the workshop. During the workshop preparation, start with each goal to determine what you actually wanted to measure
against, and for each goal collect all the measuring results, and provide an interpretation of the result. During the workshop, the participants should verify whether the results provided what they
actually need to measure success, or if there is a positive/negative trend towards the desired goal.
The objective for the workshop is to verify whether existing metrics provide what they need, or to identify whether they need any adjustments.
ADD REQUIRED METRICS
It may also be that some goals have changed, or that you notice that you need some additional metrics to be able to measure against a goal. If so, you should identify what kind of new metrics are
required, and document this in the same way as you have done for the other metrics.
Back to Top
This task has supplemental guidance that should be considered if you are executing a service based on the BPM Project Engineering view. Use the following to access the task-specific supplemental
guidance. To access all BPM Project Engineering supplemental information, use the BPM Project Engineering Supplemental Guide.
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.
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.
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
Enterprise Architect Discuss and agree with client enterprise architect on which business metrics should be collected and how. Refine collection and reporting based on
feedback.
100%
Client Enterprise Architect Work with the enterprise architect to discuss and agree on which business metrics should be collected and how. *
Back to Top
PREREQUISITES
Prerequisite Usage
Maturity Analysis and Recommendations Report
(ER.015)
The Maturity Analysis and Recommendations Report may be a good input to identify candidate areas for metrics collection.
Enterprise Research Findings (ER.040) The Enterprise Research Findings may help you identify candidate areas for metrics collection.
Business Strategy (BA.010) The Business Strategy is used to determine candidate areas for metrics collection.
Business-IT SLA Report (BA.065) Optionally, the Business-IT SLA Report may be used to assist in determining what measurement areas would be relevant for metrics
collection.
Back to Top
TECHNIQUES
Technique Comments
Service Engineering Process Monitoring If one of the areas you plan to instrument is the Engineering Process, and you are using SOA, this technique guide will help you in
adopting instrumentation for the purpose of monitoring and management over the service engineering processes.
Accelerating SOA Maturity If SOA Maturity is one of your measurement areas, then this technique guide provides a set of metrics used to measure and monitor
changes in SOA maturity.
Operational Troubleshooting If Operational Troubleshooting is one of your measurement areas, then this technique guide provides guidelines on how to perform
operational troubleshooting when using a service-oriented architecture.
SOA Capacity Planning If Capacity Planning is one of your measurement areas, then this technique guide provide guidelines for capacity planning when using a
service-oriented architecture.
Measuring SOA for Improved Business Value Use this technique to understand the role instrumentation can play in information gathering for the purpose of making improved business
decisions, as well as to assist in measuring the amount of business value generated through the IT strategy.
Workshop Techniques Handbook The Workshop Techniques Handbook provides detailed descriptions of various techniques for delivering workshops during client projects.
WORKSHOP_CHECKLISTS.DOC MS WORD - This file contains several sample workshop checklists that can be tailored for delivering workshops during client projects.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Metrics Collection and Reporting Strategy is used in the following ways:
to determine what kind of measures should be included to provide the required input to the various metrics
as a guidance on what kind of metrics are collected and how to interpret the results of the metric calculations
Distribute the Metrics Collection and Reporting Strategy as follows:
to all projects within the enterprise that touch on the areas included
to high-level enterprise management
Back to Top
QUALITY CRITERIA
Have all areas for metrics collection been properly founded in the enterprise vision?
Has a standard for metrics notation been defined?
Can all measurements be collected with adequate quality, i.e., can the measurements be trusted?
Have all calculations been properly documented?
Does each metric have a description on how the result should be documented?
Does each metric have a description on how each result should be interpreted?
Back to Top
BA.018 - ESTABLISH CURRENT BASELINE METRICS
During this task, you establish a baseline for measuring the metrics you have defined earlier in the Metrics Collection and Reporting Strategy (BA.017). This allows the
enterprise to measure subsequent performance changes against the baseline, and thereby to see what kind of changes are related to the current situation.
In this way, the enterprise is able to see the effect of various initiatives, or steps meant for improvement. In order to do this, you should always establish a baseline before
the initiatives or steps for improvement actually are executed or implemented.
ACTIVITY
BA.018.1
BA.018.2
Back to Top
WORK PRODUCT
Current Baseline Metrics - The Current Baseline Metrics contains actual figures for all the metrics that should be used to measure against a selected set of goals.
Back to Top
TASK STEPS
1 Review the Metrics
Collection and Reporting
Strategy (BA.017).
None
2 Determine how each
measurement should be
collected.
None
3 Determine the frequency of
metric capture.
Metric Capture Frequency The Metric Capture Frequency describes the frequency with which each metric should be captured. This
could be related to calendar or milestones.
4 Implement measurement
collection and metrics
calculation.
Measurement Collection and
Metrics Calculation
Implementation
The Measurement Collection and Metrics Calculation Implementation can be anything from software
components included or updated for measurement collection to implementation of manual procedures
for measurement collection.
5 Capture baseline metrics. Current Performance
Baseline
The Current Performance Baseline contains the actual baseline measurement for each metric.
Back to Top
APPROACH
Review the Metrics Collection and Reporting Strategy
Review the Metrics Collection and Reporting Strategy (BA.017) to see what kind of metrics have been defined and how they should be measured or collected. If possible,
each measurement should be collected automatically, without human intervention.
Determine the Frequency of Metric Capture
For each metric, determine the reporting frequency, as well as the frequency of collecting the measurements. Depending on the kind of measurement, and how it can be
captured, it may be an ongoing process that counts every incident of something, or it can be something that can be counted at any point in time, and still provide an
accurate measurement.
However, it is not likely that each metric needs to be measured on a continuous basis. Therefore, determine how frequent the metrics should be calculated and reported
upon. This could be by regular intervals, e.g., weekly, monthly, quarterly etc., or related to specific milestones. How large an interval should depend on the nature of the
metric. Consider the following:
How urgent you need to make adjustments if the result shows a negative trend. For example, if you just have implemented a customer service and you want to
know something about how that service is used, then initially you may want daily reporting intervals, as you want to quickly make adjustments if the result is not as
expected.
Whether you will calculate an average or absolute number. Obviously, if you are calculating an average, you will need a large enough numbers for a proper
average calculation. For example, if you are measuring the average time between an incoming call, and the time the call is answered, you will need a large
number of calls for a proper average calculation.
Whether the nature of what is measured is constant, or whether there are peaks or periods with low activity. For example, if you need to measure the time between
an incoming call and the time the call is answered in a call center, then it is likely that there are peak periods and periods with low activity. To get a representative
calculation, you need to have a large enough period so that it covers both peak and low activity periods.
Implement Measurement Collections and Metrics Calculations
When you have determined how each measurement should be collected, and the frequency of the metric capturing, then you should implement the measurement
collection, and how each metric should be calculated. Since the preferred implementation is automatic this implies that this most often will be done programmatically. For
example, if we should measure the time between an incoming call, and the time that the call is answered, you would need to ensure that the call module that handles the
call will record both the call initiation time, and the call response time. The data should be stored, and be used for the metrics calculation.
Capture Baseline Metrics
When each measurement collection has been implemented it is time to capture a baseline for each metric. Depending on the type of measurement, this can be done at a
single point in time, or over a given period. For example, in the example above where you want to know the time between the call initiation time, and the call response
time, this is probably needed to reach a goal to improve the average call response time. This means that you need to have a representative number of calls before you
have a proper baseline measure. Also, keep in mind peak periods or periods with low activity, just as you did when you determined the frequency of metric capture. For
those kinds of situations, use the same collecting period as the interval you have chosen when you determined the frequency of metric capture.
Back to Top
Back to Top
Enterprise Architect Facilitate the Business Requirements Workshop, interviews or meetings to implement measurement collections and reporting
strategy.
100%
Client Enterprise Architect Assist the enterprise architect with interviews or meetings to implement measurement collections and reporting strategy. *
Back to Top
PREREQUISITES
Prerequisite Usage
Metrics Collection and
Reporting Strategy
(BA.017)
The Metrics Collection and Reporting Strategy contains all the measurements and metrics for which the enterprise should maintain a
current baseline, including how the baseline should be reported and guidelines on how it should be interpreted.
Business Volumetrics
Report (BA.067)
Optionally, the Business Volumetrics Report may contain some baselines figures that are required and should therefore be reviewed as
a starting point if available.
Back to Top
TECHNIQUES
Technique Comments
Measuring SOA for
Improved Business
Value
Use this technique to understand the role instrumentation can play in information gathering for the purpose of making improved business
decisions, as well as to assist in measuring the amount of business value generated through the IT strategy.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Current Baseline Metrics is used in the following ways:
as a means to analyze the improvements for given areas as a result of implementing initiatives for improvement. The baseline is an indication for the current status,
the goal indicates where you want to be within the given timeframe, and using measures against the baseline allows you to see whether there is a positive or
negative trend towards goal achievement
Distribute the Current Baseline Metrics as follows:
to high-level enterprise management
to the persons who capture the measurements and compare them against the goals
Back to Top
QUALITY CRITERIA
Has the implementation of each measurement been properly documented?
Has each measurement been implemented?
Has the frequency of metric capture been properly documented? Does each frequency include a reason?
Has a baseline been documented for each metric?
Has each baseline been properly interpreted so that it is easy to understand and so it will relate to future baseline measurements?
Back to Top
BA.020 - DOCUMENT ENTERPRISE ORGANIZATION
STRUCTURES
During this task, you identify the organization structures for the enterprise. This includes an organization hierarchy showing the reporting structure in the organization, but
also locations, organization units, roles and responsibilities, relationships between organization units, and external organizations that interact with the business.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Organization Structures - The Enterprise Organization Structures defines the organization structure of the enterprise, including the organization units, the
relationship between those units, the roles and their responsibilities. It also defines all the locations the enterprise performs business, and its critical trading partners.
Back to Top
TASK STEPS
1 Identify and document the
organization structure chart.
Organization
Structure
Chart
- Organization
Units
This component is a picture of the Enterprise organization showing all the organization units, and how they
interrelate. Identify all the organization units.
2 Identify roles and
responsibilities.
Roles and
Responsibilities
The Roles and Responsibilities component describes the main roles and their responsibilities in the enterprise.
This is an important input to understand what kind of roles/persons are relevant to involve in the engagement.
3 Identify business functions for
each organization unit or
business role.
Business
Functions
The Business Functions component describes what kind of business functions are owned within each
organization unit or business role.
4 Identify relationships between
organization units.
Organization
Structure
Chart
- Relationships
This component is a picture of the enterprise organization showing all the organization units, and how they
interrelate. Identify the formal and the informal relationships between all the organization units.
5 Identify locations. Locations The Locations component describes the locations that the enterprise uses in its business. It also shows which
organization units are located at each location.
6 Identify all critical trading
partners, both suppliers and
customers.
Critical Trading
Partners
This component describe all critical partners for the enterprise. One section describes the suppliers and what they
supply to the enterprise, and one section describes the key customers and what kind of relationship the
enterprise has to those customers.
Back to Top
APPROACH
Identify and Document the Organization Structure Chart
Work with stakeholders to acquire organization structure charts and documentation about key functions of each organization. Documenting the Present and Future
Organization Structures can be accomplished in several different ways. Depending on the size of the solution being developed, you can use interviews, meetings,
workshops, as well as a combination of these methods or a series of meetings and workshops. This task may be one of many tasks being addressed in a meeting or
workshop that is being held to gather business requirements.
Identify Roles and Responsibilities
Identify roles and responsibilities of each organization, in an effort to understand the projects in the IT Portfolio and business needs of each organization. The internal
organizations are often divided into groups or departments but they may be divided by physical location. Internal organizations are also known as business units. The
internal organizations captured are those that are potentially affected by the business objectives or the resulting IT portfolio projects. Make sure that you update or add to
the Enterprise Stakeholder Inventory (BA.015). Refer to the Capturing Stakeholder technique for more details.
Identify Business Functions for Each Organization Unit or Business Role
For each organization unit identify what high-level business functions are owned by the organization unit. Identify which business role is responsible for each business
function.
Identify Relationships Between Organization Units
Discover relationships between organizations to document business level interfaces and current cross organizational business requirements.
Identify Locations
Document the locations and logistics for each organization. You should understand any impacts this logistical information has on the business requirements, or the use of
technology to support the Enterprise.
Identify All Critical Trading Partners
Discover outside relationships to Trading Partners and any impacts this information has on the timing, technical formats and urgency of information exchanged. Trading
partners are external organizations. They are also known as external entities. External organizations captured are those that need to interact with the Enterprise in the
course of conducting business.
engagements.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Elicit current organization structures from client resources, mediated and reviewed by the client enterprise architect. 100%
Client Enterprise Architect Work with the enterprise architect and mediate and review organization structures.
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Research Findings (ER.040) Use the Enterprise Research Findings as an aid to identify the organization structures.
Enterprise Stakeholder Inventory (BA.015) Update the Enterprise Stakeholder Inventory as necessary.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques Handbook The Workshop Techniques Handbook provides detailed descriptions of various techniques for delivering workshops during client
projects.
WORKSHOP_CHECKLISTS.DOC MS WORD - This file contains several sample workshop checklists that can be tailored for delivering workshops during client
projects.
Back to Top
TEMPLATES AND TOOLS
BA-020_ENTERPRISE_ORGANIZATION_STRUCTURES.DOC MS WORD
Tool Guidance Comments
Example Example Note
Enterprise Organization Structures MS Visio
Back to Top
The Enterprise Organization Structures is used in the following ways:
as input to high-level use case diagrams
as input to capacity planning
as input to Network planning
to verify that impacted parts of the enterprise have been considered
Distribute the Enterprise Organization Structures as follows:
to all participants
to the project team
Back to Top
QUALITY CRITERIA
Have all of the identified organization units been described?
Has information on enterprise locations been recorded?
Do the organizational units correspond to those defined in the Business Context Diagram (BA.045)?
Back to Top
BA.025 - DETERMINE OPERATING MODEL
During this task, you validate the organizations Operating Model to see how it potentially should change to best support the enterprise Business Strategy. The Operating
Model should define the organization and their capabilities in terms of its required levels of process integration and standardization in support of the Business Strategy.
thus, the Operating Model represents how an organization operates across the process, organization, and technology domains.
Enterprises are differentiated by, and often defined by, their business processes; an enterprise's Operating Model is a reflection of its business processes. The Operating
Model context is typically comprised of the following forces:
the level of standardization found in an enterprise's core business processes,
the level of integration found in an enterprise's core business processes, and
the function of enterprise IT as either just a supporting role or as a leading role with direct revenue responsibility.
The direction and magnitude of these forces should be identified during this task. You should also identify any potential necessary adjustments to the Operating Model
that may be necessary for the engagement supporting the Business Strategy.
ACTIVITY
Back to Top
WORK PRODUCT
Validated Operating Model - The Validated Operating Model includes information about the current Operating Model, and how it may need to change regarding levels of
standardization and integration that IT must deliver to support the business capabilities and their operations as defined by the Business Strategy. It allows the
organization and architect to understand the potential scope and constraints for delivering IT services through a common set of processes and resources.
Back to Top
TASK STEPS
1 Define the Current Operating Model. Current
Operating
Model
The Current Operating Model shows the model that supports the current business.
2 Validate the Current Operating Model. Operating Model
Challenges
The Operating Model Challenges describe any challenges that exist in the Current Operating Model that
need to change to best support what the business wishes to accomplish.
3 Refine the Current Operating Model to
depict the desired future state.
Future State
Operating
Model
The Future State Operating Model shows the model that is required to best support the desired future
state in line with the Business Strategy.
Back to Top
APPROACH
Define the Current Operating Model
Obtain any material relevant for defining the Operating Model for the current state of the enterprise or organizational unit under study. In the Operating Model, you should
visualize a simple representation of the level of integration and standardization of the enterprise core business processes, and how the IT ownership resources that
support each business process are placed within the organization.
Review the Enterprise Organization Structures (BA.020), the Analyzed Capabilities (EA.040), and the Funding Model (GV.090) in order to:
Identify the business areas that are unified and funded across the enterprise.
Per Line of Business (LOB), identify the high-level business functions they support, and how each of them operates.
Are the processes standardized across other LOBs that share the same business function?
Are processes integrated?
How are they funded?
Identify how each business function is supported by IT.
Are IT resources owned by the LOB, or shared across the enterprise?
Depict the result in a model representing the Current Operating Model.
An example Current Operating Model follows:
Validate the Current Operating Model
Review the Business Strategy (BA.010), and identify areas of the Operating Model that may need to change to support the strategy. Together with the enterprise, review
the Current Operating Model and identify business capability operations that need to change due to shifts in strategy. Review the Operating Model for each of the
following areas:
business
applications
information
technology
governance
Determine the level of standardization/integration on a scale from siloed (lowest level of standardization/integration within the enterprise) to modular (highest level of
standardization across the enterprise), and where the Operating Model needs to be for each area to best support the Business Strategy.
Consider using an Operating Model Matrix. In the matrix, you identify the current and desired future state for each area. An example Operating Model Matrix follows:
Refine the Current Operating Model for the Desired Future State
Once you have depicted the Current Operating Model and captured the desired future state, you will be able to identify the challenges needed to support the Business
Strategy. Refine the Operating Model to depict the future state, and what business capabilities support different Operating Models, where applicable. Identify the
implications to the organization in terms of capability and operational changes that will be required to reach the target state. Use the same areas as mentioned in the
previous step (Business, Applications, etc.). Describe the current state of the Operating Model for each area, what the proposed changes are and what the implications of
those changes are. For each implication, define the objective benefits to be achieved through the change. Align and discuss these changes with the enterprise in terms of
the business objectives and support for business initiatives. An example follows:
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Lead the documentation of the Current Operating Model and the validation and definition of the improved Future State
Operating Model.
100%
Client Stakeholders This task requires input from client stakeholders that are key decision makers in the organization, including input from the C-
level executives responsible for the Operation Model to ensure that the Validated Operating Model reflects the current situation,
and that any potential changes are feasible.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Review the Business Strategy to identify the impact on capabilities supporting by the Validate Operating Model.
Enterprise Organization Structures (BA.020) Use the Enterprise Organization Structures to identify the LOBs in the organization.
Analyzed Capabilities (EA.040) Use the Analyzed Capabilities to identify the capabilities the Operating Model should support.
Funding Model (GV.090) Use the Funding Model to identify how resources are funded throughout the enterprise.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLSs
Enterprise Architecture Resources The Enterprise Architecture Resources contain additional information that can be useful in completing this task.
Back to Top
The Validated Operating Model is used in the following ways:
to identify capabilities, and operational and organizational change introduced through the maturation of the architecture associated with the introduction of new
technology capabilities to the IT architecture
to identify risks related to the changes
to identify necessary people, process and capability changes that are required to mitigate the risk following the change.
Distribute the Validated Operating Model as follows:
to enterprise stakeholders (all participants) who provided information and validated the Operating Model
to Envision team member who will work on subsequent activities during the Envision engagement
Back to Top
QUALITY CRITERIA
Has the Validated Operating Model been validated by the enterprise stakeholders?
Does the Validated Operating Model discuss all the aspects impacted by the Operating Model, such as the business, applications, information, technology and
governance, even when no change is required?
Does the Validated Operating Model describe the implications of the required changes?
Does the Validated Operating Model describe the business benefits as a result of the changes in business terms?
Back to Top
BA.030 - DEVELOP ENTERPRISE GLOSSARY
This is an ongoing task in which you document all definitions of the terms that are used in the business that are relevant for the Envision engagement in a single
document or repository. Include a separate section aimed at documenting the customer's Enterprise Architecture Taxonomy, i.e., the architectural terms/acronyms used
at customer site. This document should be created from the outset of the customer opportunity (pre-sales or delivery) to ensure consistency in Oracle/customer
communications.
The terms in the Enterprise Architecture Taxonomy section are technical terms rather than the business terms that are included in the main Enterprise Glossary. It is
important to keep them separate as there are potentially two different audiences (i.e., one more business focused, the other more technically focused).
ACTIVITY
BA.030.1
BA.030.2
Back to Top
WORK PRODUCT
Enterprise Glossary - The Enterprise Glossary contains two sections:
The Glossary contains a list of definitions, with cross-references to other definitions.
The Enterprise Architecture Taxonomy is a list of architectural terms/acronyms used at customer site.
This list is used as a reference throughout the organization, and should be updated whenever new terms are introduced into the enterprise. The Enterprise Glossary helps
to ensure that the terminology used throughout the enterprise is both consistent and meaningful to everyone in the enterprise.
Back to Top
TASK STEPS
1 Create Glossary Repository Enterprise
Glossary
This may be a document, or a repository where you document the relevant terms for the enterprise. If you have
created a Repository of Artifacts (IP.005), you would store the Enterprise Glossary in this repository.
2 Update glossary definitions. Updated
Enterprise
Glossary
Whenever a new term is identified, determine the definition for the term, and include it in the Enterprise Glossary.
3 Review existing technology-
and architecture-related
customer documentation.
None
4 Assemble list of unique
technology- and architecture-
related terms for customer.
Architectural
Terms
The Architectural Terms are an alphabetical list of technology and architectural terms/acronyms used at customer site.
5 Review Architectural Terms
with customer.
Enterprise
Architecture
Taxonomy
The Enterprise Architecture Taxonomy is the reviewed alphabetical list of architectural terms/acronyms used at
customer site.
6 Distribute Enterprise Glossary Published
Enterprise
Glossary
It is important that the Enterprise Glossary, including the Enterprise Architecture Taxonomy, is available to everyone
that needs to understand the enterprise terminology. Often, an access to the Enterprise Glossary through the
organizations intranet is an effective way to make it easily available for everyone.
Back to Top
APPROACH
This task is ongoing throughout the Envision engagement. Document relevant terms as they appear, and make them available to all interested stakeholders.
Try to get the Enterprise Glossary published on the intranet as soon as possible. This might encourage employees of the enterprise that have not yet been involved to
participate in providing definitions and correct flaws. To secure the life span of the glossary you are also encouraged to hand over the responsibility of maintenance to the
customer enterprise intranet webmaster as soon as convenient.
While the Enterprise Architecture Taxonomy is positioned within the Enterprise Architecture holistic domain and has direct implications for the Information Architecture, the
scope is the whole enterprise and governance skills are needed to define Enterprise Architecture-wide accepted taxonomies.
The definition of taxonomy from wikipedia, in short Taxonomy is the practice and science of classification.
13
Sometimes enterprise architects (professors) use the word
Ontology. This also classifies things / phenomena, but more from a philosophical perspective. Modern tools can be used to document taxonomies.
Creating the Glossary
This may be a document, or a repository where you document the relevant terms for the enterprise. If you have created a Repository of Artifacts (IP.005), you would store
the Enterprise Glossary in this repository.
Whenever a new term is identified, determine the definition for the term, and include it in the Enterprise Glossary.
Creating the Enterprise Architecture Taxonomy
REVIEW EXISTING CUSTOMER TECHNICAL ARTIFACTS
Review currently available technical documentation (produced by the customer and/or consulting organization) to develop a detailed understanding of the current
technical environments and the specific technical terms relevant to customer only.
Review existing customer architecture related documentation (i.e., Business Architecture, Information Architecture, Data Architecture, etc.) as well as more generic IT
documentation (e.g., Service Catalog, project lists, etc.) and even existing consulting organization-created collateral to derive specific technology related taxonomy
information.
Prepare a bottom-up inventory of all the words / definitions / phrases. Tools, such as, UBMatrix can be used to accomplish this.
However, start with a top-down approach with the mission, vision, strategy and the operating model. Take the value-chain into account. The Taxonomy is not only used
internally, but will have great benefit communicating with customers, suppliers and partners.
Not all business operating domains / information domains will be interesting enough to define an official taxonomy. A business case has to be built for the business /
information domains that are good candidates for this task. This business case should be derived from the Business Strategy.
DEVELEP ENTERPRISE ARCHITECTURE TERMS
Define list of customer-specific technical terms and place them in the Enterprise Architecture Taxonomy.
REVIEW ENTERPRISE ARCHITECTURE TERMS WITH CUSTOMER
Review and validate the list of terms with the customer and then update term definitions as relevant to ensure general understanding of term within an Oracle (Cross Line
of Business) XLOB community. Add sufficient terminology descriptions to ensure all Oracle staff can understand the customers terminology.
This task is ongoing throughout the Envision engagement. Document relevant terms as they appear, and make them available to all interested stakeholders.
engagements.
Back to Top
Enterprise Architect Develop and maintain the Enterprise Glossary. 100%
Client Enterprise Architect Work with the enterprise architect to develop and maintain the Enterprise Glossary *
Back to Top
PREREQUISITES
Prerequisite Usage
Customer Envision Engagement Strategy
(ER.010)
Envision Engagement Strategy (ER.020)
Business Scope (BA.012)
(BA.020)
Envision Engagement Plan (ER.030)
Enterprise Research Findings (ER.040)
As these work products are produced, you may come across terms that need to be defined. Include these terms in the
Enterprise Glossary or the Enterprise Architecture Taxonomy, as appropriate.
Existing Reference Material (ER.080) Review existing business-related materials to provide context for the Enterprise Architecture Taxonomy.
Enterprise Architecture Principles,
Standards and Guidelines (EA.010.1)

Maintained Repository of Artifacts (IP.080) Review any architecture-related artifacts for specific-architecture related terms that should be added to the Enterprise
Architecture Taxonomy.
Current Enterprise Architecture (EA.030) Use this work product to develop a good understanding of the Enterprise Architecture Components.
Back to Top
TEMPLATES AND TOOLS
BA-030_ENTERPRISE_GLOSSARY.DOC MS WORD
See Manufacturer's documentation UBMatrix third party non-Oracle software may be used for this task.
Back to Top
The Enterprise Glossary, including the Enterprise Architecture Taxonomy, is used in the following ways:
to maintain consistency of terminology of the enterprise
as an explanation of terms to all project members
as a reference for the development of work products
Distribute the Enterprise Glossary, including the Enterprise Architecture Taxonomy, as follows:
to all Envision engagement team members (for example, as a dynamic, electronic document)
Back to Top
QUALITY CRITERIA
Have all of the identified terms been explained with a proper definition, preferably with examples?
Back to Top
BA.040 - CREATE ENTERPRISE FUNCTION OR PROCESS
MODEL
During this task, identify the enterprise functions or processes. This is often done in parallel, or back-and-forth with the creation of the Enterprise Domain Model
(BA.050). The Enterprise Domain Model may provide input and be an aid to identify the functions or business processes, and vice versa, the identification of functions or
business processes may provide input to the Enterprise Domain Model.
At the very highest levels, the function and process models are the same, as they both identify the enterprise functional areas to further detail.
Once agreed, just enough process modeling principles should be taken into account for high-level enterprise and solution architecture engagements, i.e., at a sufficient
level to be able to identify the relevant architectural components in a Current State architecture definition exercise or the architectural improvement options in a Future
State architecture definition exercise. In this case, you would not typically define a business process beyond the logical level (i.e., Level 3 on the diagram below).
In functional modeling, you identify enterprise function levels in a way that is identical to the strategic approach of business process modeling. However, functional
modeling does not prescribe how you actually model the business process flows (level 2 and below). You may also choose to capture the flows as scenarios in a use
case model for detailing the lower levels. In other words, functional and business process modeling are one and the same up to level 1.
See the Functional or Process Modeling technique for more details.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Function or Process Model - The Enterprise Function or Process Model documents the sets of business functions or processes that are organized into
levels where each level is comprised of functions or processes of a similar type. The model includes the following:
a strategy describing the chosen approach to enterprise modeling
a catalog describing all enterprise-level functions or processes
descriptions of the functions/processes
and optionally,
an event catalogue describing what triggers each enterprise process
business process flows that visualizes the flow of each enterprise process
CRUD-matrix that shows how the business entities are used by each business function/process
Back to Top
TASK STEPS
1 Choose either functional or
process modeling strategy.
Functional or Process
Modeling Strategy
The Functional or Process Modeling Strategy describes which modeling strategy you have
chosen and whether you are using a strategic or tactical approach.
If functional modeling or a strategic approach to modeling is chosen, perform the following steps:
2 Perform high-level functional
modeling.
Enterprise High-Level
Function or Process Model
The Enterprise High-Level Function or Process Model contains the level 1 and 2 functions or
processes of the enterprise.
3 Update Enterprise Repository
Taxonomy.
Updated Enterprise
Repository Taxonomy
The updated Taxonomy of the Enterprise Repository now includes the classifications that were
identified during the previous step.
4 Update Enterprise Repository. Updated Enterprise
Repository
The Updated Enterprise Repository includes the Enterprise Function or Process Model you have
created. The Functions are assets in the Repository.
The following additional steps are only performed in the context of business process modeling. They may not be performed at the enterprise level where the
functional modeling may be sufficient or they may be performed in a second iteration in which a limited set of business processes have been scoped.
5 Identify key events for business
processes.
Process Event Catalogue The Process Event Catalogue lists, for each process, every event that triggers the process, from
where the event is initiated, and the frequency of the event.
6 Create/update process models. Process Models This component shows the business processes visually as a flow.
7 Identify key events for business
processes.
Process Event Catalogue The Process Event Catalogue lists, for each process, every event that triggers the process, from
where the event is initiated, and the frequency of the event.
8 Identify CRUD matrix to the
Domain Model.
CRUD Matrix The CRUD Matrix shows what business entities are used and how they are used for each
business process and each step in the process.
Repository
The Updated Enterprise Repository contains the updated assets you have changed or created.
Back to Top
APPROACH
This task is often done in parallel, or back-and-forth with the creation of the Enterprise Domain Model (BA.050). It is often accomplished through one or more
workshops. The approach taken is largely dependent on the nature/scale of the engagement. Wherever possible, Just enough principles should be adopted to ensure
business processes/business functions are defined at the relevant level to support the nature of the exercise. For example, for the initial enterprise and solution
architecture discussion, you may need to limit the definition of business functions/processes to support high level architectural improvement component mapping to
business functions/processes. In such cases, you would normally only define processes up to Level 3 (i.e., Logical Level only see diagram below).
Definition of Business Function and Business Process
There is a recurring debate on the definition of functions and processes at different levels of the architecture. In addition, product focused perspectives with tools such as
BPMs (workflows), BPEL (workflows and automated sequencing of function points) blur the definitions of these further. The COSMIC functional size measurement
methodology (ISO/IEC 1976) may prove useful in defining this further based on the behavioral characteristics of distributed processing.
Common opinion for the distinction in the public domain is summarized as:
Function = Individual building block
Process = Blueprint that either shows how the individual blocks work together OR Series of activities that use individual blocks
Function Definitions:
1. the purpose or role for which an object or a person is particularly used or suited
2. a factor or quality that is dependent upon one or more other factors or qualities
Process Definitions:
1. a systematic sequence of actions used to produce something or achieve an end. example: the assembly-line process
2. a continuous series of changes, functions, or operations. example: the process of growing up
3. movement onward or forward; progression
Therefore, the definitions largely depend on the roles of the stakeholders within an enterprise. For example, we can further refine the modeling process to factor in both
human centric workflows (which tend to be more visible to the business) and automated ones (which tend to be defined by the business but is more visible in the realm of
technologists) as illustrated in the following two diagrams:
The diagram above illustrates a long lived multi-step process that involves human interaction. Each step of the process must be persisted and re-instantiated when next
activated and typically demand a BPM. The following diagram illustrates a short-lived business process.
This type of process might be initiated by a user, but is automated from an end-to-end perspective and is more likely to use BPEL PM (although, the latter also supports
human workflows). Application developers may refer to process as being a collection of flows or invocations of APIs.
In summary, we need to establish a common understanding of these terms with the customers business stakeholders prior to engaging in this exercise.
Chose Functional or Process Modeling Strategy
It is not uncommon for an enterprise to have already identified and prioritized a number of processes or functions that they wish to use as part of a business modeling. In
such a scenario, the enterprise probably has already developed a process analysis approach to be followed.
If not, begin by determining whether you want to model the business processes or simply the business functions of the enterprise. You should also decide whether you
want to take a strategic approach or a tactical approach (see below).
Process modeling or functional modeling may be done iteratively providing more and more information to the models, either for each iteration providing more details to
each function/process, or to cover a larger part of the enterprise, that is to add functions/processes. There may be different purposes for each modeling exercise, for
example to determine the boundaries for one or more projects, or as a means to determine requirements, already within a given boundary.
ENTERPRISE FUNCTIONAL MODELING
If the enterprise has not taken a business process approach, you may want to perform enterprise functional modeling outside the context of business processes. In this
case, you decompose the enterprise into business functions, without necessarily modeling processes diagrams but using other techniques for the lower levels such as
UML use-case analysis.
STRATEGIC APPROACH
Taking a strategic approach means that you will start off identifying the top level business functions of the enterprise, and identify the details from there. The strategic
approach for both functional and business process modeling is almost identical. Regardless of the approach, analyzing the first three levels of the functional hierarchy
results in the same thing: the business is decomposed into functional areas which perform business processes (dont think of the Business Process from a BPM Tool
sense, but rather the way businesss conduct their business). The difference is that the BPM approach assists an organization in choosing particular business processes
to undertake, the functional approach assists with choosing one or more projects. A project may tackle only specific parts of one or more functional areas of business
processes.
If you have decided to take a strategic approach to identifying business processes or functions, then you can use a function model decomposition approach to assist in
selecting suitable business process(es) that align/assist with the enterprises business goals and objectives. At this level, we do not go into great detail about function
model decomposition.
TACTICAL APPROACH
In contrast to the strategic approach, it is also possible to proceed by selecting low-hanging fruit business processes or functional areas. For business processes, it is
often related to current pain points, while for functional modeling it is often related to one or more already identified projects that determine the scope of the functional
modeling approach.
This tactical approach can be used to gain visibility and to gain senior management commitment for future project work.
If you have chosen a tactical approach to process identification, or functional area selection, is appropriate then a quick decision process is made on which business
process(es) or functional areas to concentrate on. These can be derived from project requirements or current pain points.
Select Tactical Processes or Projects
When taking a pure BPM approach to selecting tactical processes, enterprises tend to select a business process which is documented within the project requirements, or
focus on an existing process or set of processes that are causing the organization pain today. Similarly, with a functional approach, the projects determine the functional
areas that get the immediate attention based on pain points.
Organizational pain can include:
Takes too long to execute
Requires heroics by subject matter experts to complete
Costs too much to execute
Causes customer dissatisfaction
Is inconsistently performed
Produces inconsistent results
Exhibits impractical behavior
Ideally the processes or projects selected should achieve at least one or more of the organizations objectives. Selection based on low-hanging fruit tends to be driven in
a bottom-up approach and rarely includes senior management in the decision process. Successes using this approach serve to build early wins and establish
confidence.
Perform High-Level Functional Modeling
If you have chosen to perform functional modeling or strategic business process modeling, see the Functional or Process Modeling technique for more details.
Update Repository Taxonomy
Business functions are an obvious way to classify assets in the Maintained Repository of Artifacts (IP.080).
If a repository is used in the enterprise, and the high-level functional modeling has been performed, update the repository taxonomy based on the business functions
identified.
Update Enterprise Repository
If an Enterprise Repository is used, each component of the Function or Process Model should be inserted in the Enterprise Repository as assets linked to each other with
a hierarchy of relationship. Check the repository for existing models to avoid duplicates if this is not the first iteration. This step is in addition to the previous step of having
a taxonomy based on the Function Model.
This step is particularly important if requirements are managed at the enterprise level. Managing requirements at the enterprise level is a must where reuse across
projects is required such as it is when the enterprise is has a SOA strategy.
See the Enterprise Requirements Management technique for more details about enterprise management of requirements through function and process models.
Identify Key Events for Enterprise Processes
Once processes have been identified via either the strategic or tactical approach, you should be able to identify at least one key event that triggers each process. It may
be that multiple events trigger the same process. If you know the enterprise processes up front, ask what kind of events (internal and external) trigger the process, partly
or fully. If you do not know the processes up front, ask what kind of events (internal and external) to which the enterprise must respond.
Create/Update Model
In some cases, you may want to model business processes at the enterprise level, or you may chose to only model them at the project level. This step is only required in
the former case, and in most cases not for the whole enterprise but only after scoping has been refined.
Various modeling techniques are available. See the Functional or Process Modeling technique for more details. Choose the technique and tool that is most appropriate
for your situation.
Identify CRUD Matrix to Domain Model
If you have done domain modeling, it may also be of value to determine what business entities are used in what processes, and how they are used. You can use a CRUD
(Create, Retrieve, Update, Delete) matrix as a tool to determine this.
Update Repository
If a repository is used in the enterprise, update it by adding new models using the classification identified. Create the dependency links toward the earmarked models.
If requirements have been identified during this task, they should also be recorded in the Enterprise Repository and each of them linked to a function at one of the levels
in the model, that is a function, a business process, an activity, a step, etc.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
Back to Top
Enterprise Architect Elicit current enterprise functions and processes from client resources, mediated and reviewed by the client enterprise
architect. This task may require participation of an enterprise architect who specializes in Business Architecture.
100%
Client Enterprise Architect Work with the enterprise architect and mediate and review enterprise functions and processes. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy
(BA.010)
Use the Business Strategy to determine which processes are of relevance.
Business Scope
(BA.012)
Use the Business Scope to define where you should focus your efforts.
Enterprise
Organization
Structures (BA.020)
Use the Enterprise Organization Structures to understand the organization units for which the enterprise processes may be relevant.
Enterprise Glossary
(BA.030)
Use the Enterprise Organization Structures to understand the terminology.
Mandate Matrix
(GV.020)

Governance
Implementation
(GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
Enterprise Function or Process Models. In addition, ensure that the Enterprise Function or Process Model(s) is added/updated in the
repository.
Back to Top
TECHNIQUES
Technique Comments
Functional or Process Modeling This technique provides assistance in utilizing enterprise function or process models as a requirements gathering technique and
describes the different levels of business process models.
Functional Project Identification This technique helps to what projects will get the most out of an SOA approach.
Management
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
BA-040_ENTERPRISE_PROCESS_MODEL.DOC MS WORD
Example Comments
Enterprise Process Model
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
Resources
The Enterprise Architecture Resources provides links to additional resources that may be useful in completing this task.
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
Back to Top
QUALITY CRITERIA
Back to Top
BA.045 - DEVELOP ENTERPRISE BUSINESS CONTEXT
DIAGRAM
During this task, you develop the Enterprise Business Context Diagram. This diagram is used to depict a "high-level view" of the business and its external interfaces
(human and non-human). This diagram can be created during the sales cycle of an engagement or when starting the Inception phase of a project to help define the inputs
and outputs of a business and/or organization. This type of diagram is useful when first attempting to define the boundaries of a business. It is used to assess how our
systems can improve the client's business processes. For example, to depict the business context of a gas station. We could draw an Enterprise Business Context
Diagram that looks like this:

The Enterprise Business Context Diagram graphically represents the boundary of the business and its association with external entities called actors. An actor can be one
of 4 types (i.e., human, another system, a clock representing a time-based event, or a hardware device). These actors send and/or receive information or events to or
from the business. The key information represented on the association line between the actor and the business is at a summary-level and shows an arrow indicating the
direction of the information flow. Consider following UML modeling standards for this type of diagram.
Compared to the Business Scope (BA.012) where the scope of the engagement is identified as a summary of business functions/processes, applications, entities (or
whatever is the most appropriate for the engagement) the Enterprise Business Context Diagram provides a pictorial representation of the boundary of that scope.
If an enterprise repository is available and supports the management of models, register the model with the repository to allow dependency tracking to other models and
requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Business Context Diagram - The Enterprise Business Context Diagram depicts the boundaries of the business and the business actor interactions with the
business.
Back to Top
TASK STEPS
1 Determine the boundary of the business or the organization that you would like
to represent and draw a box with the name of that business or organization
inside.
Bounding
Box
This box represents the boundaries of the entity you are interested
in modeling.
2 Identify the actors (people, organizations, or other systems) which have a direct
relationship (or interaction) with the business or organization from step #1 and
label each actor with an appropriate role name (i.e., customer, night manager,
etc.).
Actors The actor symbol is drawn as a stick figure for humans or
organizations, a box for other systems or hardware devices, and a
clock for time-based events.
3 Identify key inputs and outputs from each actors point-of-view. Place this key
information on the line between the actor and the bounding box and label it with
an arrow indicating the direction of the information flow.
Key
Information
with
Directional
Arrows
The lines with arrows indicate the direction that the key information
flows. The words on the line should be nouns, indicating data
(not process).
4 Review available documentation and talk with subject matter experts (SMEs) to
ensure all actors have been identified.
Update the diagram for completeness.
5 Write a brief description describing the role and responsibility of each actor. Stakeholder
Description
This description helps to define the daily activities being performed
by that actor as they are related to the business or organization.
6 Identify the expectations of each actor regarding their future needs from the
business and/or organization.
Stakeholder
Expectations
This should be a bulleted list of high level goals or objectives that
each actor would expect to achieve from the business/organization
in the future (that is, Reduce Procure to Pay cycle from 14 to 7
days).
7 Register the model in the Enterprise Repository. Updated
Enterprise
Repository
The Enterprise Business Context Diagram has been added to the
Enterprise Repository with an asset type of UML model with any
relevant documents attached.
Back to Top
APPROACH
Enterprise Business Context Diagram Preparation
The Business Context Diagram represents a strategic view of the client's business. The diagram should not depict how technology will be used by the business, but
instead it shows the people, organizations, and key information that allow the business to operate (from an external point of view). One technique that is used for
accurately depicting the business is to hold a facilitated session with senior-level members of the team or a subject matter expert who knows about the business. Here
are the steps you should use for this brainstorming session:
1. Hold a 30 minute to 1 hour meeting with key stakeholders and/or subject matter experts to define the boundaries of the business.
2. Have one person draw the diagram while another person facilitates the brainstorming discussion.
3. Try to identify as many actors as possible, and postpone judgment on whether they are inside or out of the bounding box."
4. Once the actors have been identified, choose 1 actor at a time, and identify their information needs (both input and output).
5. Update the diagram with this information, making sure that the information placed on the model is at a summary level."
6. After each actors key information has been defined, briefly describe the role and responsibility from each actors point of view.
7. Identify a list of 3-5 expectations from each actors point of view.
This diagram is useful for understanding the as-is or the to-be business, however, it is recommended that you draw the Enterprise Business Context Diagram for the
to-be business.
The UML optionally allows you to indicate system actors with a rectangle and the <<actor>> stereotype. It is just another way of saying it is an actor, but some people
prefer to differentiate between human actors and actors that represent computer systems. On a business use case diagram, the business actors represent organizations
of individuals not systems.
If an Enterprise Repository is available, register the diagram by creating a new asset of type model. Fill in all properties and attach any further documentation created.
After finishing the model, provide it to the stakeholder for review. As soon as the model is agreed on, you can change the status of the model to validated.
Stakeholder Description and Expectations
As a result of preparing the diagram you include a description of each stakeholder and Identify two to three key expectations for each stakeholder. Update the Enterprise
Stakeholder Inventory (BA.015), as appropriate. Consider capturing stakeholders using the Capturing Stakeholder technique.
engagements.
Back to Top
Back to Top
Enterprise Architect Facilitate the brainstorming session and ask questions to help define the Enterprise Business Context Diagram. 100
Client Enterprise Architect Assist the enterprise architect with defining the Enterprise Business Context Diagram. *
Back to Top
PREREQUISITES
Prerequisite Usage
Governance
Implementation
(GV.100)
Enterprise Business Context Diagram. In addition, ensure that the Enterprise Business Context Diagram is added/updated in the repository.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
BA-
045_ENTERPRISE_BUSINESS_CONTEXT_DIAGRAM.PPTX
MS POWERPOINT - Use this template if you choose to create the Enterprise Business Context Diagram
in MS PowerPoint.
BA045_ENTERPRISE_BUS_CONTEXT_DIAGRAM.ZIP This zipped file contains an MS VISIO template and stencil to assist you in creating an Enterprise
Business Context Diagram in MS VISIO.
Example Comments
Enterprise Business Context Diagram MS Visio
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
The Enterprise Business Context Diagram is used in the following ways:
to help the sales or consulting team learn more about the client's business and stakeholder needs; thus better positioning them to assist the client in making
decisions about products and services that best support the business
to serve as a communication tool among the project team (and future project teams) to better understand the key information needs for each of the key actors
associated with the business
Distribute the Enterprise Business Context Diagram as follows:
to the client to demonstrate that the project team understands their business
to the project manager to help them determine the scope of the project
to the technical architect to help determine the external interfaces to other systems
to Quality Assurance to ensure test cases are written to include key actors
to the database designer to ensure key information is included in the database schema
Back to Top
QUALITY CRITERIA
Have all the external actors been drawn on the diagram?
Has the key information (input/output) for each actor been determined at the summary level?
Has the diagram been drawn using UML notation?
Back to Top
BA.050 - DEVELOP ENTERPRISE DOMAIN MODEL (BUSINESS
ENTITIES)
During this task, you identify the main business data entities and relationships between them that are of relevance to the enterprise and group them by business domains
in order to create the Enterprise Domain Model (EDM). This is often done in parallel, or back-and-forth with the creation of the Enterprise Function or Process Model
(BA.040). The Enterprise Function or Process Model may provide input and be an aid to identify the business entities.
In some circumstances, the Business Domain Model ( or Business Domains) may also be described as a Business Operating Model. Although there is no single
consistent definition of a Business Operating Model, the term is used to describe the organizational, geographical, political, industry specific nature dimensions that shape
an enterprise. This information is key to all enterprise and solution architecture Current State discovery exercises to ensure all the relevant information is captured. Any
future changes to the Business Operating Model captured as part of the discovery process will also help to shape the definition of the Future State architecture.
OUM provides two approaches to developing the enterprise data model, one starts directly with the entities and their relationships (called in this task the data relationship
approach), while the other starts looking at the existing data sources, and concentrates on data ownership (called in this task the data ownership approach).
It should be noted that detailed Data Model definition is not typically required for high level enterprise and solution architecture engagements where it is sufficient to
employ Just enough principles and limit the discovery effort to capturing information about the key (master) data entities and their relation to key organizational business
processes and governance procedures.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Domain Model - The Enterprise Domain Model shows the key business data entities within the enterprise, what the owning business domains are, and how
they are associated/related. Each business domain shows an area of relevance to the enterprise. The emphasis of the model is to capture domain knowledge. The
Enterprise Glossary may provide a starting point for relevant business objects (typically nouns).
Back to Top
TASK STEPS
1 Review engagement requirements for capturing the Enterprise
Domain Model employing the just enough principle in terms of
selecting the most appropriate data modeling approach.
None
2 Choose data modeling approach for the enterprise. Enterprise
Data
Modeling
Approach
The Enterprise Data Modeling Approach describes the chosen data modeling
approach and how it will be performed, that is, either the data relationship
approach or the data ownership approach; whichever best fits the engagement.
3 Review Industry Reference Models. Industry
Reference
Model
This component considers whether relevant Data Architecture resources are
already available. In particular, generic data models relevant to the organization's
industry "vertical" sector. For example:
The Department of Defense Architecture Framework (DoDAF) Logical Data
Model
ARTS Data Model for the Retail Industry
Energistics Data Model for the Petrotechnical Industry
TeleManagement Forum, Shared Information and Data Model (SID) for the
Telecommunications Industry
For more about Industry Reference Models, you may want review EA.002, Review
External Reference Architectures.
If you choose the data relationship approach, use the following steps:
4 Identify key data entities. Entity List The Entity List contains a list of key data entities.
5 Identify relationships between data entities. Relationships This component contains the key relationships between the key data entities.
6 Identify business domains. Domain
Model
This component contains the business domains and the relationships between
them. It also shows which key data entities and which business domain owns
relationships.
7 Update the Enterprise Repository. Updated
Enterprise
Repository
The Domain Model has been added to the Enterprise Repository.
If you choose the data ownership approach, use the following steps:
8 Identify key data sources. Data Source
List
The Data Source List contains a list of all systems, applications, and SOA services
that provide access to data.
9 Identify key data entities. Data Entity
List
The Data Entity List contains a list of all the data entities based on the data
sources that provide it.
10 Identify data authorities. Data
Authority List
The Data Authority List contains a list of who is responsible for the stewardship of
the data entities defined in the previous step.
11 Define the semantic communities. Semantic
Community
List
The Semantic Community List is a list of groups of people who have a shared
understanding of a set of related concepts.
12 Capture the Enterprise Data Model. Enterprise
Data Model
The Enterprise Data Model contains the actual business domains/data entities
and the relationships between them following the findings from the previous
steps.
13 Update the Enterprise Repository. Updated
Enterprise
Repository
The Domain Model has been added to the Enterprise Repository.
Back to Top
APPROACH
This task is often done in parallel, or back-and-forth with the creation of the Enterprise Function or Process Model (BA.040). It is often accomplished through one or
more workshops.
Chose Data Modeling Approach for the Enterprise
The data relationship approach may provide a more complete model as the relationships between the entities are clearly defined, but it can be a daunting task at the
enterprise level. It is more appropriate when the scope is limited and/or the initiative is data-driven.
Because the data ownership approach does not produce such level of detail, but instead looks at the distribution of the data across the enterprise, it may be preferable at
the enterprise level. It is especially desirable where data is to be used by multiple sources, such as it is in a SOA environment.
Carry Out Data Relationship Approach Steps
See the Enterprise Domain Model - Data Relationship Approach technique for more details on this approach.
Carry Out Data Ownership Approach Steps
See the Enterprise Domain Model - Data Ownership Approach technique for more details on this approach.
engagements.
Back to Top
Back to Top
Enterprise Architect Oversee the process of capturing the Enterprise Domain Model and provide input on the enterprise business
functions/processes that produce/consume the data.
20
Solution Architect
(information Architect)
Document the key business entities in sufficient detail. Preferably, this should be done by a solution architect that specializes in
Information Architecture.
80
Client Enterprise Architect Provide input on the enterprise business functions/processes that produce/consume the data. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Glossary
(BA.030)
Use the Enterprise Glossary to understand the terminology. The Enterprise Glossary may also provide a starting point for relevant business
objects (typically nouns).
Use the Enterprise Function or Process Model to identify the domains.
Mandate Matrix (GV.020) The Mandate Matrix lists which legislative drivers, standards and leading practices are relevant for the organization, and how the
organization describes the domains as a result of these legislative requirements.
Governance
Implementation (GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern
the Enterprise Domain Model. In addition, ensure that the Enterprise Domain Model is added/updated in the repository.
Back to Top
TECHNIQUES
Technique Comments
Enterprise Domain Model - Data Ownership
Approach

Enterprise Domain Model - Data Relationship
Approach

Enterprise Requirements Management This technique provides assistance on how to manage requirements at the enterprise level.
The Workshop Techniques Handbook provides detailed descriptions of various techniques for delivering workshops
during client projects.
MS WORD - This file contains several sample workshop checklists that can be tailored for delivering workshops
during client projects.
Back to Top
TEMPLATES AND TOOLS
BA-050_ENTERPRISE_DOMAIN_MODEL.DOC MS WORD
Example Comments
Domain Model
Tool Comments
Resources
Repository.
Back to Top
The Enterprise Domain Model is used in the following ways:
to identify how data is used across the enterprise
to identify how the key data entities interact with each other
to identify duplication of key data within the enterprise
to identify business ownership of data entities
Distribute the Enterprise Domain Model as follows:
to enterprise architects during an Enterprise Architecture Envision engagement
to the business stakeholders - owners of the data
to the data stewards
Back to Top
QUALITY CRITERIA
Have all the important data entities relevant to the scope of the Envision engagement been identified?
Have the data entities and their relationships been validated with key stakeholders?
Have the data entities been assigned to the appropriate business domains (when applicable)?
Have all of the data sources been identified?
Have multiple sources of master data been identified (where applicable)?
Have owners of the data entities been identified?
Back to Top
BA.055 - DEVELOP ENTERPRISE KNOWLEDGE FLOW
During this task, you identify the key knowledge requirements within the business and capture the relationships for information sharing between business capabilities and
processes at a high level. The Knowledge Flow represents the business knowledge used by the organization to operate and make decisions concerning the operations of
the business capabilities. Understanding of the knowledge needs of the business may provide insight into IT capabilities within the Application, Information and
Technology Architecture domains.
Depending upon the scope of the engagement, you may need to consider the development of high-level knowledge Information flow diagrams to capture the relationships
for information sharing between business capabilities and processes.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Knowledge Flow - The Enterprise Knowledge Flow documents the flow of knowledge in the organization and represents the business knowledge that is
needed and used by the organization to operate and make sound decisions concerning the operations of the business capabilities.
Back to Top
TASK STEPS
1 Determine information flow modeling
technique.
Information Modeling
Standard
The Information Modeling Standard documents how the information flow should be documented
at the enterprise level.
2 Identify key enterprise-level information
objects.
Information Objects The Information Objects cover the key enterprise-level information objects required to support
the enterprise-level business processes.
3 Determine the enterprise-level flow of each
information object
Knowledge Flow The Knowledge Flow displays how each information object flows through the enterprise
including status changes, when applicable.
Repository
The Updated Enterprise Repository contains the updated assets you have change or created.
Back to Top
APPROACH
This task is often done in parallel, or back-and-forth with the creation of the Enterprise Domain Model (BA.050), and the Enterprise Function or Process Model (BA.040). It
is often accomplished through one or more workshops. The approach taken is largely dependent on the nature/scale of the engagement. Wherever possible, Just
enough principles should be adopted to ensure the Enterprise Knowledge Flow is captured at the relevant level to support the nature of the exercise.
Review with the stakeholders specific business initiatives that require new capabilities, looking for opportunities where rapid and transitory knowledge requirements are
required by the business. Business activities that represent large scale changes in the amount of information may present additional capability requirements and
opportunities.
Determine Information Flow Modeling Technique
There are numerous techniques to illustrate the information flow at the enterprise level. Investigate what kinds of techniques have already been used in the enterprise,
and potentially choose one of those. Choose or create a diagramming technique that allows you to depict the information you need to present.
Identify Key Enterprise-Level Information Objects
Use the Enterprise Domain Model (BA.050) as a starting point to identify the most key information objects required for the operations of the enterprise as a whole.
Typically, these are information objects crossing departments, such as customer information or an order. Collaborate with the enterprise to ensure that the key
knowledge/information is captured. If you identify any information objects missing in the Enterprise Domain Model, you probably need to make an update to the
Enterprise Domain Model. Provide a short definition for each object.
Determine the Enterprise-Level Flow of Each Information Object
For each object, determine in collaboration with the enterprise, how the object flows through the enterprise. Use the Enterprise Function or Process Model (BA.040) as an
aid to identify the processes initiating, carrying or transforming the information, as well as to identify the business units owning the information.
Depict the flows using the information flow modeling technique determined in step 1. Include status changes where relevant, responsible business units and involved
business processes.
Update Repository
If an Enterprise Repository is used in the enterprise, update it by adding new models using the classification identified. Create the dependency links toward the
earmarked models. If requirements have been identified during this task, they should also be recorded in the Enterprise Repository.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Oversee the process of capturing the Enterprise Knowledge Flow. 20
Solution Architect
(information Architect)
Document the key parts of the Enterprise Knowledge Flow in sufficient detail. Preferably, this should be done by a solution
architect that specializes in Information Architecture.
80
Client Enterprise Architect Provide input on the enterprise business functions/processes that produce/consume the data. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Scope
(BA.012)
Use the Business Scope to define where you should focus your efforts.
Structures (BA.020)
Use the Enterprise Organization Structures to understand the organization units for which the information flow may be relevant.
Enterprise Glossary
(BA.030)
Use the Enterprise Glossary to understand the terminology.
Enterprise Domain
Model (BA.050)
User the Enterprise Domain Model to identify relevant information objects.
Use the Enterprise Function or Process Model to understand relevant business processes.
Governance
Implementation
(GV.100)
the Enterprise Knowledge Flow. In addition, ensure that the Enterprise Knowledge Flow is added/updated in the repository.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Resources
The Enterprise Architecture Resources contain additional information that can be useful in completing this task.
Repository.
Back to Top
The Enterprise Knowledge Flow is used in the following ways:
to understand the knowledge needs of the business, and thereby provide insight into IT capabilities within the Application, Information and Technology Architecture
domains
to understand how important knowledge flows through the organization with the purpose of identifying improvements
to identify knowledge owners
to understand knowledge transitions, and processes impacting the knowledge
Distribute the Enterprise Knowledge Flow as follows:
to enterprise stakeholders who participated in the creation of the Enterprise Knowledge Flow
to Envision team members who will work on subsequent activities during the Envision engagement
Back to Top
QUALITY CRITERIA
Does the Enterprise Knowledge Flow include the most important enterprise-level business objects?
Has the flow been determined, including the owning business units?
Have any status changes been documented where relevant?
Has the Enterprise Knowledge Flow been developed in collaboration with the enterprise?
Back to Top
BA.058 - DEVELOP BUSINESS ARCHITECTURE
During this task, you develop the Business Architecture in order to subsequently communicate and demonstrate the value to be delivered through the engagement at
hand. The goal is to capture and validate the Business Architecture to be supported. The Business Architecture should help to:
Understand where and to what extent the results of the current initiative can support the business goals, processes, and capabilities of the organization.
Understand how the business operates to ensure that the results provide meaningful value to the enterprise.
Better understand the business benefits and value expected to be received.
The Business Architecture should provide the foundation for what should be delivered as part of the engagement.
Business Architecture Perspectives
Business Architecture perspectives provide the enterprise architect with the required visibility into how the organization operates and how the IT architectures need to be
responsive to the organization. The purpose of defining the Business Architecture is to define the optimal set of business capabilities to realize the vision and the strategic
objectives of the organization. Below are some Business Architecture perspectives that should be considered:
Goals and Objectives What are the organizations business goals and objectives, and how do they apply to the current engagement? How are the business
goals and objectives translated into IT goals and objectives?
Capabilities What capabilities does the organization need to support the business objectives and operating model?
Organization How is the organization structured to support the business capabilities applied to delivery of services and products to their own customers?
Understanding this provides the ability to define how to structure IT capabilities, IT resources and IT services in support of these activities. Understanding the
strategic impact and value of IT in the fulfillment of the business capabilities provides us with an objective evaluation of impact and any constraints the application
of these capabilities have, and where they provide the appropriate balance of efficiency and operational agility.
Process How does the business organization obtain IT resources, and how do they plan and budget for these capabilities? How will the business processes be
impacted and their underlying applications in support of the business objectives and goals for operating efficiency or business agility?
Knowledge When, what, and where information resides within the organization, and the qualities of knowledge availability and access, allows us to understand
what kind of services and capabilities are required to support the business knowledge requirements, and their impact upon the development of the Information
Architecture.
Performance Understanding how the organization measures their attainment of goals and objectives is provided through the Performance View. Definition of IT
performance metrics in the context of the business operations provides the ability to define the effectiveness of IT service delivery and investment.
In short, the Business Architecture is the foundation for defining the requirements for what the organization should accomplish as a result of the engagement. The
Business Architecture defines the strategy of the organization, and how the organization is structured and operates in support of their strategy. The services and
capabilities delivered within the IT architecture must be defined to support the structure, operations, and objectives of the Business Architecture. Successful adoption or
development must demonstrate alignment to the business and return on objective value in the delivery of IT capabilities and resources.
ACTIVITY
Back to Top
WORK PRODUCT
Business Architecture - The Business Architecture documents elements of the Business Strategy and Principles that are within scope of the Business Architecture's
components. It contains a number of business views:
Business Strategy and Principles View, including the vision, goal and objectives
Business Capability View
Business Organizational View
Business Process View
Business Knowledge View
Business Performance View
The Business Architecture work product also contains a Value Hypothesis and consolidates (or incorporates) a number of earlier produced work products as indicated in
the task steps below.
Back to Top
TASK STEPS
1 Establish scope of
Business Architecture.
Business
Architecture
Scope
The Business Architecture Scope documents the business scope of the engagement. This is developed through the
execution of the task, Define Business Scope (BA.012)
2 Identify Business
Strategy and
Principles.
Business
Strategy and
Principles
The Business Strategy and Principles documents the parts of the Business Strategy and Principles that are relevant for the
engagement. It documents the vision, goals and objectives, and therefore provides the foundation for the Business
Architecture. This is developed through the execution of the task, Identify Business Strategy (BA.010).
3 Create Business
Capability View
Business
Capability
View
The Business Capability View documents which business capabilities that the organization needs to execute its strategy,
how they are prioritized, and an analysis of the aspects of each capability that are relevant for the engagement. This is
developed through the execution of the task, Analyze Capabilities (EA.040).
4 Create Business
Organizational View.
Business
Organizational
View
The Business Organizational View documents the current and future Operating Model, the organization structures, and the
Funding Model. This is developed through the execution of the following tasks:
Document Enterprise Organization Structures (BA.020)
Determine Operating Model (BA.025)
Determine Funding Model (GV.090)
5 Create Business
Process View.
Business
Process View
The Business Process View documents, typically through process models, how the organization operates to produce
certain outcomes, and who is responsible. This is developed through the execution of the task, Create Enterprise Function
or Process Model (BA.040).
6 Create Business
Knowledge View.
Business
Knowledge
View
The Business Knowledge View documents the business knowledge used by the organization to operate and make
decisions concerning the operations of the business capabilities. This is developed through the execution of the task,
Develop Enterprise Knowledge View (BA.055).
7 Create Business
Performance View.
Business
Performance
View
The Business Performance View documents how and what should be measured to provide insight and information
concerning how effectively the business is operating against their defined strategy and business operations. This is
developed through the execution of the task, Determine Metrics Collection and Reporting Strategy (BA.017).
8 Propose Value
Hypothesis
Value
Hypothesis
The Value Hypothesis documents what kind of benefits are expected to be achieved as a result of the chosen strategy
related to the engagement. This is developed through the execution of the task, Perform Benefit Analysis (ER.110).
9 Compose the
documentation and
write the Executive
Summary.
Executive
Summary
The Executive Summary summarizes the most important aspects from the other sections.
10 Present the Business
Architecture
Business
Architecture
Presentation
The Business Architecture Presentation describes the Business Architecture and is targeted for high-level management.
Back to Top
APPROACH
Develop the Business Architecture is done using an iterative process of discussions of how the business operations in support of the enterprise business strategy and
objectives and reviews of relevant existing documents. Iterate among the following tasks for the following components:
EA.040 - Analyze Capabilities for the Business Capability View
BA.020 - Document Enterprise Organization Structures, BA.025 - Determine Operating Model and GV.090 - Determine Funding Model for the Organizational View
BA.040 - Create Enterprise Function or Process Model for the Process View
BA.055 - Develop Enterprise Knowledge Flow for the Knowledge View
BA.017 - Determine Metrics Collection and Reporting Strategy for the Performance View
Establish Scope of Business Architecture
Execute this step with task, Define Business Scope (BA.012), and provide a reference to the resulting work product. Keep in mind that the Business Architecture could
provide different levels of detail based upon the scope of the engagement. The Business Architecture could be represented at a high level to help communicate the
potential for risks encountered that do not take into account the operations and organizations of business processes and capabilities. It may also be that the Business
Scope has already been defined, and thus the scope of their initiatives. In these cases, ensure that you adjust your approach to focus on those areas as appropriate,
while still remaining cognizant to other opportunities that might be found in related business areas. If BA.012 has already been executed, verify that the Business Scope
defined is an exact match to the engagement at hand, otherwise you need to revise the Business Scope.
Identify Business Strategy and Principles
It is important to understand the parts of the Business Strategy and Principles that are relevant for the current initiative. You need to have a thorough understanding of the
vision, goals and objectives that provide the very foundation for the Business Architecture. Execute this step with task, Identify Business Strategy (BA.010), and provide a
reference to the resulting work product.
Create Business Capability View
Execute this step with task, Analyze Capabilities (EA.040), and provide a reference to the resulting work product.
Create Business Organizational View
When creating the Business Organizational View, use the following tasks:
Document Enterprise Organization Structures (BA.020)
Determine Operating Model (BA.025)
Determine Funding Model (GV.090)
Understanding the Operating Model of the organization provides key information in defining an IT architecture that is consistent with the integration of business
processes, the exchange of information and the operations of IT in support of the business. You may use the Operating Model to help define the scope, distribution and
operations of applications, services or capabilities that eventually should be delivered. Key constraints such as IT funding, IT organization, IT resource ownership and
distribution can be captured through the discussions facilitated by the Operating Model.
With the Enterprise Organization Structures (IT and business organizational chart) and the Operating Model, identify organizational control and ownership of the IT
capabilities within the business structure. Based on this, capture IT funding on two levels Capital Expenditures and Operating Expenses. You need to determine how
the business units fund each type of expense. Also, capture how IT expenditures are approved and costs are allocated. Identify shared IT capabilities and services and
cost allocation to the business.
When you have created the work products for these tasks, provide a references to the work products.
Create Business Process View
Execute this step with task, Create Enterprise Function or Process Model (BA.040). There may already be process or function models in place that you may reuse, but
you should ensure that you develop a Business Process View that reflects the Business Scope. Provide a reference to the resulting work product.
Create Business Knowledge View
Execute this step with task, Develop Enterprise Knowledge View (BA.055), and provide a reference to the resulting work product.
Create Business Performance View
The Performance View provides insight and information concerning how effectively the business is operating against their defined strategy and business operations to
allow for effective decision making. The Business Performance View should be defined in the context of measuring, collecting, analyzing and distributing the information
that reflects how effectively IT is operating in support of the business investments made through IT capabilities.
Execute this step with task, Determine Metrics Collection and Reporting Strategy (BA.017), and provide a reference to the resulting work product.
Propose Value Hypothesis
The Value Hypothesis should provide insight into the benefits that are expected to be achieved as a result of the engagement. It may be that a Value Hypothesis (or
Benefit Analysis) has already been done. If this is the case, you should validate the analysis, and the business objectives supported by it. You may want to focus on
validating why now and why the engagement will improve the likelihood of success. You also should analyze whether the expected benefits are realistic. If no Benefit
Analysis has been defined, you should spend the time to describe the potential value and impacts to the business for pursuing the chosen strategy.
Execute this step with task, Perform Benefit Analysis (ER.110), and provide a reference to the resulting work product.
In both cases, whether a Value Hypothesis has already been done, or if you have to perform the benefit analysis, you should verify the areas of focus and also look at
measures that can be used to determine the success of the initiative. For the latter case where you must perform the benefit analysis, you may want to revisit task,
Determine Metrics Collection and Reporting Strategy (BA.017).
Compose the Documentation and Write Executive Summary
Typically, build the Business Architecture composite work product iteratively as each component is created or updated. Start on the Executive Summary as soon as there
is enough content to do so. The Executive Summary summarizes the most important aspects for senior management. While working on the Executive Summary, you
may discover areas that have not yet been detailed sufficiently. Keep in mind, the Executive Summary must be written using business terms, and it should be easy to
relate the content to the Business Strategy.
Present the Business Architecture
In most situations, you also need to present the results of the Business Architecture. While building the composite work product and Executive Summary, start working on
the presentation. Be sure to present the relationship to the Business Strategy and the scope of the Business Architecture. If you lack information to provide a good
presentation, this is an indication that you lack content and may need to revisit some components.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect
(Business Architect)
Develop the Business Architecture composite work product, write the Executive Summary, and prepare the Business
Architecture Presentation.
100%
Client Enterprise Architect Work with the enterprise architect to develop the Business Architecture. Review Business Architecture and participate in
presentation.
*
Client Executive(s) Provide access to all required information and resources and ensure availability of stakeholders and subject matter experts
whenever required. Review Business Architecture and participate in presentation.
*
* Participation level not estimated.Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business objectives and principles.
Business Scope (BA.012) The Business Scope provides the scope of the Business Architecture.
Metrics Collection and Reporting
Strategy (BA.017)
The Metrics Collection and Reporting Strategy contains information about how and what should be measured, and is a part of the
Business Performance View, and the Value Hypothesis.
(BA.020)
The Enterprise Organization Structures provide information about how the organization is organized and is part of the Business
Validated Operating Model
(BA.025)
The Operating Model provides information about how the organization operates to achieve their goals and is part of the Business
Enterprise Function or Process
Model (BA.040)
The Enterprise Function or Process Model provides information on the business functions and processes and is part of the
Business Process View.
Enter pries Knowledge View
(BA.055)
The Enterprise Knowledge View provides information on the business knowledge that is used by the organization and is the
Business Knowledge View.
Analyzed Capabilities (EA.040) Use the Analyzed Capabilities to identify the capabilities the Operating Model should support.
Funding Model (GV.090) The Funding Model provides information about the funding structures of the organization and is part of the Business
Benefit Analysis (ER.110) The Benefit Analysis provides information about what kind of benefits are expected to be achieved as result of the given strategy
and initiative, and is a part of the Value Hypothesis.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Business Architecture is used in the following ways:
to understand where and to what extent the chosen strategy and related capabilities support the organization
to understand how the business operates ensuring that the capabilities provide meaningful value to the enterprise
to understand the Business Strategy, and the related expected business benefits and value to be gained
to understand how to measure whether the results provide the expected value, and how effectively the business is operating against the decided strategy
Distribute the Business Architecture as follows:
to enterprise executives
to all members of the engagement team
Back to Top
QUALITY CRITERIA
Has the Business Architecture been produced in collaboration with enterprise stakeholders?
Has the Business Scope been clearly described?
Do the other parts of the Business Architecture fit the Business Scope?
Is there a clear traceability between the Executive Summary and the Business Architecture Presentation and the Business Strategy?
Is there a clear relationship between the Business Performance View and the other views, i.e., have measures been identified for the most important aspects of the
other views?
Back to Top
BA.060 - PERFORM HIGH-LEVEL USE CASE DISCOVERY
During this task, initially identify a number of high-level use cases that are relevant for the enterprise, and later in the Envision engagement, verify already defined use
cases against the improvement options identified.
From an enterprise or solution architecture standpoint, you may use this task to discover/define a business process or set of business processes to support your
articulation of how a future state architecture might support those business processes. The granularity at which the business process is defined is largely dependent on
the type of engagement. A high-level use case can be thought of as a fundamental 'Business Capability.' Just enough process design principles should always be taken
into account, for example, if you are defining a use case to support a pre-sales exercise, you should define the process at a high (conceptual) level rather than a detailed
(execution) level.
Use case discovery can assist an enterprise and solution architecture planning exercise in many ways, for example, as an overlay mechanism to show technology-
business process interaction (Current & Future State), Current State business and technology challenges, business process improvement options/recommendations,
organization/LOB/role interaction with business process, etc. Leads for where high-level use cases could be found can come from earlier compiled Enterprise Research
Findings (ER.040). In the initial discovery, without a specific solution in mind, this could be just an inventory of capabilities that could be of interest to the customer, given
their business strategy. As we are discovering entry points later on, we typically will have a better understanding of potential solutions that may fit and the use cases can
be much more detailed and specific.
ACTIVITY
BA.060.1
BA.060.2
INIT.ACT.EDBPD Brainstorm, Prioritize and Discover Entry Points
Back to Top
WORK PRODUCT
High-Level Use Cases - The High-Level Use Cases contains an Enterprise Actor Model with actors playing a role in relation to the enterprise, and high-level use cases
relevant for these actors. The final work product also shows which use cases should be pursued further. For some non-solution Discovery engagements, you might only
produce a list of Potential Business Capabilities that could benefit the enterprise. and not the more detailed UML-like business use case.
Back to Top
TASK STEPS
1 Discover required
business
capabilities.
Potential
Business
Capabilities
The Potential Business Capabilities is the list of missing business capabilities represented by generic functionalities that are
not present in the current enterprise, but could potentially support business goals and/or (partly) satisfy associated key
business requirements.
2 Identify high-level
actors.
Enterprise
Actor Model
The Enterprise Actor Model contains a list of actors where each actor represents a role played in relation to the enterprise by
someone or something in the business environment. Actors are broadly of two types:
Internal Actors - Roles within the enterprise units of the enterprise (e.g., Customer Service Representative, Sales
Manager)
External Actors - Roles that are external to the enterprise (e.g., Customer, Vendor, Partner). The actor specification
must include the names, role and responsibility of the actor and for what they use the system.
Note: The notion of Internal and External Actor should not be confused with the notion of Primary Actor and Supporting Actor
in UML Use Case Modeling. The latter to indicate the role an Actor has for a specific Use Case.
Following are some of the attributes that can be maintained for actors:
Name
Description
Kind (Person, System, Device, etc.)
Category (Internal, External)
3 Identify user goals
and use cases.
Actor - Goal
List
The Actor - Goal List shows a list with the goals for each actor identified in the previous list. It also shows which use case
accomplishes which goal. It is often that the name of the goal is the same as the name of the use case.
4 Provide a short and
high-level
description for each
use case.
High-Level
Use Case
Descriptions
This component provides a high-level description for each enterprise use case. It should be done following a use case
template, so that it easily can be expanded with more detail at a later point of time.
5 Check use cases
against the
Enterprise
Repository.
None Check whether there are any duplicate or overlapping requirements in the repository. If the customer is managing
requirements at the enterprise level, check for duplicate or existing use cases in the Enterprise Repository. If the requirement
has already been implemented by a reusable component (for example, a SOA service), it may be possible to mark it as
'already implemented.'
See the Enterprise Requirements Management technique for more details.
6 Verify candidate use
cases against
Process
Improvement
Options.
Updated
High-Level
Use Case
Descriptions
This component is the updated list of high-level use cases that are relevant after a validation against the Process
Improvement Options. This verification may be based on an initial list of use cases identified through step 1, 2 and 3, or
based on a template with candidate use cases for a business area that may be relevant for the enterprise.
7 Determine high-level
use cases to pursue
further.
Updated
High-Level
Use Case
Descriptions
This component is the updated list of high-level use cases that have been agreed upon to pursue further as part of the
engagement or in general. The list is typically expanded to include a column with an indicator showing when or if a use case
should be pursued further.
8 Add use cases to the
Enterprise
Repository.
Updated
Enterprise
Repository
The use cases have been added to the Enterprise Repository. If the customer is managing at the enterprise level, the use
cases need to be inserted in the repository for tracking. The requirements should be linked to the Enterprise Functional,
Process and Domain Models.
See the Enterprise Requirements Management technique for more details.
Back to Top
APPROACH
During the Gather Information activity, identify a number of business capabilities that are relevant for the enterprise. This is done when you have modeled the enterprise
processes and domains.
At this point of time we have not yet identified where the potential problems or improvements are required, but we have identified the enterprise processes and domains.
With this as input, you identify the key actors relevant for the enterprise, their high-level goals and use cases.
Later, during the Brainstorm, Prioritize and Discover Entry Points activity, verify the already defined High-Level Use Cases against the Process Improvement Options
(BA.090) identified. This is done when you have come further in the process and have identified the process or architectural improvement options. In some situations, you
may also have some pre-defined use cases you want to test against the client situation.
Now we have identified potential problems, and have looked into improvement options, both on a process level, and an architectural level. This means that the scope for
the use cases that will be needed is limited to those that will be relevant to support the improvement options identified.
Make sure that you update or add to the enterprise stakeholders in the Enterprise Stakeholder Inventory (BA.015). Consider capturing stakeholders using the Capturing
Stakeholder technique.
Finally make sure that the business processes for the use cases you have selected are defined at a level that is relevant to the study. If the use cases are to be used for
a high-level enterprise or solution architecture study, use just enough principles to ensure the use cases selected are defined at the relevant level of detail to support the
exercise.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Oversee the discovery of the high-level use cases. 50
Enterprise Architect (Business Architect) Elicit the use cases from the client enterprise architect. Preferably, this should be done by an enterprise
architect that specializes in Business Architecture.
50
Client Enterprise Architect Assist in the discovery of the high-level use cases. *
Back to Top
PREREQUISITES
BA.060.1
Prerequisite Usage
Enterprise Research Findings (ER.040) Use the Influence Map and Discovery Map to identify current pains associated with business goals as well as associated
stakeholders to interview.
Business Strategy (BA.010) Use the Business Strategy to determine the goals, and the relevance of possible use cases.
Enterprise Process Model (BA.040) Use the Enterprise Process Model to identify high-level use cases.
Enterprise Domain Model (BA.050) Use the Enterprise Domain Model as a supporting input for its descriptions of the High-Level Use Cases.
Governance Implementation (GV.100) If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes)
describes how to govern the High-Level Use Cases. In addition, ensure that the High-Level Use Cases are
added/updated in the repository.
BA.060.2
Prerequisite Usage
Process Improvement Options (BA.090) Use the Process Improvement Options to verify the High-Level Use Cases against the identified improvement options.
Architectural Gaps and Improvement
Options (EA.060)
Use the Architectural Gaps and Improvement Options to verify the High-Level Use Cases against the identified
Governance Implementation (GV.100) If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes)
describes how to govern the High-Level Use Cases. In addition, ensure that the High-Level Use Cases are
Back to Top
TECHNIQUES
Technique Comments
Management
Use Case Levels This technique provides guidance in utilizing Cockburn's technique for describing the different levels of use case models.
Risk Portfolio Use this technique to assess the level of risk for each use case.
2 x 2 Use this technique to prioritize high-level use cases
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
BA-060_HIGH_LEVEL_USE_CASES.DOC MS WORD
Example Comments
High-Level Use Case MS Visio
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
The High-Level Use Cases are mostly targeted internally for the Envision team, however, it should be shared with customer stakeholders for verification purposes.
Back to Top
QUALITY CRITERIA
Are all use cases prioritized?
Have you checked for duplicate use cases?
Are the use cases linked to related workshop results?
Do the use cases follow industry standards and leading practices (see technique guidance)?
Back to Top
BA.065 - REVIEW BUSINESS-IT SLA
During this task, you review the Business-IT Service Level Agreements (SLA) mainly to gain a deeper understanding of the enterprises supplemental (aka non-functional)
requirements of business critical business applications (e.g., business expectations of response times, availability, etc.). In some cases, this information is extremely
sensitive but is crucial in determining existing technology issues and gaps as well as scoping the ideal future state enterprise architecture to support current and future
business needs.
Situations differ in the level of documentation and the method of documentation of service levels for every enterprise. In addition, sometimes the documentation may be
outdated, and therefore no longer relevant.
ACTIVITY
Back to Top
WORK PRODUCT
Business-IT SLA Report - The Business-IT SLA Report specifies key business SLA categories.
Back to Top
TASK STEPS
1 Obtain and verify existing SLA details. None
2 Compile report. Business-IT SLA Report The Business-IT SLA Report specifies key business SLA categories.
Back to Top
APPROACH
Obtain and Verify Existing SLA Details
Obtain all relevant and available information on existing business IT organization SLAs. For each critical capability expected, perform an inventory to identify the
corresponding SLA.
Ensure that you understand the status of each SLA.
Have the requirements documented in the SLA been agreed upon by all parties (business and IT)?
How critical are the requirements?
Is it acceptable to deliver a lower level of service in some areas, for example, to decrease costs?
There may be expectations that have not been documented formally as part of the SLAs. These expectations may be just as important to document as the requirements.
Therefore, investigate each critical capability expected from certain IT components, and what quality of service is expected. If certain non-documented expectations are
identified encourage the stakeholders to document these as part of new or updated SLAs.
Make sure the requirements documented in the SLAs are measurable, and that the mechanism for measuring has been documented. If this is not the case, verify how is
the measurements will be evaluated against the expected results to verify whether or not the level of service has been delivered as agreed upon. Encourage the
stakeholders to update the SLAs with measurable targets.
Ensure that you also review the high-level details of the Service Level Agreements with the enterprises business stakeholders (either internal or external to those that
have an impact on or are impacted by the business). Where this information is deemed sensitive, try to obtain high-level information around typical supplemental (aka
non-functional) requirement areas, e.g., system availability, disaster recovery, etc.
Compile Report
Compile a report that documents the findings from the previous step and summarizes key business SLA categories that will form the basis of the follow up supplemental
(aka non-functional) requirement review done in the task, Define Supplemental Enterprise Requirements (ER.100).
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Elicit existing formal business-IT SLAs for critical capabilities. 50
Consult with the business stakeholders to document less formalized expectations the business has regarding quality of service
(QoS) from certain IT components. Preferably, this should be done by an enterprise architect that specializes in Business
Architecture.
50
Client Enterprise Architect Assist in the review of business-IT SLAs. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Stakeholder
Inventory (BA.015)
A good understanding of the enterprise stakeholder community is key in being able to better understand how a business-IT SLA
might be constructed for a particular enterprise.
Structures (BA.020)
A good understanding of the Enterprise Organization Structures is key in being able to better understand how a business-IT SLA
might be constructed for a particular enterprise.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Business-IT SLA Report is used in the following ways:
as key business SLA categories that will form the basis of the follow up supplemental requirements
to validate the Envision team's understanding of the level of service requirements and used as a basis for subsequent implementation projects
Distribute the Business-IT SLA Report as follows:
enterprise architects and business analysts on the Envision engagement project team.
Back to Top
QUALITY CRITERIA
Have key business-IT SLA categories been validated with the stakeholders (both business and IT)?
Are the QoS requirements documented in the SLAs measurable?
Are the SLAs specific enough to use as requirements for a technology implementation project?
Back to Top
BA.067 - REVIEW BUSINESS VOLUMETRICS
This task is aimed at reviewing existing client business volumetrics related to their critical business systems (for example, number of customer orders raised by specific
product line) and reviewing, through customer discovery, the anticipated changes to those volumetrics that will have a material impact on the IT strategy.
This review will form the basis of the Business Capacity Plan (EA.057) that will be created when the final solution architecture has been agreed on between Oracle and
the client.
ACTIVITY
Back to Top
WORK PRODUCT
Business Volumetrics Report - The Business Volumentrics report contains business volumetrics that are relevant for the client's business operation model and key
processes that may or may not be carried forward into a capacity plan. The report includes:
a list of end-to-end processes for which business transaction volume details have been captured
the questionnaires that have been used to collect the volumentrics
a justification of the answers in the questionnaire in terms of users, batch processes, transactions and data volumes
Back to Top
TASK STEPS
1 Assess client operating model and key business processes. None
2 Create or obtain Customer Questionnaire(s). Customer Questionnaire The Customer Questionnaire is used to capture business volumetrics for
the key business processes.
3 Issue the Customer Questionnaires to the appropriate
customer staff.
Completed Customer
Questionnaires

4 Compile final report on business volumetrics and review and
validate with the client.
Business Volumetrics
Report

Back to Top
APPROACH
The approach depends on the nature of the engagement. Where the information is not going to be carried forward into a capacity plan during the engagement, it may be a
simple collection of the key metrics for the business. Where costing for hardware and infrastructure is needed and the hardware supplier needs to be furnished with this
information, the approach needs to be more rigorous. Given that the hardware supplier needs the information in its own form, it is useful to derive this from the vendors
questionnaire. Joint Oracle/vendor questionnaires are available (for example, HP and Sun). These questionnaires are typically for each of the ERP packages and their
component functional areas with a separate one for technology-based systems that are not based on ERP modules and one for data warehousing. However such
questionnaires do not allow the justification of the derived answers, so it is advisable to create a work product that contains:
the relevant questionnaires
the justification of the answers in the questionnaire in terms of users, batch processes, transactions and data volumes
The questionnaires tend to ask for simple responses without taking into account the variability within day, week and year and it is useful to obtain this information to inform
the hardware vendors sizing team of this aspect.
Assess Client Operating Model and Key Business Processes
Review the clients business operating model and key processes and compile a list of end-to-end processes for which business transaction volume details can be
captured.
Create or Obtain Customer Questionnaires
Create a Customer Questionnaire that will be used to capture the business volumetrics for the key business processes. You might also want to obtain hardware vendor
questionnaires that may provide a useful baseline.
Obtaining volumetrics is often vexed because the business does not necessarily have a good handle on this, and typically the larger the organization the more fragmented
is this information. Where there are large changes in processes, this information on future use may be unknown or subject to ongoing discussion.
Because the clients staff may have difficulty obtaining the relevant information, consideration needs to be given to starting this exercise early with an early checkpoint to
assess the degree of completeness. This allows any issues arising from lack of information to be escalated early. In addition, the questionnaires may be extensive but
only a subset of the questions have a major impact on the overall sizing. Where there are difficulties in obtaining volumetrics, the hardware vendor may be able to
indicate which are the mandatory answers without which any sizing can be performed.
Oracle has sizing questionnaires which are vendor-specific. Such questionnaires should be used by that hardware vendors Oracle practice for performing the sizing. In
practice, this may be passed by that hardware vendor to a specialist group within Oracle.
Often Oracles product specialists also have their own sizing questionnaires, typically in spreadsheet format for their own sizing. You may need to use these as a set of
supplementary questions.
A key metric in hardware vendors questionnaires concerns the numbers of users by the degree to which they use the system or systems. This is typically expressed as
low/medium/high with definitions of what these mean in terms of transactions per hour. These may need to be challenged as it is often the case that client staff
overestimate the degree of usage. For ERP-based systems, such as Financials simple cross-checks of numbers of staff entering GL journals or purchase orders with the
expected average time for such data entry against the declared number of such records per year can be used to gauge the level of use.
There is a potential for double-counting where certain users make use of different facilities within a system.
Some facilities, such as time-sheet and expense input have a profile of usage which is governed by cut-off dates and times. It may be necessary to develop a proposed
profile of usage and obtain client agreement that it is a valid assumption.
Compile Final Report
Review client feedback and obtain any supplemental data (for example, any periodic fluctuations in day, in week, in month, in year). Compile and publish report.
Have the client functional staff verify the completed questionnaires and provide the justification for the answers.
Compile final report on business volumetrics and review and validate with the client.
The Business Volumetrics Report should be reviewed and signed off by the client once it is complete.
Back to Top
Enterprise Architect Capture current key metrics that may be changing as a result of pursuing the business goals and implementing the future state
architecture. If certain solutions are already being envisioned, make sure the relevant sizing parameters for that solution are
captured in this task.
100
Client Enterprise Architect Assist in capturing the current key metrics. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Functional or
A good understanding of the companys key business processes is required before business volumetrics can be properly assessed.
Enterprise Domain Model
(BA.050)
A good understanding of the companys business operating model is required before business volumetrics can be properly assessed.
Reporting Strategy (BA.017)
Optionally, the Metrics Collection and Reporting Strategy may provide useful information about what kind of volumetrics are or will be
collected and for what purpose, and therefore may be a good input to what is appropriate for review.
Back to Top
TEMPLATES AND TOOLS
Typically, use Word-based questionnaires from the vendor and supplement with justification for the answers to those questionnaires. MS WORD
The base information on users, batch processes and volumes can also be captured in a repository.
Back to Top
The Business Volumetrics Report is used in the following ways:
as the basis for the development of the Business Capacity Plan (EA.057)
Distribute the Business Volumetrics Report as follows:
to the technical architect responsible for liaising with the hardware vendor in the generation of the Business Capacity Plan (EA.057)
Back to Top
QUALITY CRITERIA
Is the work product complete?
Is it consistent?
Did the client staff answer all the questions on the questionnaires?
Is the number of users for the different applications in line with the number of users of different types and the high-level definition of the organization structure?
Back to Top
BA.070 - IDENTIFY CANDIDATE SERVICES
This task is about identifying new service candidates and discovering already existing service. This may be various types of services, depending on the type of
engagement (for example, SOA services or cloud services).
Depending on the strategy and environment, there can be one or more approaches to service identification and discovery. The approach may have already been decided
as part of prior work.
Top-Down - The top-down approach starts by obtaining the enterprise-level models, such as the Enterprise Process Model, the High-Level Use Cases, the
Enterprise Domain Model and/or the Enterprise Architecture. For SOA, see the SOA Service Identification and Discovery technique for more guidance on this
approach. This approach is an effective way to identify reusable business services.
Bottom-Up This approach looks at existing systems as potential sources for service functionality that supports enterprise business processes (via APIs,
adaptors, transactions, modules, etc.). This is often the place to start if the purpose of the effort is to modernize the architecture.
Hybrid - A hybrid approach will seek to do both. It starts with a top-down approach to define the business scope feasible for the situation. Within that scope, the
services are cut following a bottom-up approach by checking the scope against a set of boundaries to select a good service granularity. Whenever feasible, the
hybrid approach is the recommended one, as it focuses on results while at the same time the big picture is kept in scope. For SOA service identification, see both
the SOA Service Identification and Discovery technique as well as the SOA Service Boundary Analysis technique to help you to identify a good granularity of
services. In this combination, after having identified business scoped candidates (top-down), these candidates get constrained by the boundaries relevant to them
(bottom-up) possibly ending in more than one service per candidate.
If the hybrid approach is not feasible then the top-down approach is the next preferred approach.
ACTIVITY
Back to Top
WORK PRODUCT
Service Portfolio - Candidate Services - The Candidate Services may be made up of two lists depending on the type of service candidates; New Service Candidates and
Used Service Candidates. The New Service Candidates is a list of possible new service candidates and the Used Service Candidates is a list of services discovered for
reuse (typically, SOA services) with a remark if an update will be needed for reuse. When a physical Enterprise Repository has been established, this information is
captured in the Enterprise Repository.
If the organization does not have a physical Enterprise Repository, and services have been captured in the Service Portfolio template (IP.014), use the Service Portfolio
template (IP.014) to capture the Candidate Services in the same format as the Service Portfolio. This will allow you to easily merge a candidate service into the Service
Portfolio at a later point, as appropriate.
Back to Top
TASK STEPS
1 Perform analysis to identify
candidates.
Service Candidates List The Service Candidates List includes all the identified service candidates.
2 Review and justify candidates. Justified Service
Candidates
The Justified Service Candidates starts with the Service Candidates List and adds justification content
for each candidate.
3 Prioritize candidates. Prioritized Service
Candidates
The Prioritized Service Candidates adds a priority for each candidate.
For SOA, refer to the Technique Steps section of the SOA Service Identification and Discovery technique for the steps to perform this task.
Back to Top
APPROACH
For each identified new service candidate or new version of an already existing service, provide a short description of the scope and what benefit the service could deliver
to the Business Strategy.
engagements.
Back to Top
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Work with the solution architect (application architect with SOA knowledge and experience) to Identify and document candidate
business services.
50
Solution Architect
(Application Architect)
Identify services that fit the SOA model. Preferably, this task should be done by a solution architect that specializes in
Application Architecture, and more specifically service-oriented architecture (SOA).
50
Client Solution Architect Assist in identifying and documenting candidate business services. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Glossary (BA.030.1)
(BA.040)
Current Enterprise Architecture (EA.030)
Governance Policies Catalog (GV.030.1)
Use these work products to identify candidate services.
Technology Reference Architectures (EA.075) Use the Technology Reference Architecture to determine to which layer each service belongs.
Service Portfolio (IP.014) Use the initial Service Portfolio to discover existing services.
Services Meta Data Description (GV.096) Use the business taxonomy defined in the Services Meta Description to check for duplicates.
Governance Implementation (GV.100) Use the implemented Governance to understand how the Service Portfolio should be governed. If the Governance
included the installation and use of an Enterprise Repository, ensure that that the Candidate Services are
Back to Top
TECHNIQUES
Technique Comments
SOA Service Boundary Analysis Use this technique to understand how to define services to the right level of granularity.
SOA Service Identification and Discovery This technique provides assistance on understanding how to identify and discover SOA services.
Back to Top
TEMPLATES AND TOOLS
IP-
014_SERVICE_PORTFOLIO.XLS
MS EXCEL For SOA, if the organization does not have a physical Enterprise Repository, and SOA services have been captured in
the Service Portfolio template (IP.014), use the Service Portfolio template (IP.014) to capture the Candidate Services in the same
format as the Service Portfolio. This will allow you to easily merge a candidate service into the Service Portfolio at a later point, as
appropriate.
Example Comments
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
Back to Top
QUALITY CRITERIA
Back to Top
BA.080 - IDENTIFY CANDIDATE ENTERPRISE BUSINESS
RULES
During this task, you perform an inventory of enterprise business rules. Business rules are statements that describe business policies. For example, a car rental company
might use the following business rule:
If the age of a driver is younger than 21, then decline to rent.
The business rules identified here are called candidate rules because at this stage they are not expressed in any consistent semantic format, nor are they validated or
approved.
The mechanisms for discovery of candidate rules include the execution of (and/or output of) many other tasks including:
Develop Enterprise Domain Model (BA.050)
Create Enterprise Function or Process Model (BA.040)
Perform High-Level Use Case Discovery (BA.060)
Develop Enterprise Glossary (BA.030)
Review Governance Policies
Obtain trading partner business rules
In addition, the very act of assembling the inventory of candidate rules may also cause the discovery of new candidate rules.
ACTIVITY
Back to Top
WORK PRODUCT
Candidate Business Rules - The Candidate Business Rules is a list of possible rules that govern the business, and that remain stable for a longer period of time.
Back to Top
TASK STEPS
1 Harvest business rules. Inventory of
Candidate
Rules
The Inventory or Candidate Rules contains a list of candidate rules that may need to be
considered. For each rule, include a description of what the rule is about, when the rule should be
enforced, and optionally in what way it should be enforced (possibly with alternatives).
2 Review the Enterprise Domain Model, the
Enterprise Process Model, and the High-Level
Use Cases to identify candidate business rules.
Inventory of
Candidate
Rules

3 Review the IT Governance Policies to identify
candidate business rules.
Inventory of
Candidate
Rules

4 Review the Enterprise Glossary. Inventory of
Candidate
Rules

5 Obtain Trading Partner business rules. Inventory of
Candidate
Rules

6 Review the Inventory of Candidate Rules. Inventory of
Candidate
Rules

7 Record the source for each discovered rule. Inventory of
Candidate
Rules

Back to Top
APPROACH
The approach to collect candidate business rules may be a combination of harvesting already existing business rules, to review a number of work products to identify new
business business rules, as well as to organize a business rules workshop with the goal to identify as many business rules candidates as possible.
Harvest Business Rules
Business Rules may already have been identified earlier, during an earlier enterprise-level effort or during one or more projects. If so, you should harvest these as an
input to determine which are candidate enterprise-level business rules. If you harvest business rules from a project, then review the rule to see whether it actually has a
broader context than has been defined in the project. It may be that the project only covered a subset of all possible situations related to the domain of the business rule,
so that the rule should be expanded to cover other situations that may occur. For example, if the rule only covers a part of the lifecycle of an object, then expand the rule
to cover the whole lifecycle.
Review Work Products
Review the Enterprise Domain Model (BA.050), the Enterprise Function or Process Model (BA.040), and the High-Level Use Cases (BA.060) to identify candidate
business rules. While reviewing these models, you may discover rules you have already identified. You should list all the rules that you see as possible candidates to be
a business rule.
Typically, when you review the Enterprise Domain Model, look for rules that are related to data, such as rules for data validation, data transformation, dependencies
between data, calculations and so on.
While reviewing the use cases, you may also identify data-related rules, but also more process-related rules. The latter, you also identify while reviewing the Enterprise
Process Model. For example, there may be conditions that must be true to enter a certain path in the workflow, or conditions that must be true to complete a process.
Ensure that whenever you identify a new rule, you keep track of the source of the rule. Ideally, you should relate the rule to a particular use case or generic supplemental
requirement. If you identify a rule based on one of the other models, try to identify a use case that relates to the rule. This makes tracking and testing of the rule a lot
easier as you will know in what use case test you can test the business rule.
Review the IT Governance Policies
If there are IT Governance Policies available, you should review them to determine whether there are any business rules that need to be covered to ensure that a specific
policy is properly implemented. Specifically look for policies related to security or auditing.
Review the Enterprise Glossary
During the creation of an Enterprise Glossary (BA.030), business objects may be defined in terms of the categories to which they belong. For example, in an Auto
Insurance Company, the glossary may define a high-risk policy as a type of policy where the customer has had an auto accident within the past 12 months. This
constitutes a candidate rule.
Obtain Trading Partner Business Rules
In some sectors, trading partner have agreed upon standards for exchanging business rules. One trading partner will be asked to use the business rules from another
trading partner to complete a transaction on their behalf in a manner that is compliant with the underlying business policies. These form another source for relevant
enterprise business rules.
Review the Inventory of Candidate Rules
Group the initial list of candidate rules logically in terms of common business entities or processes. Once this has been done and similar rules are grouped together, new
rules are often discovered. It is also easier to discover any duplicates.
Review whether the candidate rules are defined in the scope of the whole enterprise. For example, it is easy to overlook that a rule may change dependent on its
associated business unit, or on its associated object status. Think about whether the rule is similar for all employees or business units, and whether it applies during the
whole lifecycle of the objects to which the rule applies. In this way, you may need to expand the rule to include more conditions, and in some cases, you may decide it is
not a business rule at all.
Business Rules Workshop
If you decide to perform a business rules workshop, you should use the result from the review steps above as an input to the workshop. A good way to organize the
workshop is to either use the grouping of candidate rules you did when you reviewed the inventory of candidate rules, or if you have not yet done such a grouping, to
identify the most important business domains for which business rules may apply. Let the participants first prioritize the domains or groupings, and then walk through
each to identify new business rules, and/or to review rules that have been discovered prior to the workshop. Walking through the already identified business rules will
often reveal new candidates.
Do not attempt to perform any classification of the rules at this point of time, but try to identify the nature of the business rules so that it will be easier at a later point of
time.
Record the Source
Once an inventory of candidate rules exists, ensure that the source of each rule has been recorded (e.g., specific use case, requirement or policy).
engagements.
Back to Top
Enterprise Architect Use the prerequisite work products to harvest Candidate Business Rules that should be evaluated and determine when and
how they should be enforced (procedures, database constraints, rules engine, etc.).
100
Client Solution Architect Assist in identifying and documenting Candidate Business Rules. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Glossary (BA.030)
Use these work products to identify Candidate Business Rules.
Governance Policies Catalog (GV.030)
Back to Top
TEMPLATES AND TOOLS
Example Scenario Comments
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
BA.090 - IDENTIFY PROCESS IMPROVEMENT OPTIONS
During this task you identify for the enterprise process and High-Level Use Cases, what parts already have been implemented, what parts have not yet been
implemented, but preferably should be, and what parts will remain manual.
Verify the effectiveness of the processes to identify possible improvements. For already implemented parts document what kind of improvements, if any, can be made to
make the process more efficient. For currently manual parts, identify where the process can be made more efficient through automation, or through more efficient
procedures.
Cross check the result with the High-Level Use Cases (BA.060), and possibly identify additional Process Improvement Options.
ACTIVITY
Back to Top
WORK PRODUCT
Process Improvement Options - The Process Improvement Options is a list of possible improvements that can be made to make the processes more efficient, or less
expensive.
Back to Top
TASK STEPS
1 Initially identify
implementation
options for the
processes.
None
2 Identify process
improvements
options.
Improvement
Option List
This component is a list of all identified improvements that can be done to make the enterprise processes more efficient in use.
The list contains a description of the improvement, what processes or use cases it is relevant for, a reasoning why this should
be an improvement, and a reference to relevant parts of the business strategy.
3 Quality check list of
improvement
options.
Updated
Improvement
Option List
This is the updated list produced in the previous step after the list has been quality checked.
Back to Top
APPROACH
Initially Identify Implementation Options for the Processes
Determine for each process step, what is the preferred implementation, either automated or manual. If it is perceived that it is too complex or costly to automate a specific
process step, and therefore said to be manual, then record this information too, as later on it might prove to be otherwise.
Identify Process Improvements Options
Walk through the processes to identify possible improvements, and the validity of whether it should be automated. Review the event table to verify whether the list of
events can be reduced, or whether the sets of tasks triggered by similar events can be collapsed and generalized. Look for similarities, rather than differences. Can
processes be combined with some minor changes, and thereby later be implemented through the same component(s)?
Use the High-Level Use Cases (BA.060.1) to see the goals for the enterprise actors goals to identify other candidate improvements. Determine frequency of the steps.
Frequent or repetitive tasks will often be good candidates for automation.
Review the Current Architectural Challenges (EA.050). Are there improvements that can be made to overcome some of the identified Architectural Challenges?
Quality Check List of Improvement Options
Verify the identified improvement options against the objectives documented in the Business Strategy (BA.010). Also, focus on cost versus value. What kind of automation
will provide the best return on investment?
The result of this task may trigger the need for updating the Enterprise Function or Process Model (BA.040), the High-Level Use Cases (BA.060) or Enterprise Domain
Model (BA.050). Also, you may need to revisit the Service Portfolio - Candidate Services (BA.070) and the Candidate Business Rules (BA.080). If the changes will be
substantial, consider performing another iteration of the tasks. If they are minimal, update the models as part of this task, or as part of BA.100, Maintain Enterprise
Business Models.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect (Lead) Identify improvement options. 40
Work with the lead enterprise architect to identify the improvement options. Preferably, this should be done by an enterprise
architect that specializes in Business Architecture.
60
Client Enterprise Architect Provide input on which options have relevance and may be worthwhile to pursue. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to determine whether a possible improvement option lies within the objectives
of the enterprise.
High-Level Use Cases (BA.060.1)
Current Architectural Challenges (EA.050)
Impact Study and List of Proposed Organizational
Changes (GV.040)
Use these work products to identify improvement options.
Back to Top
TEMPLATES AND TOOLS
BA-090_PROCESS_IMPROVEMENT_OPTIONS.DOC MS WORD
Tool Comments
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
BA.100 - MAINTAIN ENTERPRISE BUSINESS MODELS
During this task, all the models of the Enterprise Business Analysis process are maintained as the process moves forward and the Enterprise Business Models evolve
throughout the business lifecycle. This task is ongoing.
The Business Enterprise Models should be used by any project covering parts of the models. As the projects move along, this may however also impact the Business
Enterprise Models. So therefore, there is an ingoing and outgoing dependency between this task and the projects performed in the enterprise.
ACTIVITY
Back to Top
WORK PRODUCT
Maintained Enterprise Business Models - The Maintained Enterprise Business Models is a set of up-to-date enterprise models, the enterprise process model, use case
model and domain model.
Back to Top
TASK STEPS
1 Maintain Enterprise Function or
Process Model (BA.040).
Enterprise Functional of
Process Model
This component is the up-to-date Enterprise Function or Process Model. It contains the same
component as the initial Enterprise Function or Process Model (BA.040).
2 Maintain Enterprise Domain Model
(BA.050).
Enterprise Domain
Model
This component is the up-to-date Enterprise Domain Model. It contains the same component as the
initial Enterprise Domain Model (BA.050).
3 Maintain Enterprise Business
Context Diagram (BA.045).
Enterprise Business
Context Diagram
This component is the up-to-date Enterprise Business Context Diagram. It contains the same
component as the initial Enterprise Business Context Diagram (BA.045).
4 Maintain High-Level Use Cases
(BA.060.1).
High-Level Use Cases This component is the up-to-date High-Level Use Case Model. It contains the same component as the
initial model for the High-Level Use Cases (BA.060).
5 Analyze impact of change. High-Level Use Cases For each updated model, analyze the impact the change has on the enterprise.
6 Update the Enterprise Repository. If the model was registered in an Enterprise Repository, create a new version of the corresponding
model asset and register the changed model in the repository.
Back to Top
APPROACH
Maintain Enterprise Function or Process Model
It is important that the Enterprise Function or Process Model (BA.040) is as up-to-date as possible with the real business situation, as this model is used as input to
projects and other situations. Therefore, if the enterprise processes change, make the appropriate changes to the model. If the changes are large, consider performing a
new instantiation of the Envision Initiate phase.
Maintain Enterprise Domain Model
It is important that the Enterprise Domain Model (BA.050) is as up-to-date as possible with the real business situation, as this model is used as input to projects and other
situations. Therefore, if new domains are identified for the enterprise, or existing ones change, make the appropriate changes to the models. If the changes are large,
consider performing a new instantiation of the Envision initial phase.
Maintain Enterprise Business Context Diagram
It is important that the Enterprise Business Context Diagram (BA.045) is as up-to-date as possible with the real business situation, as this model is used as input to
projects and other situations. Therefore, if new Enterprise Business Context Diagram was needed, make the appropriate changes to the diagram. If the changes are
#TOP #TOP
large, consider performing a new instantiation of the Envision initial phase.
Maintain High-Level Use Cases
It is important that the High-Level Use Cases (BA.060) on the enterprise level is as up-to-date as possible with the real business situation, as this model is used as input
to projects and other situations. Therefore, if the high level use cases change, make the appropriate changes to the models. If the changes are large, consider performing
a new instantiation of the Envision initial phase.
Analyze Impact of Change
Analyze the changes applied to the models to understand the impact the changes will have on the enterprise. If possible try to simulate the changed models and identify
impact on systems and people.
If the model was registered to an Enterprise Repository, discover all relationships the model has and analyze each dependent asset, if the changes will have impact.
Review the classifications used and check if they need to be changed as well. This step will give you an idea on the complexity to plan for if the changes will be applied to
the systems, applications, services and people.
Update the Enterprise Repository
If the model was already registered in an Enterprise Repository, create a new version of the model asset and register the changed models with the new versions. If the
model was not already registered, review the model to check if it should be registered. In that case, create a new model asset in the proposed state, i.e., the model is
proposed to be managed by the Enterprise Repository.
In addition, one of the Enterprise Repository taxonomies may be based on the enterprise functions defined in the Enterprise Function or Process Model, in which case a
change in that model should trigger a reclassification of enterprise assets in the repository. If it the repository taxonomy needs to be changed, update the Enterprise
Repository.
Back to Top
Enterprise Architect Supervise updates to the relevant artifacts delivered by the Envision architect team as they discover new or changed
information.
100
Client Enterprise Architect Update the relevant artifacts delivered by the Envision architect team as they discover new or changed information. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Process
Model (BA.040)
Enterprise Domain
Model (BA.050)
Enterprise Business
Context Diagram
(BA.045)
High-Level Use Cases
(BA.060.2)
These work products are maintained in this task.
Governance
Implementation
(GV.100)
the Business Enterprise Models. Analyze the impact of change and register the changes per the Governance Implementation.
Back to Top
TECHNIQUES
Technique Comments
Enterprise Requirements Management This technique provides assistance on how to manage requirements at the enterprise level.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
BA.110 - MAINTAIN BUSINESS RULES
During the lifecycle of a business rule, there may be changes in the conditions against which the rule should be validated. During this task, you perform all the required
steps to make these kind of changes.
During this task, you transform the format of the rules from the one used in the rules repository into the format needed for the implementation approach defined in the
Business Rules Implementation Strategy (EA.160). For example, if a specific rules engine, such as ILOG or Oracle Business Rules, is chosen, then the business rules
must be transformed into the format needed for that engine. Depending on the tools used, this transformation may be automatic or manual. You also perform the initial
setup of the rules engine in order to be able to start implementing business rules (such as, importing fact definitions into Oracle Rules Author).
Afterwards, when there are business rules the client organization will be able to maintain in a rules engine after the project has finished, implement those business rules
into the rules engine. This would only concern volatile business rules that are implemented using a business rules engine and for which a (client) business analyst should
have prime responsibility.
Although a (client) business analyst should have the prime responsibility for this task, in practice, it is likely done by an implementation team. The team may include client
business analysts, technical staff such as, a business rules specialist, a developer, and in some cases a rules librarian.
ACTIVITY
Back to Top
WORK PRODUCT
Maintained Business Rules - The Maintained Business Rules is the up-to-date Business Rules.
Back to Top
TASK STEPS
During an Envision engagement, modifications to existing business rules will come out in the discussion of High-Level Use Cases and Business Function or Process
Models.
You should make sure that any revisions to existing enterprise-level rules are captured and recorded in keeping with the standard practices of the customer.
Use the following steps to design any new business rules and if necessary, implement them in the rules engine:
Component
Description
1 Determine rules design format template and standards.
2 Transform each rule from the Rules Repository from the standard business user format to the needed
implementation format.

3 Design Business Rules Support. Business Rules
Support

Back to Top
APPROACH
Determine Rules Design Format Template and Standards
Review the Business Rules Implementation Strategy (EA.160), and determine the rules design format templates and standards that should be used to transform the
business rules into a format required to implement the rule. The way you format your rules is dependent on the tool you use.
For example, when using a business rules engine such as Oracle Business Rules, every rule is implemented using the format "if [condition] then [actions]". The condition
part activates the rule whenever there is a combination of facts that make the condition part true, and the action part of a rule is executed when the rule fires. For every
rule that is going to be implemented using Oracle Business Rules, you must be able to express it in this format.
Import Fact Definitions
Some types of rules engines operate on so-called facts, for which the definitions or model should come from the system(s) calling the rules engine. Therefore, the
application (which might, for example, be a BPEL process or a Java application) asserts these facts to the rules engine, after which the rules engine processes those
facts and returns some result. The facts are or can be compared with specific instances of some classes. Fact definitions can be compared with class definitions.
As an example, Oracle
Business Rules supports two types of fact definitions: XML schemas (XSD) and Java classes. XML schemas are used when using Oracle
Business Rules in a BPEL process, while Java classes can be used in combination with a Java application.
In order for a rules engine to understand the facts that are to be asserted, business rules engines that work this way need to have the fact definitions deployed in the
rule engine. After deploying or importing fact definitions into the rules repository of the engine, those definitions will reflect the Java class or XML schema definitions, and
therefore probably will be technical. For a Business Analyst to understand those definitions, you might need to translate that into business vocabulary. In case of Oracle
Business Rules you can add aliases to facts and their attributes or operations (methods). When implementing business rules, you use those aliases instead of the
technical terms. ILOG has a similar distinction between the Technical Rule Language (TRL) and Business Action Language (BAL). The TRL is part of standard
functionality, but the BAL needs to be defined and mapped explicitly to the TRL.
Transform the Rules
Transform each rule in the Rules Repository from the standard business user format to the needed implementation format. Transform each business rule using the
design format template and the standards determined. Ensure that during this transformation, the rule is always traceable back to the "human readable" version of the
rule.
Design Business Rules Support
For some business rules, you need additional supporting custom code to validate the rule. During this task, you determine what supporting custom code would be needed
to perform this validation.
The way business rules support is implemented depends on your implementation mechanism. For example, in the case of ADF Business components, you might
recognize generic patterns in business rules, such as, begin date end date comparisons for which you can implement (reusable) so-called registered rules.
If you are using Oracle Business Rules, you might need to add specific functions to the Java or XML fact definitions to support rules, or (as an alternative) add functions
in RL (Rule Language) to the Rules Repository.
Implement Business Rules
Depending on on the tool you are using, and how you have accomplished the design (task steps 1-3), either an automatic import is used, or each rule must be entered
manually.
If the rules are entered manually, determine what kind of rules are the easiest to implement, and help the client implement these first. The detailed rules classification
may help in determining what rules are similar, and what kind of rules must be implemented differently. Start the client off with an easy category, and move onto more
difficult cases. In this way, business analysts may implement a large body of the rules. However, in some cases, and very much dependent on your rules engine, or the
understanding on how rules are tied together, you may need a rules librarian to approve the implementation of changes. A rules librarian should have a better
understanding of how the given rules engine works and would ensure that the change will produce the desired behavior. A rules librarian would also verify that the
original perception of the required rule has been based on a correct diagnosis and understanding of how the engine behaves.
Estimating Considerations
The level of effort required to perform this task varies heavily depending on the rule engine you have chosen, whether or not the rules can be automatically imported, and
the client skills. The less supportive your rules author is, the more effort required. Preferably, during the Inception phase let the client practice with the rule author and see
how well he can work with it. If most of the work must be done by the development organization, assume a 70% development organization effort and a 30% client effort to
implement this task. You should be able to implement and test the average rule in half a day.
Back to Top
Enterprise Architect Create/update the Candidate Business Rules and implemented rules. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Business Rules Analysis (IP.030) The Business Rules Analysis provides the analysis for each candidate business rule.
Business Rules Implementation Strategy (EA.160) This work product defines the strategy for designing the rules.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
"Implementing Rules in ADF Business
Components" - White Paper
When using ADF Business Components, this white paper provides guidelines how to transform specific types rules to an
Oracle Business Rules
http://www.oracle.com/appserver/rules.html
When using Oracle Business Rules, the Oracle Business Rules User Guide provides information on how to import fact
definitions into the rule engine, how to add business vocabulary to that, and how to implement rules.
Back to Top
Back to Top
QUALITY CRITERIA
Do the designers and developers understand in which format the business rules must be stored?
Do the designers and developers understand when and how additional custom code can be used to create business rules?
Back to Top
[OCM] ORGANIZATIONAL CHANGE MANAGEMENT
Enterprises are increasingly recognizing that adequately preparing their people for a major technological change can make the difference between the success and failure
of a project. However, they dont always have the capabilities to adequately manage the transition from the old to new systems.
needs. In addition to increasing user adoption rates, carefully planning for and managing change in this way allows organizations to maintain productivity throughout
potentially difficult technological transitions. Furthermore, it enables the organization to more easily meet deadlines, realize business objectives, and maximize return on
investment.
In OUM, Organizational Change Management begins at the enterprise level during an Envision project, where many projects across the IT Portfolio are being examined
and planned. There are enterprise stakeholders that need to be identified prior to implementation project start-up. By beginning at the enterprise level, and then
continuing on through each Implementation project, Organizational Change Management supports the organizational move to utilize the new technology, and solutions
that are put in place to support the business of the enterprise.
The Organizational Change Management process increases the probability that the technology implementation will be successful, first by getting executive commitment
and anticipating the human and organizational challenges and then by creating a strategy that is aligned with the organizations culture to help managers and users
accept the new or updated technology. The Organizational Change Management process helps better manage the "soft side" of the implementation by:
identifying and mitigating risks
generating change momentum
fostering effective communication
preparing managers and end users for the new processes, roles and responsibilities
supporting end-user acceptance
The Organizational Change Management process helps to decrease transition time, meet deadlines, meet business objectives and stay within project timeframes.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
The nature of the OUM approach, often requiring a significant change in the implementing organizations business processes and coupled with the rapid implementation
timelines, increases the importance of the Organizational Change Management process.
Change management is action oriented to anticipate risks and to manage them, rather than resolve them in a crisis situation or after resistance has become entrenched.
It is a well-known fact that when users and managers are involved in the change planning, the less likely there will be resistance during the transition. In addition, change
can be managed, and the earlier this happens, the greater the opportunity for success. Organizational Change Management activities should begin early in a project and
help maintain client accountability for the change, ensuring that the client remains involved that can help reduce any barriers to the new application system. To this end, a
considerable number of change management activities are designed to involve both executives (executive and/or steering committee) and managers in supporting the
change effort. Oracle's Organizational Change Management leading practices also address communication and adoption strategies to help build momentum and reduce
potential resistance.
Organization Change Management focuses on addressing the human and organizational factors and aligning them to minimize the implementation risk and optimize
system performance from a human perspective. Organizational Change Management increases stakeholder commitment to the new technology and resulting changes
and builds support for the implementation by informing, involving, and including stakeholders throughout the process. Organization Change Management includes the
following benefits for the organization:
Identifies organizational issues that will either lengthen the implementation or harm it and overcomes those barriers
Improves organizational knowledge and skills for the new environment, as well as organizational effectiveness during implementation
Realizes projected benefits by focusing on post-implementation issues like user acceptance, productivity, and human performance support
Change Management Roadmap and Communication Campaign
Organizational Change Management is action oriented to anticipate risks and to manage them, rather than resolve them in a crisis situation, or after resistance has
become entrenched.
A large part of Organizational Change Management is organizing change and communication activities for specific target populations from the executive level to the end-
user level to mitigate specific issues and challenges (risks). All these activities and the associated details are organized in the Change Management Roadmap and the
Communication Campaign. The Change Management Roadmap and the 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. The activities in the Change Management Roadmap and the Communication Campaign are conducted at established milestones during the
project and are aligned with the overall project deployment schedule.
Impacts on Various Audiences
Organizational Change Management impacts the following five major audiences:
Executives
Implementation Project Teams
Functional Managers
End Users
Information Technology Groups
Each of these audiences has a stake in the expected performance of the new system and can impact the success of the implementation. However, the audiences are not
mutually exclusive. For example, functional managers or members of the information technology groups may be users and also members of the implementation project
team.
Executives - Advocate Successful Change
The tasks targeted for executives consist of a facilitated Executive Alignment Workshop and a Sponsorship Program. The workshop assists executives to effectively
develop strategies for the successful execution of the enterprise-wide implementation and the management of implementation risks. A Sponsorship Program is put in
place to identify the best executives to address specific organizational challenges and coach them in mechanisms, activities and communications in order to remain
aligned throughout the project. Its goal is to mitigate risks and get management aligned behind the change. By participating in these tasks, executives have the ability to:
understand the role they are to play in the implementation, as well as the time commitment and energy required for that role
understand the benefits the implementation provides to their business, as well as the costs and timeframes
comprehend the barriers to success, based on experience with a number of similar implementations
make timely and informed project startup decisions
initiate a sponsorship network to sustain the momentum of the project
Implementation Project Team - Give the Team a Jump Start
The tasks targeted for the project team include Team-Building Workshop with a series of activities, processes, tools, and learning events to quickly orient the
implementation team to the project. Project team members acquire the skills they need to function as a team, and to represent the project to the rest of the organization.
By participating in the Team-Building Workshop, the project team has the ability to:
become a high-performance team from the onset, reducing startup time and costs
establish appropriate Project Team Rules
function as a more cohesive working group throughout the life of the implementation
Functional Managers - Create a Stepladder for Performance
Functional managers learn how the technology impacts their work groups processes and procedures. They are provided with tools to assume their role as change
leaders, and with learning events to acquire necessary application skills. They define newly required roles, competencies, and performance support and contribute to the
improvement of the workflows to take advantage of the new technology and to manage to new performance expectations. By participating in the Organizational Change
Management activities, the managers have the ability to:
develop a reasonable expectation of the benefits the implementation provides to their business units
increase performance through more effective change leadership
design optimal job roles to meet business objectives
develop new organizational structures to help maximize productivity
define recognition and rewards to encourage user performance in their new roles and responsibilities
End Users - Achieve Business Performance
Through a series of change and communication events, users acquire the skill and the motivation to perform their new role using the full potential of the technology. This
includes the procedural, functional, and technical proficiencies users need to achieve their new performance expectations. By participating in the Organizational Change
Management activities, users have the ability to:
become involved in the definition of application and business requirements
participate in just-in-time learning and receive performance reinforcement
increase their acceptance and effective use of the system
create a post-implementation environment to facilitate productivity
Information Technology Groups - Sustain Technical Gains
The tasks targeted to the information technology community provide the right skills base to enable ongoing technical support to users after the implementation and
leverage business and technical system capabilities. It includes certification paths and retention strategies for the information technology population. By participating in
the Organizational Change Management activities, the information technology groups have the ability to:
smoothly transition from implementation to on-going technical performance
develop proficiency for ongoing system improvement, furthering technical performance gains
Back to Top
The tasks and work product s for this process are as follows:
Envision
Initiate Phase
EOCM.050 Assess Enterprise Change Readiness Preliminary Enterprise Change Readiness Assessment
Implement
Inception Phase
OCM.010 Create and Manage Ad Hoc Communications Ad Hoc Communications
OCM.020 Prepare for Executive Alignment Workshop Executive Alignment Workshop Materials
OCM.030 Conduct Executive Alignment Workshop Executive Business Objectives and Governance Rules
OCM.040 Build and Deploy Sponsorship Program Sponsorship Program
OCM.050 Prepare for Team-Building Workshop Team-Building Workshop Materials
OCM.060 Conduct Team-Building Workshop Cohesive Project Team
OCM.070 Design Managers' Project Alignment Workshop Managers' Project Alignment Workshop Materials
OCM.080 Conduct Managers' Project Alignment Workshop Aligned Managers
OCM.090 Design Change Agent Workshop Change Agent Workshop Materials
OCM.100 Conduct Change Agent Workshop Enabled Change Agents
OCM.110 Develop Change Readiness Assessment Strategy and Tools Change Readiness Assessment Strategy and Tools
OCM.120 Conduct Change Readiness Assessment and Analyze Data Change Readiness Assessment Analysis and Recommendations
OCM.130 Build Communication Strategy and Change Management Roadmap Communication Strategy and Change Management Roadmap
OCM.140 Develop Communication Campaign Communication Campaign
OCM.150.1 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
Elaboration Phase
OCM.155.1
Monitor Change Management Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication Campaign Effectiveness
Assessment
OCM.160 Prepare Business Process Impact Inventory Business Process Impact Inventory
Construction Phase
OCM.155.2
Effectiveness
Assessment
OCM.170 Collect and Analyze Job Change Data Job Impact Analysis
OCM.180 Determine Impact of Job Changes Job Impact Diagnosis
OCM.190 Prepare HR Transition Plan HR Transition Plan
OCM.200 Design Managers' Unit / Department Impact Workshop Managers' Unit / Department Impact Workshop Materials
OCM.210 Conduct Managers' Unit / Department Impact Workshop Enabled Managers
Transition Phase
OCM.155.3
Effectiveness
Assessment
OCM.220 Prepare Assessment of Impact on IT Groups IT Alignment Diagnosis Grid
OCM.230 Prepare IT Transition Plan IT Transition Plan
Production Phase
OCM.155.4
Effectiveness
Assessment
OCM.250 Measure Organizational Change Effectiveness Organizational Effectiveness Assessment
OCM.260 Implement IT Transition Plan Aligned IT Organization
Back to Top
OBJECTIVES
The objectives of the Organizational Change Management process are:
Establish executive sponsorship and management advocacy.
Align business objectives and technology capabilities throughout the organization.
Increase stakeholder commitment to the new technology and resulting changes; build support for the implementation by informing, involving and including
stakeholders throughout the process.
Accelerate the implementation project team's ability to work together through team building and organization-specific application learning.
Determine human performance support implications so that the organizational structures and job roles align to meet new performance expectations resulting from
the technology change.
Create a user-friendly environment for learning about the new technology by developing learning and performance strategies and plans that promote the optimum
performance of users on the new system.
Optimize the information technology groups infrastructure to help ensure the ongoing support of the applications (including ongoing learning and certification plans
so that information technology employees can continuously optimize system functionality to meet business needs).
Establish a measurement system that provides an evaluation of organizational performance to determine whether expectations were met during implementation
and after production cutover.
Back to Top
KEY WORK PRODUCTS
Refer to Key Work Products for a complete list of key work products in OUM.
Back to Top
Role
ID
Name Responsibility
BA Business Analyst Assist with Job Impact Analysis activity.
CMS Change Management
Specialist
The change management specialist provides the client with experience with leading practices in the human and organizational facets
of change management. Change management specialists support the Organizational Change Management (OCM) process by
identifying and mitigating risks, generating change momentum, fostering effective communication, and supporting end-user
acceptance. The change management specialist works directly with executives to gain their commitment and put in place a project
governance model.
PM Project Manager Participate in definition and maintenance of an optimal project environment. Support events to help the project team function as a
high performance team. Collaborate with the change management specialist to make sure that change management and project
management activities and expectations are aligned.
TS Training Specialist Assist with Job Impact Analysis activity. Assist with Training Needs Analysis.
Client (User)
CAT Client Assessment Team Gather and analyze assessment data.
CIO Client Chief Information
Officer
Provide input for IT Alignment activities.
CCML Client Change
Management Lead
Assist with the Change Agent Workshop. Assist with gathering and analyzing assessment data.
CCS Client Communication
Specialist
Work with the Change Management Communication Specialist on all communication tasks.
CE Client Executive Participate in Executive Alignment Workshop. Participate in change and communication events.
CFS Client Functional
Specialist
Provide functional expertise.
CHRS Client HR Specialist Work with the Change Management Organizational Development Specialist and Change Management Human Performance
Specialist on Job Impact Analysis and IT Alignment activities.
CITD Client IT Director Assist with IT Alignment activities.
CPM Client Project Manager Participate in definition and maintenance of an optimal project environment. Support events to help the project team function as a
CPS Client Project Sponsor Communicate publicly and privately on change initiatives. Provide resources for change management activities. Remove barriers
identified by the change management team. Serve as a role model. Make decisions or see to it that they get made to assist in the
change management work products. Build coalitions. Manage risks.
Back to Top
The critical success factors of this process are:
definition of clear and realistic business expectations and organizational performance measures for the project
availability of the organizations stakeholders to participate fully in readiness tasks
provisions made for workload while project team members participate in readiness tasks
inclusion of key stakeholder constituencies in the change process and clear description of project impact and benefits
visible support and participation of key leaders and sponsors throughout the impacted business units
mechanism to listen and respond to top concerns about the new systems
early establishment of ongoing communication and feedback/evaluation mechanisms that fit the organizational environment
Back to Top
EOCM.010 - CREATE AND MANAGE AD HOC
COMMUNICATIONS
Ad Hoc Communications are utilized in the initial stages of an Envision-based project before the Change Readiness Assessment takes place and the Change
Management Roadmap and the Communication Campaign have been created. They respond to the stakeholders' need for information and the reality that the project is
underway. Ad Hoc Communications lower the risk of rumors and negative perceptions about the project and organize the initial communications. This task is used at the
enterprise level when it is necessary to communicate that an enterprise level-project is underway or to assess technology alternatives and how they apply to potential
projects as well as existing projects in the IT Portfolio.
In this task, you assess the project communication needs and make recommendations regarding which Ad Hoc Communication activities are appropriate and then
implement those activities. The need for Ad Hoc Communications during an enterprise-level project will depend on communication and agreement between the
implementing organization's Sales team and technology specialists and the client.
ACTIVITY
Back to Top
WORK PRODUCT
Ad Hoc Communications - Ad Hoc Communications are initial project communication activities that can facilitate the first communications quickly and professionally.
Back to Top
TASK STEPS
1 Detail the Communication
Structure for the project.
Internal
Communication
Channel Audit
Communication
Strategy
Communication
Approval Process
Grid
The Internal Communication Channel Audit identifies and records in spreadsheet format all communication
channels currently in use in the client organization, their frequency, person responsible and audience.
This section describes the initial Project Communication Strategy as well as the overall Communication Strategy
for the enterprise.
The Communication Approval Process Grid clarifies the approval process that all communications must go
through before being released.
2 Select appropriate Ad Hoc
Communications
Ad Hoc
Communications
Select from the standard types of Ad Hoc Communications those that are appropriate for the project.
3 Implement Ad Hoc
Communications
Ad Hoc
Communications
Produce and monitor Ad Hoc Communications selections.
Back to Top
APPROACH
The Ad Hoc Communications are the first initiative of the project communications. It demonstrates that the project is well organized by having the first communication
ready for the project start. It also manages the project kickoff and delivers the first key messages from the project sponsor and key leaders of the project. The Ad Hoc
Communications consist of a series of key communication events, well known for their efficiency in the project start up (for example, launched newsletter, project
presentation that the core project team can use, kickoff event read).
The purpose of the Ad Hoc Communications is to manage the initial communication needs of the stakeholders for information that the project is real and that it is
underway. These communication initiatives lower the risks of rumors and potential negative perceptions about the project due to possible political challenges. These
communication activities start on day one of the project and end when the full Communication Strategy and Change Management Roadmap (OCM.130) and the
Communication Campaign (OCM.140) are created in the Implement Inception phase. Therefore, the Ad Hoc Communications could span many weeks.
Detail the Communication Structure
Before selecting the appropriate Ad Hoc Communications for the project, detail the Communication Structure. This information will assist you in selecting the appropriate
Ad Hoc Communications. The Communication Structure consists of the following:
INTERNAL COMMUNICATION CHANNEL AUDIT
The Internal Channel Communication Audit identifies and records in spreadsheet format all communication channels currently in use in the client organization, their
frequency, person responsible and audience.
Capture the communication culture and the most efficient mediums in the organization. Provide information on the key players who are managing the internal
communications and the approval process for the communications. Finally, integrate the project communication structure that we usually see during an implementation
(for example, the communication channels with the steering committee, project team members, etc.). All the Ad Hoc Communications will be integrated in the Change
Management Roadmap (OCM.130) to capture the build up of the communication and avoid any duplication.
PROJECT COMMUNICATION STRATEGY
The Project Communication Strategy is a high-level description of how communication will be utilized in the project. It leverages the clients mediums and communication
culture. The Project Communication Strategy is also a topic covered during the Executive Alignment Workshop (EOCM.030). Therefore, for consistency, work together on
these tasks, especially if different change management specialists are are involved.
The Project Communication Strategy is the link between all work products and describes how people will be kept informed about the project. It is reviewed based on the
Change Readiness Assessment findings. The strategy follows the client culture and considers target groups/ audiences/stakeholders impacted by the change. It is based
on the involvement of key players including executive leaders, supervisors, communications liaisons, etc.). The strategy (and the Communication Campaign which is
created later) reflects the phases of the project and is aligned with project milestones.
COMMUNICATION APPROVAL PROCESS GRID
The Communication Approval Process Grid clarifies the approval process all project communications must go through before being released. It is crucial to capture the
approval process to avoid any political problems. This process also follows the leadership structure. You need to get an official approval for each step and document the
approval with emails.
The grid captures the leaders and subject matter experts who need to review communication before it is released to the intended audiences. Following the approval
process will also ensure that all subject matter experts and affected areas agree with the information that will be released to ensure that there are no surprises when
communications are published. Adequate time should be built into the communication timeline to allow for all necessary approvals.
Select Ad Hoc Communications
Ad hoc communications can take many forms. The important thing is that communication needs to start as soon as possible to ensure that the audience will receive
accurate information right away, setting the stage for successful change management.
Select from the standard types of Ad Hoc Communications those that are appropriate for the project. The following table contains the some typical types of Ad Hoc
Communications. This list is not all-inclusive. There may be other types of Ad Hoc Communications that you decide to use. You may also decide not to use any of these
Ad Hoc Communications.
Ad Hoc Communication Description
Kick-Off Newsletter Newsletters are internal news bulletins that periodically inform stakeholders on the project's progress. They serve as the official
communication link with the project team. Newsletters give background information on the project and help stakeholders prepare
for the change gradually. Topics include: the Project Background, Vision and Objectives, Training, Important Dates, How to
Prepare for the Change, etc. Create the first issue of the newsletter, the Project Kick-Off Newsletter for the Ad Hoc
Communications.
Intranet Site The Project Intranet Site is highly interactive and contains the most up-to-date information about the project. It can store a wide
range of communication tools using various formats such as Official Presentations (PowerPoint), Newsletters (Adobe), White
Papers (Word), Charts (Visio), etc. The site is usually accessible via the organizations intranet site. This communication channel
promotes two-way communication by linking stakeholders to the project teams e-mail address or a centralized address for
comments and questions.
Project Calendar The Project Calendar can take a variety of forms including the traditional monthly calendar format, or more graphic representations
like a mountain or path that represents the project's timeline with milestones illustrated with stars or dots. To get more visibility,
calendars are often printed in poster size.
E-Mails E-mails are used to communicate project-related information to stakeholders and are often employed in the initial project stage
prior to the formation of the Communication Campaign. The advantage of using this channel is that it can reach a vast group of
stakeholders quickly and simultaneously. E-mails can be used to announce important news or to give regular updates on the
project.
FAQ Sheet Frequently Asked Questions is a document that addresses stakeholders key questions and concerns about the project. FAQs are
frequently updated to follow the projects evolution and can also be created for specific events later in the project such as
Readiness Assessments or Training.
Glossary of Terms and Acronyms A Glossary is a document that clarifies specific project-related terms. It is usually distributed/posted at the beginning of a project to
provide stakeholders with the knowledge they need to follow project-related communications. The glossary and acronym list are
updated as the project evolves.
Project Overview Presentation The Overview is a PowerPoint Presentation that explains the project at a high level, answering the 5Ws: What? Where? When?
Who? How? Topics discussed include the project timeline and scope, rationale, project vision and objectives, training strategy,
etc.
Naming Contest and Collateral Provide advice and best practice on branding the project and producing branding collateral. Material includes naming contest
steps, posters, email content, flyers and logo samples.
Implement Ad Hoc Communications
The Project Manager and OCM
The roles for the project manager and the Organizational Change Management team are distinct. In order to be successful, the change management specialist works
closely with the project manager on Ad Hoc Communication activities. The change management specialist provides guidance on leading change management practices
and direction for project change management activities. The project manager promotes cooperation, provides input and validates work products. Together, the change
management specialist and project manager determine and document responsibilities for project team vs. organizational communications as soon as possible in order to
eliminate any confusion as the project progresses. This collaboration facilitates the agreed upon Ad Hoc Communications for organizational change and enables a
smooth project initiation.
Proof of Concept, Envisioning and Enterprise Architecture
During an Envision project there may be an Oracle sales manager and/or enterprise architect who rely on the Ad Hoc Communications to engage those who will provide
valuable information and support to the project team. This communication will likely involve many different business units across the enterprise. In this case, the change
management specialists work closely with the Oracle sales manager and/or enterprise architects to communicate effectively and solicit input across the enterprise.
engagements.
Back to Top
Change Management
Specialist
Create and manage the Ad Hoc Communications. 100
Project Manager See the above The Project Manager and OCM section. Effort for the project manager is not included at the task level. *
Client Communication
Specialist
Assist with the creation and management of the Ad Hoc Communications. *
Back to Top
PREREQUISITES
Prerequisite Usage
Background documentation on project vision
direction and governance rules

Executive Business Objectives and Governance Rules
(EOCM.030)
Use the Communication Strategy component of the Executive Business Objectives and Governance Rules, if
available. The Communication Strategy provides an approach for generating and coordinating
communication for all impacted audiences.
Project Team Communication Plan (PJM.CMM.020) The Project Team Communication Plan documents the overall communication strategy for the project team.
Back to Top
TEMPLATES AND TOOLS
EOCM-010_AD_HOC_COMMUNICATIONS_STRATEGY_APPROACH.DOC MS WORD
Back to Top
The Ad Hoc Communications are used in the following ways:
to provide key project information
to lower the risk of rumors and negative perceptions about the project
to provide background information
Distribute the Ad Hoc Communications as follows:
to all stakeholders, as appropriate
Back to Top
QUALITY CRITERIA
Back to Top
EOCM.020 - PREPARE FOR EXECUTIVE ALIGNMENT
WORKSHOP
In this task, you prepare for the Executive Alignment Workshop. The Executive Alignment Workshop aligns executives behind the project objectives, vision and success
criteria to provide consistent, cross-organizational project success and a valued delivery. Preparing for the Executive Alignment Workshop includes the following:
Obtaining commitment from the project sponsor to lead, prepare for and conduct the Executive Alignment Workshop.
Researching and reviewing background materials on the project direction and governance rules.
Conducting selected executive interviews.
Comparing the client data with the leading practices project direction and governance.
Developing a timeline that will ensure that the discussion focuses on the need to fill the gaps and reach a decision on governance rules.
ACTIVITY
A.ACT.CEAWE Conduct Executive Alignment Workshop - Envision
Back to Top
WORK PRODUCT
Executive Alignment Workshop Materials - The Executive Alignment Workshop Materials consists of all the background materials, interview feedback, analysis findings
and recommendations, workshop presentations, and the workshop facilitation grid cataloged and organized in order to conduct the Executive Alignment Workshop.
Back to Top
TASK STEPS
1 Obtain commitment from the project sponsor. None None
2 Research and review background materials on
project direction and governance rules.
Existing Background
Materials
It is imperative that all project-related material be read. This includes but is not limited
to a business case, consulting service proposal, the web site of the organization and
any other relevant documents.
3 Meet with facilitating organization and client project
managers to capture the project challenges and
client culture.
Interview Questions The Interview Questions address current and or foreseen challenges and those that
address the client culture including but not limited to questions regarding leadership,
reaction to change, communications and training.
4 Prepare and tailor the Executive Interview Grid. Executive Interview
Grid
The Executive Alignment Workshop Materials contain an Executive Interview Grid that
can be used to capture the responses to the interview questions from the executives.
Responses are entered into this grid and the analysis is then conducted.
5 Conduct selected executive interviews. Schedule
one-on-one interviews lasting approximately 45
minutes in order to be mindful of the executives
time.
Project Alignment
and Commitment

6 Compile and analyze findings. Executive Interview
Analysis and
Findings
Recommendations
for Project Direction
and Governance
Rules
These components provide a qualitative assessment of the information collected from
the executive interviews.
7 Schedule workshop. Workshop Logistics The Executive Alignment Workshop Materials contain a section to capture the
Workshop Logistics and provide the pertinent logistical details for the workshop (for
example, date, location, times, etc.).
8 Identify and invite participants. Workshop
Participants List
Invitation
The Executive Alignment Workshop Materials contain a section to capture the list of
participants, as well as a template for an Invitation Memorandum that can be used to
invite the participants to the workshop.
Memorandum
9 Prepare any presentation materials. Workshop
Presentation
Materials
The Workshop Presentation Materials consist of any materials that need to be
prepared for use during the workshop.
10 Build a Facilitation Grid. Facilitation Grid The Executive Alignment Workshop Materials contain a Facilitation Grid that includes
selected exercises and activities that will be implemented during the workshop to
accomplish the workshop objectives.
11 Validate the Facilitation Grid with client. Validated Facilitation
Grid
Validate the Facilitation Grid with the project sponsor and client change management
specialist. Make changes, as required.
12 Prepare Session Planning Checklist(s) Session Planning
Checklist
The Session Planning Checklist provides a way to verify that all necessary details for
the workshop have been addressed.
Back to Top
APPROACH
A technology change requires executive-level visibility and commitment to increase the potential for project success and return on investment. It is more efficient to align
the project team and direction when the executives lead the way. It is also easier to cascade the alignment at the management level when the executives have defined
the project governance, success criteria, and goals. The Executive Alignment Workshop provides the fastest and most effective mechanism to ensure executives are
aligned and stand behind the project vision, objectives and success criteria. Executives have to be aware that a Sponsorship Program will be built on risks identified
during interviews.
The project governance rules have to be defined before the start of the project or early on in the project. The executives will also have to create a consensus around the
roles and responsibilities for the Steering Committee.
The Executive Alignment Workshop (EOCM.030) is a complete day of meeting and will cover the topics determined in this task.
Before you can assist the customer in conducting the Executive Alignment Workshop, baseline information is required. Executives have to dedicate time to take part in
activities that help to mitigate the risks that have been identified. The change management specialist must know the project and the organizational culture. It is also
helpful to know the leadership style of the project sponsor.
Obtain Commitment from the Project Sponsor
Introduce the Executive Alignment Workshop to the project sponsor as well as to the facilitating organization and client project managers, if they are identified. The client
project manager and the change management specialist should lead the discussion with the project sponsor to obtain the commitment. This demonstrates the partnership
and commitment from the project team. Walk the project sponsor through the steps of the Executive Alignment Workshop by explaining what the output will be. It is
imperative for the client project manager and project sponsor identify which leaders should participate in the interviews. It is often the case that some leaders may not be
directly involved in the project or at the Steering Committee level but can influence the success of the project or have knowledge of specific risks for the project.
By obtaining the commitment from the project sponsor and moving forward with the Executive Alignment Workshop, you ensure that we can create alignment and active
sponsorship from the executives by obtaining the following output for the project governance:
Project Vision and Institutional Objectives
Shows the alignment of the project vision with the institutions strategy and identifies the
rationale for the project and expected institutional objectives, success criteria and
benefits.

Project Direction
Identifies the high-level project risks and challenges. Includes action items to manage
the impact, mitigate the risks, support key project roles, and manage the project at the
executive level.

Roles
Documents roles within the project environment, including the Executive Sponsor,
Steering Committee , and Advisory Committee

Reporting Structure
Illustrates the required level of influence and involvement that each group has related to
making project decisions
It is necessary to gain approval from the project sponsor that all individual answers and information provided by participants will be kept anonymous. This is the key for
obtaining honest input from the leaders. The data will be compiled and the results will be presented in aggregate so no one executive can be identified as supplying
specific information.
To summarize:
Obtain commitment from the project sponsor to lead, prepare for and conduct the Executive Alignment Workshop.
Gain the perspective on organizational and human risks from the project sponsor.
Obtain commitment from the project sponsor to lead the alignment activity.
Assign an appropriate party to coordinate the logistics.
The workshop must be carefully planned in order to avoid any political issues and to obtain the involvement of the executives for the workshop. For this reason, get
approval from the project sponsor to keep the individual interview data confidential and only provide the analysis to ensure confidentiality and obtain additional
information from VPs, where required. Before starting the interviews, inform the participant on the confidentiality of the interview and how the information will be
communicated with integrated data.
Research and Review Background Materials
Research and review background materials on project direction and governance rules. It is imperative that all project related material be read which includes but not
limited to: a business case, consulting service proposal, the web site of the organization and any other relevant documents.
During interviews with vice presidents, validate their understanding and level of commitment and alignment to the following items if determined:
Project Vision
Project Objective
Guiding Principles
Project Rationale
To summarize:
Validate the level of executive alignment obtained.
Identify the leadership style of the project sponsor.
Obtain the first read into specific information regarding organizational challenges.
Meet with Facilitating Organization and Client Project Managers
Project managers are already aware of key organizational risks and political challenges in place for the project. Their insight is very important to capture and they can
often sense what they see has current and foreseen challenges that can negatively affect the project. The client project manager can provide insight on the organization
culture, leadership and past commitment of executives during projects. In addition, it is very important to ensure that the facilitating organization (for example, Oracle) and
client project managers support the change management initiative.
This input from project managers can affect the change management specialists approach and it is always necessary to align to the client culture. In addition, it is
imperative that the efforts put forth can mitigate project risks before they create potential problems. If we are reactive to the risks and not strategically plan to mitigate
them, we are at risk of pushing out the timeline and going over budget.
Items listed below can serve as topics and questions of interest:
1. Project goal /vision/success criteria
2. Name of Project Sponsor
3. Project priority
4. Political issues that they may be aware of
5. Past implementation experience
6. Staffing commitment
7. Client's culture (leadership style, communication and training culture)
8. People who are likely to oppose the project and how they can resist
9. Major implementation challenges anticipated
10. Potential impact on people work most impacted groups
Prepare and Tailor the Executive Interview Grid
Based on the leading practices in governance and from the input of the project managers, generate your interview grid to capture the level of alignment, commitment and
identify the organizational risks in place. Determine appropriate questions for interviews. (If availalbe, select questions from a directory or repository of interview
questions.)
Conduct Selected Executive Interviews
Schedule the time and location of each executive interview in collaboration with the facilitating organization and client project managers. It is typical that the project
sponsor will take the lead in scheduling the logistics.
The project sponsor will send an invitation message to his/her directs to introduce the process and request participation. This initiative will confirm the importance of this
process.
Collect information to the questions listed in the Executive Interview Grid in 30 to 45 minute interviews with executives and the project sponsor. Be sure that you introduce
your self, specify what the purposes of the interviews are and that this information will be analyzed and reviewed as a collective. Encourage them to answer openly and
honestly as no individual level data will be shared with the collective and the project sponsor.
Consider the following:
Gather the information regarding project barriers, potential political issues and organizational risks.
Capture the level of alignment and gaps to manage.
Identify the level of priority this project has within the organization.
Identify the project risks and how executives can reduce roadblocks and maintain alignment.
Identify the level of alignment between executives.
Identify the level of commitment for the project.
Identify project risks and political issues.
Compile and Analyze Findings
Compare the client data with the leading practices project direction and governance. Capture the data in the Executive Interview Analysis and Findings. The Executive
Interview Analysis and Findings is built so that you can easily capture the qualitative data and be able to calculate how many respondents are sharing the same thoughts
or disagree on a topic.
The accuracy of data collected is imperative to capture. As the interviews progress there will be some consistencies and inconsistencies and is therefore important to use
a grid that enables you to quickly capture and tally up the consistencies and inconsistencies. Have each question pre filled and assign each interviewee a number. If the
interviewee says something that corresponds to anothers response check the box that corresponds to that individual for the specific question
Identify gaps from the interview data to discuss during the Executive Alignment Workshop.
Determine if there is misalignment around project priority, vision, commitment, etc.
Identify the key organizational challenges and risks in place to mitigate.
Identify the political situation to manage.
Identify the situations that will make or break the project.
Get the executives input on the project.
Involve the executives early on in the project.
Compare the commitment and alignment with the leading practices.
Schedule the Executive Alignment Workshop
Along with the facilitating organization and client project managers and the project sponsor, determine the Executive Alignment Workshop logistics, including:
date
location
times
team contact information
transportation, if applicable
hotel accommodations, if applicable
proposed agenda
any other helpful or pertinent information
Encourage the project sponsor to request 100% attendance. Craft a section of the communication that dictates what will be addressed and what will be expected of each
participant. Speak with project managers in order to determine how materials, printing, food, drinks and refreshments will be provided.
Identify and Invite Participants
Collect the names and contact information of those executives that will be required to attend the workshop from the facilitating organization and client project managers
and project sponsor. The invitation should be sent by the project sponsor to ensure that the workshop will be well attended. The impact of people missing will push out
the timeline as each designated executives input is required. Include an RSVP so that set up, materials, food, etc. is sufficient.
Prepare Any Presentation Materials
Ensure that all presentation materials along with tools and templates are printed and appropriately packaged prior to the Executive Alignment Workshop. Reserve all
items that are necessary to run the workshop and ensure that they are in the room prior to the start of the workshop. Such items include pens, markers, whiteboards,
easels, paper, projectors etc. Additional items may include name tags, badges and security passes.
Running an effective and well regarded workshop requires a professional setting where all presentation materials are prepared and made available at the time of the
presentation.
Presentation materials include:
overhead presentations
handouts
workbooks, etc.
Build a Facilitation Grid
A successful Executive Alignment Workshop depends on a well-planned and well-structured timetable. The Facilitation Grid includes selected exercises and activities and
topics for discussion that will be implemented during the workshop to accomplish the workshop objectives presented in a well-planned and well-structured timetable. It is
a timetable for the entire time of the workshop showing what activities or exercises will be accomplished at what time. It should include time allocated for breaks and
meals. Create exercises and activities (if available, select from a directory or repository of exercises and activities) that will be implemented during the workshop to
Ensure that the actual working activities are introduced and well explained at the time of their kickoff. This eliminates any potential surprises and ensures that there is full
participation.
Build on situations that need to be discussed in order to reduce misalignment or gain more commitment. Also cover topics which require clarification (for example, project
objectives or success criteria). Finally, it will respect the leadership in place and provide opportunities for participants to share their ideas. Ultimately, the grid must meet
the objectives of the Executive Alignment Workshop to ensure that the executives will lead the way by creating and fostering strong alignment and commitment to the
project. The Facilitation Grid dictates the following:
Executive Alignment Workshop Objectives
Assumptions
Background
Validate the Facilitation Grid
Validate the Executive Alignment Workshop Facilitation Grid with the project sponsor. Obtain the signoff on the completed workshop materials including the Facilitation
Grid with the project sponsor. Socialize the materials with the facilitating organization project manager so he can promote cooperation, provide input and validate work
products. This collaboration facilitates the agreed upon organizational change. Revise and re-socialize where and when required. Do not conduct the workshop without
the validation and required signoff.
The change management specialist (leadership) is the one who will keep the discussion on time and make the link between each leader who may be invited to speak. The
topics are planned for facilitating the discussion and for the decision making process. It is challenging keeping leaders on schedule but the efficiency of the workshop is
related to this capability to structure the work. Include an open issue section in the grid timetable if some follow ups are required.
The Sponsorship Program (EOCM.040) is also introduced at the end of the workshop.
Prepare Session Planning Checklist
The Session Planning Checklist provides a checklist to verify that all necessary details for the workshop have been addressed. Prepare a checklist(s) that will be used
prior to conducting the Executive Alignment Workshop to make sure last minute preparations have been accomplished.
closely with the project manager. The change management specialist provides guidance on leading change management practices and direction for project change
management activities. The project manager promotes cooperation, provides input and validates work products. Together, the change management specialist and project
manager determine and document responsibilities for the Executive Alignment Workshop as soon as possible in order to ensure that the workshop is adequately planned.
This collaboration facilitates the agreed upon division of workshop activities, roles and responsibilities.
During an Envision project, there may be an facilitating organization sales manager and/or enterprise architect who rely on the Executive Alignment Workshop to engage
those who will provide valuable information and support to the project team. This communication will likely involve many different business units across the enterprise. In
this case, the change management specialists work closely with the facilitating organization sales manager and/or enterprise architects to communicate effectively and
solicit input across the enterprise.
engagements.
Back to Top
Change Management
Specialist
Prepare the interview materials. Prepare the materials for the Executive Alignment Workshop. 50
Enterprise Architect Assist with determining possible architectural sessions and attendees. 50
Client Project Sponsor Identify the alignment challenges early on. Get a first level understanding of project barriers. Assess and articulate the level of
executive commitment for the project. Validate the Executive Alignment Workshop Facilitation Grid.
*
Client Project Manager Participate in the preparation of the Executive Alignment Workshop. *
Back to Top
PREREQUISITES
Prerequisite Usage
Background materials on project direction and
governance rules
This material allows you to understand what change management work has been conducted to date. It also
provides information on what has and what has not been successful in managing change.
Contractual and Business Agreement Documentation This documentation may include collective and ancillary documents such as vendor agreements,
contract/labor agreements, system requirements documentation, board level directives and
communications, and requests for proposal. These documents assist in the identification of the business
drivers for the project and provides details on the scope of the implementation, the modules purchased, the
agreements, and so on.
Return on Investment (ROI) Analysis A Return on Investment (ROI) analysis can document the business case and the return that the executive
management team can realistically expect from its investment in technology. If an ROI has been performed,
you need it as an input.
Project Management Plan (PJM) The Project Management Plan defines the scope, objectives, and approach for the project and refers to the
detailed standards and procedures employed during the execution of the project.
(PJM.OCHM.010)
The Client's Organizational Change Management Strategy documents how the project solution is to be
Change Management Warning Signs (PJM.OCHM.020) The Change Management Warning Signs identifies early change management warning signs.
Enterprise Process Model (BA.040) This work product includes a description of how the new processes operate, and the principles that regulate
the operation of the new processes.
Enterprise Stakeholder Inventory (BA.015)
Reviewed Project Approach (PJM.BT.060)
These work products provide insights and the framework for the project and the related plans and
expectations. Key stakeholder groups are also identified.
Enterprise Organization Structures (BA.020) This work product or an Organizational Chart assists in stakeholder analysis.
Ad Hoc Communications (EOCM.010) The Communication Structure component of the Ad Hoc Communications provides input into this task.
Back to Top
TECHNIQUES
Technique Comments
The Workshop Techniques Handbook provides detailed descriptions of various techniques for delivering
workshops during client projects.
Back to Top
TEMPLATES AND TOOLS
EOCM-020_EXEC_ALIGNMENT_WORKSHOP_MATERIALS.DOC MS WORD - Use this template to prepare for the workshop.
EOCM-020_EXEC_ALIGNMENT_WORKSHOP.PPTX MS POWERPOINT - Use this template to create a presentation for your workshop.
Back to Top
The Executive Alignment Workshop Materials are used:
to conduct the Executive Alignment Workshop
Distribute the Executive Alignment Workshop Materials as follows:
to the workshop facilitators
to the workshop participants, as appropriate
Back to Top
QUALITY CRITERIA
Back to Top
EOCM.030 - CONDUCT EXECUTIVE ALIGNMENT WORKSHOP
In this task, you conduct the Executive Alignment Workshop. The Executive Alignment Workshop is the fastest and the most effective mechanism to ensure executives
are aligned and stand behind the project vision, objectives, and success criteria. It provides the opportunity to identify the project risks, for those projects in the IT
Portfolio, and how executives can reduce roadblocks. During the workshop, executives document how to track project benefits, sponsor the projects, and prepare the
organization for changes.
ACTIVITY
Back to Top
WORK PRODUCT
Executive Business Objectives and Governance Rules - The Executive Business Objectives and Governance Rules captures the decisions made during the Executive
Alignment Workshop about project vision, objectives and success criteria in order to communicate them to the project team so that they can then provide direction to
middle managers and end users in order to manage the impact of the project on the organization as well as to mitigate organizational risks.
Back to Top
TASK STEPS
1 Prepare for the workshop. None Use the Session Planning Checklist from the Executive Alignment Workshop Materials (EOCM.020).
2 Facilitate the work session on
project vision and business
objectives.
Project Vision and
Business
Objectives
This component shows the alignment of the project vision with the business strategy and identifies the
rational for the project and expected business objectives and benefits.
project direction.
Project Direction This component identifies the high-level project risks and challenges. Includes action items to manage the
impact, mitigate the risks, support key project roles and manage the project at the executive level.
4 Introduce the Sponsorship
Program
Sponsorship
Program
This component describes the Sponsorship Program.
reporting structure.
Reporting Structure The Reporting Structure describes the reporting structure for the project.
roles.
Roles This component documents roles within the project environment, including the executive sponsor, Project
Management Office, and Advisory Committee.
7 Facilitate work session on
communication.
Communication
Strategy
The Communication Strategy is the link between all work products and it keeps people informed about the
project. The working session will help specify the roles of the executive sponsor and Steering Committee.
8 Perform a post-workshop wrap up. Updated Materials,
Workshop Results
Update any materials, if necessary. Document results.
Back to Top
APPROACH
It is crucial to the success of a project to have the executives well aligned behind the project vision and objectives. In addition, executive commitment is crucial in order to
reduce organizational project barriers.
Some organizational issues can break the project and need to be addressed as soon as possible in order to ensure the success of the project. During the Executive
Alignment Workshop, the executives will highlight the key issues to address. The Sponsorship Program (EOCM.040) will be the tool used to mitigate those issues.
The Executive Alignment Workshop (EOCM.030) is a complete day of meeting and will cover the topics determined in this task.
An integration process requires executive-level visibility and commitment to increase the potential for project success and return on investment. It is more efficient to align
the project teams and set direction when the executives are seen to lead the way. It is also easier to cascade the alignment to the next level of management when the
executives have defined the project governance, success criteria, and goals. The key objectives of the Executive Alignment Workshop are:
Ensure that the executives are aligned and stand behind the objectives for each project's, vision and success criteria to ensure that there will be consistent cross-
organizational project success and a valued delivery.
Identify the project risks for each project and determine how the executives can maintain alignment while reducing roadblocks.
Develop actionable governance improvements and provide recommendations for reducing risks.
Create a guidance coalition.
Address political issues.
Define key actions to put in place in order to reduce project barriers.
Set up a Steering Committee.
Prepare for Workshop
Use the Session Planning Checklist(s) from the Executive Alignment Workshop Materials (EOCM.020). Ensure that all of the work from the Prepare for Executive
Alignment (EOCM.020) task has been preformed. By accomplishing the necessary pre-work, you will have already attained the full commitment and buy-in from the
client. If there is something that is not completed, it is crucial to complete the activity before to the kick off of the workshop to ensure the full success of the workshop.
Facilitate Interactive Work Sessions
Key executives are assembled to identify the scope and organizational impact of the projects in the IT Portfolio, on the business, and to plan for a successful delegation to
the project team. The interactive work sessions look at key considerations when introducing new enabling technology, in order to maximize the business benefit to the
organization and reduce the implementation risks.
Use the Executive Alignment Workshop Materials (EOCM.020) to facilitate the workshop.
PROJECT VISION AND OBJECTIVES SESSION
The facilitation of this topic will take into consideration the level of alignment or lack of alignment identified during the interviews. The alignment of the project vision with
the business strategy identifies the rational for the project and expected business objectives and benefits. All executives will have to communicate this vision and ensure
that there is buy-in behind it.
The project objectives are aligned with the project vision and executives need to agree on them before having an effective discussion on the vision. They also have to
agree on the project success criteria to have a targeted discussion on the vision.
Before starting any discussion on project vision, objectives and success criteria, it could be relevant to invite the facilitating organization (for example, Oracle) and/or the
client project manager to introduce the solution. Usually, executives have a very high understanding of the project but do not always understand the magnitude or the
scope and what it is in scope and out of scope. This first step will smoothly guide the discussion.
The facilitator should call on the project managers to introduce the solution. It is best if both of them share the presentation in order to demonstrate that there is balanced
leadership positioning. Also, the facilitator should know what will be presented and can integrate the information into his/her slide deck.
Typically, executives have to agree on the top four or five objectives to build the necessary commitment. From the interviews, the workshop facilitator (change
management specialist) explains the level of alignment behind objectives:
The objectives with overall consensus.
The objectives that are not the same.
The objectives that some executives are not comfortable with or question.
The prioritization of each objective.
The facilitator should guide the discussion in a way to obtain agreement on the prioritization of the objectives for four or five of them by identifying:
Which objectives are aligned to the goals and vision of the organization
Which objectives create the greatest overall positive impact
Identifying those objectives that can be achieved in the short term vs. long term
Which objectives create the least amount of job impact
For providing direction to the project team, executives have to agree on the success criteria of the project. The measurement of these criteria also guides the Steering
Committees involvement in the project. The workshop facilitator should:
Summarize what is a good criterion (measurable, observable, etc.).
Introduce the criteria identified during interviews and recognize where there is and is not consensus.
Differentiate between those criteria that are hard to reach but attainable from those that will not be reached.
Assess the overall readiness and preparatory work that has already been conducted.
Usually the project vision is presented by the project sponsor and the draft of the vision is ready for the presentation and will follow these criteria:
Is based upon the stated beliefs and values of the organization
Is developed collaboratively by representatives from the key project groups
Is a broad, comprehensive statement of what the organization should look like as a result of the project within a certain time period
Is a future-oriented statement consistent with the current status of the organization as well as important trends within the organization
The change management specialist (workshop facilitator) supports the project sponsor with facilitating the discussion. Facilitation techniques help the participants to share
their level of comfort with the draft vision statement and will:
Define where the organization wants to be in the next few years.
How the organization will be a better/more efficient organization after the implementation.
Define what this will mean for their employees, the organization, their share holders, the industry and their competition.
What will the executives have to do in order to move this vision into action.
Facilitate the discussion in order to gain consensus on the foundations of the vision and provide opportunities for the participants to influence each other as they
share their perceptions on the way to building overall consensus.
Avoid wording work and stay on key elements.
Give opportunities to get more input as possible from participants.
Get a vote at the end of the key foundation point for validating the consensus.
Assess if the executives are able and willing to exert their own time and energy to support the vision.
When the key elements of the vision are agreed to but they cannot formulate a final vision within the group, than the facilitator will propose another version which will be
sent for approval within 24 hours. The participants will then have to send their comments within the next 24 hours and if comments are not received from some
individuals, it means that this individual(s) agreed on the statement.
PROJECT DIRECTION SESSION
During executive interviews, the high-level project risks and challenges were captured and some key risks and challenges were selected to be addressed. The project
sponsor has agreed on this prioritization. Some key actions have been identified to manage their impact and mitigate their risks.
The facilitation of this topic must ensure that the executives are on the same page on the challenging situations that can make or break the project. The participants
should discuss the organizational risks; identify what are the key actions to put in place, their role and how their direct reports can be involved in the cascade of the
problem-solving approach.
From the series of challenges (for example, cultural, organizational, political, employee resistance or relation to union potential reactions), the executives will select those
that need to be managed at the executive level and in the management cascade. The change management specialist (facilitator) will introduce the risks that were
identified at the time of the executive interviews and described as being major risks for the project.
Introduce the Sponsorship Program
As stated previously, during the individual interviews with executives, key issues have been captured. Executives are challenged with removing organizational barriers
and addressing these key issues.
During the Project Direction Session, this topic is addressed in a way to prioritize the problems that can break the project. The change management specialist will define
the Sponsorship Program for the executives and explain the leading practices related to it. The Sponsorship Program identifies the best executives to address specific
organizational challenges and coaches them on mechanisms, activities and communications in order to remain aligned throughout the project. The goal of the
Sponsorship Program is to mitigate risks and get management aligned behind the change. Therefore, a Sponsorship Program:
Identifies actions that could be taken at the executive level to address project risks/ and challenges.
Identifies what the executives will do to support the implementation team.
The Sponsorship Program is not built during the workshop, however, an outcome of the workshop will be a prioritization of the major challenges in order to give direction
and make inputs into the Sponsorship Program (EOCM. 040).
The project sponsor should explain why it is important for the project to get commitment from the executives (VPs) in reducing project barriers and ensuring the success of
the project. The project sponsor should also elaborate that the Sponsorship Program is a tool to measure the commitment of each executive. Finally, the project sponsor
should inform the executives of their commitment to the Sponsorship Program by:
ensuring that they model the change
conducting weekly Steering Committee meetings
conducting periodic meetings with the core and extended project team
In some organizations, the Sponsorship Program may be integrated in the executive performance incentive plan or an additional bonus may be applied. If that is the
case, the project sponsor should provide the details to the executives.
REPORTING STRUCTURE SESSION
Executives have to synthesize an effective process for reporting key project information up and down through the organization. This process must be captured to ensure
that reporting is performed effectively and efficiently.
During the session, this topic is addressed so clear lines of reporting can be structured.
ROLES SESSION
Project Sponsor
While all the executives will be involved in the Sponsorship Program, some members will also participate in the Steering Committees work. It is also possible that the
project sponsor will not be the Steering Committee leader, so the roles must be clearly defined to ensure a clear alignment for the work.
The project sponsor should introduce his role to the workshop participants. Before the meeting, the change management specialist will have worked with the project
sponsor to define his role. Role options include but are not limited to:
Provide policy guidance.
Mobilize the resources to implement the project.
Participate in establishing major practices for the new system.
Remove barriers.
Facilitate communications.
Chair the Steering Committee.
Steering Committee
If a proposed structure for the Steering Committee is already completed and agreed to, the project sponsor should introduce the Steering Committee charter and
members. If not, present a typical role definition for the Steering Committee:
The purpose of the Steering Committee is to create an environment conducive to a successful implementation. The Steering Committee will provide strategic direction,
allocate resources, remove barriers, protect the project from internal politics, make decisions at the appropriate level, resolve issues which have been escalated from the
advisory committee and project team, serve as the link to the project with stakeholders external to the project, and keep the project focused on the business objectives it
is intended to meet.
Invite the executives to define the roles of the Steering Committee members.
In discussions during the workshop, the executives determine the conditions for the Steering Committee success in term of participation, commitment, decision making
process (consensus, vote rules), issues resolution approach, quorum (rules for members who missed a meeting), etc.
After the Executive Alignment Workshop, you may need to facilitate the first Steering Committee for facilitating a session on the role and responsibilities of the Steering
Committee and governance rules.
Advisory Committee
For a global implementation or depending on the client culture (consensus culture), an Advisory Committee may be put in place. The project sponsor can recommend this
structure and the workshop participants can advise on this approach by defining the role of this advisory committee and select who can be members of this group. Guide
the group to consider the following:
role of the advisory committee
responsibilities
number of people who can participate
nomination process for the regions/countries
meeting schedule (quarterly? monthly?)
leader of the committee
link with the steering committee with its communication process
It is also possible that the project manager puts forth the recommendation to establish an Advisory Committee. If this is the case the decision will then be made by the
project sponsor.
COMMUNICATION SESSION
The Communication Strategy is the link between all work products and it keeps people informed about the project and helps with rumor control. The working session will
help specify the roles of the project sponsor and Steering Committee. It will be reviewed based on the Change Readiness Assessment findings. The strategy will follow
the clients culture and consider target groups impacted by the change (audiences or stakeholder groups). It is based on the involvement of key players including
executive leaders, supervisors, communications liaisons, etc.) and is aligned with the needs of the target group. The strategy and the communications portion of the
Communication Strategy and Change Management Roadmap (OCM.130) will reflect the phases of the project and will be aligned with project milestones.
Have the executives discuss their preferred process and provide the direction of the Communication Strategy, specifically regarding the communication cascade.
Perform Post-Workshop Wrap Up
Prepare the Executive Bsiness Objectives and Governance Rules that integrates into one document all the decisions reached during the workshop and complete the
related documentation to ensure that there is sign off from the project sponsor.
The Executive Business Objectives and Governance Rules that summarizes the decisions should be finalized in less than one week in order to sustain the momentum. In
some organizations, the project sponsor may require that executives sign off on the document.
closely with the project manager to conduct the Executive Alignment Workshop. The change management specialist provides guidance on leading change management
practices and direction for project change management activities. The project manager promotes cooperation, provides input and validates work products. Together, the
change management specialist and project manager perform the required activities for the Executive Alignment Workshop. This collaboration facilitates a more
successful workshop that leads to better understanding of the requirements for the organizational change.
During an Envision project, there may be an facilitating organization sales manager and/or enterprise architect who rely on the Executive Alignment Workshop to engage
those who will provide valuable information and support to the project team. This communication will likely involve many different business units across the enterprise. In
this case, the change management specialists work closely with the facilitating organization sales manager and/or enterprise architects to communicate effectively and
solicit input across the enterprise.
engagements.
Back to Top
Change Management
Specialist
Lead and facilitate the Executive Alignment Workshop. 100
Client Project Sponsor Commit to managing potential political issues. Cascade the involvement to the next management level. Actively participate in
the Executive Alignment Workshop.
*
Client Project Manager Support, provide input and participate in the Executive Alignment Workshop. *
Back to Top
PREREQUISITES
Prerequisite Usage
Ad Hoc Communications (EOCM.010) The Communication Structure component of the Ad Hoc Communications provides input into this task.
Executive Alignment Workshop Materials
(EOCM.020)
The Executive Alignment Workshop Materials consists of all the materials necessary to conduct a successful
Executive Alignment Workshop, including the interview data collected from the executives.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
EOCM-030_EXECUTIVE_BUS_OBJECTIVES_AND_GOV_RULES.DOC MS WORD
Back to Top
The Executive Business Objectives and Governance Rules is used:
to create a consensus around the project governance
to mitigate organizational risks that can make or break the implementation
to commit to managing potential political issues
to cascade the involvement to the next management level
to identify the alignment challenges early on
to asses and articulate the level of executive commitment for the project
to derive a common understanding of project vision/objectives/governance rules
to provide a picture of the level of alignment and commitment that exists at the executive level
to get a first level understanding of project barriers
Back to Top
QUALITY CRITERIA
Back to Top
EOCM.040 - BUILD AND DEPLOY SPONSORSHIP PROGRAM
In this task, you build and deploy a Sponsorship Program. The Sponsorship Program identifies the best executives to address specific organizational challenges and
coaches them on mechanisms, activities and communications in order to remain aligned, lead the change and mitigate organizational risks throughout each project in the
IT Portfolio. These executives then cascade (or sponsor) the involvement to the next level and lead the next level of management in the change path in order to obtain
their buy-in. The objectives of the Sponsorship Program are to:
Obtain commitment from the executives to lead the way and model the change.
Reduce organizational barriers and obtain the buy-in from the middle managers and stakeholders.
ACTIVITY
Back to Top
WORK PRODUCT
Sponsorship Program - The Sponsorship Program identifies the best executives to address specific organizational challenges and coaches them on mechanisms,
activities and communications in order to remain aligned throughout the project. The goal of the Sponsorship Program is to mitigate risks and get management aligned
behind the change.
Back to Top
TASK STEPS
1 Identify who is the best executive to be the owner of the Sponsorship
Program as well as the best executives who can handle these
organizational risks and lead the organization to address specific
organizational challenges.
Sponsorship
Program
Leaders
This component identifies the leader for the Sponsorship Program as
well as other executives that will assist in deploying the Sponsorship
Program.
2 Using the executive interviews conducted for the Executive Alignment
Workshop Materials (EOCM.020), identify the key risks that need to be
mitigated as well as an action to put in place to mitigate the risk.
Sponsorship
Grid - Risks to
Manage
Sponsorship
Grid - Action
to Put in
Place
The Risks to Manage is a list of all the risks that have been identified
and selected to include in the Sponsorship Program.
The Action to Put in Place describes the mechanism, activity and/or
communication that will be used to mitigate each risk throughout the
entire project.
3 Define executive responsibilities in deploying the Sponsorship Program. Sponsorship
Grid -
Leadership
Accountability
The Leadership Accountability assigns a leader to each risk. The leader
is responsible for putting the mitigating action in place and monitoring
the action as well as cascading the action to the next level, if
appropriate.
4 Determine the cascade to the next management level. Sponsorship
Grid - Other
Level of
Involvement
The Other Level of Involvement will identify the next level(s) in the
organization that will participate in the mitigating action, as appropriate.
5 Put measures in place to monitor the accomplishment of the actions.
Back to Top
APPROACH
roles and responsibilities for the steering committee. This alignment work was performed in the Executive Alignment Workshop (EOCM.030).
During the interviews for the Executive Alignment Workshop, a series of questions were asked to address the challenges and issues for the project. During the workshop,
executives identified the prioritized those issues and determined which ones would be addressed in the Sponsorship Program.
Some organizational issues can break the project and need to be addressed as soon as possible in order to ensure the success of the project. The Sponsorship Program
will be the tool used to mitigate those issues. The prerequisite for this task is the Executive Business Objectives and Governance Rules (EOCM.030) developed during
the Executive Alignment Workshop. The Sponsorship Program will be utilized and deployed during all phases until the end of the project.
The Steering Committee and the change management specialist meet to identify key risks and determine actions to mitigate them, identify Sponsorship Program leaders,
define responsibilities, and put measures in place to mitigate those risks. The change management specialist captures the highlights of this discussion and documents
them in the Sponsorship Program document.
Identify Sponsorship Program Leaders
Identify who is the best executive to be the owner of the Sponsorship Program as well as the best executives who can handle these organizational risks and lead the
organization to address specific organizational challenges.
The Sponsorship Program is a risk mitigation plan that can only be managed at the organizational level. It requires leaders who are visible and capable to make decisions
for the organization. The project sponsor needs to be involved at the highest level in order to avoid any potential political issues.
Some people within the organization may associate the deployment of the Sponsorship Program with the executive compensation program, for this reason the highest
level is required to manage this plan.
The project sponsor determines who will lead and carry out the sponsorship activities and articulates the importance of actively sponsoring the project. The project
sponsor articulates the importance of being actively engaged through out the project as each executive has a direct affect on each other. Usually, the project sponsor
assumes this responsibility, but increasingly, the Steering Committee leader assumes it.
If the leader of the Sponsorship Program is not the CEO (for a large transformation) or the project sponsor, it is crucial that this program receives the approval from these
leaders. In addition, if an executive member is the leader of the program, they need the authorization to escalate tasks to the CEO or project sponsor, as required.
Identify Key Risks and Actions
Use the Executive Interview Grid from the executive interviews conducted in preparation for the Executive Alignment Workshop Materials (EOCM.020) to help identify the
key risks that need to be mitigated. The Executive Interview Grid contains the analysis conducted on assessing the key organizational risks that need to be managed at
the executive level. Some of these were selected by the executives during the Executive Alignment Workshop or by the project sponsor to include in the Sponsorship
Program.
Once the risks are identified, define a mitigation plan for each risk that consists of actions to be put into place in order to mitigate the risk. The actions can be any
mechanism, activity and/or communication that can be used to mitigate each risk throughout the entire project.
Define Executive Responsibilities
In general, the Sponsorship Program executives responsibilities include but are not limited to the following:
Participate actively in the process be accountable for what activities are assigned and perform by the assigned date
Facilitate open and regular communication
Demonstrate personal commitment
Address issues in an open and timely way
Support those involved in the implementation process
By adhering to these responsibilities, enhance the positive
In addition, the executives are assigned to specific risks in order to deploy and monitor the mitigating action for that risk as well as cascade the action to the next level, if
appropriate.
Determine the Cascade to the Next Management Level
The Sponsorship Program identifies the best executives to address specific organizational challenges and coaches them on mechanisms, activities and communications
in order to remain aligned throughout the project.
The leaders accountable for some activities may have some actions that will start at their level and, in a second step, transfer some deployment activities to the next level.
In this case, the leader will monitor the work to be sure that the alignment is properly followed. The Sponsorship Program follows a top down approach for demonstrating
the level of commitment at the highest level of the organization. Usually, the executives will give the direction and establish the appropriate conditions, and monitor the
work in order to succeed and involve their managers in the day to day activities.
For each risk, establish a cascade order, beginning with the next level down in the organization, if appropriate.
Put Measures in Place
The monitoring of the accomplishment of activities is the responsibility of the executive who was assigned to the risk. Follow-ups are conducted in order to ensure that the
necessary actions are appropriately performed.
The leader of the Sponsorship Program will request status reports for the plan from the various executive leaders. During the Steering Committee meetings, an item is
integrated in the agenda in order to monitor the deployment of the Sponsorship Program.
Different measurements can be utilized based on the organizations culture and the preference of the Sponsorship Program leader. They may include:
Evaluate with departments/constituencies/region/countries the number of activities accomplished during an appropriate period of time
Conduct a web cast in order to check if the managers planned activities are in place
Regularly follow up during the Steering Committee meetings
Ask project managers to see if they have observed significant commitment from the management team
Lastly, examine the wider issues that need to be considered that can affect the continued effectiveness of the Sponsorship Program. Continue to evaluate the cascade
orders as the Sponsorship Program contains mechanisms, activities and communications that will be used to remain aligned and to mitigate risks throughout the entire
project.
change management specialist and project manager perform the necessary activities to build and deploy the Sponsorship Program. This collaboration facilitates the
agreed upon organizational change.
During an Envision project, there may be an Oracle sales manager and/or enterprise architect who rely on the Sponsorship Program to engage those who will obtain buy-
in for the projects that are being proposed by the project team. This Sponsorship Program will involve many different business units across the enterprise. In this case, the
change management specialists work closely with the Oracle sales manager and/or enterprise architects to communicate effectively and solicit input across the
enterprise.
engagements.
Back to Top
Change Management
Specialist
Build and deploy the Sponsorship Program. 70
Enterprise Architect Assist with any architectural topics. 30
Client Project Sponsor Assist with deploying the Sponsorship Program. *
Client Project Manager Assist with buliding and deploying the Sponsorship Program. Also provide input and validate the program before presenting it
to the project sponsor.
*
Back to Top
PREREQUISITES
Prerequisite Usage
(EOCM.020)
Use the interviews from the Executive Alignment Workshop Materials.
Executive Business Objectives and
Governance Rules (EOCM.030)
The Executive Business Objectives and Governance Rules captures the decisions made during the Executive
Alignment Workshop about project vision, objectives, and success criteria in order to communicate them to the project
team, middle managers, and end users and manage the impact of the project on the organization as well as to
mitigate organizational risks.
Back to Top
TEMPLATES AND TOOLS
EOCM-040_SPONSORSHIP_PROGRAM.DOC MS WORD
Back to Top
The Sponsorship Program is used:
to commit executives to managing potential political issues
to deploy the Sponsorship Program
Back to Top
QUALITY CRITERIA
Back to Top
EOCM.050 - ASSESS ENTERPRISE CHANGE READINESS
In this task, you conduct interviews with the facilitating organization (for example, Oracle) and the client project managers, client change management specialist and other
key stakeholders to gather information in order to determine the readiness of the enterprise to build a specific Enterprise Change Management Readiness Assessment to
be recommended based on the client culture and enterprise challenges and risks.
ACTIVITY
Back to Top
WORK PRODUCT
Preliminary Enterprise Change Readiness Assessment - The Preliminary Enterprise Change Readiness Assessment details an initial change management strategy
that is recommended based on the client culture and enterprise challenges in order to mitigate the project risks.
Back to Top
TASK STEPS
1 Document the process. Project Scoping
Process
The Project Scoping Process explains what project scoping is and the process followed to identify the
change management activities needed for the project.
2 Conduct interviews with client
and Oracle project managers
and gather information.
Appendix B Project
Manager(s) Interview
Grid
The Project Manager(s) Interview Grid includes issues to review with the project managers as well as
space to record the responses. This information is for analysis only and should not be included with the
work product delivered to the client. Tailor the grid to fit your project.
3 Identify key stakeholders,
conduct interviews and focus
groups.
Appendix A - Project
Scoping Interview
Schedule Template
Appendix C Business
Owners Interview Grid
Appendix D - Interview
Focus Group Grid
This template and the grids are used to plan and schedule and conduct the interviews. Tailor these
components to fit your project.
4 Analyze data. Appendix E
Compilation Grid
The Compilation Grid can be used to assist you in your analysis.
5 Make recommendations. Recommendations The Recommendations component includes the recommendations for the Organizational Change
Management work products that will be executed and delivered for the project. It also outlines the roles
and responsibilities for both the facilitating organization and client, where possible.
6 Validate the scoping process
results.
Validated Preliminary
Enterprise Change
Readiness
Assessment
The Validated Preliminary Enterprise Change Readiness Assessment includes the initial findings and
recommendations of the scoping process validated by project leaders and key stakeholders.
Back to Top
APPROACH
The purpose of the Preliminary Enterprise Change Readiness Assessment is to explain, to the client, the process that OUM uses to identify the change management
tasks to put in place in order to mitigate the project risks. The document describes the project scoping process and details the specific change management tasks that are
recommended for the project based on the project challenges. Further, it captures clients change management capability and provide first read in to the client culture.
The Preliminary Enterprise Change Readiness Assessment includes the following components:
Project Manager Interview Grid
Project Scoping Process
Project Scoping Interview Grids for Key Stakeholders
Documentation and compilation of the data
Recommended Organizational Change Management Work Products
Document the Process
Explain what project scoping is and document the process followed to identify the change management activities needed for the project. Topics include but are not limited
to the following:
Project Scoping
Project Scoping Steps
Before starting, refer to any available project-related documentation, (for example, Request for Proposal, solutions proposed by Oracle in the Proposal document, clients
organizational information on the company web site and any other relevant documentation).
Conduct Interviews
Meet with the Oracle and client project managers and conduct interviews to understand the project goals and objectives, sponsorship, key stakeholders, project team,
major challenges, clients past experience with change and change management capability. These meetings will be used to acquire relevant documentation from the
project managers that will provide the background information and specifics on implementation. The information acquired in these meetings will provide input in creating
the interview grid and focus group grids that will be used for project scoping.
Identify key stakeholders and target groups to interview. Who will be the most impacted and where are they located? What level of change can we already identify? From
the organizational structure, which level of management could be significantly impacted? This information can be identified by the client at different levels and the
resource who is leading this change effort can direct the change management specialist to identify the target populations. Consider the following key stakeholders:
Project Sponsor
Steering Committee Member(s)
Project Managers
Project Team Member(s)
Representatives from IT and Training Area
Consider the following target groups:
Key groups impacted
Others who may not fully use the applications
Interviews are individual meetings with managers and employees to gather information on major project challenges, risks, impacts, target groups and understand the
communication/training culture and needs/fears/expectations.
In large organizations, it is not possible to complete this task with interviews; a focus group approach can capture more information in less time. Focus groups can be
used to supplement information collected from individual interviews.
Establish an interview schedule. The number of interviews and focus groups that need to be held depend on the size of the organization and the size of the
implementation. Steps will be taken to ensure that representatives from all stakeholder groups and impacted groups are included in this activity in order capture required
information.
Analyze Data
Compile all the date captured during the interviews with the different stakeholder groups including the steering committee, business owners, project team, middle
managers and end users. This data will make it possible to identify the gaps between the new requirements and the current organizational structure, roles, resources,
and workflows.
The accuracy of the data collected is imperative. As the interviews and focus groups progress there will be some consistencies and inconsistencies. Therefore, it is very
important to use a template that will enable you to quickly capture and analyze the consistencies and inconsistencies.
Analyze for the following:
Compare responses and pay particular attention to multiple similar responses to issues.
Identify where the major challenges are, the organizations capability to manage risks based on its experience and if people have faith in the organizations
capability to successfully manage the change.
Determine if the knowledge, skills and capability of internal resources to mitigates risks in place and as well as the leadership to lead the change.
Identify the communication culture.
Identify the most effective and preferred communication channels.
Determine if the organization is perceived as having a learning culture and has a past experience in successfully deploying training.
Identify the effectiveness of a Change Agent Structure based on culture or number of sites or geographical distances.
Summarize the magnitude of the risks and the change capability.
The findings from the data will provide input on the change management needs of the client through a high-level assessment of the organizational culture and capabilities,
training capabilities, communication styles, past experience, concerns, fears, expectations, project risks and challenges. This in turn, will enable the selection of change
management work products required for successful implementation of the technology.
Validate findings with both the faclitating organization and client project managers.
Make Recommendations
Make recommendations regarding the change management activities needed for the project. Project scoping data and findings will be used as an input to make these
recommendations. Include a listing of change management tasks required for the project and identify faciliting organization (e.g., Oracle) and client resources
responsible.
In short, the objective is to identify key work products needed for the projects to mitigate organizational risks and make recommendations on who will be accountable for
each of them. Suggestions will include client responsibilities, as well as the role of a change management specialist and client resources and the estimated number of
days required for completing the change management tasks and activities.
Validate Recommendations
Validate findings with both Oracle and client project managers in terms of internal organizational situation as well as client change capability.
Request an internal validation to confirm the analysis, recommendations and planning. Create a presentation to present the findings and recommendations based on the
assessment to the project sponsor and key stakeholders. The presentation should contain the following information to be validated:
Findings from Scoping Interviews and Focus Groups
Change Management Needs for the Project
Recommended Change Management Work Products
During the presentation of the assessment, key stakeholders will be asked to review the information presented and resolve potential issues and validate
recommendations. Finalize the Preliminary Enterprise Change Readiness Assessment by incorporating this feedback.
change management specialist and project manager determine and document responsibilities for the activities of the Enterprise Change Readiness Assessment as soon
as possible in order to eliminate andy confusion as the project progresses. This collaboration facilitates the agreed upon plan for organizational change.
During an Envision project, there may be an facilitating organization sales manager and/or enterprise architect who rely on the Preliminary Enterprise Change Readiness
Assessment to assess the potential risks for the projects being proposed. This Preliminary Enterprise Change Readiness Assessment will involve many different
business units across the enterprise. In this case, the change management specialists work closely with the facilitating organization sales manager and/or enterprise
architects to communicate effectively and solicit input across the enterprise.
Back to Top
Change Management
Specialist
Lead the activities required to complete the Preliminary Enterprise Change Readiness Assessment and recommend the
necessary change management work products to accomplish change management activities.
100
Back to Top
PREREQUISITES
Prerequisite Usage
(EOCM.030)
The Executive Business Objectives and Governance Rules captures the decisions made during
the Executive Alignment Workshop about project vision, objectives, and success criteria in order
to communicate them to the project team so that they can then provide direction to middle
managers and end users and manage the impact of the project on the organization as well as to
Back to Top
TEMPLATES AND TOOLS
EOCM-
050_PRELIMINARY_ENT_CHANGE_READINESS_ASSESSMENT.DOC
MS WORD
Back to Top
The Preliminary Enterprise Change Readiness Assessment is used:
to document the OCM strategy for the client
to identify the relevant OCM tasks and work products
to mitigate risk
Back to Top
QUALITY CRITERIA
Back to Top
EOCM.060 - PREPARE PROJECT TEAM FOR ENTERPRISE
CULTURE
In this task, you prepare the core project team for the enterprise culture. During Envision, this includes the Sales, Consulting, and Enterprise Architecture resources.
ACTIVITY
Back to Top
WORK PRODUCT
Prepared Project Team - The Prepared Project Team can interact with the enterprise and is sensitive to enterprise cultural and political issues.
Back to Top
TASK STEPS
1 Review the Preliminary Enterprise
Change Readiness Assessment
(EOCM.050)
None The Preliminary Enterprise Change Readiness Assessment details the specific change management steps
and activities that are recommended based on the client culture and enterprise challenges in order to mitigate
the project risk.
2 Determine cultural or political topics
of interest.
Assessment
of Client
Culture
The Assessment of Client Culture organizes your findings and provides insight from the assessment.
3 Prepare the presentation. Client
Culture
Presentation
The Client Culture Presentation is used to sensitize the project team to the client culture. It should contain
information on all of the cultural or political topics of interest.
4 Deliver the presentation. Prepared
Project
Team
The Prepared Project Team is prepared to interact with the client and is sensitive to client cultural and political
issues.
Back to Top
APPROACH
The difference between winning or losing a deal and experiencing overall success resides in our capability to establish and then foster a lasting relationship with our
clients. Focusing on the uniqueness of our clients culture allows us to influence our clients with integrity and respect and enhance the relationship.
This task must be carefully planned in order to assess client culture. Understanding the culture of our client is extremely necessary as it will give you a clear cut advantage
in ensuring that you are taking the necessary steps in identifying risks that could affect the level of acceptance and adoption of the new technology and processes from
the end-user community. In addition, there are aspects of a clients culture that can be leveraged and will enhance the success of the project by producing greater buy in
and engagement from all levels of the organization.
Organizational culture is all of the following:
Organizational culture refers to the unwritten, unspoken, but powerful "rules of the game" that determine appropriate ways to "think, act and feel. Therefore, be
mindful of how you treat the client during the sales cycle through delivery.
The culture determines the employee experience and the degree to which mission and values are realized. Oracle implementations bring about substantial change
so leverage the positive aspects of the culture and manage the change effectively.
Organizational culture has also been considered a form of organizational capital. If it is lacking rest assured that you will have to manage resistance and risks that
could negatively impact the overall solution.
Factors that define an organizational culture include:
Degree of hierarchy within the organization the extent to which the organization values traditional channels of authority and the need to utilize those channels.
Degree of urgency - how quickly the organization wants or needs to push decision-making and innovation.
People/task orientation An organization with a strong people orientation tends to put people first when making decisions. An organization with a strong task
orientation tends to tasks and processes first when making decisions.
Assertiveness/courtesy dimensions is it a matter of speed or is there time taken in respecting ones position?
Functional orientation get a handle on what the majority of employees perceive to be the companys functional orientation.
Institutional personality issues How is your organization known to others? How would you and others characterize the organization?
Values What do you value as an organization? What does your organization feel to be its most important quality?
Use the following opportunities/situations to assess client culture include:
Look around. What do the headquarters and other buildings look like? How are people dressed? How much interaction is there? Who is talking to whom? How
does the place feel?
Read newsletters and other internal documents. What values are emphasized? Who is held up for praise? Are parties, celebrations, or other ceremonies
mentioned? What sorts of things are discussed?
Look at annual reports or other communications to those outside the company. What face is being presented to the world?
Ask, Can you tell me anything about what the culture is like here? Are there any stories that people here tell about X?
Ask, What values are stressed in X? How are they communicated? How are they reinforced?
Ask, Who is looked up to in X?
See what you can learn about rites and ceremonies in the organization. What happens when people accomplish something? Are there rites of passage such as
promotion ceremonies and retirement parties? Are there regular get-togethers such as holiday parties, social events, and company softball games?
Ask, What sorts of behaviors are expected and rewarded here? What sorts of behaviors are punished?
Ask people outside the firm what they think of it.
Check magazines, newspapers, and other sources to get clues about the culture.
Review the Preliminary Enterprise Change Readiness Assessment (EOCM.050)
The Preliminary Enterprise Change Readiness Assessment (EOCM.050) details specific change management steps and activities that are recommended based on the
client culture and enterprise challenges in order to mitigate the project risk. Although the method reflects the leading practices for implementations, we must deal with the
behavioral component meaning that our approach must be aligned to the change management strategy and the client culture that is in place.
Organizational culture has the potential to enhance organizational performance, individual satisfaction, the sense of certainty about how problems are handled, and other
aspects of work life. If your client counterparts are going against the culture then there are ideals and perspectives that are nonaligned. Therefore it would beneficial to
take a step back, assess your approach and create better alignment where possible.
Keep in mind that you will need strong executive support. Strong corporate cultures improve firm performance by facilitating internal behavioral consistency. Executives
must stay aligned and engaged by sponsoring the project to ensure that the culture supports the consistency.
Determine Cultural or Political Topics of Interest
In a scoping effort you would want to get a good read into the clients culture. As you perform this task you are already allowing different folks to contribute and be heard.
This helps in creating not only a larger network but it is more likely that they will buy-in and stay engaged in the project.
While assessing organizational culture, take note of the following factors:
Underlying assumptions Shared beliefs that are not necessarily at the level of awareness. Therefore gain the perspectives of those involved from various
constituencies. One on one discussions and focus groups are very beneficial. Ensure that raw data will not be presented/released in order to allow participants to
be open and honest.
Values and beliefs Consciously shared beliefs, values, moral and ethical codes and ideologies. These organizational aspects can be gathered by those who
allow themselves to be sensitized to the situation and environment. Be mindful of displays and the manner in which clients interact and collaborate.
Patterns of behavior Rites, rituals and behavioral norms. Ensure that your approach to addressing the soft side of the implementation is aligned to the clients
patterns of behavior. Be prudent but pay special attention to the interactions and communication style.
Artifacts and the physical environment Material and nonmaterial objects and patterns that communicate information about the organizations beliefs, values,
assumptions, etc. You should not only detect the impact of these aspects but take note of what works and what does not. By doing so you can create better
visibility about the project and enhance the manner in which communication is delivered and successfully received.
Organizational climate and subcultures - (attitudes and biases) feeling, tone or organizational mood. If poor, build in team building initiatives, reward mechanisms
and create milestone celebrations. This will enhance the visibility of the project and get people to buy in and get engaged early and often.
Organize the findings of your assessment into a grid that can serve as a coaching tool to the project team members to act appropriately.
Prepare a presentation (for example, PowerPoint Presentation) from the Assessment of Client Culture that covers all of the topics. Keep in mind the following:
Officially develop the time, date and logistics for the client culture presentation with the Oracle and client project managers along with the project sponsor.
Craft a section of the communication that dictates what will be addressed and what will be expected of each participant.
Speak to the Oracle project manager in order to determine how materials, printing, food, drinks and refreshments will be provided.
Ensure that all presentation materials along with tools and templates are printed and appropriately packaged prior to the client culture presentation.
Reserve all items that are necessary to run the session and ensure that they are in the room prior to the start of the presentation. Such items include pens,
markers, whiteboards, easels, paper, projectors etc.
Additional items may include name tags, badges and security passes.
It is imperative to assess the client culture on a continuous basis. Cultures change and in projects that require the project team to be on site for a significant duration the
team will see that as well. The project team must be aware of the clients culture and must be able to act appropriately.
Deliver Presentation
Deliver the presentation to the project team. The presentation is used to prepare the project team for the enterprise culture. It should contain information on all of the
cultural or political topics of interest. Provide tools and templates as you coach the project team to increase their accuracy of assessing the enterprise culture.
When delivering the presentation, pay attention to the following tips:
Was I am impartial observer of the culture in action? Look at the employees and their interaction.
Have I paid attention and watched for emotions? Emotions are indications of values. People do not get excited or upset about things that are unimportant to
them. Examine conflicts closely, for the same reason.
Did I locate and pay attention to relevant objects and artifacts? Those that sit on desks and hang on walls. Observe common areas and furniture arrangements.
Did I observe and interact with employees watching for things that are not there If nobody mentions something that you think is important (like the customers),
that is interesting information. It will help you understand the organization's culture.
change management specialist and project manager perform the necessary activities to ensure the project team has an understanding of the enterprise culture. This
collaboration facilitates the agreed upon activities necessary for the organizational change.
During an Envision project, there may be an Oracle sales manager and/or enterprise architect who rely on an understanding of the client culture to engage those who will
provide valuable information to the project team. This understanding of the culture will assist in understanding the many different business units across the enterprise. In
this case, the change management specialists work closely with the Oracle sales manager and/or enterprise architects to communicate effectively and solicit input across
the enterprise.
Back to Top
Change Management Specialist Lead the work to prepare the project team for the client culture. 100
Project Manager See the above The Project Manager and OCM section. Effort for the project manager is not
included at the task level.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Preliminary Enterprise Change Readiness
Assessment (EOCM.050)
The Preliminary Enterprise Change Readiness Assessment details the specific change management steps
and activities that are recommended based on the client culture and enterprise challenges in order to
mitigate the project risk.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Prepared Project Team is ready to interact with the enterprise and is sensitive to cultural and political issues.
Back to Top
QUALITY CRITERIA
Back to Top
EOCM.070 - IDENTIFY CHANGE AGENT STRUCTURE
In this task, you educate the enterprise regarding the Change Agent Structure, work with the enterprise to identify change agents, and obtain a commitment (from the
enterprise and change agents) on the overall change agent approach.
ACTIVITY
Back to Top
WORK PRODUCT
Change Agent Structure - The Change Agent Structure consists of committed key stakeholders including managers, business owners and end users who have been
selected to serve as change agents for the project.
Back to Top
TASK STEPS
1 Educate enterprise regarding the Change Agent Structure. None
2 Work with the organization to identify key members who potentially could
be trained to deploy the change management and communication
activities and communications generated by the change management
specialists.
Change
Agent
Structure
The Change Agent Structure consists of managers, business owners and
end-users that the organization recognizes as key leaders who can
effectively represent the groups impacted by the anticipated changes.
3 Obtain commitment from enterprise and identified change agents on the
overall change agent approach.
Committed
Change
Agents
Committed Change Agents are key leaders that have committed to being
trained as change agents and who are competent using their training to
deploy the change management activities and communications within their
respective groups.
Back to Top
APPROACH
The Organization Change Management (OCM) process uses a Change Agent Structure to deliver the OCM activities and communications. This approach leverages the
client networking to involve key players that model the change.
Change agents are internal resources that are responsible for helping the project team drive messages down to the end-user level within an organization. They are
typically:
Representative people from the target groups impacted by the project and the regions or departments
Leaders, preferably a manager with a strong networking, good reputation
Good communicators, not afraid of rocking the boat, etc.
The Change Agent Structure consists of key stakeholders who have been selected to serve as change agents for the project. These participants can be from the following
groups:
managers
business owners
experienced stakeholders with knowledge in a process
This group is typically responsible for driving critical project-related messages deep into the organization helping to dispel rumors and deliver timely and accurate
information to the impacted end users.
Educate the Enterprise
The first step is to educate the enterprise in the Change Agent Structure. Meet with enterprise project managers to educate them on purpose and methodology behind the
change agent structure. This is a critical step to increasing the effectiveness of project change management and communications. It is critical during this step that both
client and facilitating organization manager understand the functionality and time commitment of resources delegated to the task of change agent.
During this step, you will also explain the value proposition of developing a Change Agent Structure and provide the criteria to select these networking leaders. Change
agents serve key roles in supporting associates throughout organizational change. They act as an information conduit between the project team and impacted business
areas. They also facilitate a vehicle in which constructive feedback can be provided from the impacted business areas to the project team.
The Change Agent Structure identifies leaders (managers, team leads, business owners and users) who represent the affected populations or regions/organizations.
These leaders are then trained as change agents in order to deploy the activities and communications generated by the change management specialists from the core
change management team. The team leads from the core project team (internal resources assigned to the project) will also follow a similar approach, and both groups
will receive coaching and tools from the change management specialists throughout the project. By educating this population and making them aware of the role of
change agents, they are more prepared to deploy the activities and communications generated by the change management specialists from the core change
management team.
Identify the Change Agent Structure
Once the client understands the Change Agent Structure model, work with them to identify key members who will be trained to deploy the change management and
communication activities and communications generated by the change management specialists. Work with client sponsors and key project leads to identify candidates
who can act as effective change agents for the organization.
Members are chosen according to criteria based on leadership competencies and their ability to drive change. Identify and document key communication and change
leaders who will be educated on their role as a change agent so they can effectively represent their groups who are impacted by the anticipated changes.
Change agents are individuals that the organization recognizes as key leaders who can effectively represent the groups impacted by the anticipated changes. Individuals
selected as change agents should be carefully screened to ensure that they have the leadership competencies to effectively act in this role. Good change agents:
Command exceptional verbal and non verbal communication skills.
Demonstrate a willingness to embrace change and be proactive.
Display the ability to multi task.
Support the vision of the new organization.
Possess a strong knowledge of a business area and are respected within their business unit.
Accept this role as a priority.
Are team players.
Drive to gain clear answers for team/group questions.
Get resistance out in the open.
Build morale.
Listen empathetically.
Strive for "win-win" solutions and celebrate successes.
Change agents will act as catalysts of the change, ensuring that leadership and associates understand and commit to changes.
Obtain Commitment
Finally, obtain commitment from the client and facilitating organization project managers on the approach and resource assignment of the Change Agent Structure.
Obtain commitments from both management and the change agents to participate in a Change Agent Workshop and spend a specified amount of time each week during
the project to perform their change agent duties. Change agents will play an active role during the project. During the Change Agent Workshop, they will learn their role
and also get some information on how to deploy some change management and communication activities. For this reason, they should get approval to spend this time on
the project activities.
Committed change agents can assist with distributing information, and identifying additional training needs that cannot be easily identified from a remote location. They
may also participate in the following activities:
Perform Audience Assessments (identify groups at their locations needing specific and targeted information regarding the project).
Help to identify communication vehicles (the best way to communicate these messages, i.e., email, newsletters, etc.).
Assist in identifying change management and communication needs throughout the project.
Provide content for and validate project-level communications (verbiage appropriate to specific locations).
Facilitate a swift review/approval process when team members in their location need to review and approve communication.
Committed change agents may also be involved in supporting change management and communications work stream activities as needed, including but not limited to:
Facilitation preparation for training
Delivery and distribution of project communications
Identification of key stakeholders at designated sites
change management specialist and project manager perform the necessary activities to identify the appropriate Change Agent Structure for the enterprise. This
collaboration facilitates the agreed upon activities necessary for the organizational change.
Back to Top
Change Management
Specialist
Educate the client regarding the Change Agent Structure. Work with the organization to identify key members who will be
trained to deploy the change management and communication activities and communications generated by the change
management specialists.
100
Client Change Management
Lead
Assist with identifying change agents. *
Client Project Manager Identify and secure change agents for the project. Ensure that change agents are available to do OCM work throughout the
project lifecycle.
*
Client Project Sponsor Assist client managers in enforcing role and time commitment for Change Agent Structure. *
Back to Top
PREREQUISITES
Prerequisite Usage
Preliminary Enterprise Change
Readiness Assessment (EOCM.050)
The Preliminary Enterprise Change Readiness Assessment details the specific change management steps and activities that
are recommended based on the enterprise culture and challenges in order to mitigate the project risk.
Back to Top
TEMPLATES AND TOOLS
EOCM-070_CHANGE_AGENT_STRUCTURE.DOC MS Word
Back to Top
The Change Management Team facilitates the Change Agent Structure to integrate the work of the change agents and ensure that a common approach is taken.
Back to Top
QUALITY CRITERIA
Back to Top
[EA] ENTERPRISE ARCHITECTURE
Enterprise Architecture covers an enterprise-level view on both the application and technical architecture of the systems. The scope of Enterprise Architecture includes
aspects like technologies, frameworks, development tools, delivery methods (including standards and guidelines), network, hardware and security. The Enterprise
Architecture process also covers archiving, cataloguing and managing the repository of the artifacts of all the other processes of the Oracle Unified Method.
Back to Top
PROCESS FLOW
Back to Top
APPROACH
High-Level Architecture Approach
Industry practices for Architecture are included in OUM. At a high level all, types of architecture are evaluated using the following high-level approach:
In OUM, there are four main classifications of Architecture type, described as follows:
Business Architecture
The Business Architecture provides a business reference model used to align a business' operating model, strategies, and objectives
with IT; creates a business case for IT transformations, and provides a business-centric view of the enterprise from a functional
perspective.

Information Architecture The Information Architecture provides an information/data-centric view of an enterprise/business that focuses on key information
assets that are used to support critical business functions and are made accessible via application services for sharing, update and
exchange and provides information strategy for governance, privacy and data content/exchange standards, etc.

Applications Architecture The Applications Architecture provides an application and services-centric view of an enterprise/business that ties business
functions/services to application processes/services to application components in alignment with the application strategy and provides
industry reference architectures mapped to products (apps and tech).

Technology Architecture The Technology Architecture provides a technical reference model used to align technology purchases, infrastructure, and solution
implementations with the enterprise's IT strategies, architecture principles, standards, reference architectures, and governance model.
In principle each of the four types of architecture distinguishes the following levels:
Conceptual
The main goal of a conceptual architecture is to provide an understandable picture of the architecture. The components of the
architecture are described as black-boxes. For each black-box, its responsibility is defined and the relationships between the
components are described.

Logical The main goal of the logical architecture is to provide a description of the solution of the architecture. The components of the
architecture are detailed as white-boxes. However, the logical architecture does not include organizational unit names, application
names, server names, etc.

Physical The main goal of the physical architecture is to identify the specific business units, technologies, applications, servers, networks, etc.,
which need to be used or created to support the architecture.

For more details on how Enterprise Architecture engagements are structured using the Enterprise Architecture tasks, refer to the OADP view.
Back to Top
Initiate Phase
EA.210 Maintain Enterprise Architectural Models Maintained Enterprise Architectural Models
Back to Top
OBJECTIVES
Back to Top
KEY WORK PRODUCTS
Back to Top
Back to Top
Back to Top
EA.001 - JUSTIFY AND ENGAGE ENTERPRISE ARCHITECTS
Oracles product portfolios have increased substantially over the last few years and, as a product vendor, we are often asked by our perspective clients how the various
Oracle products can meet their needs from an enterprise wide perspective. In addition, our products often have some degree of functional overlap and it is therefore
important to position skilled architects who have a holistic view of the enterprise s business requirements and technology solutions to effectively position our products in
the most efficient manner. An enterprise architect (EA) is solution agnostic and by the nature of their role, in a position to become a strong neutral influencer with the
client and is often in the best position to unify solutions across Oracles lines of business.
However, Oracle recognizes a number of different architect roles across both license and consulting. During this task, you will identify the need to engage one or more
types of architects (e.g., business architects, information architects, application architects, etc.) in either a pre-sales or post-sales opportunity. Because each organization
may have its own engagement models, you need to contact the organizations owning the desired resources and adhere to their engagement models.
The goal is to get buy-in from internal Oracle management teams for the value of the engagement.
ACTIVITY
Back to Top
WORK PRODUCT
Assigned Enterprise Architect - The Assigned Enterprise Architect is engaged with the enterprise.
Back to Top
TASK STEPS
1 Identify the need for architects and the type(s) of
architect required.
None If the client has challenges in managing the complexity of their technology real estate or in
starting a new strategic IT initiative.
2 Engage architect resources. None Use your local engagement model to find and engage the architect resources on your enterprise
or solution architecture opportunity.
Back to Top
APPROACH
Identify the Need for Architects and the Type(s) of Architects Required
An enterprise architect focuses on enabling clients to maximize the leverage of their IT portfolio. The EA organizes the business, application, technology and integration
portfolios into a coherent structure reflected by architecture blueprint documentation to enable the business to operate and change effectively. A key aim for an EA is to
organize the technical complexity of interdependencies into a manageable structure that enables clients to adapt and transition their business and technology assets
more effectively to meet future requirements. an EA will inevitably need strong facilitation and communication skills and show no bias for a given technology or product
line. Therefore, it is highly likely that the role involves long-term commitment but not one that requires a consistent presence at the client's locations.
Oracle recognizes a number of different architect roles across both pre-sales and consulting, all of whom are in limited supply. The role names for these architects may
differ globally, but many of the concepts are the same. For an apps/tech, cross-domain, strategic account Insight, you will likely want to request and justify the
engagement of an Oracle enterprise architect during the Insight discovery, solution development and solution presentation phases. When deep architecture skills in
specific domain areas are required, you will want to engage more specialized solution or technical architects.
The following illustrates a typical client architecture blueprint that focuses on service orientation that an EA is likely to develop on behalf of the client. The example outlines
the fact that blueprints may be focused in specific parts of an enterprise architecture, such as, the application portfolio.
Example Enterprise SOA Blueprint
The role of the enterprise architect in the engagement is:
to act as a strong neutral influencer within the group of decision makers and influential stakeholders (e.g., C-Level stakeholders) in the clients environment
to govern the overall end-to-end solution architectures and propositions delivered by Oracle license and consulting stakeholders
Leverage Your Local Engagement Model
This task is not trying to replace your local and possibly unique engagement models for justifying and securing architect resources. Please follow the appropriate
engagement model rules and processes to find an architect for your enterprise or solution architect client opportunity.
Back to Top
Enterprise Architect Work with the sales manager to qualify the opportunity for engaging with a particular client. Once qualified, the appropriate
roles and expertise is identified and a team is assembled according to those needs.
50
Sales Manager Work with the enterprise architect to qualify the opportunity for engaging with a particular client. Once qualified, the appropriate
roles and expertise is identified and a team is assembled according to those needs.
50
Back to Top
PREREQUISITES
Prerequisite Usage
Approval in the form of presales or investment effort for the client by the appropriate level of management.
Acceptance of the goals of the EA by the appropriate client stakeholders.
The EA is knowledgeable about the use of general enterprise architectural frameworks and methodologies (e.g., TOGAF, RUP, etc.).
Back to Top
TEMPLATES AND TOOLS
Back to Top
An Assigned Enterprise Architect is used as follows:
to produce holistic enterprise architectural collateral for the client and Oracle stakeholders
to facilitate key decision processes relating to the adoption of Oracle technologies within the client
to identify and influence the clients adoption of Oracle technologies
to identify client deficiencies in the operational elements of their IT portfolio relating to unnecessary OPEX costs
Back to Top
QUALITY CRITERIA
Back to Top
EA.002 - REVIEW EXTERNAL REFERENCE ARCHITECTURES
The emergence of industry-specific or technology-specific reference models is increasing. This task involves assessing the current (as-is) and potential future (to-be)
architectures of the organization against such frameworks as a means to measure compliance and maturity.
Examples of reference architecture frameworks include:
1. TMF Enhanced Telecommunications Operating Model (eTOM) for telcos
2. U.S. Department of Defense Application Framework (DODAF)
3. UK Ministry of Defense Application Framework (MODAF)
4. Oracle Reference Architecture, containing multiple architectures, such as SOA, BPM, EDA, Cloud, etc.
During this task, you develop a high-level current view of the organizations enterprise architecture and determine potential future architectures relevant for the
organization. You review existing external reference architectures that may be relevant to the organization.
This task can be used to help develop a better understanding of an organizations high-level current technology architecture and a pre-cursor to developing future state
high-level enterprise architectures.
ACTIVITY
Back to Top
WORK PRODUCT
External Reference Architectures Review - The External Reference Architectures Review documents the organizations high-level current technological state and what
external reference architectures are relevant for the organization for moving towards a desired future state.
Back to Top
TASK STEPS
1 Review organization
current state
architecture situation.
Architectural
Areas
The component lists the architectural areas for which reference architectures should be reviewed.
2 Identify relevant
reference
architectures.
External
Reference
Architectures
This component contains all the reference architectures that have been identified as relevant for the organization. It also
contains a rationale of why each architecture is relevant and what parts of the reference architectures are relevant for
which parts of the organization situation.
Back to Top
APPROACH
The following is an example of an Industry Specific Reference Architecture that is specific to the Telecoms industry. It is known as the Enhanced Telecoms Operations
Map (eTOM) and outlines several subordinate views that expand the base architecture with more detail:
eTOM Reference Architecture
Review Organization Current State Architectural Collateral
Collect all relevant current state architecture material of the organization and use this material to determine the architectural areas of interest to review any reference
architectures. If present, use the Current Enterprise Architecture (EA.030). Also, review the Business Strategy (BA.010) as this provides information on what is important
for the organization and will help to define the areas of interest. Provide a reason for each architectural area of interest.
In addition, review the Enterprise Process Model (BA.040) and Enterprise Domain Model (BA.050) to gain an understanding of the business and thereby determine the
relevant reference architectures, e.g., industrial, etc.
Identify Relevant Reference Architecture
Once you have determined the current organization situation, identify the relevant reference architectures for the organization. Indicate what part of each reference
architecture is relevant. Include a list of pros and cons. Multiple reference architectures may be appropriate for the same architectural area, and the same reference
architecture may be appropriate for multiple architectural areas. For example, in the context of Business Process Modeling, both a BPM Reference Architecture and a
SOA Reference Architecture are relevant. The same SOA Reference Architecture may also be relevant for systems integration.
Try to use as few reference architectures as possible, covering as much as possible for the organization situation. Preferably, there should be one main recommended
reference architecture, but you might have one or more additional ones covering specific gaps in the main reference architecture. For example, in Business Process
Modeling, the main reference architecture is the BPM Reference Architecture. The BPM Reference Architecture may have touch points with specific aspects of the SOA
Reference Architecture, as well as specific aspects of the Security Architecture.
Keep in mind that you are not developing the organization reference architecture in this task; that is done in task EA.075, Develop Technology Reference Architectures.
Instead, in this task, you identify relevant reference architectures that you will use as an input to create or update the organization's reference architecture.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Compile industry reference architectures (including Oracle's) and determine the fit/gap with the client's current state. 50
Solution Architect Contribute domain- or solution-specific reference architectures and performs fit/gap analysis with respect to the client's current
state.
50
Client Enterprise Architect *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy
(BA.010)
Understanding the Business Strategy will assist in the understanding of the organizations business architecture and the business drivers that will
help determine what is important for the organization.
Current
Enterprise
Architecture
(EA.030)
The Current Enterprise Architecture can be used to assess the maturity of the existing enterprise architecture (for a given technology domain) and
from there determine which external reference architectures might be useful to enhance the existing enterprise architecture or if one needs to be
developed (if none exists).
Enterprise
Process Model
(BA.040)
A good understanding of the organizations key business processes will help develop a view of the key high-level technological capabilities that are
required to support those processes both now and in the future.
Enterprise
Domain Model
(BA.050)
The Enterprise Domain Model (business and/or technological domain centric) will help determine what kind of reference architectures may be
relevant.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
task.
Back to Top
The External Reference Architectures Review is used in the following ways:
assist the enterprise architects in describing the current architectural options
assist the organization in understanding the architectural reference s relevant for their situation
Distribute the External Reference Architectures Review as follows:
to the enterprise IT stakeholders
to the project team
Back to Top
QUALITY CRITERIA
Is the relevance of the identified external reference architectures properly motivated?
Are external reference architectures that were considered, but found not to be relevant, properly documented?
Does the External Reference Architectures Review properly describe the organization's existing architectural options?
Back to Top
EA.010 - REVIEW ARCHITECTURE PRINCIPLES, GUIDELINES
AND STANDARDS
During this task, you determine and document the Architecture Principles, Guidelines and Standards that are relevant to the organization.
For high-level architecture engagements, a just enough principle should be employed when performing a discovery of and definition of Architecture Principles, Guidelines
and Standards. When you are considering constructing principles, guidelines and standards, you should first focus on determining what activities and artifacts will benefit
from or even require principles, guidelines and standards. Typically, you should concentrate on the principles, guidelines and standards that have a material impact on
the current state architecture and may need to be updated as part of the future state architecture planning.
The definition of principles, guidelines and standards is an ongoing task during an engagement. Initially, focus on identifying the Architecture Principles, Guidelines and
Standards that are currently in place in the enterprise and then update/add to this list to arrive at an initial set of principles, guidelines and standards that will be used as
the basis for defining the future state Enterprise Architecture. On an ongoing basis, keep them up-to-date with new developments, insights and enterprise-level
requirements as you work towards the creation of the Future State Enterprise Architecture. Separate from a specific engagement, the Architecture Principles, Guidelines
and Standards are maintained as they evolve throughout the business lifecycle.
From an enterprise architecture engagement standpoint, you would first collate all the Architecture Principles, Guidelines and Standards that govern the existing
Enterprise Architecture and then work with the organization to add to the list or amend existing entries that will be relevant to the Future State Enterprise Architecture.
If available in the enterprise, the Enterprise Repository is an important place to share and control enterprise-relevant information. The Enterprise Repository should be
used to record the individual policies, standards and guidelines. Not only can they be centrally managed but their usage can be tracked. For example, assets can be
marked as compliant or non-compliant to certain policies which is very useful for IT Governance. Similarly, tracking the usage of standards is an invaluable source of
information for future direction.
OUM contains several techniques to help you define standards and guidelines for SOA services. Refer to the Techniques section below for more details.
ACTIVITY
EA.010.1
EA.010.2
Back to Top
WORK PRODUCT
Architecture Principles, Guidelines and Standards - The Architecture Principles, Guidelines and Standards details the principles, guidelines and standards under
which the enterprise operates and that are applicable for programs and projects performed in the enterprise. They allow for consistency of work over all programs and
projects and provides a starting point for principles, guidelines and standards definitions for each project.
Back to Top
TASK STEPS
1 Determine need for principles,
guidelines and standards.
None
2 Compile a top-down level draft of
current state principles, guidelines
and standards.
None Gather the architectural principles, guidelines and standards that are relevant to the scope of your
engagement. This may include interviewing key staff within the organization where the principles,
guidelines and standards have not been formally captured in documents.
3 Determine initial set of principles,
guidelines and standards.
Architecture
Principles,
Guidelines and
Standards
Working with the key stakeholders, the current state and other inputs are evaluated to form the initial set
of principles, guidelines and standards. This may also involve the identification of any gaps in the
existing principles, guidelines and standards, and the definition of new principles, guidelines and
standards as appropriate.
4 Verify the Architecture Principles,
Guidelines and Standards with the
business stakeholders and obtain
sign off.
verified
Architecture
Principles,
Guidelines and
Standards
The verified Architecture Principles, Guidelines and Standards have been verified and updated based on
the review with the business stakeholders. They describe all the high-level corporate principles,
guidelines and standards under which the enterprise operates.
5 Update the Architecture Principles,
Guidelines and Standards after the
future state architecture has been
developed.
updated
Architecture
Principles,
Guidelines and
Standards
The updated Architecture Principles, Guidelines and Standards have been updated to incorporate those
principles and guidelines that will help govern the Future State Enterprise Architecture.
6 Verify the Architecture Principles,
Guidelines and Standards with the
business stakeholders and obtain
sign off.
verified
Architecture
Principles,
Guidelines and
Standards
The verified Architecture Principles, Guidelines and Standards have had a final business stakeholder
validation of the updated/amended principles, guidelines and standards, e.g., after the Future State
Enterprise Architecture has been defined.
Back to Top
APPROACH
During this task, you determine and document the corporate Architecture Principles, Guidelines and Standards that are relevant to the organization. There are many
resources for determining and documenting principles, guidelines and standards (e.g., TOGAF).
Principles, guidelines and standards are defined as follows:
PRINCIPLES
Principles characterize themselves as durable intentions. Well-chosen principles rarely change and have a great impact on the development of the enterprise. Most
enterprises (such as Oracle) are founded on principles.
Examples of architecture principles and guidelines would include:
Data Owners are accountable for controlling access to the information that they own.
Maximize ROI on existing technology investments.
Utilize open vendor APIs to support application to application integration initiatives.
Maintain service oriented/autonomous computing.
The architecture principles may be categorized as Functional (e.g., Finance, CRM) or Technological (BI, Collaboration) domains.
Because architecture principles tend to be strong guidelines, they have to be verified by the business owners. Verify draft output with customer and update if required.
Obtain final sign off when complete. When creating an Architecture Principles, Guidelines and Standards document it has to be sold to the key stakeholders as a
valuable document. The lead enterprise architect or someone representing the board should be able to articulate the value and get commitment. Only then will the
Architecture Principles, Guidelines and Standards achieve their maximum value.
GUIDELILNES
Guidelines indicate behaviors or characteristics that are preferred. Guidelines are intended to support the enterprises principles while providing a lower level of technical
detail than what is captured in a principle. It may be possible to violate a guideline while still adhering to a principle. For example, using a non-standard implementation
technology (e.g., SOAP over JMS) to implement a business service may violate the guideline Web services are to be based upon web services standards but comply
with the standard Integration is based upon a Services Oriented Architecture.
STANDARDS
A standard establishes a technical norm or requirement. Where a principle or guideline will generally tell you what is expected, a standard will tell you how to go about
complying with the principle. A standard is usually at a lower level of detail than either a principle, or a guideline; however, standards should support the principles and
guidelines. For example, a principle may deal with the general security of data, while a standard would dictate the various data sensitivity classifications and the
acceptable mechanisms to protect data of a certain classification.
Determine Need for Principles, Guidelines and Standards
Determine what areas would benefit from or require principles, guidelines and standards. This is guided by the nature of the engagement, and the types of activities that
will benefit from the definition of principles, guidelines and standards. This task step should adhere to the just enough principle, i.e., focus on developing principles,
guidelines and standards where it is clear they will be used, or where there will be a negative impact upon the enterprise architecture in the event that the principles,
guidelines and standards is not adhered to applied.
Gather Existing Principles, Guidelines and Standards
Obtain all relevant artifacts that would help to compile a list of key principles, guidelines and standards relevant to the scope of the exercise you are performing. Example
inputs would be annual reports, mission statements, vision strategy documents, etc. Arrange stakeholder interviews to help compile the list (as relevant).
Gather existing principles, guidelines and standards that have been used in the enterprise. Look through project standards. Where needed standards and guidelines
cannot be found in the enterprise, acquire suitable standards and guidelines elsewhere.
Capture and document corporate Architecture Principles, Guidelines and Standards. Often customers already have these documents. Clarification about the status (e.g.,
Is the document up-to-date and accepted by the enterprise stakeholders?) and a review of the quality of the information are important.
If an Enterprise Repository is in place, review the meta model and see if it includes a policy asset type. If so, select all policies from the repository to create a list of
already defined principles, guidelines and standards.
Determine Initial Set of Principles, Guidelines and Standards
From the list of principles, guidelines and standards that you have pulled together, determine which of them should be included in the formal Architecture Principles,
Guidelines and Standards. It is also likely that there are gaps. If so, relevant stakeholders (business, IT, architecture) should be involved in order to identify new
principles, guidelines and standards that apply to the Future State Enterprise Architecture.
Classify the guidelines and standards for applicability to a specific project, technique, modeling tool, programming language, etc.
Once the Future State Enterprise Architecture has been defined, the Architecture Principles, Guidelines and Standards should be updated to align with the new
architecture.
Each principle, guideline or standard should be given a unique identifier so that it can be easily referenced.
If an enterprise repository is in place, review the meta model for corresponding asset types. Document any needed changes to the model and hand it over to portfolio
management (GV.096) for approval and realization.
Verify the Architecture Principles, Guidelines and Standards
Work with the key stakeholders in the enterprise (business, and IT stakeholders) to ensure that the current state Architecture Principles, Guidelines and Standards are
complete, correct and up-to-date.
Update the Architecture Principles, Guidelines and Standards
During the enterprise lifecycle, there will be changes in the type of activities performed and the kind of artifacts produced. The Architecture Principles, Guidelines and
Standards should be updated accordingly, both in the document and/or the Configured Enterprise Repository, as appropriate.
If an already existing principle, guideline or standard needs to be updated, a new version of the asset should be created in the Enterprise Repository. By analyzing the
relationships already registered in the Enterprise Repository, you can identify the assets that might be impacted by the change. For each asset decide, if the changed
policy should be applied or if the relationship can be deprecated.
Verify the Architecture Principles, Guidelines and Standards
Work with the key stakeholders in the enterprise (business, and IT stakeholders) to ensure that the updated Architecture Principles, Guidelines and Standards are
complete, correct and up-to-date.
engagements.
Back to Top
BPM Roadmap
Supplemental Guide.
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Determine relevant areas for defining principles, guidelines and standards. Compile the initial Architecture Principles,
Guidelines and Standards and obtain sign-off. Update the Architecture Principles, Guidelines and Standards as appropriate
and obtain sign-off.
100
Client Enterprise Architect Assist in determining relevant areas for defining principles, guidelines and standards as well as defining and updating the
Enterprise Architecture Principles, Guidelines.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Envision Strategy
(ER.020)
Agreed On
Envision Plan
(ER.050)
Review the Envision Strategy and Agreed On Envision Plan to determine the areas where standards and guidelines are needed.
Mandate Matrix
(GV.020)

Maintained
Repository of
Artifacts (IP.080)
Use this work product to determine what kind of principles, guidelines and standards are required.
Governance
Implementation
(GV.100)
Architecture Principles, Guidelines and Standards. In addition, ensure that the Architecture Principles, Guidelines and Standards are
Back to Top
TEMPLATES AND TOOLS
EA-010_ARCHITECTURE_PRINCIPLES_GUIDELINES_STANDARDS.DOC MS WORD
Tool Comments
Overview
Back to Top
TECHNIQUES
Technique Comments
Service Architecture Use this technique to understand the architecture standards and guidelines that apply to SOA services.
SOA Service Boundary Analysis Use this technique to understand the standards and guidelines relative to SOA Service Boundary Analysis.
SOA Service Identification and Discovery Use this technique to understand the standards and guidelines relative to SOA service discovery.
Back to Top
The Architecture Principles, Guidelines and Standards is used in the following ways:
to help develop the Future State Enterprise Architecture (EA.110)
as a basis for the Governance (GV) process
Back to Top
QUALITY CRITERIA
Do all stakeholders understand what is meant by principle?
Do the principles point toward a future goal?
Are there no more than 5-20 top-level principles?
Can every (business) domain have a short list of main principles again, for example
When using a framework (such as TOGAF), domains are also defined by the framework.
All architecture principles will add up to hundreds of principles.
All architecture principles will be aligned with the enterprise taxonomy.
Back to Top
EA.030 - IDENTIFY CURRENT ENTERPRISE ARCHITECTURE
During this task, you define the key architectural components that would assist in the definition of the current state Enterprise Architecture for the purpose of identifying
misaligned areas and areas that require change. The current state business situation is documented in the Enterprise Process Model (BA.040).
The current state Enterprise Architecture is comprised of the following:
Business Architecture
Application Architecture
Information Architecture
Technology Architecture
The current state Enterprise Architecture may be documented at various levels depending on the scope of the engagement, such as:
technology capabilities (e.g., Master Data Management, Portal, Identity Management, etc.)
business capabilities (e.g., Order Management, Performance Management, etc.)
vendor product capability (Oracle Fusion Middleware, Oracle E-Business Suite, SAP BW, etc.)
hardware/network Configurations
etc.
The information can be either overlaid onto an existing current state reference architecture diagram (if available) or onto an Industry Reference Architecture (see EA.002).
It is important, to employ Just enough and 'Just in time' principles to ensure the Current Enterprise Architecture discovery is only conducted to the level that is relevant to
the scope of the engagement.
ACTIVITY
Back to Top
WORK PRODUCT
Current Enterprise Architecture - The Current Enterprise Architecture documents the current Enterprise Architecture that is relevant for the engagement. It documents
the capabilities and functionality and the related supporting structures and technologies. It details who is responsible and dependent. The lifecycle of relevant assets is
documented as part of the Governance process (GV.092, GV.094, GV.096, GV.098).
Back to Top
TASK STEPS
You should follow these steps as they relate to the engagement:
1 Identify capabilities and functions at
a high level.
High-Level
Capability and
Functions
Inventory
The High-Level Capability and Functions Inventory describes the capabilities and functions supported by
the Current Enterprise Architecture.
2 Identify current frameworks,
reference architectures and other
reused architecture components.
Architecture
Frameworks
and Reference
Architectures
The Architecture Frameworks and Reference Architectures lists all currently used frameworks, reference
architectures and other reused architecture components, their purpose and where they have been used,
and to which high-level capabilities they relate. It also documents the vendors if no in-house built.
3 Identify current systems and
services.
Current
Systems and
Services
Inventory
The Current System and Services Inventory lists all the current systems and services available in the
enterprise, and for which capabilities and functions they support. For each system describe the status and
purpose, and how it is used by the system. You should be able to list the technical attributes of all of the
Applications in the current IT Portfolio (IP.012).
4 Identify current deployment and
supporting infrastructure.
Deployment
Infrastructure
Supporting
Infrastructure
The Deployment Infrastructure lists for all current systems the infrastructure on which they are deployed,
including the configurations.
The Supporting Infrastructure lists all the supporting infrastructure used for one or multiple applications,
their purpose and usage.
5 Identify current technologies used
for development, testing,
deployment and O&M.
Current
Technologies
Inventory
The Current Technologies Inventory lists all the technologies that are used for development, testing,
deployment, and operations and management (O&M), including status, purpose, vendors and where they
have been used.
6 Identify owners. Architectural
Owners
The Architectural Owners documents which individual or group own the different architectural elements,
such as capabilities, functions, systems, services infrastructure, etc.
7 Identify user communities. User
Communities
Inventory
The User Communities Inventory includes a list of all the user communities relevant for the enterprise,
including a description and their key interests.
8 Identify service providers. Service
Providers
Inventory
The Service Providers Inventory includes a list of service providers, their name and a description of what
kind of services they provide.
9 Identify any dependencies or
interfaces between the different
software components and the
hardware on which it is installed.
Current System
Inventory -
Interfaces and
Dependencies
The Current System Inventory is updated with the appropriate Interfaces and Dependencies information that
lists all dependencies and interfaces between the software components listed in step 1, as well as the
hardware on which the components are deployed.
10 Identify overlap and redundancy. Overlaps and
Redundancies
The Overlaps and Redundancies shows overlap or redundancy between systems and services. It
documents what kind of overlap/redundancy it is (e.g., data or functionality).
11 Verify the findings. None
Back to Top
APPROACH
There may be a single enterprise architect, or many people that collaborate in some form or another to provide you with the necessary information for this task. The
objective is to collect information from this person or persons in order to gain a good understanding of the current state architecture. Information can be collected in
different ways, such as:
Questionnaire Provide a questionnaire to be filled out that asks for all relevant information. This method allows for the collection of information from multiple
people without being constrained to individuals schedules.
Interviews or Workshops Conduct one-on-one interviews or execute workshops with all contributors of information at once, to collect the information first hand.
Documentation Some organizations may have a well-documented enterprise architecture. In this case they will likely prefer to have you read their documentation
before scheduling time for other activities.
The method used to collect information from an enterprise will vary depending on the state of existing documentation and availability of participants. You may find that a
combination of methods may be necessary, such as reading documentation and following up with interviews or workshops to fill in the gaps and get questions answered.
The intent is to gain an understanding of the key architectural elements that will influence the future vision. This may be individual applications and infrastructure
components, or it can be a list of approved products and technologies to which current projects are constrained.
Identify Capabilities and Functions at a High-Level
For the enterprise, and within the scope of the current engagement (Just Enough and Just in time), identify and document the high-level capabilities and functions. The
enterprise functions should have already have been identified as part of the Enterprise Function or Process Model (BA.040).
For each high-level capability, where applicable, include the investigation of any strategies or applicable regulatory requirements that support a capability. For example,
for the capabilities mentioned above, you may include the investigation of any redundant site and disaster recovery strategy.
Identify Current Frameworks, Reference Architectures and Other Reused Architecture
Components
For each architectural domain (business, application, information, technology), identify any frameworks or reference architectures used in the enterprise, their purpose
and where they have been used. Identify any other type of reused architecture components. Also identify architectural components such as domain architectures, or
technical sub-architectures, such as for example security, data, integration, and presentation architectures. Also document the delivery channel architecture(s). Identify
the vendors for each component (if not in-house built).
Identify Current Systems and Services
For each capability and function, perform an inventory on all distinct software that the enterprise possess and uses to support the capabilities and functions. This could be
anything from larger systems, to smaller services or distinct software components. Specify the status of the software (under development, test, production, retirement,
etc), what is the purpose of the software, and how it is used. Also document whether it is enterprise-managed or outsourced. Review the IT Project Portfolio (IP.010) as it
contains the list of current projects that will result in new software. Specify what kinds of users use the software. How it is used may be different for different user
groups/actor. You should also review the (SOA) Service Portfolio (IP.014).
Document Current Deployment and Supporting Infrastructure
For the whole enterprise (all applications), identify the networks, deployment configurations, etc. Identify any supporting infrastructure used for one or multiple
applications. Define their purpose and usage.
Also, identify all the products and technologies that are used in production, where and with what purpose they are used.
Also review the IT Project Portfolio (IP.010) as it contains the list of current projects that may result in new infrastructure.
Identify Owners
For each architectural element, identify the owner, that is identify who owns or is responsible for a given capability or function, who is the owner for each system or service
and who is the owner of the infrastructure, etc.
Identify User Communities
Identify the User Communities that are relevant for the enterprise and depend on the identified capabilities and functions. Provide a short description of each user
community, and clarify their key interests. If time allows, also determine what kind of systems or services are of interest to each user community.
Identify Service Providers
Identify the service providers that are of relevance to the enterprise and what kind of services they deliver that are of interest to the enterprise.
Identify Current Technologies used for Development, Testing, Deployment and O&M
Document the technologies that are used for development, testing, deployment, and operations and management (O&M). This may come from the enterprise architecture
team, or from other members of the IT organization.
Identify Dependencies or Interfaces between the Software and Hardware
Document the dependencies and interfaces between the software components, and in what context this dependency/interface is used. Also, document the hardware on
which the components are deployed. If it is deployed on multiple hardware components, indicate the usage for each installment.
Identify Overlap and Redundancy
You may choose to also identify any overlap and redundancy between the current systems and projects. This could be important information as an input to determine
improvement options. Be aware though that this could be a fairly time-consuming task, so therefore be certain about whether this is within scope of the engagement.
Verify Findings
Verify the findings with the client.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect This task requires several iterations in order to compile the required information. Initially, establish a very high-level
overview. In subsequent iterations, work with the solution architect (domain-specific technical architects) to document the
specific details and provide vendor strategy and roadmap information.
100 (first
iteration)
20-50
(subsequent
iterations)
Solution Architect
(Technical Architect)
Work with the enterprise architect and client enterprise architect to document the specific details and provide vendor strategy
and roadmap information.
0 (first
iteration)
50-80
(subsequent
iterations)
Client Enterprise Architect Work with the enterprise architect and solution architect to document the specific details and provide vendor strategy and
roadmap information.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Function or Process Model (BA.040) Use the Enterprise Function or Process Model to get descriptions of the functions supported by the
enterprise.
Architecture Principles, Guidelines and Standards
(EA.010)

IT Project Portfolio (IP.010) Use the IT Project Portfolio to get information on all current projects within the enterprise.
Back to Top
TEMPLATES AND TOOLS
EA-030_CURRENT_ENTERPRISE_ARCHITECTURE.DOC MS WORD
Tool Comments
Overview
task.
Back to Top
The Current Enterprise Architecture is used in the following ways:
to provide an initial baseline to compare against a desired future state
to describe the high-level capabilities and functions that are available in the current environment, and that are relevant for the scope of the current engagement
to describe which systems and services support the capabilities and functions
to assist with identifying gaps or constraints in the capabilities and functions
to assist with identifying overlap, dependencies and redundancy between the current systems and projects
to assist with identifying dysfunction and unnecessary complexity
to facilitate the appropriate updating of infrastructure documentation
Distribute the Current Enterprise Architecture as follows:
to enterprise IT staff
to the Envision project team
Back to Top
QUALITY CRITERIA
Have you identified all high-level capabilities and functions relevant to the scope of the engagement?
Are the architectural elements documented to a level relevant to the scope of the engagement?
Have any frameworks or reference architectures already in use in the enterprise been identified?
Have all the current systems, integration points and infrastructure been identified?
Back to Top
EA.040 - ANALYZE CAPABILITIES
During this task, you review existing documents and discuss these with the enterprise to obtain a view of their business or architectural capabilities. Start with the
business capabilities and for each business capability relevant for the engagement build a Capability Model showing the essential elements of the capability and the
relationships to the factors that make the capability actionable through people, processes and systems.
ACTIVITY
Back to Top
WORK PRODUCT
Capability Model - The Capability Model depicts which capabilities the organization requires to execute its strategy and how they are prioritized, as well as provides an
analysis of the aspects of each capability that is relevant for the engagement.
Back to Top
TASK STEPS
1 Create Top-Level Business
Capability Map.
Top-Level
Business
Capability Map
The Top-Level Business Capability Map provides a common view of what the organization requires to execute
its strategy. Capabilities are a combination of people, processes, and technology that serve a common
purpose.
2 Select top-level capabilities
relevant for the scope of the
engagement.
Prioritized Top-
Level
Capabilities
The Prioritized Top Level Capabilities contain a sub-view of the Top-Level Business Capability Map showing
those capabilities that should be analyzed further. Also, each capability has now been prioritized.
3 Determine Capability Model
Components.
Capability Model
Components
The Capability Model Components describe all aspects that should be analyzed for each capability. Which
aspects are relevant is dependent on the engagement at hand.
4 Create Capability Model for each
top-level capability.
Capability Model The Capability Model shows the analysis of each business capability for each component defined in the
Capability Model Components. There will be one Capability Model for each business capability within the
scope.
Back to Top
APPROACH
It is recommended that you create multiple views of the Capability Model to reflect the various qualitative perspectives you are investigating.
Depending upon the scope of the engagement (segment, domain, or time), the Capability Model should be developed to capture the essential details that define the
capabilities defined in the capability map. For example, if the scope is constrained by segment, define only the Capability Models appropriate for the section. When time
is limited, focus first on those capabilities that are changing.
The capability map provides relational details between organizations, roles, technology, processes, metrics, objectives, etc. Additional qualitative information can be
added to help begin the development of business services.
Create Top-Level Business Capability Map
The capability map provides a common view of what the organization requires in order to execute its strategy. Capabilities are a combination of people, processes, and
technology that serve a common purpose. Capabilities typically consist of subordinate capabilities. Consider the following example:
Select Top-Level Capabilities
Determine which top-level business capabilities you should focus on further as part of the scope of the engagement at hand. Be certain that there is an agreement on this
before continuing with the next step. If time is limited, select only those capabilities that are changing. Prioritize the capabilities within scope so that you continue with the
most critical ones first.
Determine Capability Model Components
When you analyze each business capability, the goal is to get a deeper understanding of the relationships between the given capability, the organization, and the
technology that should support the capability. Therefore, define the required elements of the Capability Model that will provide you with this view. It may vary based on
the type of engagement.
A Capability Model should define the essential components of the operations of the business for a business capability. The components describe the essential elements
of the capability and the relationships to the factors to make the capability actionable through people, processes and systems. The following is a list of typical
components:
People
Processes
Technology Enabler
Information
Service Levels
Security
Functions
Business Goals and Critical Success Factors
Metrics
Current Issues
Continuity of Operations
Performance
Create the Capability Model
Create a Capability Model for each of the business capabilities that you have identified to be within the scope of the engagement. Start with the highest prioritized
capability. Below is an example Capability Model for for one of the capabilities shown in the Capability Map example above, specifically, the Product R&D Business, using
the components listed above:
Missing capabilities or duplicate capabilities may lead to either a lack of ability to meet an objective, or inefficient operations.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Work with the enterprise to identify the business capabilities, components and Capability Model. 100%
Client Enterprise Architect Work with the enterprise architect to identify the business capabilities, components and Capability Model. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Organization Structures (BA.020) Use the Enterprise Organization Structures to identify level 0 business capabilities.
Enterprise Function or Process Model (BA.040) Use the Enterprise Function or Process Model to identify business capabilities.
Current Enterprise Architecture (EA.030) Use the Current Enterprise Architecture to review already identified high-level architectural capabilities.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
EA.050 - IDENTIFY CURRENT ARCHITECTURAL CHALLENGES
The purpose of this task is to identify constraints and gaps in the current architecture in order to meet the defined future state objectives and requirements. The task also
provides a list of current architectural pains tat need to be addressed in the design of the future state architecture.
During this task, you review the current situation, and identify the current deficiencies or working constraints related to that situation. In most situations, this view is on the
enterprise level, but the scope engagement might also be limited to a part of the enterprise. Ensure that your effort is in line with the given scope. Also, the scope may be
enterprise wide, but limited to a specific aspect of the architecture. For example, it may be limited to map the architectural aspects related to data structures, or only to
cover security aspects of the architecture. Alternatively, you may use this task to define certain technology constraints that may have a material impact on developing the
optimal to-be architecture (e.g., technology standards, such as OS or DB Platform, etc.).
ACTIVITY
Back to Top
WORK PRODUCT
Current Architectural Challenges - The Current Architectural Challenges contains a list of architectural problem areas with which the client is faced including the impact
of each challenge on the organization or the application(s)/services used in the enterprise.
Back to Top
TASK STEPS
1 Review IT Project Portfolio (IP.010) and
the Current Enterprise Architecture
(EA.030).
None
2 Initially, identify possible challenges. Architectural
Challenges
(initial)
The Architectural Challenges component is a list of architectural problem areas that the client is faced with.
In this step an initial list is produced.
3 Prepare client meeting or workshop. None
4 Walk through current architectural
situation, and identify challenge areas.
None /td>
5 Conclude workshop and isolate
challenges.
Architectural
Challenges
The Architectural Challenges component is a list of architectural problem areas that the client is faced with.
In this step the initial list from step 2 is expanded to include the impact of each challenge on personnel or
application(s).
Back to Top
APPROACH
This task is best accomplished during a well-prepared meeting or workshop with the client.
Review Previously Gathered Materials
Review the IT Project Portfolio (IP.010) and the Current Enterprise Architecture (EA.030) to understand the current situation on which you should identify possible
architectural challenges.
Initially Identify Possible Challenges
Some challenges will already be known prior to this task. Include these in the list of challenges, and try to identify any other possible challenges. View the current
situation (portfolio and architecture components), the domain and process models, and the technical enterprise requirements.
Prepare Client Meeting or Workshop
Set up a meeting or workshop with the relevant participants from the client to go further into detail in areas where more information is required or information is
completely missing. Prepare a question list to go through during the meeting/workshop that will help identifying the challenging areas. The purpose of the
meeting/workshop is to identify the primary pains that are or may be a result of the current architecture, or that may be improved upon making architectural changes.
Walk Through Current Architectural Situation, and Identify Challenge Areas
During the client meeting or workshop, walk the client through your findings until now, and ask for feedback. Go through the additional questions you have prepared to
complete the picture, and to identify/verify possible architectural pains. Keep in mind that you are only gathering information at this stage. Do not be tempted to suggest
solutions at this point of time, as you might not yet have a good enough picture to make the best recommendations.
Conclude Workshop/Meeting
Walk through the result of the meeting to conclude on the relevant architectural challenges.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Identify current architectural challenges. There may be a need to engage solution architects (domain-specific technical
architects) with specific knowledge in a given domain, e.g., SOA, etc.
100
Client Enterprise Architect Assist in identifying current architectural challenges. *
Back to Top
PREREQUISITES
Prerequisite Usage
IT Project Portfolio (IP.010)
Review these work products to understand the current situation in which you will identify architectural challenges.
Use these models to identify possible challenges.
Supplemental Enterprise Requirements (ER.100) Review these requirements to help identify possible challenges.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
The Current Architectural Challenges is used during the workshop with the client in addition to being a concluding work product for the workshop. It is a prerequisite into
the design of the future state architecture.
Back to Top
QUALITY CRITERIA
Have all views of the enterprise architecture been considered?
Back to Top
EA.057 - REVIEW BUSINESS CAPACITY PLAN
This task supports the estimating and cost validation activity by providing a gross estimate of capacity requirements based on the volumetrics identified to-date within the
Business Volumetrics Report (BA.067). It is developed for each functional area as well as addresses the requirements arising from system operations, such as integration
and system management.
ACTIVITY
Back to Top
WORK PRODUCT
Business Capacity Plan - The Business Capacity Plan documents the projections of business capacity requirements for servers, disk, processing, memory and network
requirements and the corresponding detail worksheets that include the document the details, formulae, and assumptions on which the estimates were based.
Back to Top
TASK STEPS
1 Determine minimum client requirements. Minimum Client Requirements
2 Determine sizing requirements per functional area. Sizing Requirements
Back to Top
APPROACH
Determine Minimum Client Requirements
The minimum requirements for the client requirements need to be specified.
Determine Sizing Requirements by Functional Area
The minimum requirements are:
Basis of Sizing: How each sizing was derived.
Level of Confidence: Confidence rating based on a scale of: Very High, High, Medium, Low, Very Low.
Sizing Assumptions: Any assumptions made during the sizing.
Capacity Estimate: The sizing estimate, which also indicates whether each component can be deployed as N+1 for availability.
Typically, the basis of the sizing is the information contained in the Business Volumetrics.
The sizings for the individual functional areas are needed because higher level decisions on any phasing may require the sizing to be revisited phase by phase. This can
be supported by keeping the sizings of the functional areas distinct and then having a summarization.
A typical way of expressing the technical capacity requirements is in a table. An example is:
Area
Windows
Version
Browser CPU Type Memory Disk
Notes
<usage 1>
XP, 2000 IE 5.5 1 GHz 256 MB

<usage 2 >
XP, 2000 IE 5.5 1 GHz 256 MB

A capacity estimate may be expressed in a table with additional notes. In the following N+1 indicates whether or not it is possible to deployed as multiple instances to
achieve high availability.
Area
Component N+1 Operating
System
CPUs CPU Type Memory Usable Disk
Notes
Systems
Mgmt
OMS Application
Servers
Possible Windows /
Linux
2 Intel Xeon 3.0 GHz or
higher
2 GB 10 GB (OMS) Binaries, 10GB
OMS Receive Directory
Needs Shared File
System
Systems
Mgmt
OMR Database
Server
Possible Windows /
Linux
2 Intel Xeon 3.0 GHz or
higher
4 GB 10 GB (DB) Binaries, 50GB
Database
RAC Cluster
The level of confidence is needed to identify which elements of the overall sizing are solid.
This task is similar to the OUM Implement task, Define System Capacity Plan (TA.160) but is performed during an Envision engagement in order to produce hardware
costs as part of an overall costing and planning exercise.
engagements.
Back to Top
Enterprise Architect Provide input to the solution architect. 20
Solution Architect
Translate business metrics into technical metrics for sizing. Preferably, this should be done by an solution architect that
specializes in Technical Architecture.
80
Client Solution Architect
Provide input to the solution architect. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Volumetrics Report (BA.067) The volumetrics included in this report are the basis for this task.
Supplemental Enterprise Requirements
(ER.100)
The Supplemental Enterprise Requirements impose constraints on the form of the architecture and on additional storage
required for auditing.
Technology Architecture (EA.130) The Technology Architecture defines the technology components and their disposition.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Is the Business Capacity Plan complete?
Is the Business Capacity Plan consistent, especially with reference to the Supplemental Enterprise Requirements?
Back to Top
EA.060 - IDENTIFY ARCHITECTURAL GAPS AND
IMPROVEMENT OPTIONS
During this task, you investigate further the current-state architecture and the ways in which it constrains the business. Review the Current Architectural Challenges
(EA.050) and determine possible options for improvement. In most situations this view will be at an enterprise level, but the scope engagement might also have been
limited to a part of the enterprise. Ensure that your effort is in line with the given scope. Also, the scope may be enterprise wide, but limited to a specific aspect of the
architecture. For example, it may be limited to map the architectural aspects related to data structures, or only to cover security aspects of the architecture.
The type of improvements options depends on the client situations, and how large the pain, but you will often see options like providing consistency across systems,
ensuring compatibility between systems, use of reference architectures, defining a common set of standards, guidelines, approaches and techniques. But you should not
be limited to overall aspects. It could also be that some of the pains are very specific, and related to a single or a few applications but that may result in a suggested
overall improvement option. Focus on identifying the improvement options. After they have been identified, prioritize them in the MoSCoW Improvement List (ER.130).
ACTIVITY
Back to Top
WORK PRODUCT
Architectural Gaps and Improvement Options - The Architectural Gaps and Improvement Options is a list of possible improvements that can be made to improve the
situation where there are problems related to the architecture in the organization, where it can be made more efficient, or less expensive.
Back to Top
TASK STEPS
1 Review the
existing
architecture.
None
2 Review the
Current
Architectural
Challenges
(EA.050).
None
3 Identify pros
and cons for
the options.
None
4 Determine
preferred
improvement
options.
Architectural
Improvement
Options
This component is a list of all identified improvements that can be done to make improvements to the enterprise architectures. The
list contains a description of the improvement, what applications, systems, or architectures it impacts, a reasoning why this should
be an improvement, and a reference to relevant parts of the business strategy. During this step, the list is made final. The other
steps also provide input to the work product.
Back to Top
APPROACH
During this task, you may also consider doing some prototyping in order to determine whether an option is feasible, or to see whether it covers the requirements it should
solve. Prototyping may also be done at a later point of time.
Note: You should involve resources from the client in this task.
Review the Existing Architecture
Review the Current Architectural Challenges (EA.050) related to the clients current infrastructure. Define any possible missing pieces relevant to defined the current
architecture. Careful consideration of the existing architecture enhances the understanding of the current situation, and therefore should improve the quality of a
suggested improvement option.
Review Current Architectural Challenges
Review the Current Architectural Challenges (EA.050) and determine improvement options for the existing architecture. When considering the existing infrastructure, and
the related architectural pains, identify possible options that will improve the situations. For some areas, you may not identify multiple solution options. This may for
example be because there is one very obvious option, or because the client already has used similar options other places. Do not spend unnecessary effort trying to find
alternative solution options when there is one obvious one.
Identify Pros and Cons
Determine the pros and cons for the alternative options you have identified. This should not be a complete benefit and risk analysis, but should preferably provide
sufficient information to be able to choose a preferred alternative.
Determine Preferred Improvement Options
For each problem area, determine a preferred improvement option dependent on the pros and cons in the previous step. If you are uncertain about what option would be
best, do not identify a single preferred option, but present the different alternatives as options, with their pros and cons. It may be that the client immediately has a
preferred one.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Along with the client enterprise architect, Identify architectural gaps and improvement options. There may be a need to engage
solution architects (domain-specific technical architects) with specific knowledge in a given domain, e.g., SOA, etc.
100
Client Enterprise Architect Assist in identifying current architectural gaps and improvement options. *
Back to Top
PREREQUISITES
Prerequisite Usage
Current Architecture (EA.030) Investigate the current-state architecture to identify improvement options.
Current Architectural Challenges (EA.050) Use the Current Architectural Challenges to identify possible improvement options.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
The Architectural Gaps and Improvement Options is used in the following ways:
to identify possible improvement options based on the current architectural challenges
to serve as input to the business case
Note: There might be some iterations between business case and improvement options discussion as customers may want to understand the business case impact of
different improvement options.
Back to Top
QUALITY CRITERIA
Have domain architects been consulted to discuss and elaborate on different improvement options?
Is a description of the improvement, what applications, systems or architectures it impacts, a reasoning why this should be an improvement and a reference to
relevant parts of the business strategy included?
Does the work product include how the improvement options align to the Business Strategy?
Back to Top
EA.065 - IDENTIFY ENTERPRISE IT STRATEGY
During this task, you identify the current Enterprise IT Strategy and validate it against the Business Strategy relevant for your engagement. Developing a new Enterprise
IT Strategy is a time consuming task, and therefore, this activity must be carefully scoped to best support the engagement at hand.
An Envision effort is often undertaken because of a change in strategy. As a result, it often has an impact on the Enterprise IT Strategy. This task often goes hand in
hand with a number of other tasks that either provide input to the strategy, or are done as a is a result of the strategy. Those tasks are:
evaluating the current situation against the business principles, strategy and capabilities (EA.010, EA.030, EA.050), and as part of this determine the IT principles
identifying gaps between the current situation and a desired future state (EA.060)
defining a future state architecture (EA.110)
identifying and defining KPIs to measure the progress and success of the Enterprise IT Strategy elements (BA.017)
identifying organizational changes required to best support the changes in strategy (BA.020/GV.040)
identifying required governance to best enforce the strategy (multiple GV tasks)
The future state architecture may sometimes be created ahead of the actual Enterprise IT strategy, while in other cases it is the opposite way around. Either way, it is
important that they are aligned, so one should follow the other.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise IT Strategy - The Enterprise IT Strategy in full is a detailed document that covers all the aspects required to fully support the Business Strategy. If the scope
of the engagement is to cover a specific subset of the Business Strategy, the document may be limited to the identification of IT strategy changes supporting just the
change in Business Strategy.
Back to Top
TASK STEPS
1 Review the Business Strategy and identify
the business capabilities that impact the
current IT landscape.
Business Strategy
and Capabilities
The Business Strategy and Capabilities summarizes the Business Strategy and capabilities
impacting IT.
2 Review the current Enterprise IT Strategy
and identify required changes.
IT Strategy
Highlights
The IT Strategy Highlights describe what kind of IT changes are required to support the
Business Strategy and Capabilities.
3 Identify gaps between current IT
capabilities and those required by the
Business Strategy
Gaps The Gaps describes the gaps between what IT capabilities are required to support the Business
Strategy and the current situation.
4 Analyze gaps and determine direction on
shorter and longer terms.
IT Domains
Strategies
The IT Domains Strategies details, per IT domain, the direction that should be taken to fill the
gaps on shorter and longer terms.
5 Determine KPIs. Key Performance
Indicators
The Key Performance Indicators document what kind of measures should be used to provide
visibility in the effectiveness of the Enterprise IT strategy.
6 Determine Technology, Operations and
Infrastructure Strategy.
Technology,
Operations and
Infrastructure
Strategy
The Technology, Operations and Infrastructure Strategy document the chosen technology
supporting the Enterprise IT Strategy, the operational principles and strategy, and the
infrastructure required to support the strategies.
7 Determine IT Organizational Impact. IT Organizational
Impact
The IT Organizational Impact documents required changes to the IT organization in order to
support the Enterprise IT Strategy. It also documents any requirements for required new hires
or required training of existing resources.
8 Determine IT Governance Impact. IT Governance
Impact
The IT Governance Impact documents what kind of governance activities are required to
support the IT Strategy.
Back to Top
#TOP #TOP
APPROACH
This task is executed iteratively in close collaboration with enterprise executives.
A detailed Enterprise IT Strategy document includes sections describing the following:
the parts of the Business Strategy that impact IT
the business capabilities required by the Business Strategy
which IT capabilities are required to best support the business capabilities, including a justification in business terms
the gaps between the current IT capabilities and what is required
a grouping of IT capabilities that should be supported by the IT strategy
the IT steps that should be undertaken on shorter and longer term for each group of IT domain
the impact on technology, operations and infrastructure
the organizational impact and required governance structures
the KPIs measuring the progress and effect of the IT strategy
Review the Business Strategy, and Identify Business Capabilities that Impact Current
IT Landscape
Review the Business Strategy relevant for the Envision effort to identify areas in the strategy that will have an impact on IT. Summarize the key Business Strategy
elements in business language as an introduction to explaining the impact. Use terminology used in the Business Strategy. Use the Analyzed Capabilities (EA.040) to
identify which business capabilities must be supported by IT capabilities.
Review the Current Enterprise IT Strategy, and Identify Required Changes
In most cases, an Enterprise IT Strategy already exists and is more or less up-to-date. Review the current Enterprise IT Strategy, and identify which areas of the must
change as a result of the Business Strategy and business capabilities to be supported by IT. Document for each Business Strategy domain within the scope of the
Envision effort, which IT capabilities are required. Document this as much as possible in business terms, and provide a reason and traceability between Business
Strategy/capabilities and IT capabilities. By providing this traceability, you provide a high-level mechanism in support of IT expenditures.
Identify Gaps
Identify gaps between the current IT situation, and what IT capabilities are required to support the Business Strategy. Use the Architectural Gaps and Improvement
Options (EA.060) as an input, if available. Document the gaps as much as possible using business terminology.
Analyze Gaps and Determine Direction
In many cases, a direction has been determined at a high level already, and a target architecture may already exist (see the architecture tasks: EA.110, EA.120, EA.130,
EA.140). Either way, you need to analyze the identified gaps and verify them against either a current architecture, or a target architecture.
Group the identified gaps into logical IT areas or domains, and analyze what kinds of changes are required to fill the gaps for a longer term (3 to 5 years horizon). Some
gaps are more critical and need more tactical solutions, which needs to be taken into consideration as well. Prioritize the gaps to identify which gaps are critical in the
short term, and which can be filled in the longer term.
With this as a starting point, review the future state architecture (if it exists), and determine whether you need to do any changes, either in the actual target architecture,
or in the roadmap to get there due to changed or new priorities. Required changes should be documented, and provide input to the execution of the applicable EA tasks
determining an updated future state (EA.110, EA.120, EA.130, EA.140).
For each IT area or domain, document in business terms what the domain covers, what business objectives and business capabilities it supports, and what IT objectives
and capabilities are required for each domain. Document the direction for each domain.
Determine KPIs
Execute the task, Determine Metrics Collection and Reporting Strategy (BA.017) relative to the Enterprise IT Strategy at hand. Document the KPIs you identified as part
of the Enterprise IT strategy.
Determine Technology, Operations and Infrastructure Strategy
Identify any required changes to the technology used to support the IT direction. Document which technology should be used for what purpose. Consider all layers, from
enterprise modeling, through test, deployment and maintenance.
Identify and document operational principles and strategy supporting the IT direction and technology strategy. Document the Infrastructure principles and strategy
supporting the IT direction.
Determine IT Organizational Impact
Identify what kind of skills are required to support the Enterprise IT Strategy, and whether any changes to the IT organizational structures will better support the strategy
compared to the current situation. Document the required changes, and what new skills needs to be acquired, whether new hires are required, training or a combination
of the two is needed.
Determine IT Governance Impact
Determine what kind of governance activities needs to be done and implemented to enforce the strategy. The execution of these activities will be done using the
applicable GV tasks.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Work with the enterprise to iteratively develop the Enterprise IT Strategy components. 100%
Client Enterprise Architect Work with the enterprise architect to develop the Enterprise IT Strategy compoents. *
Client Executive(s) Communicate and ensure alignment and acceptance with the enterprise. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to determine the impact on the Enterprise Strategy to best support the strategy.
Architecture Principles, Guidelines and Standards
(EA.010)
Use this work product to understand the IT principles that should be supported by the Enterprise IT Strategy.
Current Enterprise Architecture (EA.030) Use the Current Enterprise Architecture to evaluate the current situation against the capabilities required by the
Business Strategy.
Analyzed Capabilities (EA.040) Use the Analyzed Capabilities to define or analyze the Enterprise IT Strategy.
Current Architectural Challenges (EA.050) Use the Current Architectural Challenges to identify how the Enterprise IT Strategy should best support the
Business Strategy.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Enterprise IT Strategy is used in the following ways:
to show the direction of the IT and how it impacts architecture, organization and governance.
Distribute the Enterprise IT Strategy as follows:
to enterprise executives
Back to Top
QUALITY CRITERIA
Do the Enterprise IT Strategy components show a clear trace to the Business Strategy, objectives or business capabilities?
Does the Enterprise IT Strategy support the defined IT principles?
Does the Enterprise IT Strategy explain gaps between current and desired situation, and how the gaps should be handled?
Does the Enterprise IT Strategy include organizational impact, including potential change in organization structures and skills?
Does the Enterprise IT Strategy include governance impact?
Does the Enterprise IT Strategy include which KPIs are relevant to measure the effectiveness of the strategy elements?
Does the Enterprise IT Strategy include a time horizon for when the strategy elements should be enforced?
Back to Top
EA.075 - DEVELOP TECHNOLOGY REFERENCE
ARCHITECTURES
The emergence of industry-specific or technology-specific reference models is increasing. During this task, you use one or more external reference architectures (EA.002)
as a basis to determine the organization's own enterprise-level Technology Reference Architecture(s).
Some of the topics of the reference architectures will relate to the Architecture Principles, Guidelines and Standards (EA.010), and may need to be recorded in the
Enterprise Repository as enterprise-wide rules.
You develop the future view and determine the transitions from the current situation as documented in the Current Enterprise Architecture (EA.030) to the chosen
external reference architectures.
When the future view has been completed and validated, and the high-level enterprise solution components have been identified, you determine the type of products and
technologies that are required to move forward.
Note: This task is central to the SOA Reference Architecture Planning view that provides guidance for defining a SOA reference architecture that is linked to the
customer's business objectives and includes a Roadmap for rollout. If you intend to define the SOA Reference Architecture for a customer, consider using that view for a
more complete picture.
ACTIVITY
Back to Top
WORK PRODUCT
Technology Reference Architectures - A Technology Reference Architecture describes the architectural choices the organization has made for a given domain or
technology. The aim is to ensure a commonality throughout all projects executed within the enterprise. A Technology Reference Architecture should cover guidelines for
all areas relevant to a specific technology. An organization may have multiple Technology Reference Architectures, for example, you might create just a SOA Reference
Architecture, or a master Technology Reference Architecture that covers multiple architectural areas for the organization.
Back to Top
TASK STEPS
1 Determine
Architectural Vision.
Architectural
Vision
The Architectural Vision documents the organization's architectural vision.
2 Review relevant
leading practices.
None
3 Determine the
Technological
Reference
Architecture per vision
subject.
Technological
Reference
Architecture
The Technological Reference Architecture covers the complete reference architecture as chosen for the organization on a
given subject. For example, if the vision includes SOA, there would be a SOA Reference Architecture. There may be a
master Technology Reference Architecture covering the whole architecture, or multiple Technology Reference
Architectures, each covering a part of the architecture, for example a SOA Reference Architecture. The component also
includes a reference to any external reference architecture as appropriate.
4 Determine required
changes.
Reference
Architecture
Changes
The Reference Architecture Changes covers all the deviations that you determined for the related external reference
architectures that you have chosen as a basis for your Technological Reference Architecture. The component also includes
a rationale for why you exclude or deviate from parts of that reference architecture.
5 Determine products
and technology to use
for implementing the
Technology
Reference
Architecture.
Architecture
Products and
Technology
The Architecture Products and Technology lists all the products and technologies that are chosen for the various parts of the
reference architecture.
6 Determine principles
and guidelines.
Architectural
Principles
and
The Architectural Principles and Guidelines includes all the architectural principles to which the organization should adhere,
as well as guidelines related to those principles. Guidelines may also be independent guidelines. The section should also
include a rationale for each principle or guideline. In addition, it includes if there are any standards (e.g., a specific industry
Guidelines standard) related to a given principle or guideline.
Back to Top
APPROACH
Determine Architectural Vision
You need to ensure that there is a common understanding of the Architectural Vision prior to defining the Technology Reference Architecture relevant for the organization.
Architecture Principles, Guidelines and Standards (EA.010)
Supplemental Enterprise Requirements (ER.100)
Current Architectural Challenges (EA.050)
External Reference Architectures Review (EA.002)
Review Relevant Leading Practices
When the Architectural Vision has been determined, review any leading practices available for the given vision. For example, if the vision includes SOA, review the
Service Architecture technique for guidance, and if the vision includes BPM, review guidance related to that subject.
In practice, an enterprise can be using more than one reference architecture at a time. For example, in the context of Business Process Management, a BPM Reference
Architecture can be created. This may be closely related to a SOA Reference Architecture, as well as a Security Reference Architecture. The related reference
architectures may exist and require an update, or may have to be created as well.
Determine Technological Reference Architecture per Vision Subject
Examples of things to consider include:
conceptual architectural components and layers
infrastructure
security
deployment
Determine Required Changes
The Reference Architecture Changes covers all the deviations that you determined for the related external reference architectures that you have chosen as a basis for
your Technological Reference Architecture. The component also includes a rationale for why you exclude or deviate from parts of that reference architecture.
Determine Products and Technology to Use for Implementing Technology Reference
Architecture
For each conceptual component or layer (when applicable) identified, determine the products and technology that best satisfy its requirements. To determine this, not only
the features of the products and technology should be taken into consideration, but also the skills and training required for using it properly. In some cases, it may be
necessary to determine an approach in which products and tools are applied incrementally over time.
Determine Architectural Principles and Guidelines
You may want to leave this section empty if this is the first iteration. Architectural Principles and Guidelines can be added as the enterprise gains experience implementing
the reference architecture.
There should be a clear relation between the architectural principles and the enterprise business objectives and architecture drivers.
The Architectural Principles and Guidelines should be formulated at a high level, describing the what and why, and not elaborating on the how.
An example of an architectural principle follows. The example is in the category technology, and the technology is BPM:
Principle 1: Traceability
Statement: Models should be linked to enable traceability from original business motivation to technical implementation of business process.
Motivation: When a close association to the core business models is maintained a number of potential benefits arise including: traceability of requirements, impact
analysis for changes, project justification, and Key Performance Indicators (KPIs) that can be derived to measure effectiveness in association with Business Activity
Monitoring (BAM).
Implications:
Business strategy models are needed to describe the overall enterprise goals and to provide traceability and justification to the BPM solutions.
If there are chosen standards relevant for an architectural principle or guideline, then it is recommended to include this in this section as well. An example would be the
standard that states that BPMN is to be used for modeling business processes.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Provide the business perspective for key aspects of the Technology Reference Architectures. 20
Solution Architect
Define the Technology Reference Architectures. There may be a need to engage solution architects (domain-specific technical
architects) with specific knowledge in a given domain, e.g., SOA, etc.
80
Client Enterprise Architect Assist the enterprise and solution architects. *
Back to Top
PREREQUISITES
Prerequisite Usage
IT Governance Policies Catalog
(GV.030)
Future State Enterprise
Architecture (EA.110) or
equivalent document, if available
If available, these documents may have already established how the strategy for the chosen technology supports the overall
Business and IT strategy. The Future State Enterprise Architecture is probably not available at the time this task is executed. See
if the enterprise has an equivalent type of document.
Supplemental Enterprise
Requirements (ER.100)
External Reference Architectures
Review (EA.002)
Architecture Principles,
(EA.010)
(EA.030)
Current Architectural Challenges
(EA.050)
Use these work products to develop the Technology Reference Architectures.
Back to Top
TECHNIQUES
Technique Comments
Service Architecture When developing a SOA Reference Architecture, use this technique to define the service definition and service layering.
SOA Service Lifecycle When developing a SOA Reference Architecture, use this technique to understand how to define the SOA service lifecycle.
SOA Release Planning When developing a SOA Reference Architecture, use this technique to understand how to define the deployment of services.
Back to Top
TEMPLATES AND TOOLS
EA-075_SOA_REFERENCE_ARCHITECTURE.DOC MS WORD - Use this template when developing a SOA Reference Architecture.
Tool Comments
Overview
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
EA.095 - REVIEW ENTERPRISE SOFTWARE DEVELOPMENT
PROCESS
During this task, you identify the software development process of the enterprise and review it for the purpose of either understanding it, or improving or extending it. The
scope of this task is typically broader than a single project, as it assumes a generic software development process that is used for multiple projects within the enterprise.
When the software development process should be enhanced or complemented, and therefore needs to be updated, this requires that a repeatable process and sound
engineering disciplines be applied through delivery cycles. This is especially true if external or offshore resources are to be utilized. Many enterprises struggle with
inconsistency across deliveries for projects that need to coexist.
ACTIVITY
Back to Top
WORK PRODUCT
Enterprise Software Development Process - The Enterprise Software Development Process documents the process for the enterprise, including points for
improvements or extensions.
Back to Top
TASK STEPS
1 Assess enterprise software
development process.
Assessment The Assessment documents the maturity of the enterprise's as-is software development situation.
2 Identify gaps or areas for
improvement.
Gaps and Improvement
Areas
The Gaps and Improvement Areas component contains a list of missing pieces and improvement areas in
the development process, as well as suggestions on how this can be improved.
3 Review and document
findings.
Enterprise Software
Development Process
The Enterprise Software Development Process contains a summary of the updated development process.
Back to Top
APPROACH
Assess Enterprise Software Development Process
This step is about gathering the as-is situation of the Enterprise Software Development Process. Try to get written information on the current development processes and
the guidelines and leading practices on software development. The as-is situation will be further analyzed in the next steps and will be validated against the special
requirements for the engagement.
Identify Gaps or Areas for Improvement
Review the various processes within the software development lifecycle, for example, the Requirements Management process, and the Testing process. Analyze how the
enterprise process is fit for business purpose, whether it supports the enterprise strategy for software development, and whether it fits what is expressed in the scope of
the engagement. Identify any missing parts, or areas that should be improved. Describe the purpose of any identified missing parts, or the reason why the process should
be improved. If the enterprise's approach can be improved, conduct a workshop with enterprise stakeholders to create a to-be picture of the process.
Review and Document Findings
Update the enterprise approach according to the findings of the workshop. Review the improved method with the enterprise. Check the changes agreed upon have been
documented and the enterprise has assigned responsibilities with respect to implementation of the changes.
Back to Top
#TOP #TOP
Back to Top
Enterprise Architect Perform the review with input from the solution architect and client SDLC staff. 50
Solution Architect Assist the enterprise architect with the review. There may be a need to engage solution architects (domain-specific technical
architects) with specific knowledge of best practices in a given domain, e.g., SOA, etc.
50
Client Software
Development Lifecycle
(SDLC) Staff
Ensure consistency and conformance of changes to the Software Development Process. *
Back to Top
PREREQUISITES
Prerequisite Usage
Technology Reference
Architectures (EA.075)
For SOA engagements, the Technology Reference Architecture for SOA is a useful input.
Services Meta Data
Description (GV.096)
For SOA engagements, the definition of a service lifecycle and how the versioning of services should be done as well as the definition of
asset types needed in the software development process for service engineering is useful input.
Back to Top
TECHNIQUES
Technique Comments
Management
Use this technique to define leading practices on requirements management.
SOA Service Boundary
Analysis
Use this technique to understand the leading practices around SOA service boundary analysis.
SOA Service
Identification and
Discovery
For SOA engagements, this technique defines leading practices on service identification and discovery.
SOA Release Planning For SOA engagements, this technique defines leading practices for SOA release planning.
Service Design For SOA engagements, this technique defines leading practices for service design.
Service Implementation Use this technique to review how services are implemented and how the enterprise ensures quality of delivery from implementation.
Service Testing Use this technique to review the concept of service-based testing.
Service Packaging and
Deployment
Use this technique to consider a service to be a smaller sized application that can be packaged and deployed as independent unit, which is
very important for decoupling the service lifecycle from the lifecycle of applications.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
EA.110 - DEVELOP FUTURE STATE ENTERPRISE
ARCHITECTURE
During this task, you define the "to-be" (future state) enterprise architecture. The problems and improvement options and their priorities are validated, and a final choice is
made as to which improvement options should be used.
ACTIVITY
Back to Top
WORK PRODUCT
Future State Enterprise Architecture - The Future State Enterprise Architecture shows the "to-be" enterprise architecture, including changes to existing architecture,
and at a high-level new identified reference architectures.
Back to Top
TASK STEPS
1 Review the existing
architecture and the
prioritized improvement
options to the current
architecture.
None
2 Determine changes to
existing architecture.
Existing
Architecture
Changes
The Existing Architecture Changes components documents what existing architectural elements are recommended for
change or to be replaced, including a reason and a reference to the architectural improvement options.
3 Determine high-level
reference architectures.
High-Level
Reference
Architectures
The High-Level Reference Architectures component contains a list of high-level reference architectures that are
recommended for use in multiple projects in the enterprise. Determine first the requirements for the reference
architectures. Indicate per reference architecture whether existing reference architectures are recommended (delivered
by one or multiple vendors), or whether it should be built upon the architecture already existent at the enterprise.
4 Verify suggested changes
with the client.
None
5 Optionally, prototype
architectural changes.
Architectural
Prototype
The Architectural Prototype is used to test parts of the architectural solution if needed to determine the feasibility of the
change.
Back to Top
APPROACH
This task may include prototyping of various improvement options. Prototyping may also be done in the task where the improvement options are determined (EA.060)
Review Existing Architecture and Improvement Recommendations
Review the existing architecture and the prioritized MoSCoW Improvement List to the current architecture.
Determine Changes to Existing Architecture
When considering the existing infrastructure, identify what should be retained, what you recommend to replace, and what and where the new components related to the
improvement options are recommended. For components that should remain, consider whether any changes or wrappers are recommended. Focus on the areas with the
highest architectural challenges (EA.050).
Determine High-Level Reference Architectures
You may decide to determine a high-level reference architectures that should be used for multiple projects in the enterprise. Determine first the requirements for the
reference architectures. When this is known, you may decide to use already existing reference architectures (delivered by one or multiple vendors), or you may decide to
further build your own reference architecture.
Verify Suggested Changes
Verify the suggested changes with the client. For some areas you may suggest to perform some prototyping to validate the suggestion. If so, agree with the client the
approach to take.
Prototype Architectural Changes
Optionally, prototype architectural changes. Prototype parts of the architectural solution if needed to determine the feasibility of the change.
There are many organizations, including Oracle, that have defined reference architectures. Refer to the Enterprise Architecture Resources below for additional resources
that may be useful in completing this task.
engagements.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Using input from client enterprise architect, collaboratively compile new architectural models that take into account the selected
improvement options and selected reference architectures.
100
Client Enterprise Architect Assist the enterprise architect in compiling new architectural models that take into account the selected improvement options
and selected reference architectures.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Architecture Principles,Guidelines
and Standards (EA.010)
The Architecture Principles, Guidelines and Standards describe all the high-level corporate principles, guidelines and standards
for architecture under which the enterprise operates.
(EA.030)
Improvement Options (EA.060)
Prior to beginning work on this task you should have a good understanding of the as-is technology structure and the Architectural
Gaps and Improvement Options, based on the business requirements and strategy.
Back to Top
TEMPLATES AND TOOLS
EA-110_FUTURE_STATE_ENTERPRISE_ARCHITECTURE.DOC MS WORD
Tool Comments
Overview
task.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
EA.120 - DEVELOP INFORMATION ARCHITECTURE
During this task, you identify the business objects in the overall enterprise. This is typically performed for a number of purposes:
to identify the source information for conversion for systems which are to be migrated
to identify information in systems to be retained as the basis for the development of the integration
to document the information contained in the system or systems that are proposed to be implemented and the business owners responsible for its maintenance
This task uses information at the level of domains and business objects to keep this at a high level. Taking this below this level should not be undertaken because it does
not support the development of the scope and costing needed in the development of an enterprise architecture and the identification of projects. Developing a Domain
Model as described in BA.050, Develop Enterprise Domain Model, prior to this task will facilitate the preparation of the information architecture model. You may also
determine that an Entity Relationship Diagram works well at the Enterprise level.
This task is executed in parallel with the following tasks:
Technology Architecture (EA.130)
Applications Architecture (EA.140)
ACTIVITY
Back to Top
WORK PRODUCT
Information Architecture - The Information Architecture identifies the business objects in the overall enterprise.
Back to Top
TASK STEPS
1 Identify information domains and the business objects for any existing systems. Business
Object list
List of Business Objects grouped into Information Domains
marked as current
2 Identify information domains and the business objects for the proposed systems
and any retained systems.
Business
Object list
List of Business Objects grouped into Information Domains
marked as future.
3 Map the business objects from current to proposed state. Business
Object list
Current state mapped to future state.
4 Identify master application for business object in the future state. Business
Object list
Identified future state application that is the master of the
individual business objects.
5 Document any particular measures needed for data security. Business
Object list
State data security principle/category, for example, regulatory
driven.
6 Identify External Sources of Data. Business
Object list
Name external source of a given Business Object is any, e.g.,
D&B for customer data.
Back to Top
APPROACH
Business Object Identification
Based on the definition of the legacy systems, both those to be replaced and those to be retained, document the business objects that they contain, along with the
volumes involved. For the systems that are being proposed identify the business objects that they contain. Map the business objects between the as is and to be
states. This may highlight gaps in the provision of data from existing systems.
Master Data Identification
For both the as is and to be states, identify for each business object, the master system(s). This may highlight anomalies such as multiple masters for particular
business objects which will need to be resolved. Such a situation occurs when the future state is made up of one or more software packages and retained systems. When
this occurs, it affects the application architecture whether through the need for interfacing between packaged applications or through configuration to prevent duplicate
data mastering. The occurrence of multiple master data in the current application architecture may also call for measures to merge and de-duplicate such information as
part of the data conversion process, with attendant decisions on the means of merging such data.
For each data master, identify the business owner.
Data Security
Some aspects of the data may require enhanced security. The client may have specific data security policies that need to be enforced, typically arising from regulatory
requirements. For example, the storage of some personal or financial information may need to be held in an encrypted form. Identify those business objects that will
require such measures.
External Sources of Data Identification
Some data may be provided from external sources, particularly as reference information. This may be industry-standard product numbers but also facilities such as
address or bank code checking systems where the data in the future state will need to conform to a standard. Identify the data management procedures that will need to
be put in place for the maintenance of such externally-sourced data.
Views of the Information Domains for Different Business Areas
Based on the functions carried out by the different business areas, describe the scope of the information domains that are accessible including those areas for which the
business area is master and where dependent on other business areas.
TOGAF
It should be noted that TOGAF has as part of this task, the development of a business data model (entities, attributes and relationships) as well as views into this for the
different stakeholders. This reflects the custom-development emphasis within that framework. For ERP implementations, the data models come with the product or
products and the development or duplication of the documentation of such products data models is wholly inappropriate. Regardless, the enterprise architecture has to
consider the state of data duplication in the to be state as this may call for the addressing the issues that may arise. This may lead to the need to enforce a single master
per business entity and allied considerations of master data management.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Identify business objects in the current and future state architecture. 40
Solution Architect
(Information Architect)
Develop the Information Architecture with input from the enterprise architect and client solution architect. Preferably, this should
be done by a solution architect with experience in Information Architecture.
60
Client Solution Architect Assist the solution architect with developing the Information Architecture.
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Glossary (BA.030) Use the Enterprise Glossary to review the terms in the Enterprise Architecture Taxonomy section.
Future State Enterprise Architecture
(EA.110)
Refer to the future state architecture to understand how the information model supports the applications in the Future
state.
Enterprise Domain Model (BA.050) The Information Model is used to describe the domains and classes in more detail for the future state.
Back to Top
TEMPLATES AND TOOLS
EA-
120_INFORMATION_ARCHITECTURE_DEFINITIONS.XLS
MS EXCEL - You may use this template in conjunction with the template for the Domain Model (BA.050) to
further describe the Information architecture.
The definitions of business objects, their location, etc. can make use of architecture repositories. Alternatively, simple spreadsheets can be used for document domains,
business objects, applications, business owners etc.
Tool Comments
Overview
task.
Back to Top
The Information Architecture is used in the following ways:
to identify the source information for conversion for applications which are to be migrated
to identify information in applications to be retained as the basis for the development of the integration
to document the information contained in the application or applications that are proposed to be implemented
to identify any externally-sourced data that may have implications on cost and in the development of the procedures to manage the maintenance of such
information
Distribute the Information Architecture as follows:
to the person responsible for describing the requirements for data migration
to the subject matter experts for the different functional areas and any master data management
to the person responsible for dealing with the procurement of external services where data is to be sourced from an external organization
to the technical consultants responsible for the security architecture
Back to Top
QUALITY CRITERIA
Is the scope of the business objects complete?
Do all business objects have owners identified?
Have all gaps in business objects between current and future state been identified?
Has the use of externally-supplied data been identified?
If there are multiple masters of business objects, has the resolution been identified or raised has an issue?
Has the need for enhanced security measures been justified or identified as not required?
Back to Top
EA.130 - DEVELOP TECHNOLOGY ARCHITECTURE
During this task, you develop the proposed set of technology software required to meet the business' supplemental (aka non-functional) requirements as well as the
platforms needed to support the applications and/or custom-developed software to meet business requirements. This has to take into account any constraints imposed by
the proposed software on which platforms can be supported.
Information Architecture (EA.120)
It may be necessary to perform early iterations of the following Implement Inception phase tasks at the enterprise level:
Conduct Technical Architecture Workshop (TA.010)
Define Technical Architecture Requirements and Strategy (TA.020)
ACTIVITY
Back to Top
WORK PRODUCT
Technology Architecture - The Technology Architecture describes the proposed technology software required to meet the business' supplemental requirements as well
as the platforms needed to support the applications and/or the custom-developed software to meet business requirements.
Back to Top
TASK STEPS
1 Obtain prerequisites such as any client architectural
principles, the supplemental (non-functional)
requirements and the business volumetrics.
This information frames the overall work package into the language of the client and
factors in the operational and technical constraints of their environments.
2 Develop and document the overall technical architecture. Technical
Architecture
Overview
The Technical Architecture Overview contains the following:
model and definition of the technology architecture for the to be landscape
identification of legacy technology components that will still exist in the to be
landscape
a list of the technology owner (e.g., hardware vendor for Infrastructure, Oracle for
applications, etc) for each technology component in to be landscape
3 Define the system administration architecture. System
Administration
Architecture
The System Administration Architecture contains the following:
definition of the system management requirements
definition of the system management components meeting the requirements
identification of the as is system management components that will be kept
definition of the hardware vendors system management components in the to be
definition of the Oracle system management components in the to be
This becomes the enterprise information that will provide requirements information
to the implement task TA.060 Define System Operational and Management
Strategy for each subsequent implementation project.
4 Define the disaster recovery strategy. Disaster
Recovery
Strategy
The Disaster Recovery Strategy contains the following:
definition of the disaster recovery requirements
definition of the conceptual and physical disaster recovery solution
identification of the technology used within the disaster recovery solution
to the implement task TA.050 Define Disaster Recovery Strategy for each
subsequent implementation project.
5 Define the integration architecture Strategy. Integration
Architecture
Strategy
The Integration Architecture Strategy contains the following:
definition of the enterprise level integration requirements
definition of the enterprise integration architecture solution
identification of the technology to be used within the integration solution
to the implement task TA.030 Define Integration Requirements and Strategy for
each subsequent implementation project.
6 Define the security architecture strategy. Security
Architecture
Strategy
The Security Architecture contains the following:
definition of the security architecture requirements
documentation of the logical and physical layers of the security solution
a mapping of security requirements to hardware / software components
a mapping of security requirements to Oracle software components
to the implement task TA.090 Develop Security and Control Strategy for each
subsequent implementation project.
7 Define the Platform and Network architecture. Platform and
Network
Architecture
The Platform Architecture contains the following:
definition of the platform and network architecture requirements for planned
implementation projects
documentation of the physical platform and network architecture solution
a mapping of platform and network requirements to hardware / software
components
a mapping of Oracle software requirements to Platform and Network Architecture
components
to the implement task TA.150 Define Final Platform and Network Architecture for
each subsequent implementation project.
Back to Top
APPROACH
The main objectives for this task are:
to support the planning and scoping of any subsequent implementation through:
capturing enough detail to support costing and planning
addressing the key topics that impact costing and planning
stating major assumptions and constraints that affect the architecture
stating, or referring to, key architecture principles that impact costing, planning and readiness
to give sufficient detail concerning the technical solution to drive the work breakdown structure and cost estimating process
to take into account the key inputs:
use of software products, best practice, implementation and solution recommendations
the application architecture
known constraints, e.g., existing infrastructure, strategies, deployment models
architecture scope
A key driver for this task is the set of supplemental (aka non-functional) requirements that have a major influence on the level of scalability and resilience.
Security Architecture
The development of Security Architecture should take into account a large number of aspects. The following are some considerations:
if the security architecture will be built on top of retained or planned network infrastructure
traffic between browsers and DMZ Servers
traffic between DMZ and private network VLANs
securing file transfer
authentication and coarse-grained authorization to Web-based applications
passwords encryption and repository usage with any allied security within the repository
fine-grained authorization and audit
third-party access to internal systems
securing and monitoring of access to web services both internally and externally (i.e., B2B)
user provision and allied business rules
the location of the authoritative definition of users
the means by which temporary staff and contractors who may or may not appear in the same definition of employee will be on-boarded
the control and approval of changes in entitlement to systems and resources
compliance reporting on the registry of users, accounts and entitlement
the identification of the enterprise LDAP directory its use as a data store for user/group information
the means by which users are required to access highly sensitive and secure data, should be used to provide additional strong authentication without the need to
provide new hardware (such as card readers, biometric devices) to clients
business forensics, in particular risk scoring and management and fraud detection
The level of depth on this task depends on the scope and nature of the Enterprise and the candidate projects in the IT Portfolio. You should consider this task as an early
iteration of some components of it's related Implementation tasks. The outcome of this task is similar to the following OUM Implement tasks and encompasses subsets of
them relevant to the engagement:
Conduct Technical Architecture Workshop (TA.010)
Define Architecture Requirements and Strategy (TA.020)
It may also include elements of the following OUM Implement tasks:
Define Reporting and Information Access Strategy (TA.040)
Define Disaster Recovery Strategy (TA.050)
Define System Operations and Management Strategy (TA.060)
Develop Initial Architecture and Application Mapping (TA.070)
Define Backup and Recovery Strategy (TA.080)
Develop Security and Control Strategy (TA.090)
Define Final Platform and Network Architecture (TA.150)
This Envision task is a prerequisite touch point to the above OUM Implement tasks. The difference between this task and the Implement tasks listed above, is that in an
Envision engagement, all the aspects of these tasks are part of a single work product that addresses the technology-related aspects in a High-Level Enterprise Technical
Architecture. The level of detail for this work product is governed by the objective, typically to drive out the scope of the infrastructure and allied software to be provided
and a work breakdown structure for both client and Oracle staff to obtain costs for the project.
You should review the corresponding Implement task(s), to determine information required before the Implement task can begin. The work product produced by this task
may become an artifact used by subsequent IT Portfolio Project Implementation engagements.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Oversee consistency with other future state architecture models. 20
Solution Architect
Develop the Technology Architecture with input from the client solution architect. Preferably, this should be done by a solution
architect with experience in Technical Architecture.
80
Client Solution Architect Assist the solution architect with developing the Technology Architecture. *
Back to Top
PREREQUISITES
Prerequisite Usage
Supplemental Enterprise Requirements (ER.100)
Future State Enterprise Architecture (EA.110)
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
EA.140 - DEVELOP APPLICATIONS ARCHITECTURE
During this task, you describe the candidate applications to meet the Architecture requirements, the decisions made to select those applications and the resultant set of
software components.
The Application Architecture will consist of three levels of abstraction:
Conceptual Application Architecture outlining the top most abstraction level of applications groups/domains, WITHOUT naming of specific products
A Logical Application Architecture outlining the individual applications building blocks, WITHOUT naming of specific products
A Physical Application Architecture outlining the physical application building blocks, i.e., WITH naming of specific products
The Application Architecture should be all-inclusive, i.e., include legacy building blocks as well as external building blocks.
The Application Architecture might be complemented by a number of additional components, e.g., a System Architecture where interfaces and relationships between
applications are diagrammed, an application/process matrix where relationships between Application Architecture building blocks and Business Architecture building
blocks are cross-referenced .
Future State Enterprise Architecture (EA.110)
Enterprise Function and Process Model (BA.040)
Enterprise Business Context Diagram (BA.045)
Information Architecture (EA.120)
Technolgy Architecture (EA.130)
The task will have an iterative nature where iterations are made top down from Conceptual to Logical to Physical following the work done in the above parallel tasks.
ACTIVITY
Back to Top
WORK PRODUCT
Applications Architecture - The Applications Architecture defines the applications that will provide application support for the Business Architecture and functional
requirements of the business.
Back to Top
TASK STEPS
1 Define the Conceptual
and Logical
Application
Architecture.
Conceptual
and Logical
Application
Architecture
The result of this initial mapping will be a view on the types of applications (conceptual/logical) needed to support the
Business Architecture provided through the business requirements. Please note that a business process will be
considered a business requirement, even though no detailed requirements are stated other than a process name, e.g.,
Time & Absence Management.
2 Define the Physical
Application
Architecture.
Physical
Application
Architecture
The result of this step is a view of the physical applications that will support the Business Architecture. The Physical
Application Architecture may include multiple options that must be evaluated with the customer and considered in the
business case, as a given business requirement may be solved more or less sophisticated.
3 Create Logical System
Architecture.
Logical
System
Architecture
The Logical System Architecture shows a diagram with logical applications and their interconnection.
4 Create Physical
System Architecture.
Physical
System
Architecture
The Physical System Architecture shows a diagram with physical applications and the interconnections this diagram will
be used directly during implementation as scoping. In some engagements this component will first be done during
Implement.
5 Create Applications &
Processes Matrix.
Applications &
Processes
Matrix
The component maps the different Logical Application building blocks to the process model in the Business Architecture.
6 For each candidate
application, identify
application security
requirements.
Application
Security
Requirements

Back to Top
APPROACH
For the functional requirements, identify the existing systems that support them and the candidate applications. This may include, where relevant, a definition of what is
and is not in scope.
The clients description of the requirements can take many forms, from the superficial that just has the business components to lengthy tables of requirements.
Describe the choice in the selection of applications to meet the requirements. This is a refinement of the list of candidate applications. Identify any retained systems. This
is typically produced in both narrative and diagrammatic forms. The narrative form lists the requirements and, for each, the software component to selected address this.
The diagrammatic forms:
depicts the business components as functional areas and assigns the selected software modules. This may have the same module being used by different
business components. There may also be some modules which address common requirements for administering the business such as Financials, HR and
reporting.
a footprint diagram which shows the set of software modules (both new and retained) grouped by functional area
The first type of visualization is used to show where the requirements are addressed by which software module. It may also be used to show where business
requirements are met by manual processes or are out of scope. The second type of visualization shows the scope of the software modules in the future state.
The production of the visualizations of the Applications Architecture is particularly important in order for the client staff to understand the scope of the proposed system
and in the demonstration that the requirements are addressed.
For the set of selected applications and retained systems, identify the data flows between those systems. This is typically presented as:
a table of dataflows identifying source and target systems and the business objects involved
a diagram of the dataflows
This is performed at level of business objects and informs the information architecture which in turn forms the basis of developing the integration architecture.
Process Views
To demonstrate the use of the different applications, and identify any issues, choose a set of business processes and identify their use of the components within the set of
select applications. From these identify any inter-application interfacing points.
This aspect is typically where there are multiple applications, whether new or retained that have implied process issues that might need to be resolved by integration or
double-entry.
The process flows may be those being used as the basis for confirming requirements or may need to be developed. Process flows that make use of a single set of
integrated modules, for example a process concerned with an ERPs Financials modules, would not be used for this purpose if it has no effect on demonstrating the
application architecture.
System Architecture
The Application Architecture views are extended into a dedicated System Architecture diagram that shows interconnections between the individual application building
blocks. Normally two different diagrams will be created:
Logical System Architecture that can be considered a generalized view of the system architecture without any product namings
Physical System Architecture that specifically identifies Applications and Interfaces
Applications and Process Matrix
To demonstrate the use of the different applications, and identify any issues, choose a set of business processes and identify their use of the components within the set of
select applications.
This aspect is typically where there are multiple applications, whether new or retained that have implied process issues that might need to be resolved by integration or
double-entry.
The process flows may be those being used as the basis for confirming requirements or may need to be developed. Process flows that make use of a single set of
integrated modules, for example a process concerned with an ERPs Financials modules, would not be used for this purpose if it has no effect on demonstrating the
Application Security
From the clients security principles, identify any measures required to implement application security that may have an impact on the application architecture. For
example, the definition of users and their roles may be sourced from one system
Supplemental Information
LEGACY SYSTEMS
When not described in another work product, list any legacy systems identifying which are to be replaced by what software module, leaving the residue of retained
systems.
PRODUCT GLOSSARY
Where not included in the Enterprise Glossary (BA.030), include a product glossary that summarizes the functionality provided by each of the candidate applications so
that anyone reading the document can identify what the application does. In major implementations of ERP modules, client staff may be familiar with only the subset of
applications for their role. Other client staff, particularly technical staff who may review the work product, may have little knowledge of the proposed applications.
EXTERNAL INTERFACES
Where the overall solution includes interfaces to or from external parties, define the nature of the interface and any commercial implications. This includes online
interfaces, e.g., to a payment processor or the provision of data from external sources.
engagements.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Oversee consistency with other future state architecture models. 40
Solution Architect
Develop the Applications Architecture with input from the client solution architect. Preferably, this should be done by a solution
architect with experience in Application Architecture.
60
Client Solution Architect Assist the solution architect with developing the Applications Architecture. *
Back to Top
PREREQUISITES
Prerequisite Usage
(BA.020)
This work product defines the different user communities for the applications.
Enterprise Glossary (BA.030) The Enterprise Glossary may define some of the terms relevant to this work product thereby negating the need for including a
glossary component in the Applications Architecture.
Requirements (ER.100)

Desired Future State (ER.160) The Desired Future State defines in business terms the desired end state.
Architecture (EA.110)
The Future State Enterprise Architecture defines a high-level enterprise architecture. Use it as a frame of reference for the basis
for mapping applications.
Technology Architecture (EA.130)
Back to Top
TEMPLATES AND TOOLS
Example Comments
EA-140_Application_Architecture_Sample_A.PPT MS Powerpoint - Sample Conceptual, Logical, and Physical Application Architecture
EA-140_Application_Architecture_Sample_B.PPT MS Powerpoint - Sample Conceptual, Logical, and Physical Application Architecture
EA-140_Application_and_Process_Model_Matrix_Diagram.vsd MS Visio - Sample Applications & Process Matrix diagram
EA-140_Application_Architecture_Physical_Sample.vsd MS Visio - Sample Physical System Architecture
Tool Comments
Back to Top
The Applications Architecture is used in the following ways:
as input into the Future State Transition Plan (ER.170) defining the scope of the application architecture by implementation phase
as scoping of integration components
as input into the Information Architecture (EA.120) to develop the domain models at the level of business objects
as input to the Business Volumetrics Report (BA.067) in terms of the questionnaires to be included and information on interfaces and users
Distribute the Applications Architecture as follows:
to the client staff responsible for the different business areas
to technical consultants responsible for the development of the Technology Architecture (EA.130) and the integration
to the staff responsible for gathering the business volumetrics
Back to Top
QUALITY CRITERIA
Are all Business Processes and Business Requirements supported by an application?
Has the full scope of the selected application(s) been defined?
Have any gaps and resultant custom modules been identified?
Have inter-application interface points been identified?
Have external interfaces been defined?
Back to Top
EA.150 - DEFINE TRANSITIONAL ARCHITECTURES
During this task, you define one or multiple Transitional Architectures, each that provide value to the enterprise for moving their architecture maturity forward, eventually to
a future state that supports the business operations and strategy objectives. The intent is to minimize risk and maximize value returned.
You need to define a strategy that governs how the Transitional Architectures will be deployed. It may be that you decide not to apply the changes for the whole enterprise
at one time, but rather implement them to impact one part of the organization at a time. The approach depends on the current situation and where the organization is
heading.
You also look into dependencies so that you can take into account necessary accomplishments before moving into another phase (transitional phase, not to be confused
with OUM phases).
By defining a roadmap through a series of Transitional Architectures, changes in capabilities, their costs, and effectiveness can be completed and evaluated in definable
transitional phases building toward the future state. The intent is to reduce or minimize disruptions to the business operations, delivering the capabilities when the
organization needs them to support the strategy, and allow for mid-course corrections that may occur due to changes in the business climate or adjustments to strategy
without having to re-work the architecture from the original current state.
ACTIVITY
Back to Top
WORK PRODUCT
Transitional Architectures - The Transitional Architectures provide a set of multiple architectural states that are meant to be intermediate architectural states before
arriving at a desired future state architecture. Each architecture state provides value to the enterprise and moves the architecture maturity forward. The Transitional
Architectures are typically used as part of developing an architectural roadmap from a current to a future state, via the transitional architecture states.
Back to Top
TASK STEPS
1 Determine the Transitional
Strategy.
Transitional
Strategy
The Transitional Strategy component describe the chosen approach when developing the Transitional
Architectures, e.g. based on enterprise architecture maturity, using a horizontal approach, or a vertical
approach.
2 Develop Capabilities Inventory
reflecting the Transitional
Strategy.
Capabilities
Inventory
The Capabilities Inventory describes the capabilities and their priorities as which ones will be required for each
transitional state following the Transitional Strategy.
3 Determine Dependencies and
dependency order.
Dependencies The Dependencies documents the capabilities, technological and operational / organizational dependencies, and
the order of these dependencies.
4 Develop Transitional
Architectures
Transitional
Architectures
The Transitional Architectures contains the actual Transitional Architectures describing the path to arrive at the
desired future architecture.
5 Consider technical and non-
technical dependencies.
Dependencies
(Updated)
The updated Dependencies documents an updated view of capabilities, technological and operational /
organizational dependencies, and the order of these dependencies.
6 Consider other business and IT
initiatives.
Capabilities
Matrix
The Capabilities Matrix compares key capabilities being delivered in a phase (or overall) to other busines and IT
initiatives in order to identify those that may be dependent upon or would benefit from the current engagement
capabilities.
7 Summarize the Transitional
Architectures.
Transitional
Architectures
Summary
The Transitional Architectures Summary summarizes the enterprise architecture transitional roadmap
recommendations, including risks and risk mitigation strategies to support the transitions.
Back to Top
APPROACH
Determine Transitional Strategy
Before determining the actual Transactional Architectures, you should determine the strategy to move forward to the desired future state. The strategy depends on the
organizations timelines, priorities, maturity and ability to accept risk. One approach is to start with the results from an Enterprise Architecture maturity assessment to
determine the maturity level, and then move forward to a desired level by determining the transitional phases (sometimes referred to as states or stages) through which
the organization should pass to eventually reach the desired future state.
You typically define phases with different architectural focus. For example, you may have phases where each state has a different focus, such as:
standardization of IT capabilities and resources
consolidation of IT capabilities and resources
optimization of IT capabilities and resources
Develop Capabilities Inventory
Starting with the capability priorities, considering both the initiatives related to the engagement at hand and other IT initiatives develop an initial inventory of capabilities
that are required to establish the foundational components to support the future state.
Make a list of the high-level capabilities that you have identified and analyzed earlier as part of the Maturity Analysis and Recommendations Report (ER.015), the
Architectural Gaps and Improvement Options (EA.060), and the Analyzed Capabilities (EA.040) when available.
Group the capabilities into high-level domains relevant for the type of future architecture, and sequence them in the order of defined priorities or in support of prioritized
capabilities and initiatives. Split the capabilities into core and supporting capabilities.
Determine Dependencies and Dependency Order
Review the identified capabilities against the organizational/operational capabilities and determine which capabilities, technological and operational / organizational, are
dependent upon one another. Consider the technology recommendations being applied to the future state. Keep in mind that new technologies may require the
augmentation or development of skills that do not yet exist in the organization.
Review and identify the technologies and supporting technology deployment and operational capabilities that require new or additional skills. Define technology that is
dependent upon other technologies or supporting architectural components. Define and capture the order of deployment or requisite skills or processes that are required
to support the adoption of the capability.
Assess the appropriate placement of the capabilities within the transitional architecture states.
Organize the capabilities in a dependent order, and for non-dependent capabilities validate these against the defined priorities.
Develop Transitional Architectures
Begin the development of the actual Transitional Architectures. Use an iterative process, and, if needed, develop multiple alternative transitional architecture paths.
If developing multiple transitional architecture approaches, various options can be presented to the enterprise stakeholders for review, before selecting the final options.
The alternatives can represent various considerations such as accelerated delivery, risk avoidance, and investment options (cost to value). Each alternative would affect
the risk, cost, time, and value to different degrees.
Take into consideration impacts and implications of the Operating Model and strategic objectives as the future state architecture is decomposed into a phased model for
adoption. Strategic objectives should provide guidance in terms of the time lines required to reach specific objectives and the methods for defining the value expected
from the capabilities implemented. The Operating Model must be considered because the capabilities will affect integrated processes and the applications and
Information Architecture capabilities they support, and therefore, how and when the capabilities supporting the Operating Model will be available. This can identify risks in
the roadmap associated with the scope and breadth of the capabilities required across the organization. For example, shared service capabilities implemented in a single
region, might move the organization forward in terms of maturity and capabilities, but may not provide the required capabilities across multiple regions required by certain
business processes. Remediation for those regions not serviced would need to be considered as well.
Different views or focus may be applied to the different transitional architecture phases, depending on the objectives for each phase. Some view examples are:
a type of view that includes the relationship to the business and technology strategies supported by the phase, along with the associated risks
an organization / operational view, focusing on the impacts to the organization and operations through the organization and process impacts
a benefit / value view that provides linkage between the capabilities developed or acquired in a given phase to the business objects and the strategy objectives
being received or realized in the phase
When developing the transactional architecture states there may be situations where timelines and objectives are in conflict with the determined path. For example, if the
phases are based on the maturity model, there may be conflicts with the maturity model definition. For all these situations, you should identify these as potential risks.
You can then apply additional capabilities to mitigate the risk. Keep in mind that if you use an appropriate maturity model as a basis, this is still intended for reference,
and not to be a strict set of required guidelines. Adjust the phases to support the objectives and priorities, using cost and risk adjustments to balance the time to delivery
and the gaps in maturity.
Consider Technical and Non-Technical Dependencies
As the Transitional Architectures are developed and refined, both technical and non-technical dependencies need to be reconsidered in the context of the capabilities to
be realized within and across the phases.
Technical capabilities are often more obvious and evident than the non-technical ones. Non-technical capabilities are often an afterthought, but are just as or sometimes
even more important than the technical capabilities. Think about operational and organizational capabilities supported by the people and processes that will deliver and
operate the defined technical capabilities
Update the dependencies you started with earlier with new findings.
Consider other Business and IT initiatives
Further refine the Transitional Architectures and take into consideration other business and IT initiatives that are not directly related to the engagement at hand. These
may already be in-flight. Identify the initiatives that may be dependent upon or would benefit from the current engagement capabilities.
Review the business objectives and other architecture initiatives to ensure that the capabilities delivered within the various Transitional Architectures are being considered
in terms of either dependencies or that would be enhanced or could take advantage of the capabilities within a given transitional stage.
This could present opportunities to increase the value proposition of the capabilities where they can support other projects and programs. This may lead to funding
opportunities in the development of the infrastructure or other type of implementation that will be required as result of the Transitional Architectures.
It is recommended that you create a matrix where one axis displays the key capabilities for a given phase (or overall), and at the other axis displays the initiatives where
you have identified some relationships to one or more capabilities. In the junction cells, you describe per capability what should be accomplished per initiative (if
anything), and then you can highlight all the junction cells where there are relationships to or dependencies to the engagement at hand. Below, is an example for a cloud
initiative:
Summarize Transitional Architectures
Last, combine the various views into a summary describing the Enterprise Architecture transitional roadmap recommendations. Clearly define the risks and risk mitigation
strategies to support the transitions. As the scope requires, develop the business case for each state incorporating the value to be received based upon the investment
required. Describe the value within the time horizon the organizations decision makers use to evaluate investment performance.
In support of this, it is recommended that you look into funding the Transitional Architectures by looking at the enterprise Funding Model (GV.090) and performing a
Benefit Analysis (ER.110).
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Work with the enterprise to iteratively develop the Transitional Architectures. 100%
Client Enterprise Architect Work with the enterprise architect to develop the Transitional Architectures. *
Client Executive(s) Communicate and ensure alignment and acceptance with the enterprise. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business objectives.
Validated Operating Model
(BA.025)
Use the Validated Operating Model to determine implications.
Maturity Analysis and
Recommendations Report
(ER.015)
Use the Maturity Analysis and Recommendations Report (from an enterprise maturity assessment) to identify required capabilities
for the Transitional Architecture states, and potentially to determine the strategy for the transitional states.
(EA.030)
Use the Current Enterprise Architecture to determine the architectural path from the current to the future state.
Analyzed Capabilities (EA.040) Use the Analyzed Capabilities as an input to the Capabilities Inventory.
Current Architectural
Challenges (EA.050)
Use the Current Architectural Challenges to identify the most critical challenges related to the current architecture.
Improvement Options (EA.060)
Use this work product to identify capabilities relevant for the Transitional Architecture states.
Future State Architecture
(EA.110)
Use the Future State Architecture to determine the architectural path from current to future state.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Transitional Architectures is used in the following ways:
as an input to final architectural roadmap creation.
Distribute the Transitional Architectures as follows:
to client enterprise architects
Back to Top
QUALITY CRITERIA
Are the transitional architecture states founded in a clearly phased strategy?
Have capabilities been identified for each phase, and does each state fully support these capabilities?
Have technical, organizational and operational dependencies been identified and handled?
Have potential risks been identified for each state, and have mitigation capabilities been included?
Is there a clear relationship between each transitional architecture state and the business objectives?
Is it clear how each individual transitional architecture provides value to the enterprise?
Have other initiatives (independent on this engagement) been considered (to receive benefit from the Transitional Architectures or important dependencies)?
Back to Top
EA.160 - DEFINE BUSINESS RULES IMPLEMENTATION
STRATEGY
During this task, you review the business rules that have been identified. Based on the nature and amount of the business rules found per category, you determine and
document an implementation strategy for business rules.
For any situation that involves a set of business rules of any significant size, it is important to determine and document a consistent strategy for implementation of
business rules. Failure to establish such a strategy might result in an inconsistent implementation of rules and may jeopardize the overall quality of the implementation.
Choices may include more than one means of rule implementation depending on the categorizations used and the size of the rule bases involved as well as the overall
process and enterprise architecture improvement opportunity goals.
ACTIVITY
Back to Top
WORK PRODUCT
Business Rules Implementation Strategy
Back to Top
TASK STEPS
Component
Description
1 Review the Future State Enterprise Architecture (EA.110) and the MoSCoW Improvement List
(ER.130).

2 Determine Business Rules Implementation Strategy. Business Rules Implementation
Strategy

Back to Top
APPROACH
Any business rules implementation strategy is influenced significantly by the technical architecture (which has been derived from the requirements), and the options for
implementing business rules as provided by that technical architecture. Therefore, review the Supplemental Enterprise Requirements (ER.100) to determine the
constraints to which the Business Rules Implementation Strategy must adhere.
A distinction can be made between business rules of a static nature (for example, a rule such as: end date must be on or after the start date), and more volatile business
rules that are likely to change over time due to changes in the business, laws, or policies. For volatile rules, the business may have the requirement to be able change a
rule by configuration rather than by involving developers. Typically, the most common volatile rules are provided for in commercial off-the-shelf (COTS) configurations. In
some cases, COTS applications are highly configurable in these situations. Use cases may be developed to elicit the business requirements that should be applied in
complex situations, such as Business Intelligence especially when complex data aggregation, transformation and analytics are required.
In a system with a lot of data entry and retrieval screens, you might have chosen to implement using Oracle
Application Development Framework (ADF) or some kind of

similar tool. When using ADF, you can also choose to use Oracle
ADF Business Components for Java (ADF BC4J) as the persistence layer or for providing other kinds
of business services. ADF BC4J offers specific features for implementing specific types of (static) business rules. Other similar types of tools may have similar
capabilities. Next to that, you may choose to use a business rules engine for implementing business rules with a volatile nature. What is important, is to understand what
options are available for implementing rules and to keep this in mind as you determine an appropriate strategy for implementation.
Another example is where several existing applications need to be integrated, or (reusable) services need to be provided, and you have chosen to implement that using
the Oracle
SOA Suite or the Oracle
BPM Suite. With that associated technical architecture, you are faced with different capabilities. Hence, a persistence layer may
play only a marginal role in the architecture, and most business rules may be related to decisions in (business) processes, and therefore of a nature that makes
#TOP #TOP
implementation as decisions in a BPEL process or a routing rule in a Mediator more applicable. Especially in the case of a service-oriented architecture, the use of a
business rules engine for implementing rules with a volatile nature becomes eminent. In that case, a business rule engine such as Oracle Business Rules or Oracle
Policy Automation may be appropriate.
Determine Business Rules Implementation Strategy
Independent of the type of architecture, for any situation that involves a set of business rules of any significant size, it is important to determine and document a
consistent strategy for classification and implementation of business rules before designing rules on a large scale. It may be that the enterprise has used a different kind
of technical architectures in the past, or have decided to use a different kind of architectures for different kind of situations. The Business Rules Implementation Strategy
for the enterprise should cover the strategy for all types of architectures that will be used by the enterprise.
If a project uses a new type of architecture, it may be that there is not yet a Business Rules Implementation Strategy that fits that project. If so, the strategy for that project
should be elevated to become a part of the enterprise strategy.
Back to Top
Enterprise Architect Make recommendations on how the remaining rules should be handled. 30
Solution Architect
Provide input on which candidate rules are suitable for implementation in a particular product, such as a rule engine. 70
Back to Top
PREREQUISITES
Prerequisite Usage
MoSCoW Improvement List (ER.130) Use the MoSCoW Improvement List to view the priorities of the various elements of the future architecture.
(EA.110)
Use the Future State Enterprise Architecture to determine the constraints to which the the Business Rules Implementation
Strategy must adhere.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
ADF (Application Development Framework) Business Components. When using ADF Business Components, a strategy
for classifying and implementing business rules using ADF BC could be based on this white paper.
Oracle Application Server - Oracle Business Rules provides a classic rules engine approach that can be called as a
SOA division support service. Oracle Business Rules is included in the "rules" directory of the Application Server.
Back to Top
The Business Rules Implementation Strategy is used in the following ways:
to determine and document a consistent strategy for the implementation of business rules
as a reference for future projects
Distribute the Business Rules Implementation Strategy as follows:
to the Maintained Repository of Artifacts
Back to Top
QUALITY CRITERIA
Do the designers and developers understand the methodology to define business rules?
Do the designers and developers understand which development tool(s) is used to manage business rules?
Back to Top
EA.170 - IDENTIFY INTEGRATION REQUIREMENTS
During this task, you identify a number of candidate business processes that are required to implement a given integration solution. Using the candidate business
processes as a basis, analyze the actors and their roles, and then identify all the existing applications or SOA services that should be part of the solution. Also, identify
any units of the enterprise that are out of control, as well as external parties that participate in the process.
For each candidate process, determine the integration requirements, analyzing the relevant business events and data flows. Last, determine the quality of service (QoS)
requirements relevant for the business processes.
ACTIVITY
Back to Top
WORK PRODUCT
Integration Requirements - The Integration Requirements include a description of the candidate business processes that are required to implement the integration
solution, including the requirements that are needed to integrate the processes as desired.
Back to Top
TASK STEPS
1 Identify candidate business processes for
integration solution.
Candidate Business
Processes
The Candidate Business Processes is a list of the business processes with a brief description that
have been identified for the integration solution.
2 Analyze actors and their roles. Integration Approach This component describes the recommended approach for each integration point.
3 Classify actors. Actor Classification
4 Determine integration requirements. Integration
Requirements

5 Analyze business events. Analyzed Business
Events

6 Analyze business data flows.
7 Define quality of service.
Back to Top
APPROACH
Identify Candidate Business Processes
When determining integration solution requirements, you must first identify the business processes that are candidates for the integration solution. If available, use the
Business Function or Process Model (BA.040) as input. Ensure that you achieve a good understanding of the candidates, what work is done in each process, and the key
activities. Also, ensure that you understand the characteristics for each process or component, such as:
sequence or order (in relation to other tasks and activities
frequency of occurrence
urgency and timeliness
duration or elapsed time
volume range, including average volume, peaks and lulls
Analyze Actors and their Roles
If available, use the High-Level Use Cases (BA.060) and in particular the Enterprise Actor Model as an input for this analysis. For each business process, ask the
following questions related to the identified actors:
Do the actors include other departments within a company, for example, vendors, customers, systems, and web users?
What is the geographic topology of these entities? Are they located at one site or are they distributed across other locations? Which entities are located at which
sites?
How is data transported between actors?
at a single location (within a LAN or domain)
across a WAN to other locations within the same organization
outside the WAN to actors beyond a firewall
What is the format of the events flowing in and out of each entity in each business process?
To further analyze each role, ask the following questions:
What roles are involved in the candidate business process?
What is the sequence in which the work of each role is performed?
How does the work of each role fit into the overall business process, specifically, does the given role:
initiate the process
provide a service to the process
consume business events generated by the process without returning a response
review, approve, reject or otherwise make a decision along the way
How many people and processes are associated with each role?
Classify Actors
When you have analyzed the actors and identified those that are involved in each candidate business process, characterize the different types of actors involved in a
business process, such as:
human users
enterprise information systems (EIS) or SOA services
enterprise internal domains, outside scope of control
external trading partners
Determine Integration Requirements
Determine the integration requirements per type of actor.
HUMAN USERS
For human users, distinguish between two kinds of involvements. First, the work-list kind of users, where they work directly with the business process, as the business
process itself allocates work to an actor, and second, the users that work indirectly with the business process through an application or service that takes part in a
business process. For each interaction with the business process, determine the type of interaction, such as for html or email.
ENTERPRISE INFORMATION SYSTEMS (EIS) OR SOA SERVICES
The technical infrastructure of an organization can consist of a variety of enterprise information systems (EIS), including legacy mainframe systems, client-server
applications, and packaged applications, such as ERP and CRM applications, as well as a number of SOA services. Some examples of EIS applications include:
packaged applications (including email)
custom applications
applications that use middleware technologies
applications with queue-based interfaces
technology adapters
Use the IT Application Portfolio (IP.012), the Services Portfolio (IP.014) and the Applications Architecture (EA.140) as an input to identify the relevant enterprise
information systems and SOA services. You should focus on those systems and services that will be directly involved in the integration solution, i.e., taking a part of the
candidate business processes, and asking questions such as:
Will the candidate processes include a direct connection to the EIS, or SOA Service? And, if the answer is yes:
Can the EIS be customized to support the integration?
Can the SOA service be reused without customization, or not?
Will the EIS and the business process exchange events?
What business functionality does the EIS or SOA Service provide (such as purchase order management, inventory management, and so on)?
What kind of application details and interfacing technology will be used?
Further, for each EIS and SOA service evaluate:
What are the name and version of the EIS or SOA service?
On which platform(s) does it run?
What interfacing technology does the EIS offer? Does the EIS offer an API? Does the EIS have a file-based interface? Does the EIS use a middleware-based
interface?
Do the EIS internal business processes that will be involved in the integration mandate the use of a particular EIS interface?
What is the format of the data passed by the interface (binary, XML, other)? Is metadata (data that describes the data) available, or does this metadata need to be
created by hand?
For each business event that is exchanged between the business process and the EIS application, what is the EIS interface (API, event, database table, and so
on) that will be used?
What are the human and application interfaces?
What are the mappings between interfaces?
Finally, determine whether any additional customization is required for each EIS application or SOA service as it may not implement all the functionality required to
support the integration solution and might require internal customization. Determine whether this is needed and, if so, define the technical requirements.
ENTERPRISE INTERNAL DOMAINS, OUTSIDE SCOPE OF CONTROL
An integration solution might involve contact with other locally-administered domains in the enterprise, such as remote offices. In such situations, the internal mechanics of
the other domain are beyond the control of the integration solution. The interface between the business process and other domains like this is the set of business events
that flow between them. These interfaces must be defined.
One approach is to represent independent domains as trading partners within the enterprise, using B2B integration functionality to support the flow of information among
them. For example, suppose an enterprise owns a factory in Malaysia that supplies parts to a wholly-owned assembly-line factory in Japan. Using B2B integration, the
Malaysian office can act as a supplier ("seller") of components to the Japanese office, which acts as a buyer.
EXTERNAL TRADING PARTNERS
An integration solution might involve external trading partners with which a business process needs to communicate. Such processes cross the enterprise firewall. For
trading partner integration, the integration specialist must define:
What is the nature of the B2B integration?
Is it a value-chain integration? If so, is it a supply-chain integration (where the trading partners are suppliers to the enterprise), a demand-chain integration
(where the trading partners are customers to the enterprise), or a combination of both?
Is it a B2B exchange that can enlist trading partners for B2B transactions?
Are there mandated protocols that must be included in the integration solution?
Analyze Business Events
Business events are exchanges of messages or tasks that occur between actors during a business process. A business event indicates that a business activity has taken
place and needs to be performed. For example, an EIS could publish a new customer created event, or an order management application could subscribe to new
order events to process new orders. Each actor can exchange business events with the business process. Each business event should be given a descriptive name that
uniquely identifies it in the business process.
Business events contain business data. For example, suppose that a create new customer event occurs during the execution of a customer management application. In
the process of creating a new customer, the application might receive the name and address of the customer name from another actor in the business process and return
a number for the customer to that actor.
DEFINING BUSINESS EVENT CHARACTERISTICS
For each interaction between an actor and the process you should define:
business events that can be sent and received
any unique characteristics of elements in the business events
DEFINING THE MESSAGE FORMAT FOR BUSINESS EVENTS
Define:
business event format (XML or binary) and metadata - A common format (such as XML) is used whenever possible.
any information in the event that may be used for controlling decisions (such as conditional processing, routing, triggering, and so on)
Analyze Business Data Flows
The business process defines the required flow of data between actors. From this flow, you can determine how the business data needs to be manipulated. Perhaps, for
example, the business data should be split into multiple events, concatenated from multiple events, or transformed from one data format to another.
This data flow should also define any business data that is used in the business process to make processing decisions. For example, if the business process includes an
algorithm specifying that purchase orders over $5,000 must be approved by a vice president, then the amount of money in each purchase order should be defined as
required business data. View the Candidate Business Rules (BA.080) to find this information.
DEFINING DATA FLOW REQUIREMENTS
For each data flow, define the following::
Conditional Data - data that is required to make processing decisions. This data is extracted from business events.
Business or Application Rules - processing rules that are applied to the conditional data to determine the run-time execution path of the process.
Mappings - data transformations between the business events used as input and those used as output.
Business Transactions - transactional boundaries in the process. A single process might contain many business transactions. In addition, for each business
transaction, the integration specialist needs to define any compensating actions that must be performed if a transaction needs to be rolled back.
Error Handling - what exceptions can occur and how they should be handled.
ANALYZING THE DATA FLOW
The integration specialist needs to analyze the technical aspects of the data flow, asking questions such as the following:
What are the characteristics of each data element?
What are the characteristics of messages?
message size, specified in terms of minimum, maximum, and average size
message volume, specified in the number of messages at peak, lull, and average volumes, plus any cyclical patterns
single or batched (aggregated) message - If messages are aggregated, do they need to be split up and routed appropriately? If so, what are the routing
criteria or conditions?
What data transformations are needed between the source data and target data?
For example, suppose an order management application sends a new order event to a shipping application for processing. Suppose that a shipping application runs in
three separate regional offices (eastern, central and western) as three separate instances. The order management application needs to notify the appropriate application
instance based on the ship to address in the order. In addition, the order management application needs to notify the billing application of the new order.
In this scenario, the data flow requirements would be:
Three business events:
New order event from the order management application
Ship goods event to the shipping application
Send invoice event to the billing application
Conditional Data - the state to which the order will be shipped - This information is extracted from the billing address in the new order event.
Business rules - the rule used to identify the shipping application instance to receive the ship goods event, which is based on the ship to state/province in the order
and the list of states/provinces associated with each application instance
Mappings - the data transformation mappings from:
New order event to the ship goods event
New order event to the send invoice event
Business Transaction - Either both the shipping and billing applications are updated successfully, or neither is updated. Compensating actions for rolling back each
application if the other fails must be defined.
Error Handling - If a data error occurs, such as an order is received with an invalid state/province.
Define the Quality of Service (QoS)
For each process determine the quality of service (QoS) characteristics in business and technical terms.
PERFORMANCE
How quickly, in business terms, must the business process be carried out?
What are the peak and off-peak performance requirements?
AVAILABILITY RELIABILITY
When must systems be available? Are they needed 24 hours a day, 7 days a week (24x7)?
What are the planned and anticipated periods of scheduled and unscheduled system downtime, respectively?
What is the maximum allowable downtime?
What failover and recovery protections are required in case a hardware or network failure occurs?
Do business messages need to be persisted while in transit and recovered upon a system restart?
RESPONSE TIMES
Define the response time requirements for the business process. For example, suppliers might need to respond to a bid request within 24 hours, or suppliers might need
to be notified within 60 minutes of the bid award. An event might time out if the response time limit has elapsed.
SECURITY
How sensitive is the information in the business process?
What are the privacy needs associated with each role?
What security safeguards are currently in place?
SCALABILITY
Define the scalability requirements for the business process, based on the current volume of work and the projected volume in the future. For example, an order-
processing integration solution might need to be able to handle triple, within two months, the volume of orders it can handle, without interruption to service or additional
application development.
LOGGING AND NONREPUDIATION
What kinds of problems can arise?
What information needs to be logged and monitored?
For integration solutions that use B2B integration, what information needs to be logged and maintained for audit or nonrepudiation purposes?
Nonrepudiation is the ability of a trading partner to prove or disprove having previously sent or received a particular business message to or from another trading partner.
Nonrepudiation of origin and nonrepudiation of receipt might be required by law for critical business messages.
Back to Top
BPM Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Integration requirements result from the future enterprise business processes and their mapping to the future state application
architecture. Along with the solution architect, analyze the process and data requirements that resulted in integration
requirements and make an inventory of quality-of-service requirements for each discovered integration.
30
Solution Architect Along with the enterprise architect, analyze the process and data requirements that resulted in integration requirements and
make an inventory of quality-of-service requirements for each discovered integration.
70
Back to Top
PREREQUISITES
Prerequisite Usage
IT Application Portfolio (IP.012) Use this as an input to determine which applications (EISs) may be involved in the implementation of the candidate
business processes.
Service Portfolio (IP.014) Use this as an input to determine which services may be involved in the implementation of the candidate business
processes.
Technology Architecture (EA.130) Use this as a help to determine the integration requirements for each integration point.
Applications Architecture (EA.140) Use this as an input to determine which applications (EISs) may be involved in the implementation of the candidate
business processes.
Enterprise Business Function or Process Model
(BA.040)
If available, use this as a basis to select candidate business process models to be included in the integration
solution.
High-Level Use Cases (BA.060) If available, use the Enterprise Actor Model as an input for your actors and roles analysis.
Candidate Business Rules (BA.080) Use this as an input to determine what kind of business data will be required in the data flow.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
EA.190 - DEFINE PRODUCT IMPLEMENTATION
PRIORITIZATION
This task is aimed defining a logical product (i.e., business capability) implementation roadmap based on medium to long term business/IT strategy (i.e., 3 to 5 years)
and taking into account both internal and external influencing factors (e.g., Business EA_190_DEFINE_PRODUCT_IMP_PRIORITIZATION_OVERVIEWTransformation
Programs, competing IT projects, etc.). The successful completion of this task is entirely dependent on gaining access to the enterprise business and IT strategy
information as well as details of In Flight and planned business/technology programs that could have a material impact on the prioritization planning.
ACTIVITY
Back to Top
WORK PRODUCT
Product Implementation Prioritization Report - The Product Implementation Prioritization Report defines a medium to long term (e.g., 3 to 5 years) implementation for
core logical product (component) capabilities that need to be deployed/updated in an enterprise based on a detailed understanding of the enterprise's business and IT
strategy.
Back to Top
TASK STEPS
1 Review existing current state
and future state customer
architecture materials.

2 Identify technology products. Product List The Product List identifies additional individual technology product offerings (Applications or Technical) that have
been identified within the future state architecture based on a current state / future state gap review.
3 Create Product
Implementation Prioritization
Report.
Product
Implementation
Prioritization
Report
The Product Implementation Prioritization Report defines a medium to long term (e.g., 3 to 5 years)
implementation for core logical product (component) capabilities that need to be deployed/updated in an
enterprise based on a detailed understanding of the enterprise's business and IT strategy.
Back to Top
APPROACH
The definition of product in this task is aimed at Logical Capability, e.g., Business Intelligence, Portal, High Availability Infrastructure rather than naming Oracle
Products directly (i.e., unless otherwise directed by the client). An Oracle product overlay can be performed as a separate activity.
This task forms part of/informs the articulation of a To Be Enterprise Architecture strategy as set out in the High-Level Future State Enterprise Architecture (EA.110) and
is linked to the IT Portfolio Plan (IP.060) that contains details of IT projects that are cross referenced in the Product Implementation Prioritization Report.
Review Current State / Future State Architectural Collateral
Review all existing collateral describing both current state and future state architectures and specifically the business drivers leading to the rationale for the future-state
architecture.
Identify Technology Product Gaps
Identify the product capability gaps inferred from the future state architecture design. The resulting product list forms the basis of the Product Implementation Prioritization
Report.
Develop Product Implementation Prioritization Report
Develop the final report.
Back to Top
Enterprise Architect (Lead) Along with the client enterprise architect, prioritize the proposed implementations based on input from an enterprise architect
that specializes in Business Architecture.
40
Provide input regarding the business value of the implementations, timing of business initiatives and competing programs. 60
Client Enterprise Architect Assist the lead enterprise architect with prioritizing the proposed implementations. *
Back to Top
PREREQUISITES
Prerequisite Usage
A high-level view of the target Enterprise Architecture (i.e., based on a detailed review of the current state architecture) is required before a
recommendation for product implementation prioritization can be put in place.
(EA.120)
Review the Information Architecture to form a basis for the Product Implementation Prioritization Report.
(EA.130)
Review the Technology Architecture to form a basis for the Product Implementation Prioritization Report.
Applications Architecture
(EA.140)
Review the Applications Architecture to form a basis for the Product Implementation Prioritization Report.
Plan (ER.170)
A high-level view of the Future State Transition Plan (particularly the underlying business needs prompting the architectural transition)
needs to be understood before a product implementation prioritization recommendation can be put in place.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Overview
task.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
EA.200 - DETERMINE DEVELOPMENT FRAMEWORK AND
POLICY GUIDELINES
During this task, you determine the development process to be used by the enterprise, including methodologies, team organization structures and roles, COTS
(commercial off the shelf) development principles, looking into the leading practices that should be adopted for developing in the new application landscape.
The task defines the different development tools that will be used and the means of classifying development effort using these tools.
ACTIVITY
Back to Top
WORK PRODUCT
Development Framework - The Development Framework documents the development process for developing in the new application landscape.
Back to Top
TASK STEPS
1 Define the organizational structure for the teams
undertaking the development.
Organization Structure The Organization Structure describes the governance structure, the project
management and development streams.
2 Define the roles and responsibilities. Roles and
Responsibilities
The Roles and Responsibilities defines the roles and their responsibilities.
3 Define situations where it is and is not applicable to use
development partners and the processes involved.
Development Partners This component defines the criteria for the use of development partners.
4 Define the principles for COTS implementations, if
applicable.
COTS Implementation
Principles
The COTS Implementation Principles define the configurations, extensions,
modifications, localizations and interfaces and identifies which are and are not to
be supported by the development team(s).
5 Identify information on development leading practices to
which you will need to adhere.
Development Leading
Practices
The Development Leading Practices identifies any leading practices to be
followed.
6 Define the development tools to be used. Development Tools For the scope of the software to be implemented, the Development Tools identify
the appropriate software development tools.
7 Define the development complexities so that the
categorization of these is common to all parties, even
though the actual metrics may vary.
Development
Complexities
The Development Complexities defines the complexities for the development
tools identified in Step 6.
8 Define the methodologies to be used for the different
types of configuration and software development.
Configuration and
Software
Development
Methodologies
This component lists and provides the necessary detail of the various
methodologies to be used for the different types of configuration and
development.
9 Define the approach to unit testing and any tools that
are to be used.
Unit Testing The Unit Testing component define the approach to unit testing and any tools that
are to be used and for which aspects of the implementation.
10 Define the approach to software configuration
management.
Software
Configuration
Management
The Software Configuration Management defines the strategy and any tools to be
used for software configuration management.
11 Identify the training paths for client staff involved in
development.
Training Paths This component provides the training path needs for any client staff involved in
software configuration or custom development.
Back to Top
APPROACH
Typically, the need to perform this task as part of Envision is when the client is adopting new technology and needs to be informed of new ways of working that will affect
existing staff, their training and organization. This is particularly important where any ongoing development activity will be performed by client staff. The new way of
working and the use of new software may call for additional costs in training staff as well as organizational change.
Organization Structure
Describe the governance structure, the project management and development streams.
Define the roles and their responsibilities. Typically such roles includes: program manager, project manager, governance program manager, governance authority,
enterprise architect, team leader, technical expert, analyst/designer, developer, tester. This may need to be supplemented by: functional consultants, business
authorities, process leads, testing manager and solution architect.
A typical set of roles and responsibilities for a major program is:
Group
Role Responsibilities
Project Management
Program Manager
Manage all developments in the program.
Manage the individual development team project managers.
Report to the wider program board.

Project Manager
Manage the individual development streams.
Prioritize the work of the development stream.
Report progress back to the Program project manager.
Governance and
Compliance
Governance Program Manager
Define the governance procedures and processes.
Define the governance compliance reporting procedures.
Define the Quality Assurance standards.
Manage the Governance and quality assurance team.
Governance Authority
Apply the Governance principles across the development streams.
QA the designs and code deliverables.
Provide advice and guidance to development teams on development approach and principles.
Define the high-level enterprise architectures.
Assure sponsorship of the enterprise architecture by key business stakeholders.
Guard that individual projects comply to the enterprise architecture (or provide exemptions from
doing so).
Identify issues with the current state architecture and initiate improvements of that architecture.
Development Stream Team Leader
Manage the individual development streams.
Report progress back to the development project management.
Schedule and Resource non-core development team members as required in the development
project plan.
Quality of all team deliverables.
Provide Technical advice and guidance to the development team.
Technical Expert
Provide advice and guidance to the design and development teams.
Develop the system test scripts.
Review the developed functional and technical design documents.
Review the delivered programs.
Analyst / Designer
Investigate the detailed requirements.
Verify the functional requirements and designs.
Develop the technical design specifications.
Develop the program unit test scripts.
Review the unit test results.
Developer
Develop the programs.
Develop the program installation scripts.
Execute and document the technical unit test scripts.
Tester
Execute and document the functional tests scripts.
Functional Functional Consultants
Document the functional requirements for the developments.
Provide advice and guidance to the development streams.
Assist the development streams with setup, configuration and test case scenarios.
Specify functional test scripts.
Business Authority
Verify that the developed code meets the business requirements.
Provide advice and guidance to the functional consultants and development streams.
Process Leads
Review the functional test scripts.
Provide advice and guidance to the development streams.
Verify the functional testing of the developed code.
Solution Architect
Review of approach and fit with overall solution.
Testing Testing Manager
Management of system and integration testing activities.
Use of Development Partners
Where applicable, define the criteria for the use of development partners, e.g., offshore resources, and the process that needs to put in place for the interface between the
parties. This may call for additional effort in the development of specifications to a greater level of detail than for local resources and the need for an acceptance process
for software developed in this way prior to any testing.
Definition of Principles for COTS Implementations
Define the the configurations, extensions, modifications, localizations and interfaces and identify which are and are not to be supported by the development team(s).
Leading Practices
Identify leading practices to be followed.
Development Tools
For the scope of the software to be implemented, identify the appropriate software development tools. For major ERP implementations with associated development
activities, this may encompass a range of tools.
Development Complexities
Define the complexities for the development tools identified. It is not the metrics themselves that are defined but the means by which a new/ modification or a form/report/
workflow is categorized. For example, a new form of medium complexity might be defined as Single or multiple block (2-3) with up to 20 columns. Significant functional
logic - edits, calculations, flexfield validations, totals , Subtotals - No Tab control. 1 level master Detail. Such commonality of understanding is needed in the development
of effort estimates.
Development Methodologies
List and provide the necessary detail of the methodologies to be used for the different types of configuration and development. This may need to encompass: ERP
configuration, custom development and business intelligence.
Unit Test Tools
Define the approach to unit testing and any tools that are to be used and for which aspects of the implementation.
Software Configuration Management
Define the strategy and any tools to be used for software configuration management. The client may have already mandated these but if not, they will need to be defined.
The use of third-party tools for testing and configuration management may have cost implications that need to be identified in advance. If they are mandated by the client,
the assumption that the client is responsible for any licensing may need to be added.
Developer Training
Determine the training path needs for any client staff involved in software configuration or custom development.
The identification of training required for client staff involved in software development may also require quantification in order to derive a cost.
Back to Top
Enterprise Architect Set the standards and guidelines regarding reuse/buy/make policies, choice of implementation technologies, implementation
methodologies, and implementation governance policies.
100
Back to Top
PREREQUISITES
Prerequisite Usage
(EA.030)
The Current Enterprise Architecture identifies the architectural landscape in which the Development Framework has to fit and
identifies specific functional and technical domains that have to be supported by the Development Framework.
Current Enterprise Software
Development Process (EA.095)
If existing, the Current Enterprise Software Development Process identifies the gaps and improvements that are required to create
the targeted Development Framework.
(EA.120)
The work product provides the Information Architecture that has to be supported by the Development Framework.
(EA.120)
The work product provides the Technology Architecture that has to be supported by the Development Framework.
Applications Architecture
(EA.140)
The work product provides the Applications Architecture that has to be supported by the Development Framework.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Development Framework is used in the following ways:
as input to any Organizational Change Management activity that addresses changes to the client's IT department
as input to the client's IT organization for the development of internal staff costs for projects
Distribute the Development Framework as follows:
to the organizations responsible for the implementation phases in determining cost of custom-development elements
to the implementing company's Organizational Change Management consultants
to the enterprise IT staff
Back to Top
QUALITY CRITERIA
Back to Top
EA.210 - MAINTAIN ENTERPRISE ARCHITECTURE MODELS
During this task, you maintain the architecture models in pace with any changes that impact the models. The architecture models will provide input to the projects
performed in the enterprise. Therefore, it is important that these remain up-to-date throughout the enterprise lifecycle. Projects that are performed may impact the
models, so you must make certain that this information is fed back to the models. In other words, this task is not about changing the Enterprise Architecture, but restricted
to updating the architectural models to keep them up-to-date with the as-is Enterprise Architecture.
If the intent is to make major changes to the architectural models, for example, to model a desired future state through a defined roadmap, then you should use the
specific tasks for that purpose as follows:
EA.110 Develop Future State Architecture
EA.120 Develop Information Architecture
EA.130 Develop Technology Architecture
EA.140 Develop Applications Architecture
EA.150 Define Transitional Architectures
ACTIVITY
Back to Top
WORK PRODUCT
Maintained Enterprise Architectural Models - The Maintained Enterprise Architectural Models is a set of up-to-date architectural models.
Back to Top
TASK STEPS
1 Provide Enterprise Architecture Models to projects. None
2 Provide Enterprise Architecture Models assistance to
projects.
None
3 Extract Enterprise Architecture Model impacts from
projects.
None
4 Maintain Enterprise Architecture Models. Maintained Enterprise Architecture
Models
This component is an up-to-date version of the Enterprise
Architectural Models.
5 Feed updated models into repository. None
Back to Top
APPROACH
Provide Enterprise Architecture Models to Projects
Ensure that every project that starts within the Enterprise obtain the relevant Enterprise Architecture Models.
Provide Enterprise Architecture Models Assistance to Projects
Provide assistance to technical architecture staff in projects related to the Enterprise Architecture Models.
Extract Enterprise Architecture Model Impacts from Projects
Review project architecture models, and verify against enterprise models. Point out inconsistencies. If the inconsistencies are valid, ensure that the Enterprise Models are
updated when required.
Maintain Enterprise Architectural Models
Maintain any changes required to the Enterprise Architectural Models. This may be due to project impacts (see above), or may be a result of enterprise-level activities.
Feed Updated Models into Repository
Ensure that any new or updated models are fed into the Maintained Repository of Artifacts (IP.080).
Back to Top
Solution Architect Identify changes needed and apply changes to existing enterprise architecture models. The type of solution architect engaged
(Information, Technical, Application) depends on the domain captured by the models. Submit updated architectural models for
inclusion in a repository or other type of enterprise archive.
100
Client Enterprise Architect Assist the solution architect as appropriate. *
Back to Top
PREREQUISITES
Prerequisite Usage
Future State Enterprise Architecture (EA.110) The initial version is maintained as a baseline. Thereafter, updates of the architecture should be maintained.
Information Architecture (EA.120) The initial version is maintained as a baseline. Thereafter, updates of the architecture should be maintained.
Technology Architecture (EA.130) The initial version is maintained as a baseline. Thereafter, updates of the architecture should be maintained.
Applications Architecture (EA.140) The initial version is maintained as a baseline. Thereafter, updates of the architecture should be maintained.
Transitional Architectures (EA.150) The initial version is maintained as a baseline. Thereafter, updates of the architecture should be maintained.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
[IP] IT PORTFOLIO MANAGEMENT
IT Portfolio Management covers a holistic view of the overall IT strategy of the enterprise. Its main purpose is to ensure that IT projects are aligned with the corporate
strategy by maximizing the investment in IT projects while minimizing the risks. The criteria that are used should be derived from the business objectives that have been
identified during Business Requirements Modeling. The key work product of the IT Portfolio Management process is an IT Portfolio Plan in which only projects are
identified that comply with these criteria.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Back to Top
Initiate Phase
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.060 Develop IT Portfolio Plan IT Portfolio Plan
IP.070 Execute and Maintain IT Portfolio and Programs Maintained IT Portfolio and Programs
IP.080 Maintain Repository of Artifacts Maintained Repository of Artifacts
Back to Top
OBJECTIVES
Back to Top
KEY WORK PRODUCTS
Back to Top
Back to Top
Back to Top
IP.010 - INVENTORY PROJECTS
During this task, you inventory all projects and programs that currently are in progress or are planned, and perform a short inventory on each. You also inventory
dependencies between the various projects. For each engagement, this is a singly instantiated task. Depending on the scope of the enterprise under discussion, the set
to consider may be limited to the major projects and programs, all projects and programs in the enterprise under discussion, or something in between. This is all
organized into an IT Project Portfolio.
ACTIVITY
Back to Top
WORK PRODUCT
IT Project Portfolio - The IT Project Portfolio contains all the current projects and programs in the enterprise under discussion that are either ongoing or planned. For
each project or program, it also contains the business objectives the programs and projects support and it may include the estimated costs. When an Enterprise
Repository has been established, the work product is the population of that repository with the inventoried projects and their relationships to other IT assets in the
repository.
The tooling choice for the Enterprise Repository is determined in the Governance task, Define Policy Implementation Tooling (GV.060). Typically, the implementation of
an Enterprise Repository is done in the context of an Implement project. The implementation of the organization's procedures and policies governing the Enterprise
Repository are established and maintained in the Governance task, Implement Governance (GV.100). If an Enterprise Repository is being used, both of these
Governance tasks would have preceded this task, Inventory Projects.
Back to Top
TASK STEPS
1 Inventory current
programs.
Program
Overview
This component lists all the programs that are ongoing or planned. For each program, a purpose and description is provided.
2 Inventory current
projects
Project
Portfolio
This component lists all the projects that are ongoing or planned according to the Projects Meta Model (GV.092).
3 Document costs
and objectives.
Project
Portfolio
Add the estimated costs (initial, actual and estimate to complete) and the business benefits to expect to each project in the Project
Portfolio.
4 Identify overlap
and redundancy.
Overlap This component shows the overlap or redundancy between programs or projects, if any. For each identified overlap/redundancy, it
should include what kind of overlap it concerns, and the level of redundancy (is it a 100% overlap, or only partial).
Back to Top
APPROACH
In its final state, the IT Project Portfolio should list all the current programs and projects and be updated on a regular base to reflect the current state. Depending on the
scope, you might want to limit the initial version of this work product to an identification of the programs and projects that are relevant for the engagement at hand. For
example, in the case of a program in which the scope is to integrate some existing systems, the initial version might be limited to programs and projects that are related to
these systems. Sources that you can use to perform this task are project calendars the client (CIO, client program managers, Systems Support) might already have
available.
During some successive engagement, the IT Project Portfolio may be populated with a new set of programs and projects. However, this task is not meant to cover the
ongoing maintenance of programs and projects in the IT Project Portfolio as that should be covered by an (implicit or explicit) last step of the task creating or maintaining
those programs or projects.
Inventory Current Programs
Perform an inventory to identify any IT programs relevant for the IT Project Portfolio. For each program, at a minimum document the name, purpose, start data, (planned)
end date, and the (business) owner of the program. Whenever available and allowed to be disclosed in this document, also capture the available budget for the program.
Also document dependencies between the programs.
Inventory Current Projects
For each program, perform an inventory to identify the IT projects within that program. Among other things, for each project document the name, goals, what will be
developed as a result of the project, and for what stakeholders this will be relevant. Document dependencies between the programs/projects and existing systems and
services. Also document the scarce resources needed for projects. This is important to identify any bottleneck in the overall-staffing.
Document Costs and Objectives
As far as available and allowed to be disclosed in this document, also capture the initial budget, the actual budget used so far and the estimate to complete. Having a
clear view on overruns of projects can provide valuable information to stakeholders such as CIOs and enterprise architects. Document the business benefits of each
project and the estimated return on investments (ROI). In case disclosure in this document is inappropriate, consider creating a separate document that lists all the
projects by name with costs and objectives.
You may choose to also identify any overlap and redundancy between current projects as well as overruns. This could be important information to determine improvement
options. However, this could be a fairly time-consuming task so make sure it is within scope of the engagement.
Back to Top
Back to Top
Enterprise Architect Interview stakeholders to compile the IT Project Portfolio. 100
Client Enterprise Architect Interview stakeholders to compile the IT Project Portfolio. *
Client CIO Provide an overview of the programs and projects. *
Client CTO Provide an overview of the programs and projects. *
Client Project Managers Provide detailed information about the projects. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business
Strategy
(BA.010)
Review the Business Strategy for business objectives for which current projects may be addressing.
Projects Meta
Model (GV.092)
Use the Projects Meta Model to determine what information about the projects and programs should be captured and how to classify these projects
and programs.
Governance
Implementation
(GV.100)
inventoried projects and their relationships to other IT assets. In addition, ensure that the inventoried projects and their relationships are
Back to Top
TEMPLATES AND TOOLS
IP-010_IT_PROJECT_PORTFOLIO.DOC MS WORD - Use this template to create an IT Project Portfolio when a physical Enterprise Repository is not available.
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The IT Project Portfolio is used in the following ways:
to identify relevant programs or projects that may be used to achieve a desired future state through a roadmap
as an overview of all current and planned project and programs to understand the level of required resources over time
as an input to verify whether current or planned project and programs are supporting the current business vision, objectives and strategy
Distribute the IT Project Portfolio as follows:
to senior management representing both IT and the business
to the Envision engagement or roadmap leaders
Back to Top
QUALITY CRITERIA
Have at least the following attributes been defined for each program: name, purpose, start date, (planned) end date, (business) owner?
Have at least the following attributes been defined for each project: name, goal, description, stakeholders and dependencies?
Has the information for all programs and projects been captured at the same level of detail?
Back to Top
IP.012 - INVENTORY APPLICATIONS
During this task, you inventory all applications that currently are in use, pending to go live, or have been identified to be developed and perform a short inventory on each.
For each engagement, this is a singly instantiated task. Depending on the scope of the enterprise under discussion, the set to consider may be limited to the major
applications, all applications in the enterprise under discussion, or something in between. This is all organized into an IT Application Portfolio.
ACTIVITY
Back to Top
WORK PRODUCT
IT Application Portfolio - The IT Application Portfolio contains the current applications in the enterprise that are either ongoing or planned. When an Enterprise
Repository has been established, the work product is the population of that repository with the inventoried applications and their relationships to other IT assets in the
repository.
Governance tasks would have preceded this task, Inventory Applications.
Back to Top
TASK STEPS
1 Identify
current
applications.
IT
Application
Portfolio
This IT Application Portfolio consists of a table for each application that is ongoing or planned according to the Applications Meta Data
Description (GV.094).
2 Identify
planned
releases.
IT
Application
Portfolio
Complete the Release Information section of each table for each application with the any planned new releases. When these new
releases are not the result of a project identified in the IT Project Portfolio (IP.010), a brief description of the new release is included.
3 Document
costs.
IT
Application
Portfolio
Complete the Costs section of each table for each application. This adds financial metrics of the application to the identified applications
(for example, the initial development costs, the average maintenance and operational costs for the last five years, the current year and
planned for next year).
4 Identify
overlap.
Overlap and
Redundancy
The Overlap and Redundancy identifies the functional overlap the existing applications have, as well as redundancy concerning the
information they store.
Back to Top
APPROACH
In its final state, the IT Application Portfolio should list all the current and planned applications. Depending on the scope, you might want to limit an initial version of this
work product to an identification of the applications that are relevant for that engagement. For example, in the case of program where the scope is to integrate some
existing systems, an initial version might be limited to effected systems.
During some successive engagement, the IT Application Portfolio may be populated with a new set of applications. However, this task is not meant to cover the ongoing
maintenance of applications in the IT Application Portfolio as that should be covered by an (implicit or explicit) last step of the task defining or maintaining those
applications.
Identify Current Applications
Perform an inventory to identify all commercial of-the-shelf (COTS) and custom built applications relevant for the IT Application Portfolio. For each application, the
minimum to document will be the name, description, and major technologies used as well as dependencies between the applications. Information about the major
technologies used provides important input to stakeholders, such as architects in order to determine a strategy to move from a as-is technical environment to a to-be
targeted technical environment.
Identify New Releases
Identify all new releases that are planned for the application by version number and planned date. When the new release is not the result of a project previously identified
in the IT Project Portfolio (IP.010), include a brief description of the new release (for example, which major bugs are fixed, which major new features are added).
Document Costs and Objectives
Whenever available and allowed to be disclosed in this document, capture the available financial metrics of the applications. Financial metrics can provide very important
information for discovering application improvement opportunities.
You may choose to also identify any overlap and redundancy between current applications. This could be important information to determine optimization options.
Especially for an engagement involving integration, it provides valuable input to determine which applications potentially could provide which functionality or information,
or where data-synchronization might be appropriate. However, this could be a fairly time-consuming task, so be certain not to go beyond the scope of the engagement.
Back to Top
Enterprise Architect Interview stakeholders to compile the IT Applications Portfolio. 80
Solution Architect
Assist in interviewing stakeholders to compile IT Applications portfolio. Preferably, this should be done by a solution architect
that specializes in Application Architecture.
20
Client Enterprise Architect Assist in interviewing stakeholders to compile IT Applications portfolio. *
Client CIO Assist in interviewing stakeholders to compile IT Applications portfolio. *
Client System Expert Assist in interviewing stakeholders to compile IT Applications portfolio. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy
(BA.010)
Review the Business Strategy for business objectives that current projects may be addressing.
Applications Meta
Data Description
(GV.094)
Use the Applications Meta Data Description to determine what information about the applications should be captured and how to classify these
applications.
Governance
Implementation
(GV.100)
inventoried applications and their relationships to other IT assets. In addition, ensure that the inventoried applications and their relationships are
Back to Top
TEMPLATES AND TOOLS
IP-
012_IT_APPLICATION_PORTFOLIO.DOC
MS WORD - Use this template to create an IT Application Portfolio when a physical Enterprise Repository is not
available.
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The IT Application Portfolio is used in the following ways:
by enterprise architects to determine next steps
by the client organization to confirm the understanding of the applications within the current architecture of their enterprise
Distribute the IT Application Portfolio as follows:
to the individual application owners, both business and technical for validation
to operations specialists within the client organization
Back to Top
QUALITY CRITERIA
Have at least the following attributes been defined for each application: name, description, major technologies used and dependencies?
Has the information for all applications been captured at the same level of detail?
Back to Top
IP.014 - INVENTORY SERVICES
During this task, you inventory the services of the enterprise. The type of services you inventory depends on the engagement. For example, for a SOA effort, you will
inventory SOA services, while for a cloud effort, you will inventory cloud services (which may or may not be SOA services).
When you inventory services, this includes existing services, services pending to go live and services that have been identified to be developed. This is all organized into
an initial Service Portfolio. For each engagement, this is a singly instantiated task. The type of services that you inventory typically will be limited to those that have an
enterprise-level reuse potential, and are within the scope of the engagement at hand. The result is a repository of information about the services, including but not limited
to:
the service contract of the service
the nature of the service provider
technical constraints
usage fees
security issues
contact persons
In short, this should be a complete single-source of information about service policies, service level agreement (SLA) contracts, design and implementation artifacts and
interdependencies that govern service usage.
The majority of this task is written in the context of SOA services.
In some cases, SOA service repositories are merged with service registries. However, do not confuse the design-time focus of a Service Portfolio with a runtime focus on
services in production. This task concerns the design-time focus.
Service Portfolio Management is related to other portfolio management disciplines. IT Project Portfolio Management allows enterprises to collaboratively propose, fund,
prioritize, plan, align and control their IT initiatives to achieve their objectives while understanding the impact of changing or adding initiatives to their portfolios. IT
Application Portfolio Management utilizes operational metrics to measure the benefits and continual investment into each application and how it aligns and supports the
business. The following show the interaction of Service Portfolio management and traditional Portfolio Management disciplines.
#TOP #TOP
Service Portfolio Management enables an enterprise to manage a long-term Service Portfolio that defines the right set of services and enables when, where, and how
they are used. Service Portfolio Management allows enterprises to:
Identify and classify a coherent portfolio of Services, rather than an ad hoc approach to identifying services that leads to service sprawl (that is, duplicate services,
no service reuse, etc.).
Define and utilize a service candidate selection framework to analyze whether a service candidate is realized as a shared service or not. (Refer to SOA Service
Identification and Discovery technique for more details.)
Define the schedule in which service candidates and service modifications are realized. The prioritization approach should cater for effort, complexity, resource
availability, and the delivery date, driven by the needs of the projects requiring the services.
Define a service sourcing and ownership strategy, based on build vs. buy vs. borrow (SaaS) strategies.
Define a set of processes and techniques that continuously measures SOA investments against business goals (for example, cost reduction, IT simplification,
process agility). The intent is to maximize the return and alignment of SOA assets and investments to the enterprise, while making timely investments in SOA, and
effectively managing change.
This task is only applicable when service-oriented architecture (SOA) is involved in some form.
ACTIVITY
Back to Top
WORK PRODUCT
Service Portfolio - The initial version of the Service Portfolio created in this task, contains an overview of those services that have an enterprise-level reuse potential.
When an Enterprise Repository has been established, the work product is the population of that repository with the inventoried services and their relationships to other IT
assets in the repository. If the organization does not have a physical Enterprise Repository, capture the inventoried services and their relationships to other IT assets in
the OUM Service Portfolio template.
Governance tasks would have preceded this task, Inventory Services.
Back to Top
TASK STEPS
1 Inventory current
services.
Service Catalog The Service Catalog is populated with a listing of the existing services according to the Services Meta Data
Description (GV.096).
2 Inventory planned
services.
Service Catalog The Service Catalog is populated with a listing of the planned services.
3 Identify overlaps. Overlap and
Redundancy
This component shows the overlap or redundancy between services as well as identifies services that are not in
use.
Back to Top
APPROACH
This task is most effectively executed when it is limited to an inventory of those service that have a potential reuse for the engagement at hand, or that are likely to be
reused in project that have been identified. What should be prevented is an inventory for the sake of inventory, as that can easily become a time-consuming task with a
result that has a relatively limited value.
In its final state, the Service Portfolio should list current and planned services that have an enterprise-level reuse potential. In the case of a scope that limited to
implementing one or more business processes that use some known systems or to integrating some existing systems, an initial version might be limited to those systems.
During some successive engagement, the Service Portfolio may be populated in this task with a new set of services. However, this task is not meant to cover the ongoing
addition or maintenance of services as that should be covered by an (implicit or explicit) last step of the task discovering, or maintaining those services.
Inventory Current Services
Perform an inventory to identify all existing services relevant for the initial Service Portfolio. Candidates are (reusable) business services like Get Customer Profile, or
Create Customer Order, but it may also involve utility-like services such as, Get Product Catalog, Get Countries or Get Postal Codes. Individual programs, projects,
IT departments, etc., may have a listing of existing services. Also existing systems documentation may list the services that those systems can deliver.
Services that have no reuse potential, such as services that have been created to do point-to-point integration and offer very specific functionality to do just that, normally
can be safely ignored. When more than one version of the service exists, the most recent version is probably the only one relevant for the inventory. Fine-grained
services that are used to compose course-grained services, normally can also be ignored for now, as they will typically be inventoried within the scope of a project that
has a need for them, in the Service Portfolio - Candidate Services (Implement task, RA.025).
Capture the services, and document these following the Services Meta Data Description (GV.096), if available. If no such repository meta data description exists yet,
capture the minimal set of information for each service including the name, a description of its contract, and the interface provided. In case of web services that have
(reachable) WSDL, capture that WSDL so that later it can be analyzed in more detail. Also classify services according to the taxonomy that has been determined in the
Services Meta Data Description (GV.096).
Inventory Planned Services
Identify all services that are planned, and document these following the Services Meta Data Description (GV.096), if available.
You may choose to also identify any overlap and redundancy between services. This could be important information to determine optimization options. As this can be a
fairly time-consuming task, be certain not to go beyond the scope of the engagement.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Interview stakeholders to compile the IT Services Portfolio. 100
Client Enterprise Architect Assist in interviewing stakeholders to compile IT Services portfolio. *
Client CTO Assist in interviewing stakeholders to compile IT Services portfolio. *
Client System Expert Assist in interviewing stakeholders to compile IT Services portfolio. *
Client Project Managers Assist in interviewing stakeholders to compile IT Services portfolio. *
Back to Top
PREREQUISITES
Prerequisite Usage
Services Meta
Data Description
(GV.096)
Use the Services Meta Data Description to determine what information about the services should be captured and how to classify these services.
Governance
Implementation
(GV.100)
inventoried services and their relationships to other IT assets. In addition, ensure that the inventoried services and their relationships are
Back to Top
TECHNIQUES
Technique Comments
SOA Service Identification and Discovery Use this technique to understand the justification process for a service through the analysis of benefits and risks.
Back to Top
TEMPLATES AND TOOLS
IP-014_SERVICE_PORTFOLIO.XLS MS EXCEL - Use this template to create a Service Portfolio when a physical Enterprise Repository is not available.
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Service Portfolio is used in the following ways:
by enterprise architects to review the available Service Portfolio
by anyone that has a need to discover existing services for reuse
Distribute the Service Portfolio as follows:
to a central place that is available to anyone who has a need for service discovery
Back to Top
QUALITY CRITERIA
Have the services been captured according to the Services Meta Data Description?
Have all the services been identified and named in such a way that they are easily identified for reuse?
Have the services been designated with service owners, and have service consumers been considered?
Are the services at the proper level of granularity?
Back to Top
IP.015 - CONDUCT PORTFOLIO ANALYSIS
In this task, you create a deeper understanding of the current and planned enterprise technology estate, interdependencies and relationships between products (for
example, from an integration standpoint). This information is gathered based on detailed understanding of in flight and planned business/IT projects that will have a clear
impact on the existing technology landscape.
This approach supports gaining a better understanding of the changing architectural landscape both in terms of identifying possible future opportunities as well as being
better able to describe the integration landscape in a heterogeneous technology environment.
A portfolio consists of all the elements of the IT landscape (networks, platforms, applications and technology components) and must capture the interdependencies
between them. However, gathering the various dependencies and details to build a complete and holistic perspective may be difficult especially in large enterprises. In
some cases, the portfolio analysis may only be applicable to a formal request for information (RFI) or invitation to tender (ITT) process and may be restricted to the
elements of the solution being proposed.
The portfolio analysis can therefore be performed on subsets of components or processes linked to the overall enterprise architecture, such as, application capabilities or
integration depending on where the portfolio analysis is most applicable.
ACTIVITY
Back to Top
WORK PRODUCT
Portfolio Analysis Report - The Portfolio Analysis Report reflects a deeper understanding of the current and planned enterprise technology estate, interdependencies
and relationships between products.
Back to Top
TASK STEPS
1 Review details of existing IT
architecture.
None
2 Review the enterprise's existing or
planned business / IT projects and
programs.
None
3 Compile Project / Program list. List of
Projects
The List of Projects contains all "in flight" and planned projects and programs.
4 Review existing plans for technology
changes.
Impact
Assessment
The Impact Assessment provides the potential impact on any future technology components that are relevant
for the enterprise.
5 Review impact of proposal. Proposal
Impact
Assessment
The Proposal Impact Assessment provides the potential impact of the introduction of the proposed technology
components on the enterprise's existing / planned IT architecture/infrastructure.
6 Compile Portfolio Analysis Report. Portfolio
Analysis
Report
The Portfolio Analysis Report combines the List of Projects and the Impact Assessment and reflects a deeper
understanding of the current and planned enterprise technology estate, interdependencies and relationships
between products.
Back to Top
APPROACH
Review Existing IT Architecture
Review the existing enterprise IT architecture (Current Enterprise Architecture, EA.030) to better understand any possible impact on business/IT changes.
Review Existing and Planned Projects and Programs
Work directly with the relevant person in the organization that is able to identify all the key in flight and planned Business/IT projects (captured in the IT Project Portfolio,
IP.010) and programs that may be impacted by the introduction of new technology components
Compose Project / Program List
Compile a table/list containing all in flight and planned projects and programs that would impact the existing IT architecture / infrastructure.
Review Existing Plans for Technology Changes
Compile a high-level assessment detailing the impact on the existing IT architecture / infrastructure (captured in the Current Architectural Challenges, EA.050) through the
introduction of new technology related projects and programs. This should provide sufficient information to understand the potential impact on any future technology
components that a company may be proposing.
Review Impact of Oracle Proposal
Compile a high-level assessment detailing the impact on the existing/changing IT environment based on the introduction of the proposed (new) technology components.
Compile Final Report
Compile the final report containing the List of Projects and the overall IT impact assessment.
Back to Top
Enterprise Architect Review current state and planned/underway projects to determine strengths/weaknesses. Analyze impact of planned offerings. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Current Enterprise
If the Current Enterprise Architecture is available, use it to get a better understanding of the current technology state.
Current Architectural
Challenges (EA.050)
If the Current Architectural Challenges is available, use it to identify improvement options by positioning specific products.
IT Project Portfolio
(IP.010)
The IT Project Portfolio contains all the current projects and programs in the enterprise that are either ongoing or planned. For each project or
program, it also contains the estimated costs and the business objectives the programs and projects support.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Portfolio Analysis Report is used in the following ways:
to provide an understanding of current and planned technologies, and products, and how they relate to each other
to assist in the selection of actual technologies or products to obtain/purchase
Distribute the Portfolio Analysis Report as follows:
to individuals responsible for the technology estate at the enterprise (CIA, CTO, client enterprise architect, etc.)
to business stakeholders to understand the IT portfolio required for supporting the business objectives
Back to Top
QUALITY CRITERIA
Does the List of Projects contain both current and planned projects and programs?
Does the Portfolio Analysis Report document what kind of plans there are for technology changes?
Does it include an impact assessment for each technology change documented, related both to:
existing or planned IT architecture and infrastructure
existing or planned programs and projects
Back to Top
IP.020 - ANALYZE SERVICES
During this task, you further analyze each new service candidate and service version listed in the Service Portfolio - Candidate Services document (BA.070). The type of
analysis that is to be performed depends on the type of engagement (for example, a SOA engagement or a cloud engagement).
At the end of this task, you will update the Service Portfolio - Candidate Services to contain the list of service candidates proposed to realize the engagement
requirements driven by the Business Strategy. These could be candidates for completely new services, candidates to consume services or candidates to modify known
services. This should be communicated to the business as it shows how the Service Portfolio must be changed to reflect the Business Strategy. In addition, the proposals
will be registered in the Enterprise Repository to allow for others working within the enterprise to discover the proposed candidates.
The proposed services should be reviewed by business and service portfolio management to decide upon realization or use as part of a project or as a project of its own.
Services proposed at this stage are typically strategic to the enterprise but it may be too early for specifying the detailed requirements and needs in the case of
implementation. Depending on the type of service, they may stay in a proposed state for some time until the first project arises having a concrete need to consume or
implement the service. When that happens, the service candidate may be refined with more concrete requirements and need to be analyzed again.
ACTIVITY
Back to Top
WORK PRODUCT
Service Portfolio - Proposed Services - The Proposed Services is the set of services proposed to support the Business Strategy to be created, and when applicable, a
set of existing services that the business will use is proposed. When an Enterprise Repository has been established, the portfolio within the repository needs to be
updated creating new services or service versions. If the organization does not have a physical Enterprise Repository, and SOA services have been captured in the
Service Portfolio template (IP.014), use the Service Portfolio template (IP.014) to capture the Proposed Services in the same format as the Service Portfolio. This will
allow you to easily merge a proposed service into the Service Portfolio at a later point, as appropriate.
Back to Top
TASK STEPS
1 Perform classification. Classified Service
Candidates
The Classified Service Candidates shows how the service candidates are classified against the classifications
defined by Service Portfolio management.
2 Determine evaluation and
weighting criteria.
Evaluation and
Weighting Criteria
The Evaluation and Weighting Criteria explains the method and criteria against which each service candidate will
be analyzed.
3 Evaluate candidates. Evaluated Service
Candidates
The Evaluated Service Candidates lists all the service candidates with their evaluation result and reasoning.
4 Determine dependencies. Service
Dependencies
The Service Dependencies describes existing service dependencies.
5 Assign ownership. Service
Candidates
Ownership
The Service Candidates Ownership documents the Identified owner for each service candidate.
6 Update Service Portfolio -
Candidate Services
(BA.070). (Optional)
Updated Service
Portfolio -
Candidate
Services
The Updated Service Portfolio - Candidate Services is the updated work product from BA.070 including the results
of the analysis.
7 Perform service
traceability.
Service
Traceability
The Service Traceability shows the traceability from requirements (use cases, business processes, or
supplemental requirements) to the service(s) that should implement the requirements. Optionally, you can use the
MoSCoW List-Excel (RD.045) for traceability of requirements.
8 Review and prioritize final
services with enterprise.
Prioritized Final
Services
The Prioritized Final Services shows the services that have been chosen to be implemented, including a priority
that represents the need and urgency for the service.
Back to Top
APPROACH
Perform Classification
Perform a first categorization of all the Candidate Services (BA.070) you have identified. Typically, you use predefined categories determined by the enterprise Service
Portfolio Management Process. If a service cannot be classified against only one category, this may be an indication of a service boundary violation. For each boundary
violated, you should split the service to fit. As a consequence, one candidate at this level can result in multiple service candidates being proposed with finer granularity.
Determine Evaluation and Weighting Criteria
Before starting the evaluation of the service candidates, you need to determine exactly what should be evaluated. For example for a SOA engagement, you typically
evaluate whether or not you want to develop or reuse a candidate, while for a cloud engagement, you may evaluate whether a service candidate is appropriate for the
cloud, and if so whether it best should be deployed in a private or public cloud. Determine the evaluation criteria and what kind of weighting criteria you need to use.
If the service candidates are SOA service candidates, consider evaluating for the following benefits:
benefit arising due to the planned scope of the service candidate, e.g., Will it be available on multi enterprise or on intra application level?
level of reusability of the service candidate, i.e., probability of additional consumers having an interest on the service candidate
level of business agility created by the service candidate
level of enterprise compliance created by the service candidate
enablement to create the service candidate from already existing assets
Also if the service candidates are SOA service candidates, consider the following risks factors:
availability of the skill set to create the functionality in sharable style
need and availability of additional tools or technology needed to create a sharable service
impact on all projects incurred by realizing a shared service
difficulty to realize all requirements as a shared service
See the SOA Service Identification and Discovery technique for more guidance in the justification process for SOA services.
If the service candidates are cloud service candidates, consider evaluating against the following (among others):
What are the availability requirements?
What are the latency requirements?
Are there any government regulations to consider?
What are the security requirements?
and other similar questions
There are various Cloud Candidate Selection Tools available. Visit www.oracle.com/technetwork for the most current information on this topic.
The whole purpose of the analysis is to maximize the business benefit ensuring that you best meet the requirements, and minimize the risks for the organization ensuring
that the enterprise will not lose competitive advantage as a result of the change. Therefore, the criteria should reflect this, independent of the types of services to be
analyzed.
Evaluate Candidates
For each new candidate, evaluate against all the relevant criteria as defined in the previous step. When you have evaluated a service candidate against the criteria, you
should be able to determine the potential business value of moving forward with the candidate. You should also be able to determine the potential risks, and whether the
risks can be mitigated. Be especially mindful about risks where the enterprise could lose competitive advantage. For each service candidate, summarize the potential
business benefits, and the known risks, including potential risk mitigation strategies.
Determine Dependencies
Investigate any dependencies for the service. For a SOA composite service candidate, what are the dependencies to other services? Do they exist and can they be
reused, or do they also need to be developed? For a cloud service candidate, what affinities exist to other components, and what level of affinity exist?
Assign Ownership
Each service candidate should have an assigned owner. Typically, services should have a business owner. Try to identify an owner from business side. This owner will
then be able to initiate a project for implementation or can include the candidate in the scope of a broader project. If no business owner can be identified, then the
candidates are owned by enterprise architects.
Update the Service Portfolio - Candidate Services
Depending on the governance approach chosen, you may need to document the results of your analysis. Specifically, if you want to be able to provide your results to the
business, or if you need to initiate a review of your results, a document summarizing the results and mapping specific Service Portfolio elements to the Business Strategy
can be very helpful.
Update the Service Portfolio - Candidate Services (BA.070) according to your analysis work. Consider including a protocol on the justification you have done.
When an Enterprise Repository is being used, the Service Portfolio should be considered a part of (a chapter if you will) of the repository. Each new service candidate
proposed should have an entry in the Enterprise Repository with status of 'proposed'. It should include all dependency links to models, requirements, etc. that apply.
For each service that needs to be changed for reuse, create a new version of the already existing service asset. Also, update the links to the new model versions and
requirement versions. For each service intended to be used, regardless of the type of services, or if the service is to be used or is to be created as a new service, you
should create a usage agreement asset in the Enterprise Repository in the 'proposed' state and link it to the service asset. Add a link to all consuming parts as well, that
is, another service or an application. In case an application becomes a consumer of the service, you amy need to create a new asset for the application if it does not
already exist.
By adding new assets, the portfolio directions discovered by the analysis of the Business Strategy will get visible to Service Portfolio management and projects. Review
the IT Asset Management technique for further details on the meta data descriptions for services and usage agreements.
If the organization does not have a physical Enterprise Repository, and therefore services have been captured in another format, then capture the Proposed Services in
the same format as the Service Portfolio. This will allow you to easily merge a proposed service into the Service Portfolio at a later point, as appropriate.
Perform Service Traceability
All services should be traceable to specific high-level use cases, business processes, or supplemental requirements, unless these have not been captured as such. But
when they are, linking them to those requirements provides useful information for later, in particular for test preparation. During the task to identify candidate services
(BA.070), you should already have documented the origin of the candidate (i.e., the source of discovery). Services that were originally discovered via captured
requirements, policies, domain models, etc. should be revisited to see whether they can be mapped to use cases or to a high-level business process. If, so add the
corresponding dependency to the Enterprise Repository.
Review and Prioritize Final Services with Client
The client should verify the list of services and prioritize it based on highest business value, technical criteria or criticality. The prioritizing can be done using the MoSCoW
principle.
Back to Top
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Analyze Candidate Services and select services to be included in implementation proposal. 50
Solution Architect
Assist the enterprise architect with defining services with the right business value, granularity and reusability. 50
Client Enterprise Architect Analyze Candidate Services and select services to be included in implementation proposal. *
Back to Top
PREREQUISITES
Prerequisite Usage
Service Portfolio
(IP.014)

Service Portfolio -
Candidate Services
(BA.070)
These are the services that are being analyzed in this task.
Services Meta Data
Description (GV.096)
Use the business taxonomy defined in the Services Meta Data Description to analyze service boundaries and register the assets.
Governance
Implementation
(GV.100)
proposed services and their relationships to other IT assets. In addition, ensure that the final proposed services and their relationships are
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique to access information on the meta data descriptions for services and usage agreements.
SOA Service
Identification and
Discovery
Use this technique to understand the approach to discover, reuse and identify new SOA service candidates with the help of models and
requirement documents. It includes a description of the justification process to analyze benefits and risks.
Analysis
Use this technique to understand how to define SOA services to the right level of granularity.
SOA Service Lifecycle Use this technique to understand the SOA service lifecycle and the enterprise repository assets used.
Back to Top
TEMPLATES AND TOOLS
IP-
MS EXCEL - If the organization does not have a physical Enterprise Repository, and SOA services have been captured in the
Service Portfolio template (IP.014), use the Service Portfolio template (IP.014) to capture the Proposed Services in the same format
as the Service Portfolio. This will allow you to easily merge a proposed service into the Service Portfolio at a later point, as
appropriate.
Tool Comments
Resources
Repository.
Back to Top
The Service Portfolio Proposed Services is used in the following ways:
to understand which services are proposed to best support the Business Strategy
to provide enough understanding of the proposed services, to be able to make a final decision for implementation
Distribute the Service Portfolio Proposed Services as follows:
to requirements stakeholders to review the suggested services supporting the requirements
to (candidate) service owners for review
to enterprise decision makers (individuals or boards) for final decision
Back to Top
QUALITY CRITERIA
Have all service candidates been classified against the classifications defined by the enterprise Service Portfolio Management Process?
Has the evaluation and weighting criteria for the analysis been documented or referenced?
Has each service candidate been evaluated and weighted consistently against the same evaluation and weighting criteria?
Have any dependencies been documented for each service candidate?
Has an owner been assigned to each service candidate?
Have the service candidates been included or updated in Enterprise Repository, if used?
Is there a clear trace from requirement to each service candidate?
Has it been documented which of the service candidates are proposed for actual implementation?
Have the proposed services been prioritized?
Back to Top
IP.025 - POPULATE SERVICES REPOSITORY
During this task, a design-time services repository is used to store the current and candidate services. This serves as a database of information about the services
including:
technical constraints
usage fees
security issues
contact persons
In short, this should be a complete single source of truth about service policies, SLAs contracts, design and implementation artifacts and interdependencies that govern
service usage.
There is a recent trend towards service repositories merging with service registries. Even then, there is still distinction between each in terms of design time versus
runtime focus.
ACTIVITY
Back to Top
WORK PRODUCT
Populated Services Repository - The Populated Services Repository is a design-time repository that stores all the candidate services, and contains useful information
about each service. When an Enterprise Repository has been established, the work product is the result of populating the repository with the services and documenting
their relationships to other IT assets in the repository.
Governance task would have preceded this task, Populate Services Repository.
Back to Top
TASK STEPS
1 Decide on
Services
Repository.
Services
Repository
Decision
This Services Repository Decision documents the decision regarding which Services Repository should be used in the enterprise. It also
includes the requirements for a Services Repository, and the Services Repository products that were considered as candidates. It
provides a mapping between the requirements and the candidate products, leading up to the reasoning behind the chosen Services
Repository Product that was selected.
2 Define
Service
Templates
and
format.
Service
Templates
Service Templates are only relevant when there is no current use of a Services Repository, and therefore no Service Templates exist. A
Service Template describes the type of information and format with which to document services in the Services Repository. There should
be one Service Template for each type of service, e.g., one for SOA services, one for each type of cloud service relevant for the
enterprise (e.g., one for Iaas, one for Paas, and one for Saas), and so on. Therefore, there are multiple Service Templates.
Refer to the IT Asset Management technique for guidance on which properties to capture for services in order to include them on the
Service Templates.
3 Format
current
and
candidate
services.
Described
Services
The Described Services contains all current and candidate services described using the Service Template.
4 Populate
the
Services
Populated
Services
Repository
The Populated Services Repository is the actual design-time repository including all the current and candidate services described using
the relevant Service Template.
Repository.
Back to Top
APPROACH
Decide on Services Repository
The first thing you should do is to investigate whether a Services Repository is already in use within the enterprise, and if so, determine the status of that Services
Repository. It is strongly recommended that a single Services Repository is used by the entire enterprise, including all the individual projects. This allows for easier
identification of services available for reuse.
Determine the requirements for a Services Repository. If a Services Repository is in use, verify whether it is appropriate and sufficiently supports the requirements, both
regarding content and tooling. Otherwise, verify what kind of products meets these requirements.
Define Service Templates and Format
This step is only relevant when there is no Services Repository in use within the enterprise, or when no proper Service Template has been defined or where there is one
(or more) but it is lacking. Keep in ming, there should be one Service Template for each type of service, for example, one for SOA services, one for each type of cloud
service relevant for the enterprise (for example, one for Iaas, one for Paas, and one for Saas), and so on. That is, there are multiple Service Templates. Determine what
kind of information, and in what format you want or need to store this kind of information for each candidate service. It is recommended that you include an example on
how the template is used, so that it is easier for anyone to understand what each section in the template means.
Refer to the IT Asset Management technique for guidance on which properties to capture for services in order to include them on the Service Templates.
Format Current and Candidate Services
Transform each current and candidate service into the relevant Service Template determined in the previous step. This ensures a consistent description of each
candidate service.
Populate Services Repository
Populate the Services Repository with all the services described in the relevant Service Template format.
In some cases, there may be one or more project- or program-specific Service Catalogs outside of the repository that use a proprietary format. Some services might not
be documented at all. Another source of information is the documentation of the existing systems, which sometimes includes available services, such as COTS
applications. In every case, the services should be migrated to the proper enterprise Services Repository using the correct Service Template format
Back to Top
Enterprise Architect Submit initial list of Candidate Services into repository. 30
Solution Architect
Migrate existing Services Portfolio into repository. 70
Back to Top
PREREQUISITES
Prerequisite Usage
Services Meta Data Description
(GV.096)
Use the Services Meta Data Description to determine what information about the services should be captured and how to classify
the services.
Executed Policy Implementation
Process (GV.100)
If an Enterprise Repository is in use, the Governance Implementation describes the tooling and related procedures and policies to
populate and maintain the Services Repository within the repository.
Back to Top
TECHNIQUES
Technique Comments
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Populated Services Repository is used in the following ways:
to document the all types of services relevant for the enterprise (for example, SOA and cloud services)
to facilitate reuse of services
Distribute the Populated Services Repository as follows:
to Envision engagement resources as needed to prepare work products
to support the rollout of service-oriented architecture and cloud architecture
Back to Top
QUALITY CRITERIA
Have all the services been identified and named in such a way that they will be easily identified for reuse?
Have the services been designated with service owners, and service consumers in mind?
Have all the services been described following the Service Template relevant for the type of service?
Back to Top
IP.030 - ANALYZE BUSINESS RULES
During this task, you analyze each candidate business rule (BA.080) to determine the nature of the rule. First, perform a categorization of the rules, and then determine
which rules are volatile and which are fairly static. Next, document how each rule traces back to the initial requirement. Depending on how you do requirements analysis,
this could be through the appropriate use cases, business processes, domain model or directly to the functional or supplemental requirements. At this point, you also
verify the identified rules with the organization.
ACTIVITY
Back to Top
WORK PRODUCT
Business Rules Analysis - The Business Rules Analysis documents what kind of business rule categories are used to categorize the rules and how each rule has been
categorized. The analysis also includes traceability for each rule to the appropriate use, case, business process or supplemental requirement.
Back to Top
TASK STEPS
1 Determine rule category types. Rule Category
Types
The Rule Category Types is a list of all the rule categories with a name and a description explaining
the characteristics for the category.
2 Perform an initial categorization and
determine the volatility of the rules.
Categorized
Business Rules
The Categorized Business Rules contains a list of all the business rules within a category. This
includes an initial evaluation of the expected frequency of change for each rule.
3 Perform rule traceability and define rule
sets.
Business Rules
Traceability
Business Rule Sets
The Business Rules Traceability shows how each business rule can be traced back to the original
requirement.
The Business Rules Sets lists all the business rules grouped into logically related related rule sets
or groups.
4 Quality check the list of business rules. Business Rules
Analysis
The Business Rules Analysis is comprised of all the previous components, quality checked and
ready for review.
5 Review business rules with enterprise
stakeholders.
Business Rules
Analysis (updated)
The Business Rules Analysis is updated as a result of the stakeholder review.
Back to Top
APPROACH
Determine Rule Category Types
You should first determine how you should categorize the rules. Business rules can be categorized in many ways. Some examples are:
Example 1
Structural - Structural rules are rules that define the static aspects of a business.
Behavioral - Behavioral rules are rules that are concerned with the execution of tasks in a business.
Managerial - Managerial rules are rules that an organization uses to adjust or correct performance.
Example 2
Data-Related Rules - Data-related rules are rules that restrict the state of the data at a stable point (invariants), must hold true before a particular change of the
data can take place (preconditions), or concern derivations.
Workflow/Process-Related Rules - Workflow/process-related rules are recognizable as decisions with guards in activity diagrams/business process diagram and
determine the flow.
Security Rules - Security rules restrict access to the resources a system offers to specific users or user groups. A distinction can be made between security rules
that define if a user (group) is authorized to execute a specific action (Are you authorized to start this use case?) or define (generic) restrictions on the use of data
(Are you authorized to view, insert, update, delete this data?).
Note that as this task is an analysis task and not a design task, this categorization abstracts from any implementation. Performing such a categorization should help to:
Improve the quality regarding completeness and consistency of the set of business rules.
Ease the communication with the user community.
Determine a strategy for business rule implementation.
The size and scope of the rule set and the background of the rules team dictates the nature of the rule categories that are used. If the team has a high involvement with
business analysts and users, then a more business oriented set of categories would be implied, such as Example 1 above. If the rules team consists of technical staff
with development experience, a classification similar to that of the Business Rules Group might be used. If the rules team consists of cross-functional line of business
users, then something similar to Example 2 might be used.
Perform an Initial Categorization and Determine the Volatility of the Rules
Perform a first categorization of all the business rules you have identified so far following the categories determine in the previous step. Some business rules are valid
during a specific point in time. For example, there might be business rules that the business wants to enforce, however, existing data might not comply with those rules.
For rules like this, the validity should be carefully considered. Or there might be a requirement to define rules that are related to some sales campaign, and therefore are
only valid during that campaign. If this is the case, then this is a strong indication that in the future the nature of existing rules might change, or even that new rules might
emerge. Another example would be (security) rules that restrict access to sales data during the quiet period of an enterprise before the results are published.
It also may be required that some business rules should be implemented in a flexible way, allowing to change one or more arguments used in a rule. For example, when
reviewing a business rule such as No employee may earn more than $10.000, it might already be obvious that you should not hard-code the amount in the business
rule, but anticipate on using some parameter mechanism instead.
During the review of the business rules, the time span during which the rules are valid should be considered. If there is any reason to expect a rule not to be valid
indefinitely, it should be noted. Discuss any requirement to be able to change the nature of business rules over time or to add new business rules in the future. In
addition, make notes where you expect that flexibility might be needed by using a parameter mechanism.
Business rules that are valid only during a limited period in time, for which the nature might change over time, or that require a parameter mechanism, are volatile rules.
Typically, this volatility is initiated by changes in the way the enterprise does its business or by changes in the environment in which the enterprise operates (such as
legal or regulatory changes).
Volatile rules are likely candidates to be implemented using a business rules engine such as Oracle Business Rules, while static business rules are often better
implemented in the code of an application. Therefore, in order to know where and how a business rule is best implemented, it is important to determine whether a rule
has a volatile nature, and if so, how volatile is it.
Perform Rule Traceability and Define Rules Sets
In the end all rules should be traceable to either a specific use case, a supplemental requirement, or one or more specific classes from the Analysis Class Diagram [which
is part of the Enterprise Domain Model (BA.050)]. Rules that were originally discovered via requirements, policies, domain models, etc. should not be revisited to map to
use cases. Rules that are used by logically-related use cases can be grouped into rule sets (for example "High risk auto loan" rule set, "Credit scoring" rule set) to
assist/complement subsequent use case testing.
Quality Check the List of Business Rules
When you have completed a first list of business rules (which evolves over time), you should quality check the business rules. Ensure that each rule is described
consistently and in a consistent type of language. Business rules should be documented in a way that is understandable to the business reader, as owners of the
requirements need to be able to verify the rules.
Review Business Rules with Stakeholders
Enterprise stakeholders should verify the business rules and initially indicate the criticality of each rule, whether or not it should be implemented and prioritize it,
preferably using the MoSCoW principle. Keep in mind that rules sometimes may prove to be too strict. For example, constraints may have been identified to exclude
situations that in principle are unwanted, but in practice may occur nevertheless and therefore must be dealt with. You could call it the exceptions to the rule. Therefore,
you must ask the enterprise whether they can think of any such exceptions. If there are, this may either lead to a decision that the rule will not be implemented, or that the
exceptions should be implemented as part of the rule itself.
Back to Top
Enterprise Architect Analyze Candidate Rules into categories. 70
Solution Architect
Determine rule enforcement strategy per category. 30
Client Enterprise Architect Analyze Candidate Rules into categories. *
Back to Top
PREREQUISITES
Prerequisite Usage
Candidate Business Rules (BA.080) The Candidate Business Rules are being analyzed in this task.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Business Process Analysis Suite
http://www.oracle.com/technologies/soa/bpa-
suite.html
Oracle Business Process Analysis Suite's component Business Process Architect contains the Business
Rules Designer for capturing business rules and associating them with use cases.
Back to Top
The Business Rules Analysis is used in the following ways:
to understand which business rules are required to support the requirements supporting the Business Strategy
to provide enough understanding of the business rules, to be able to make a final decision for implementation
Distribute the Business Rules Analysis as follows:
to requirements stakeholders to review the analyzed business rules supporting the requirements
to decision makers (individuals or boards) for final decision
Back to Top
QUALITY CRITERIA
Has a set of business rules categories been described, including criteria on how business rules should be categorized?
Has each business rule been categorized following the set of business rules categories?
Is there a clear trace between all the business rules and originating requirements?
Have the business rules been reviewed by enterprise stakeholders?
Back to Top
IP.040 - IDENTIFY CANDIDATE PROJECTS
During this task, you gather information about candidate projects from the other Envision processes, such as the Enterprise Architecture and Enterprise Business
Analysis processes, in order to make a total list of candidate projects. Each of these processes provide input to this task, either as candidate projects on their own, or as
parts that should go into one or more candidate projects. Once you have determined the projects and organized them into the Candidate Projects, you will prioritize
between those projects in the following task, Prioritized Projects (IP.050) and the IT Portfolio Plan (IP.060).
ACTIVITY
Back to Top
WORK PRODUCT
Candidate Projects - The Candidate Projects shows a list of all identified projects including goals and objectives, with reference to the Business Strategy elements that
should be accomplished as a result of the execution of the projects. When an Enterprise Repository has been established, the work product is the population of that
repository with the candidate projects and their relationships to other IT assets in the repository.
Back to Top
TASK STEPS
1 Describe the common goal(d). Common Goal The Common Goal is a description of the common goal(s) for which you identify projects.
2 Determine candidate projects. Candidate
Projects
This component lists all the candidate projects that have been identified. For each a project a purpose
and description is provided, the user communities impacted and it describes from where the candidate
project was originated or what it should solve/improve.
3 Determine goals for each candidate
project.
Project Goals
and
Objectives
This component describe for each project the goals and the objectives that should be accomplished partly
or fully through the project. There should be a direct reference to the Business Strategy.
4 Determine dependencies between
candidate projects, and between
candidate and existing projects.
Project
Dependencies
The Project Dependencies describe all relevant dependencies between both the candidate projects and
existing projects. It also describe the nature of the dependency. This is useful information for planning
the order in which the projects should be executed.
5 Verify candidate projects. Updated
Candidate
Projects
This component is the updated list of Candidate Projects. The initial list has been quality checked.
Back to Top
APPROACH
Describe Common Goal
Before starting the identification of candidate projects, you need to have a clear understanding of the common goal or goals that are to be achieved by executing the
candidate projects. These goals are typically related to a desired future situation that typically reflects the Business Strategy.
Determine Candidate Projects
In most situations, candidate projects have already been separated out as part of the work done in the other processes. If a Future State Transition Plan (ER.170) has
been created, a number of candidate projects may have been identified. For the Enterprise Business Analysis process, you may have identified candidate services and
rules, processes and improvement options that all together already have been factored into other candidate projects. Gather all this information, and create an initial list
with candidate projects that are required to achieve the documented common goal(s).
Review also the MoSCoW Improvement List (ER.130) to see the kind of improvements that have been identified so far. The list contains all identified improvement
options, the process improvement options, architectural improvement options, candidate services, candidate rules and identified high-level use cases. Verify whether the
candidate projects cover the most important improvement options.
#TOP #TOP
Determine Goals for Each Candidate Project
For each candidate project, determine the goals. Review the objectives in the Business Strategy (BA.010) and determine which objectives should be achieved or
supported through the project. There must be at least one strategic objective that you can tie to the project, or else the project is not a good candidate and should be left
out. This should not be a complete benefit analysis. The latter is done in the task ER.110, Perform Benefit Analysis. Lastly, determine the urgency for each candidate
project.
For each candidate project, determine the dependencies with other candidate projects, or existing projects or systems. Determine the type of dependency (interface,
data, architectural, etc), and vitality (for example, could the project/the eventual system still work without the dependent project/system?).
Verify Candidate Projects
Review the list of candidate projects. Review whether there are overlaps between the projects, and determine whether some of the candidate projects better are
combined into a single project. Review again the MoSCoW Improvement List (ER.130) to see the kind of improvements that have been identified so far. Verify whether
the candidate projects cover the most important improvement options.
Back to Top
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Develop Candidate Projects from the business goals and portfolio analysis results. 100
Client Enterprise Architect Develop Candidate Projects from the business goals and portfolio analysis results. *
Client CIO *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to determine the goals for the identified candidate
projects.
Business Models and other work products developed in the Execute Discovery
activities.
Use these work products to identify candidate projects.
Future State Transition Plan (ER.170) Use this plan to identify candidate projects.
Back to Top
TECHNIQUES
Technique Comments
Functional Project Identification This technique helps determine what projects will get the most out of a SOA approach.
Back to Top
TEMPLATES AND TOOLS
IP-040_CANDIDATE_PROJECTS.DOC MS WORD
Tool Comments
Overview
Back to Top
The Candidate Projects is used in the following ways:
to show which projects are candidates for the realization of the Business Strategy, as documented in the common goals
to show the purpose of each of the candidates, and how they are dependent on each other
as input to determine the priorities of the projects to create a IT portfolio Plan or roadmap to achieve a desired future state
as input to the priorities of the projects within a roadmap to achieve a desired future state that supports the Business Strategy
Distribute the Candidate Projects as follows:
to enterprise senior management for review and to ensure completeness
Back to Top
QUALITY CRITERIA
Have the common goals to be achieved through the execution of the candidate projects been described?
Are all challenges and requirements included in the identified projects?
Have the goals for each of the project candidates been documented?
Have the relationships and dependencies of the project candidates been documented?
Back to Top
IP.050 - PRIORITIZE PROJECTS
During this task, you review all the candidate projects from the Candidate Projects (IP.040) to determine which candidates will be prioritized and planned for execution.
The priorities of the projects will change throughout the enterprise lifecycle, dependent on the strategies and available funds. In most situations, there are more candidate
projects than available funds. Therefore, it is important that the highest priority is given to those projects that align best with the Business Strategy (BA.010) and provide
the highest business benefits (or are prerequisites for such projects). For those projects that appear to have the highest benefit / risk ratio, approval for execution by C-
level management should be obtained.
ACTIVITY
IP.050.1
IP.050.2
Back to Top
WORK PRODUCT
Prioritized Projects - The Prioritized Projects shows all the newly identified and approved projects to be executed. The IT Project Portfolio should be updated as
appropriate.
Back to Top
TASK STEPS
1 Determine relative importance between
candidate projects, and previously
identified not-yet-started projects.
Candidate
Projects
Prioritization
The Candidate Projects Prioritization is a prioritized listing of all projects.
2 Determine projects to be proposed. Proposed
Projects
The Proposed Projects is a listing of those projects that have the highest benefit / risk ratio that fits within
the available budget and timeline.
3 Obtain approval for final Proposed
Projects.
Prioritized
Projects
The Prioritized Projects is the final list of those projects that have the highest benefit / risk ratio that fits
within the available budget and timeline that have been approved by C-level management for execution.
These projects will be added to the IT Project Portfolio.
Back to Top
APPROACH
The task is normally done iteratively together with the Perform Benefit Analysis (ER.110) and Identify and Mitigate Future State Risks (ER.120) tasks.
First, an analysis is done of the scoring or the projects with respect to the aspects taken into consideration (next to a scoring regarding benefits and risks, also a scoring
regarding aspects such as, technical complexity and functional effort may have been done). Then those projects are selected that appear to have the highest benefit / risk
ratio (for any other final scoring that may be in use). This analysis is then used to revisit the analysis of those projects. After that the benefit analysis (ER.110) and risk
analysis (ER.120) is completed for the projects with the highest benefit /risk ration. If there are surprises discovered during that process, the analysis and scoring needs
to be revisited.
If enterprise functional modeling or process modeling (BA.040) has been carried out, it is possible to prioritize business processes or functions as a source of prioritized
project candidates. Refer to the Functional Project Identification technique for more details.
Determine Relative Importance Between Candidate Projects and Previously Identified
Not-Yet-Started Projects
Include previously identified projects (if any) that have not yet started in the list of candidate projects. Ensure that there is no duplication of projects. Determine the
relative importance between the candidate projects. Various techniques can be used to do this, but you will need to review the Business Strategy (BA.010), the objectives
and goals in general, and the identified benefits and risks for each project specifically as an input to this step. You also need to review the dependencies. That is, It is
more efficient to start with projects that provide a foundation for subsequent projects. The required foundation may be architectural, for example, where one project is
dedicated to develop a required reference architecture. The required foundation may be procedural, where one project is dedicated to implement a new development
process or technique with the purpose of mitigating risk through lessons learned as part of a smaller, low risk project.
The chosen technique will also depend on how many candidate projects there are to consider. If the list is short, you should be able to decide by discussing each
candidate project. Either way, it is often useful to gather the stakeholders and decision makers in a workshop to make the process as efficient as possible.
For each prioritized project, document the justification or reasoning behind the given priority.
Determine Projects to be Proposed
For the candidate projects that have been analyzed, determine the set of those projects that appear to have the highest benefit / risk ratio, that fits within the budget and
timeframe available. Briefly revisit the analysis and scoring of those project and inter-project dependencies that may exist. In case there are surprises, the initial scoring
and analysis may need to be adjusted until a set of projects could be identified that appears to be feasible to be realized. This set of projects will be proposed for
execution to C-level management during the task, Develop IT Project Portfolio Plan (IP.060).
Obtain Project Approval
If you have performed the previous steps using a workshop, then preferably the decision makers should take part in the workshop. If that is the case, then the approval
should already be there when the workshop is completed. However, this must be communicated up-front.
If it is not determined as part of a workshop, then prepare the list of Proposed Projects, including the objectives and benefits for each project, the proposed timeline for
execution, and the reasoning for the benefit / risk ratio. If the decision makers have not been involved in the process, then a presentation should be done by, or together
with the key stakeholder that took part of the prioritization process, for the executive management.
The result of this step should be the final list of Prioritized Projects that should be updated to the IT Project Portfolio by adding those projects to the portfolio. During the
task, Develop IT Project Portfolio Plan (IP.060) a more thorough planning and risk analysis of those projects will be performed.
Back to Top
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Analyze priorities and dependencies of Candidate Projects and develop proposal. Obtain approval from client. 100
Client Enterprise Architect Analyze priorities and dependencies of Candidate Projects *
Client CIO *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to determine the priorities.
Candidate Projects (IP.040) The Candidate Projects lists the projects that are being prioritized in this task.
Benefit Analysis (ER.110) Use the identified benefits for each project to determine priority.
Future State Risks (ER.120) Use the identified risks for each project to determine priority.
Back to Top
TECHNIQUES
Technique Comments
Functional Project
Identification
If enterprise functional modeling or enterprise process modeling (BA.040) has been carried out, it is possible to prioritize business processes
or functions as a source of prioritized project candidates.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Prioritized Projects is used in the following ways:
to show which of the project candidates are the most important
as input to determine the final IT portfolio Plan or roadmap to achieve a desired future state
Distribute the Prioritized Projects as follows:
to enterprise C-level management for a final decision
Back to Top
QUALITY CRITERIA
Has each project received a priority, and has the reasoning for the given priority been documented?
Has the list been approved by C-level management?
Back to Top
IP.060 - DEVELOP IT PORTFOLIO PLAN
During this task, you develop the actual plan for when programs and projects should be executed. When doing this, consider the overall risks for the enterprise, but also
the main individual project risks.
The IT Portfolio Plan is typically created or updated at the end of an Envision (roadmap) engagement, to identify the schedule and the required projects that should
implement the elements decided upon as part of the enablement of specific business goals into capabilities (initiative). The IT Portfolio Plan includes the schedule for the
entire initiative, but it also includes any other projects or programs that are not necessarily related to the initiative at hand. The plan is a high-level schedule that illustrates
the ordering and dependency relationships between program-level activities, and projects for the enterprise as a whole.
ACTIVITY
Back to Top
WORK PRODUCT
IT Portfolio Plan - The IT Portfolio Plan shows all the programs and projects that should be performed within a given timeframe, including the dates on which they expect
to start and when they expect to be completed. If projects are planned as part of the program, the relationship to the program is also shown. If they exist, dependencies
between the projects are also shown.
Back to Top
TASK STEPS
1 Determine planning horizon. Planning Horizon The Planning Horizon describes the period for which the programs and projects should be planned, how
they should be phased, and the intervals into which each phase should be divided (e.g., weeks, quarters,
half years, etc.).
2 Review the Projects MoSCoW
List and IT Portfolio Risk
Analysis.
Programs and Projects This component shows which programs and projects should be planned for within a given Planning
Horizon.
3 Determine dependencies
between projects.
Dependencies (as part
of the IT Portfolio
Plan)
The Dependencies component shows dependencies between individual projects, between programs, and
between projects and programs and describes the nature of each dependency.
4 Determine project durations. Project Durations (as
part of the IT Portfolio
Plan)
The Project Durations shows the estimated length of time for each project.
5 Plan programs and projects. IT Portfolio Plan The IT Portfolio Plan contains all the programs and projects shown in a timeline with planned execution
periods.
Back to Top
APPROACH
The creation of the IT Portfolio Plan is an ongoing activity as it should show an up-to-date picture of all the programs and projects that are executed or planned for within a
given timeframe for the enterprise as a whole. When there is a current IT Portfolio Plan in place, then any new programs or projects that are planned, (for example as a
result of an Envision roadmap engagement) will impact the current IT Portfolio Plan. The current IT Portfolio Plan needs to be updated to incorporate the new programs
and projects in the overall enterprise IT Portfolio Plan. The new programs or projects may impact current programs and projects, and therefore, it is important to review
the plan as a whole to ensure that no programs or projects will interfere or contradict each other. Also, resources and budgets must be considered to ensure that the
schedule is feasible.
This task may also be executed at the end of a roadmap engagement, to identify the existing or new programs or projects that may be needed to realize the roadmap. If
this is the goal of the exercise, the end result would be an IT Portfolio Plan showing only the programs or projects related to the roadmap. However, this must still be
aligned with the overall IT Portfolio Plan to ensure that the plan is feasible.
The task steps in the table above are typically executed iteratively.
Determine Planning Horizon
When you start IT Portfolio planning, you need to have an idea of the planning horizon, that is, for how long in the future you will plan. You often see a planning horizon of
about three years, but sometimes as much as a 5, 7 or even 10 years horizon. The planning horizon must reflect the business goals and objectives. There is no point in
planning for a 10 year horizon in a volatile business area. In this case, a 2 or 3 year horizon would probably be best. Avoid using a planning horizon of under 2 years as
this makes it more difficult to support the overarching business strategies.
When you have to determine a proper planning horizon that fits the business, determine the intervals or level of details you will provide in the plan. This will typically differ
throughout the planning horizon. For example, in a 3 years planning horizon, you may want to plan on a monthly basis for the first 6 months, on a quarterly basis for the
next 12 months, and then use a 6 months intervals for the remainder. If you have a planning horizon going further, you may show yearly intervals after three years, and
on a 10 years horizon, even use 2 or 3 years intervals near the end. There is no point to spend a lot of effort thinking about detailed planning too far ahead, because it will
change. The point of long term planning should be limited to visualizing the future intentions, and the details will be added as timeframes get closer.
Review the Projects MoSCoW List and IT Portfolio Risk Analysis
Once you have determined the planning horizon, first ensure that you have identified all current and planned programs and projects required to implement the business
vision, strategies and goals, and the supporting IT vision, strategies and goals. Next, review the project charter. A well defined project charter should be defined before
the project is put into the IT Portfolio. The project charter should be a clear statement of the scope, objectives, stakeholders and participants in a project.
Review the Prioritized Projects (IP.050) and the associated Future State Risks (ER.120) to determine the logical order in which the projects should be performed. For
each project, consider how likely the risks are to occur, and the possible impact to the business if a risk should occur. Is there a risk mitigation option? Preferably, do not
plan more than a single high-risk project at the same time. If multiple projects are run in parallel try to prevent critical dependencies between them, and try to keep a good
mixture of risky and less risky projects.
Determine Dependencies Between Projects
Determine the dependencies between projects, and the nature of these dependencies. This has partly been done when the candidate projects were identified. Verify that
result against the review above.
If there are strong dependencies between projects, and they are not included in a program, consider whether it makes sense to include them in a common program with
common goals. This provides better visibility of related projects. Also, in this way, you may prevent duplicate work (the same or similar work to be done in multiple
projects) by doing the work all at once at the program level. This also helps avoid inconsistencies in how the work is done. Be careful combining projects into larger
projects, as you usually will have greater agility and less risk with multiple smaller projects run as part of a single program.
Determine Project Durations
Calculate a rough estimate of the project durations. The more details you know about the projects, the easier it is to calculate such an estimate. The purpose of estimating
at this point in time is to have an idea of the expected duration of each project . Obviously, it is more important to properly estimate the projects that scheduled to start
first. You should have some idea of which programs' activities and projects are the most urgent to the enterprise.
The first estimate is typically very rough, and when you have had a chance to review the planning, you will gather more details about the project charter and high-level
requirements of the projects in order to provide a more accurate estimate.
To provide a more reliable and consistent estimate on programs and projects on a longer term, it is recommended that you build an experience base where you provide
some characteristics to which you can compare new projects or initiatives, in order to provide the first rough estimate. This would also provide useful information in the
prioritization (IP.050) of projects or initiatives.
Plan Programs and Projects
Plan program activities and projects over the planning horizon based on the analysis and project durations. Determine whether the projects should be planned
individually, or whether they should be planned as part of a program. For larger projects (with a foreseen lifecycle of more than a year), consider splitting them into
smaller projects performed as part of a larger program.
Consider dependencies between projects. For one-way dependencies, ensure that the dependent project is performed second. For two-ways dependencies, consider
whether the projects can be run in parallel, or whether they can be split into smaller parts where the dependencies can be made one-way. To limit the risks, do not plan
projects dependent on each other too tight after each other to prevent a delay of one resulting in a delay of the other.
Start with planning the programs first. Determine when they should start, and when they should be completed. Program-level activities should be visualized as part of the
program, as projects may depend on the completion of certain program activities. Therefore, projects that are expected to leverage the outcomes of the program-level
activities should not seriously begin until the program-level activities are completed. However, some overlap may be allowed since the earliest phases of a project (for
example, Inception) can usually commence before the program-level activities are completed.
The end date of a program is constrained by the completion of the program-level activities and the projects included in the program. The end date for the project is
determined by effort, complexity, resource availability, and budget. Sometimes the end dates are mandated by business needs. In either case, the end date for the
project is put into the schedule.
This kind of detail can be provided in a relatively short-term planning horizon. The further into the future, the more likely it is that you will use business or IT needs to
determine the end date of a program/project and the duration based on a high-level estimate to determine the start date. Set the start date to as soon as possible to
provide for some contingency, especially when the required delivery dates are fixed.
At this point, any resource constraints need to be incorporated into the short term schedule. Dependent on the situation, this may typically be important for the first year,
but less important on a longer term, as the situation may change over time. This may require that start dates are delayed or durations are increased. Alternatively,
changes must be made in the resource situation, for example, through hiring or procurement.
If you need some early wins to support a certain roadmap, it may be useful to plan for some early projects with relatively short duration and effort. Subsequent projects
can then be devoted to more complex efforts that could take years to complete.
Back to Top
Cloud Roadmap
SOA Roadmap
Supplemental Guide.
BPM Roadmap
Supplemental Guide.
Back to Top
Enterprise Architect Review and provide input for the IT Portfolio Plan. 40
Project Manager Plan the approved projects in the IT Portfolio Plan 60
Client Stakeholders Provide input into existing projects and future projects. This may include members of the enterprises PMO, C-Level
Executives, heads of the various lines of business, IT management, etc.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Prioritized Projects (IP.050) This list contains the projects as they should be performed over time.
Benefit Analysis (ER.110) Use this work product to determine the portfolio plan.
Future State Risks (ER.120) The Future State Risks contains identified risks and risk mitigation for the portfolio.
Future State Transition Plan (ER.170) This work product contains the plan on how to move from the current architecture to the future, desired architecture.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The IT Portfolio Plan is used in the following ways:
to provide visibility within the enterprise on which programs and projects are planned and when they should be completed
to ensure that the programs and projects within the enterprise support the business and IT visions, goals and strategies
as input to determine where new initiatives, programs, roadmaps or projects may fit into the overall enterprise portfolio
to allow all managers impacted or that have an interest in the plan to visualize how changes in programs and projects may impact other programs or projects
Distribute the IT Portfolio Plan as follows:
to C-level management within the enterprise
to all program and project managers so they can provide any input that might impact the schedule in order for the plan to be adjusted
to all managers affected by the programs or projects
Back to Top
QUALITY CRITERIA
Is the chosen planning horizon relevant for the business?
Is the plan sufficiently detailed for the short term?
Are the projects planned for the short term properly estimated?
Is it clear what the programs or program-level activities are and what the projects are?
Are the dependencies between programs/program-level activities and projects clear?
Are the dependencies between individual projects clear?
Is it clear which projects and program-level activities belong to a given program?
Back to Top
IP.070 - EXECUTE AND MAINTAIN IT PORTFOLIO AND
PROGRAMS
This task is an ongoing task after the IT Portfolio Plan (IP.060) has been produced. The task is performed throughout the lifecycle of the enterprise. During this task, new
programs and projects may be initiated, funding requests may be needed, and the status for the current programs and projects is monitored. At the end of each project,
actuals are collected to verify these against the estimates that were performed at the start of each project. Based on that, the estimating model is verified and improved.
ACTIVITY
Back to Top
WORK PRODUCT
Maintained IT Portfolio and Programs - The Maintained IT Portfolio and Programs is the ongoing IT Portfolio as it emerges throughout the lifecycle of the enterprise. It
contains all candidate programs and projects that are initiated in the enterprise, as well as the ongoing programs and projects. For each project, the estimates are
collected, and at the end verified against the actuals.
Back to Top
TASK STEPS
1 Determine status
reporting and review
strategy.
Status
Reporting
and Review
Strategy
This component explains how the status should be reported for programs and projects, the resources that should be
involved, and the frequency on which it should be reported.
2 Update IT Portfolio Plan. Updated IT
Portfolio
Plan
This is the ongoing, and updated IT Portfolio Plan that was first created during IP.060.
3 Initiate new programs and
projects.
New Project
Proposition
This component is contains a suggestion for a new program or project. It typically contains a reasoning why the project is
proposed, expected benefits, a high-level scope, the timeframe, estimated expected cost, required resources and
possible risks.
4 Start up of new programs
and projects.
None
5 Monitor status for
programs and projects.
Status
Report
This component is a report that shows the status of a certain program or project. It typically contains a status against
schedule, cost, risk and benefit realization.
6 Validate investments
against promised benefits.
None
7 Collect estimates and
actuals and validate and
improve the estimating
model.
Experience
Report
Estimating
Model
The Experience Report shows positive and negative experiences at the end of a project or program, including comments
on how the negative experiences could have been avoided (if possible). It also contains the initial estimates for the
project, compared with the actuals, including explanations for the larges discrepancies on why they differ.
The Estimating Model is the updated estimating tool that the Enterprise uses for estimating programs and projects.
Back to Top
APPROACH
Determine Status Reporting and Review Strategy
Determine the method and schedule on which projects should report on their status, and on what they should report. Ensure that the status reporting points correlate with
the risk mitigation reviews defined in the Future State Risks (ER.110). Also determine the intervals in which the portfolio should be monitored. During these intervals, you
should review the status of each project (Task Step 5), make updates to the IT Portfolio Plan (Task Step 2), review new project and program proposals (that are initiated
as part of Task Step 3) and validate the investments (Task Step 6). As a minimum, this should be done on a quarterly basis. Verify if an update of the IT Portfolio Plan is
necessary at the start as well as at the end of every individual project in the portfolio.
Update IT Portfolio Plan
The IT Portfolio Plan (IP.060) should be updated whenever necessary. New risks may have emerged, or the enterprise market situation might impact how the enterprise
wants to invest its funds. Also experience with finished projects may require an update of the IT Portfolio Plan, especially when the initial budget for the finished project
has significantly been exceeded. Consider the same steps as when you initially created the IT Portfolio Plan.
Initiate New Programs and Projects
New programs or projects may be initiated by anyone at any time during the process. This should be done in the form of a program or project proposal, and should
include benefit and risk analysis. For each proposal you should investigate the business impact and enterprise risks, and suggest a priority. It may result in an update to
the IT Portfolio Plan (Task Step 2).
Start Up of New Programs and Projects
When in the IT Portfolio Plan, a startup is planned for a new program and project, this should be initiated.
Monitor Status for Programs and Projects
At a regular basis each project and program should report their status, and the status of the risks. Dependent on this reporting, determine whether any changes should be
made to the portfolio, or whether any actions should be taken towards the project/program.
Validate Investments Against Promised Benefits
Verify whether the portfolio investments will still provide the benefits, and work towards the identified objectives as initially thought. During status reporting, each
project/program should report on the costs, and the status of the identified benefits and objectives. During the project, this may change due to changed priorities and
focus.
Collect Estimates and Actuals and Validate and Improve Estimating Model
For each project, collect the initial estimates and the actuals when the tasks have been completed. Use this as input to validate the correctness of the estimates. Ask for
factors that may have impacted the actuals, such as the use of lesser-experienced resources than anticipated. If necessary, ensure that the result is fed back to the
people being responsible for the used estimating model.
Back to Top
Enterprise Architect Review and update the IT Portfolio Plan. 20
Project Managers Provide status, estimates and actuals on projects. 80
Back to Top
PREREQUISITES
Prerequisite Usage
Executed Policy Implementation Processes (GV.100.2)
Prioritized Projects (IP.050.2) This list contains the prioritized projects that are to be implemented over time.
Future State Risks (ER.110) The Future State Risks contains identified risks and risk mitigation for the portfolio.
IT Portfolio Plan (IP.060) The IT Portfolio Plan is maintained by this task.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IP.080 - MAINTAIN REPOSITORY OF ARTIFACTS
During this task, you update assets in the Enterprise Repository.
Depending on the defined Governance policies, the repository can be used by both enterprise as well as project-level activities, to store and make updates to IT assets.
During this task, the enterprise repository manager typically has the role of gatekeeper to make sure that updates to the repository comply with the Governance policies.
If a repository tool is used, this Governance can be supported by the tooling. When a repository tool is utilized, the enterprise repository manager can approve or reject
updates, according to the lifecycle of the IT asset. In other situations, a manual process may be used until the enterprise can become more mature in its Governance
process.
The Governance policies can also dictate that the producers of the (changes to) IT assets must provide these assets to the enterprise repository manager. The enterprise
repository manager then reviews the updates and (when approved) applies them to the Enterprise Repository.
This is an ongoing task that is performed as needed.
ACTIVITY
Back to Top
WORK PRODUCT
Maintained Repository of Artifacts - The Maintained Repository of Artifacts consists of new entries or updates to existing entries of the actual data that has been
populated in the Enterprise Repository.
Back to Top
TASK STEPS
1 Maintain Enterprise
Repository content.
Maintained
Repository of
Artifacts
The Maintained Repository of Artifacts consists of the ongoing adding or updating of the data in the Enterprise
Repository.
Note: Depending on the Governance policies defined, this step will either cover adding data about any IT asset by
the enterprise repository manager or only reviewing that data.
Back to Top
APPROACH
Maintain Enterprise Repository Content
Add or review the information about new assets or update existing assets when required. This is an ongoing effort in the lifecycle of the enterprise.
Back to Top
Back to Top
Enterprise Architect Assist the client enterprise repository manager in maintaining the repository of enterprise artifacts as appropriate for the
engagement.
100
Client Enterprise
Repository Manager
Implement the meta models in the repository and specific reports and screen to support the information needs. Maintain the
meta models in the repository and populate it with new data when necessary. Validate new data.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Governance
Implementation
(GV.100)
The actual implementation of the assets in the Enterprise Repository is performed as part of Governance Implementation, that is, the Enterprise
Repository is established and rolled-out. The Governance Implementation also describes how to govern the assets in the Enterprise Repository, that
is the related policies and processes.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Maintained Repository of Artifacts is used in the following ways:
by enterprise stakeholders that wants to be informed about planned or existing IT assets, their interrelationships, owners, etc.
by enterprise stakeholders that perform updates to the Enterprise Repository
Back to Top
QUALITY CRITERIA
Is the existing data in the Enterprise Repository actual and complete?
Have the updates to the content of the Enterprise Repository been done following the established Governance Implementation?
Back to Top
[GV] GOVERNANCE
In the most general sense, governance relates to decisions that define expectations, grant power, or verify performance. Thus, an organization will establish a system of
governance, that is, structures, policies and processes that facilitate the correct running of the organizations affairs.
Structures define the roles and relationships of organizational units and individuals.
Policies define the rules to which those active units must adhere.
Processes ensure that the policies are applied consistently and correctly.
Examples of governance in action is the imposition and monitoring of speed limits on public roads, namely:
A local government unit, acting under a mandate granted to it by the citizens through elections, within a framework established by the national government, decides
that for the purposes of reducing death and injury (a sound principle), vehicles should not exceed a certain speed on a section of road (a policy); the limit is
published (traffic signs), and the public are informed that people infringing the policy will be subject to a sanction.
Another organizational unit, the police, monitor the performance of individuals against the policy (speed limit), using defined processes and standards e.g. random
checks with calibrated speed guns.
Should an individual be found to have exceeded the limit, they are submitted to the judgment of the organizational unit known as the judiciary, and an appropriate
sanction (punishment, fine, imprisonment) is imposed.
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.
TYPES OF GOVERNANCE
In the context in which OUM is likely to be used, there is a number of relevant areas of governance, which are related, but not necessarily in your scope, each of which
has a specific main concern:
Corporate Governance
IT Governance
Architecture Governance (sometime referred to as Enterprise Architecture Governance)
SOA Governance
Project Governance
Data Governance
etc.
There are different views as to the relationships between these various governance disciplines. Some sources cite IT Governance as a part of Corporate Governance,
and the other disciplines being part of IT Governance. These disciplines sometime overlap and are sometimes separated depending on the point of view. For example
ITIL (The IT Infrastructure Library), which is traditionally the most common standard used for IT Governance, does not specifically cover SOA Governance.
Corporate Governance
Corporate Governance relates to the running of the business, the behavior of the company officers, accounting principles, etc. Sarbanes-Oxley is an example of
legislation that specifies some principles for Corporate governance, meaning what controls, reporting standards, etc., a corporation must have in order to operate within
US law. It is unlikely that you and OUM will be used to set up or maintain a Corporate Governance mechanism, although IT can clearly be used to support Corporate
Governance processes, e.g., through reporting. For this reason, Corporate Governance is likely to impose requirements on (enterprise) architecture and specific solutions
in the IT area that normally are dealt with in the Enterprise Business Analysis (Envision), or Requirements Definition (Implement) processes. Corporate Governance
policies necessarily have an impact on other governance areas, in that they provide a context for the entire organization, but do not address the detailed concerns of the
other areas.
IT Governance
IT Governance relates to matching the organizations IT-related strategies and objectives to those of the organization. A well-defined IT Governance process ensures that
the IT investments are aligned with the business strategies throughout the enterprise, and mitigate associated risks. For example, instead of making ad hoc investments
to cover for short-term goals of separate units, the investments should be in-line with the overall business strategy and fulfill strategic business objectives. IT Governance
should ensure that a consistent message is sent to the organizational units and individual employees about IT spending. IT Governance is defined and managed within
the constraints of Corporate Governance, but does not always overlap with it in practice. IT Governance impacts the whole organization, from Board level and senior
executive to group or team leads, and it includes all IT assets, including hardware, software, and people. The goal of the process is to achieve alignment with the
enterprise strategy, its needs, challenges and initiatives, to deliver promised benefits, and to leverage IT to increase enterprise value.
Architecture Governance
Architecture Governance, also referred to as Enterprise Architecture Governance (for example, in TOGAF), addresses the maintenance of architecture-related standards
and conformance to those standards, as distinct from those of the wider IT scope. There may be some element of potential overlap between Architecture and IT
Governance, and if your scope is limited to one or the other, it is important to ensure that the boundaries and relationships are sufficiently clearly defined.
#TOP #TOP
SOA Governance
SOA Governance is a process that relates to exercising control over services in a service-oriented architecture (SOA). A SOA specifically requires a number of IT support
and organizational policies and processes to ensure that the benefits of SOA are realized, mostly because of additional reuse and cross-dependencies that SOA
introduces. For example, SOA benefits from a specific funding model to support the provision of a service by an organizational unit against its reuse by other units, and
the service level agreement (SLA) (availability, performance etc.) for that service. As SOA is relatively new, these aspects usually are being considered in traditional IT
Governance initiatives.
Project Governance
Project Governance relates to the management of an individual project, and incorporates appropriate elements of Corporate, IT, Architecture and potentially SOA
Governances, with the addition of project specifics. This is the concern of an individual project, and is therefore dealt with in OUM within the Manage and/or Implement
focus areas, rather than the Envision focus area.
Data Governance
Data Governance is concerned with managing data and ensuring data quality and consistency across the organization. The need for data governance arises from
regulatory requirements for accurate auditing as well as the enterprise view of data stemming from MDM and BI initiatives.
Relationship to Other Processes and Focus Areas
The policies defined in this process should be used within the other OUM processes in Envision as follows:
In the IT Portfolio process to ensure that candidate projects defined in the IT portfolio are aligned with the overall business strategies.
In the Enterprise Business Analysis process to ensure that requirements determined are in-line with the business objectives.
In the Enterprise Architecture process to ensure that a sound IT architecture is provided representing the overall business strategy.
The policies should be used within most PJM processes, with the approaches defined for Scope Management, Financial Management, Risk Management, Issue and
Problem Management, Quality Management, Configuration Management and Infrastructure Management process especially being aligned with the Governance policies.
Furthermore they should be used in all PJM and OUM Implementation processes when defining roles and responsibilities, to ensure that the proper roles with the proper
authorities are involved in any decision making as addressed in the IT Governance policies. It is especially important that the proper customer roles are involved in that.
For example, using the Governance policies one should be able to determine the scope, roles and responsibilities involved in the Configuration Management process.
Back to Top
PROCESS FLOW
Back to Top
APPROACH
Back to Top
Initiate Phase
GV.010 Define Governance Strategy Governance Strategy
GV.015 Review Current Governance Model Current Governance Model
GV.040 Determine Organizational Impact of Governance Impact Study and List of Proposed Organizational Changes
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.110 Monitor and Analyze Governance Processes Governance Implementation Improvement Proposal
Back to Top
OBJECTIVES
Back to Top
KEY WORK PRODUCTS
Back to Top
Back to Top
Back to Top
GV.010 - DEFINE GOVERNANCE STRATEGY
During this task, you review the Business Strategy (BA.010), the Envision Engagement Strategy (ER.020) and the Enterprise IT Strategy (EA.065) to determine the
objectives for Governance, and define the strategy on how to reach those objectives. This is a task done in collaboration with the enterprise management.
Information Technology (IT) can no longer be seen as a secondary enterprise function simply supporting the business. It is becoming an integral part of the business itself
with goals to provide more business value with less costs, and to help provide higher and higher service levels to customers and employees. In addition, the quantity and
quality of business critical information kept within information systems is increasing dramatically. This reinforces the need for effective control and management of IT,
related to both existing IT systems as well as new IT spending.
The Governance Strategy should provide the necessary boundaries to ensure that IT decisions are made in line with the overall Business Strategy and Business
Objectives. It should describe
how IT can, and should, be used to maximize business benefit
how business opportunities can be pursued using IT
how resources should be used and prioritized
how risk management should be applied
The IT Governance Strategy articulates and exposes core IT principles for the enterprise that will be used in IT decision-making.
Note that this is distinct from Governance in other areas (for example, overall Corporate Governance that ensures that the company officers conduct the business
transparently and honestly). It is important to ensure that the scope of Governance remains as described above. IT is likely to have a role in the execution of Corporate
Governance, but Governance is not to be confused with that (see also the Governance Process Overview).
In addition, there are more and more standards a business decides to follow, or is forced to adhere to, that must be included in a Governance Strategy to ensure that the
business performs the necessary actions for compliance. This is covered in a separate task, Determine Regulatory and Business Mandates (GV.020).
ACTIVITY
Back to Top
WORK PRODUCT
Governance Strategy - The Governance Strategy should provide the foundation to:
Determine what polices and procedures will be required to provide the best business value.
Enable compliance to rules or regulations the enterprise should adhere to.
Evaluate and determine the Funding Model or necessary organizational changes.
The Governance Strategy should provide the underlying principles and guidance for the tasks to be performed such that each of these efforts achieves synergy with the
other.
Back to Top
TASK STEPS
1 Review the Business Strategy
(BA.010), Envision
Engagement Strategy
(ER.020) and Enterprise IT
Strategy (EA.065).
Objectives The Objectives documents the objectives and how they impact the Governance Strategy.
2 Determine Areas of
Governance.
Areas of
Governance
The Areas of Governance documents the specific Areas of Governance that should be covered in the
Governance Strategy, for example, IT Governance, Architecture Governance, SOA Governance, Data
Governance (as recognized by OUM), Integration or Security Governance. It also describes the relationships
and boundaries between the Governance Areas. It describes how each area is relevant for the organization and
how it should be supported.
3 Define Governance
arrangements.
Arrangements The Arrangements documents the types of Governance arrangements that will be required as part of the
Governance Strategy.
#TOP #TOP
4 Define principles/criteria. Principles/Criteria The Principles/Criteria document what kind of principles or criteria should be taken into consideration for each IT
investment to ensure that each investment is considered related to expected business value, increased
performance (human or system).
5 Define Strategy and Standards
for procedures.
Strategy and
Standards
The Strategy and Standards details how Governance procedures and monitoring procedures should be
produced, the required level of detail, the approval structure, what each procedure should be tested against, and
the review/update frequency.
6 Define Governance
Communication and Adoption
Strategy.
Communication
and Adoption
Strategy
The Communication and Adoption Strategy describes how the Governance regulations should be communicated
to the organization, how employees will receive proper training and support to ensure that the defined
Governance policies and procedures will be followed, and how perceptions will be monitored, managed and
optimized for successful adoption.
7 Review and approve
Approved
Governance
Strategy
The Approved Governance Strategy is the Governance Strategy approved internally and by the enterprise
management.
Back to Top
APPROACH
The best and only way to carry out this task (and in particular the steps defining the strategy) is in close cooperation with the enterprise stakeholders. In the end, they
know the culture of the enterprise best and, more importantly, they will have to implement the Governance Strategy. There are no right or wrong answers, it is best to
review leading practices and the different available options in collaboration with the enterprise stakeholders, make sure they fully understand the implications and benefits
of each option and have them decide what is best for them. In other words, facilitated workshops with the stakeholders are probably the best way to determine the
In addition, if the Governance is to have any chance of being successful or even implemented at all, the enterprise stakeholders involved in the workshop must be senior
executives. Executives not only have the biggest incentive to the success of the Governance Strategy, but also have the most leverage to make it happen. At the very
least, the enterprise representatives must have been explicitly delegated and be trusted by senior executives to devise the Governance Strategy. Otherwise, it is very
likely that the recommended processes and organizational changes will never be fully implemented or audited. It is important that someone empowered with the authority
to apply decisions and actually govern.
Each of the steps defining the Governance Strategy (Define Governance Arrangements, Define Principles/Criteria, Define Strategy and Standards for Procedures, Define
Governance Communication and Adoption Strategy) may be done in a single workshop or in a series of smaller workshop, depending on the participants availability. It is
recommended, that if done in several workshops the participants are the same each time. If there is a gap between two sessions, start the workshop by restating what
has been decided previously.
It is best to start the first workshop with an overview of the initiative and its goals so that the Governance Strategy decisions are done with these goals in mind. It is
important to avoid the pitfall of designing Governance for Governances sake and the addition of a new organizational structure or Governance process should only be
done if it brings real benefits to the wider goal for which the Governance is being designed. Remember, that in real life Governance can too easily become a burden if it is
not designed to be lean and efficient.
Review the Strategy Documents
Review the Business Strategy, including the Business Objectives (BA.010) that are important to determine the Governance Strategy. Also review how IT is responding to
the Business Vision, Goals and Objectives by reviewing the Enterprise IT Strategy. Identify the underlying objectives that need specific Governance actions to be taken
(for example, how IT spending is performed, or how the enterprise decides to comply to certain standards). Document these objectives and how they impact Governance,
and depict the trace to the Business Strategy and Enterprise IT Strategy element s..
Determine Areas of Governance
The Governance Strategy should list any areas of Governance, for example, IT Governance, Architecture Governance, SOA Governance, Data Governance, etc. It should
describe how each area is relevant for the organization and how it should be supported. One specific area of Governance may have been determined in the scope of the
engagement. If so, focus on this area and only mention other areas in relation this area. For some areas, specific Governance arrangements will be put in place, while
others will be sufficiently covered by general Governance arrangements.
Define Governance Arrangements
Determine with enterprise executives what kind of Governance arrangements are required to meet the objectives of the Governance Strategy. Start with restating the
Business Strategy (BA.010) and the Governance objectives. Then facilitate the definition of the arrangements, which should ensure that IT will be properly controlled and
managed, that risks related to IT initiatives will be considered, and properly managed. For example, this includes descriptions of key roles and responsibilities, and
typically, a short description of the overall processes, such as the decision-making process, and conflict handling. The details of these processes will be described in the
task, Determine Organizational Impact of Governance (GV.040).
Define Principles/Criteria
Determine with enterprise executives what kind of principles or criteria should be taken into consideration for each IT investment to ensure that each investment is
considered related to expected business value, increased performance (human or system). Principles to IT investments and funding models ensure that investments are
considered in light of expected business value, following a given set of criteria. Further detailing of the Funding Model, will be done during the task, Determine Funding
Model (GV.090).
Define Strategy and Standards for Procedures
Determine with enterprise executives how Governance procedures and monitoring procedures should be produced, the required level of detail, the approval structure,
what each procedure should be tested against, and the review/update frequency. The policies could be a collection of working documents, or a set of assertions in a
policy engine implemented with workflow. The policy engine could operate at design-time and/or run-time and/or change-time. The Governance Strategy should address
the desired scope, depth and degree of initial automation needed. Basically, these procedures provide for performance management (including definition of business,
process and performance metrics) for how each IT investment should be evaluated for improvements for stakeholders and their satisfaction.
Define Governance Communication and Adoption Strategy
Determine with enterprise executives how the Governance regulations should be communicated to the organization, how employees will receive proper training and
support to ensure that the defined Governance policies and procedures will be followed, and how perceptions will be monitored, managed and optimized for successful
adoption.
Review and Approve Governance Strategy
It is important that management takes ownership of the Governance Strategy. Management is responsible for the success and failure of the strategy. Therefore, this
strategy should be created in cooperation with the enterprise management, and the final result must be reviewed and approved.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Provide the IT knowledge to ensure all appropriate measures are defined. 60
Work with the client stakeholders to ensure the appropriate linkage to business requirements and Governance. Preferably, this
should be done by an enterprise architect that specializes in Business Architecture.
40
Client Stakeholders Own the Governance Strategy and execute against that strategy. *
Back to Top
PREREQUISITES
Prerequisite Usage
Envision Engagement
Strategy (ER.020)
Enterprise IT Strategy
(EA.065)
Use the Business Strategy, particularly the Business Objectives, the Enterprise IT Strategy and the Envision Engagement Strategy to
determine any objectives that require Governance.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Governance Strategy is used in the following ways:
to understand what the Governance goals are for the Governance Areas within scope
to understand the strategy for how to reach those goals
as input to the Governance activities to ensure they are executed in line with the strategy
Distribute the Governance Strategy as follows:
to enterprise executives for approval
to individuals that should work on Governance activities
Back to Top
QUALITY CRITERIA
Has the Governance Strategy been made in close collaboration with the senior executives of the enterprise?
s there visible traceability from the business and IT objectives to the Governance objectives?
Are the areas of Governance clearly defined by the Governance Strategy?
Is it clear how the included Governance Areas relate and are impacted by other Governance areas?
Have the required Governance arrangements needed to meet the Governance Strategy objectives been fully described?
Have principles been described for IT investments?
Has a strategy and standards for the creation of Governance and monitoring procedures been described?
Does the Governance Strategy address the desired level of policy automation and monitoring?
Is there a Communication and Adoption Strategy?
Has the final Governance Strategy been reviewed and approved by enterprise executives?
Back to Top
GV.015 - REVIEW CURRENT GOVERNANCE MODEL
During this task, you investigate the current Governance approaches used in the enterprise. Generally, this task is applicable to the Governance of IT or to a specific
Governance area within IT, such as, Data Governance, SOA Governance or Enterprise Architecture Governance.
Even though there is often information available from the repositories and documentation of the enterprise, the best source of information for what really happens during
the day-to-day work of the enterprise is always the employees. This task uses workshops to elicit information from the employees.
ACTIVITY
Back to Top
WORK PRODUCT
Current Governance Model - The Current Governance Model shows the current state of an enterprise in terms of Governance. Most often this will be in the form of a
presentation including backup documentation.
Back to Top
TASK STEPS
1 Determine the areas that should be covered by the current state
Governance Model review.
Governance Model
Review Areas
The Governance Model Review Areas are the subjects that should be
covered during the review.
2 Establish adequate data for key topics within scope. Review Data The Review Data is the actual data that has been collected during
interviews and workshops.
3 Understand how data relates to areas of the review areas. Grouped Review Data The Grouped Review Data is the raw data grouped into logical areas
defined in step 1.
4 Establish common themes that underlie/interconnect the data. Common Themes The Common Themes are commonalities that you discover while
grouping the data.
5 Develop draft Current Governance Model. draft Current
Governance Model
The draft Current Governance Model is the result of the review in draft
format.
6 Validate and complete Current Governance Model. final Current
Governance Model
The final Current Governance Model is the result of the review in its
final format.
Back to Top
APPROACH
You would typically determine the current state by acquiring and gathering data/information through quantitative research that involves a combination of interviews,
discussion groups and/or surveys. Ensure that the appropriate stakeholders are included for the subject at hand. You should make sure stakeholders are included who
can provide perspective on the current state, the flaws in the current state and the desired state going forward to remediate those flaws and gaps. It is important that
employees' voices are heard early on in the process. As it is often these employees who really know where the bottlenecks and disconnects really are in the current state
(i.e., areas of friction between teams and problems during delivery of a project).
Each Governance Model review will have a different scope and requirements which in turn have an impact on how the following questions will be answered:
How many employees should be questioned in gathering information?
What medium should be used to gather the information (e.g., interviews, discussion group, surveys)?
What levels, functions and locations should be included?
A representative sample should be chosen from all levels and from all areas (functions, locations, teams, groups, departments, etc.). This ensures that all viewpoints are
heard and one level of department doesn't skew the findings. Not every level has to be represented at every location or every function represented at every level. Choose
population segments based on your hypotheses regarding which groups may have differing perspectives. You might want to take into account some short tenure
employees to get a different perspective but dont include too many. It is also recommended that you include employees who have experience in dealing with other
departments within the organization.
Enough employees should participate to allow trends to emerge and to ensure the data is not distorted by the opinions of a few people. These employees should be
knowledgeable about what is assessed and are willing to express their opinion. If you ensure confidentially to individuals then employees are more likely to be candid.
The findings will need to identify differences in viewpoints by group (function, location, level) but they should be reported in such as way that none of the comments can
be traced back to an individual source.
Surveys may need to be considered if you have a very large number of people, particularly when there are multiple locations.
Before the actual review, agree upon in what format the work product should be, either as a written document, a presentation document or both.
Determine the Governance Areas
Determine the Governance areas that should be covered by the Governance Model, for example, data, SOA, Enterprise Architecture or IT Governance. The areas
included should be those that are relevant to the engagement, and should have been determined as part of the Governance Strategy (GV.010). In some situations, you
may have a predefined Governance Model for a specific area. If so, use this as a starting point.
Establish Adequate Data for Key Topics within Scope
Review the Validated Scope (SM.010), and the Envision Engagement Plan (ER.030) to see what key topics are relevant for the Governance Model review. Use this as an
input to prepare the data gathering.
ACQUIRE DATA POINTS VIA INTERVIEWS
Very often a discussion group or workshop is the best way to accomplish good results quickly. However, for this type of task, it is often that interviews are the best
technique to use at least initially. This is important as it allows for in-depth questioning and ensures that each person's view is heard. However they are indeed time
intensive and expensive to conduct.
When conducting the interviews, the line of questioning should be based around the interviewees current role and the agreed scoped key topics.
Before each interview make sure you have some time scheduled where you can prepare for the interview itself.
Review any previously collected materials.
Contemplate the interview approach (who will perform the interview, who will take notes).
Define the objective of the interview.
Determine the key topic areas to cover.
The quality of questions will determine the depth of information that the review will provide. If you have any previously performed reviews available, or relevant reports or
documents, then use these to build a knowledge base.
Craft a set of open-ended questions that allow participants to paint a picture of the current situation and the factors that shape it from their viewpoint. After discussing a
persons role and their department, solicit employees views of the key topics. They should be asked to assess the current state for those topics, including strengths. For
each key topic, solicit challenges and ideas for improvement.
It is important to get a picture of how Governance is meant or defined to work within the organization, and to what extent this actually has been implemented and followed.
Where there are discrepancies, try to get an understanding of the reasons why there are discrepancies. Some examples follow:
What is documented in Governance policies has not (yet) been implemented through proper implementation procedures.
What is documented in Governance policies has been poorly communicated.
The policies are being met with resistance in the organization.
It is common knowledge that to get meaningful responses from an employee, it is best to ask open-ended questions. This gives them an opportunity to expand on
background on why certain situations exist. If a response seems superficially brief, try asking a counter-question and keep the employee talking and listen for the words
behind the words. If required, do not hesitate about asking for clarification, but do not interrupt the employee unless they go off topic. Be wary of time allocated for the
interview and the number of key topics you wish to cover. Therefore, timebox your key topics and do not let the employee get bogged down with insignificant detail.
If possible, perform parallel interviews. Be aware that this may force you to re-visit some of the interviewees as some of the information gathered from one interview may
influence the information you wish to capture in the next.
During the interview, keep good notes and once the interviews have been completed, it is important that the interview notes are documented. At the end of each
interview, you should:
Consolidate notes.
Check for discrepancies.
Check for differences of interpretations.
Contact interviewee if discrepancies are found.
ACQUIRE DATA VIA GROUP DISCUSSION, IF NEEDED
When using discussion groups, it permits a large number of employees to be involved in the Governance Model review than individual interviews. A discussion group
essentially allows for a group of people to be interviewed all at the same time. Although some employees might not say much in a group as they would in a one to one
interview, hearing others comment can actually help employees to stimulate their own thinking. The discussion can crystallize issues and help everyone focus on those
that have the highest impact.
The design of the discussion group affects the quality of the output. Take into consideration the following:
the skill of the facilitator
the number of participants - 5 - 7 people are the ideal number of participants - large enough to break into sub-groups and to ensure there will be a range of
opinions in the room. With more then 10 people the intimacy of the group is lost and people will feel too intimidated to actively participate.
the surroundings - Use a comfortable, private room where people will feel free to speak. A U shaped layout of the desks works best.
possible interruptions - Do not allow cell phones.
the relationship of the participants - Do not mix levels nor have people who report to each other within a given group.
Understand How Data Relates to Areas of the Review
REVIEW COLLECTED DATA AND DOCUMENTS
During the interviews, you gather a number of documents to either back-up what the interviewee was discussing or documents that go into greater detail. Either way,
these documents give you some additional supporting data for any analysis and synthesis you might execute later in the engagement.
If there is a need, ask the client project manager or the project sponsor for additional documents or contact the interviewee for more supporting data.
SEGMENT DATA AGAINST THE AREAS OF THE REVIEW AND THE KEY TOPICS FOR THE ENGAGEMENT
Organize all of the data gathered via the interviews, discussion groups, surveys and documents obtained and segment the data against the areas of the review and the
scoped key topics for the engagement. This will assist in highlighting key areas and areas that might need extra attention.
This is the first instance where common themes and patterns will start to emerge that will highlight the greatest Governance challenges the enterprise is likely to
encounter.
INTERVIEW AND WORKSHOP NOTES
Make certain notes are taken during the interview or workshop by someone else that is leading the discussion. You may also choose to record interviews if the person
being interviewed is in agreement. After every interview and workshop, you should complete all of your notes as soon as possible while they are still fresh in your
memory. The notes are often given to the client at the end of the engagement, but this must be clarified in the beginning of the project, at least prior to the review. This is
especially important if employees have been promised confidentiality.
Establish Common Themes that Underlie/Interconnect the Data
When you have organized the collected data, you should look for some common themes that you see in the data, or that makes the data interconnect. You may do this
as follows:
ANALYZE SUPPORTING DATA AGAINST INDUSTRY LEADING PRACTICES
If you have available information about the industry leading practices related to the type of review, you should analyze the collected data against these leading practices.
If there is an area where little experience exists, but there are related areas that can be used, then consider to use this as a basis. If you know of any experienced
persons on the area, ask them to review as early as possible.
RETURN TO INFORMATION SOURCE IF DATA GAPS EXIST
During the analysis of the information across the key areas, you might need extra data and you might need to return to some of the interviewees for additional data or
confirmation of some conflicting data. Make sure that you do not make any assumptions and that an individual employee passing comments does not skew your analysis.
Try to have multiple sources for your supporting data, if you do not either ask the project manager or project sponsor at the enterprise, or return to the interviewee to ask
who would be best to expand on their opinions.
CONSTRUCT COMMON THEMES
Employees tend to speak of symptoms - what they experience personally - but when the themes are repeated consistently across different levels and departments, it
should be possible to discern the underlying problem.
Construct these underlying problems into a snapshot/summary of the strengths and weaknesses of the organization at a point in time. Make sure to highlight the
strengths and not just the weaknesses, as well as the root causes. As mentioned already, make sure to have multiple sources for any supporting data.
Develop Draft Current Governance Model
When you have collected and segmented the data, and identified some common themes, you are ready to develop the first version of the Governance Model review. You
should already have determined the medium in which the work product should be produced, either as a written document or a presentation format or both.
Synthesize the content into an overall story of the clients current state. Use the predefined areas for the review to organize the review. Provide information about the
current state for each of these areas, and make a conclusion for each. Finally, provide an overall conclusion.
Validate and Complete Governance Model
Distribute the Governance Model Review to senior persons that are knowledgeable of the area that you have assessed so that they can assist you and review/validate
your findings and review. This is especially important if this is the first time you have executed such an engagement.
If during the feedback, there are specific issues that need to be discussed in further detail, consider scheduling a conference call to expedite specific issues so that there
is no delay in presenting the review to the enterprise representatives.
When you have completed a draft version of the Governance Model Review, verify this with the engagement sponsor before presenting to a larger audience. This is to
make sure that our message/story is validated before we present to the enterprise's senior management.
Get some feedback from the project sponsor to see if the findings may be too sensitive to share beyond the executive team.
Does it expose too much "dirty laundry?"
Could the findings be demoralizing if circulated without a context to the rest of the organization?
A high-level summary of the findings should be shared with the whole organization or at least with those who participated in the review process. Nothing is more
frustrating to people than a lack of feedback after they've honestly shared their viewpoints in interviews, discussion groups or surveys.
Synthesize all the feedback that you have received and incorporate it into the final Current Governance Model.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Conduct interviews to establish a baseline view of current Governance. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Validated Scope (PJM.SM.010) Use the Validated Scope to determine which key topics are within scope of the engagement.
Governance Strategy (GV.010) Use the Governance Strategy (GV.010) to understand the Governance objectives and Governance Areas that are relevant for the
engagement.
Envision Engagement
Strategy (ER.020)
Use the Envision Engagement Strategy to check whether any approach has been determined to perform the Governance Model
review, as well as if the persons who should be involved have been identified.
Envision Engagement Plan
(ER.030)
Use the Envision Engagement Plan to determine which key topics are within scope of the engagement and how to deal with them.
Enterprise Stakeholder
Inventory (BA.015)
Use the Enterprise Stakeholder Inventory to identify which stakeholders should be included in the review.
Enterprise Business Context
Diagram (BA.045)
Use the Enterprise Business Context Diagram to determine the business context and to identify stakeholders for the review.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Current Governance Model is used in the following ways:
to determine next steps for the organization
Distribute the Current Governance Model as follows:
to senior persons knowledgeable of the type of review you perform - These members can assist you and review/validate your findings and review.
to the project sponsor to validate your findings and review - This is to make sure that the message/story is validated before it is presented to the enterprise senior
management
the entire organization or at least with those who participated in the review process should received a high-level summary of the findings
Back to Top
QUALITY CRITERIA
Have stakeholders with different viewpoints and level been heard to ensure the broader perspective?
Have enough employees been included in the process to be able to discover trends?
Have actions been taken to ensure confidentiality to individuals enabling candid responses?
Have the Governance Areas that should be covered by the Governance Model been documented?
Were open-ended questions used during interviews?
Have the notes taken during the interviews been consolidated?
Have discrepancies been identified, and if so, has the reason for the discrepancies been identified?
Have common themes been identified, and have strengths and weaknesses been identified?
Have the root causes of strengths and weaknesses been identified?
Has the Governance Model been reviewed by senior persons knowledgeable to the area, and have their comments been incorporated?
Has the Governance Model Review been verified by the engagement sponsor before being presented to enterprise senior management?
Has a high-level summary of the findings been produced with the purpose of sharing with the whole organization?
Back to Top
GV.020 - DETERMINE REGULATORY AND BUSINESS
MANDATES
During this task, you identify legislative drivers, standards, and leading practices to which the business decides to use or needs to adhere. A leading practice is a practice
a certain business or industry recognizes to be efficient and effective for delivering a particular outcome. The result of this should drive the Governance Policies Catalog
(GV.030), providing a prescriptive framework for the Measurements Portfolio (GV.070) and drive the Governance Policy Tooling (GV.060).
ACTIVITY
GV.020.1
GV.020.2
INIT.ACT.ME Maintain and Evolve
Back to Top
WORK PRODUCT
Mandate Matrix - The Mandate Matrix lists which legislative drivers, standards and leading practices are relevant for the organization, and how the organization positions
itself for each of these.
Back to Top
TASK STEPS
1 Identify the business areas and regions in which
the organization performs business.
Mandate Matrix -
Business Areas and
Regions
The Business Areas and Regions section of the Mandate Matrix documents the regions
and business areas that reflect the way the enterprise is organized.
2 Identify legislative drivers and standards relevant
for the business areas and regions for the
organization.
Mandate Matrix -
Legislative Drivers and
Standards
The Legislative Drivers and Standards section of the Mandate Matrix lists all the
identified drivers and standards to which the enterprise may need to adhere.
3 Identify relevant leading practices for the
business.
Mandate Matrix -
Relevant Leading
Practices
The Relevant Leading Practices section of the Mandate Matrix lists all the leading
practices that may be relevant for the enterprise.
4 Document the organizations position for each
identified driver, standard and leading practice.
Mandate Matrix -
Organization Position
The Organization Position section of the Mandate Matrix shows the enterprise's position
by region and business area for each identified legislative driver, standard, and leading
practice.
Back to Top
APPROACH
Depending on the kind of business the organization performs, and the countries in which the organization does business, there will be a number of legislative drivers and
standards that the company must or chooses to follow. For example, determining that the company does business in New Zealand, the UK and the US would imply that
AN/Z4360 and British Standard BS 7799 part 3 and COBIT 4 (COSO) were required under local risk mitigation legislation.
Describe the business position regarding the identified legislative drivers, standards and leading practices. The details of the specific standards themselves will be
described as part of the Governance Policies Catalog (GV.030). For example, the Governance Strategy might state we should follow the W3C standards for web
services, while the Governance Policies Catalog policy will define which ones (WS-Security, WS-Addressing, etc.). Other examples are the Sarbanes-Oxley in the USA
and Basel II in Europe.
It is recommended that you document the result of this investigation in a Mandate Matrix. Such a matrix provides a clear and easy overview of the business' position
regarding the identified legislative drives, standards and leading practices across the business areas and regions.
Identify the Business Areas and Regions
Review the Enterprise Organization Structures (BA.020) to identify organizational units, and regions wherein the enterprise operates. Create a matrix. Review the
Enterprise Function or Process Model (BA.040) to identify the business areas that are relevant for each region or organizational unit.
Start with the creation of the Mandate Matrix. You may enter the regions at the top on the horizontal axis, and in the next row enter enter the business areas for a given
region.
Mandate Matrix:
Region: UK Nordics
Business Area: Finance Insurance Finance Insurance
Keep in mind that there may regulations that are specific to a lower level region that you indicate initially. In such cases, consider whether you will make even a lower level
of detail for the regions, or whether to make a note that it is valid only for a specific part of the region. A good indicator should be to analyze how the enterprise is
organized. For example, in the matrix example above, is there a single unit of control for the Nordic countries, with no separate departments in the individual countries, or
are there separate departments within each country. In the first situation, it is probably better to keep the matrix at the Nordic level, and indicate that a specific regulation
only is relevant for example in Denmark. In the other situation, it would probably be better to split the Nordic region and visualize each country separately in the matrix, as
it then better reflects how the enterprise itself is organized.
Identify Legislative Drivers and Standards
Identify any candidate legislative drivers and standards that may be relevant for each region or business area you have identified for the organization. Use the Business
Strategy (BA.010), and Enterprise IT Strategy (EA.065) to get an understanding of the business objectives and principles, as well as the supporting IT objectives and
principles that may direct you to which legislative drivers or standards may be of relevance. Also, review the enterprise Architecture Principles, Guidelines and Standards
to identify current standards that are relevant to the enterprise.
You may document all the candidates on the left hand side of the Mandate Matrix so that it will be possible to indicate which drivers and standards may be relevant for a
given business area within a region. An example of this follows:
Region: UK Nordics
Business Area : Finance Insurance Finance Insurance
Supporting Business or IT
Objectives
Legislative Drivers/Standards
Name Driver A C C
Name Driver B C C
Name Driver C C C
The C indicates that you have identified the driver or standard to be a candidate that may be relevant for the business. If you know more details about how the driver or
standard is of relevance to the business area and region, then replace the C with more information. Notice the column Supporting Business or IT Objectives. The
intention is that you should document the business or IT objectives to which the legislative driver or standard is relevant.
Identify Relevant Leading Practices for the Business
Similar to the legislative drivers and standards, identify any leading practices that may be relevant for the business in the various regions. A leading practice is a practice
within a certain business or industry that is seen to be efficient and effective for delivering a particular outcome. It can be compared with best practices, but may not
necessarily have been proven to be the best. The point is to identify those practices, relevant for the business situation, that are known as leading or even the best
practices for given circumstances.
Again use the Business Strategy (BA.010), and Enterprise IT Strategy (EA.065) to get an understanding of the business objectives and principles, as well as the
supporting IT objectives and principles that may direct you to identify which leading practices are relevant to the business. Document the relevant leading practices
similar to how you documented the drivers and standards earlier.
Region: UK Nordics
Business Area : Finance Insurance Finance Insurance
Supporting Business or IT
Objectives
Legislative Drivers/Standards
Name Driver A C C
Name Driver B C C
Name Driver C C C
Leading Practices
Name Practice D C C
Name Practice E C C
Document the Organizations Positions
Now that you have prepared the Mandate Matrix, and have identified a number of candidate drivers, standards and leading practices relevant to the business, you need
to review this with the stakeholders from the enterprise. You should especially talk to legal representatives to identify what candidates have actual relevance, and to
identify potential missing drivers, standards or practices that the enterprise needs to adhere to or chooses to follow.
If an identified legislative driver, standard, or leading practice is decided to be of no relevance to the enterprise, document the reason for this so that you have it
documented when the Mandate Matrix is revisited at a later point in time.
When you have validated the results with the enterprise stakeholders, update the matrix, and remove all the candidates, and instead indicate to what level the driver,
standard or practice is relevant to the business. For example, there may be parts of a certain standard that need to be followed, and if so indicate this in the column. You
may also choose to add a column for comments.
When you have finalized the matrix, perform a final review with the enterprise stakeholders, and in particular senior management.
Back to Top
Compile Mandate Matrix. Preferably, this should be done by an enterprise architect that specializes in Business Architecture. 100
Back to Top
PREREQUISITES
GV.020.1
Prerequisite Usage
Envision Engagement Strategy (ER.020)
Enterprise IT Strategy (EA.065)
Use the strategies to understand the business objectives and principles, the supporting IT objectives and principles and
what is within the scope of the Envision engagement.
Architecture Principles, Guidelines and
Standards (EA.010.1)
Use this work product to identify current standards that the enterprise should follow.
(BA.020)
Use the Enterprise Organization Structures to understand what kind of organization units and regions comprise the
enterprise.
(BA.040)
Use the Enterprise Function or Process Model to understand the business areas relevant for the enterprise.
GV.020.2
Prerequisite Usage
Mandate Matrix (GV.020.1) Use the existing Mandate Matrix as a starting point for updating the matrix.
Architecture Principles, Guidelines and Standards (EA.010.2) Use this work product to identify current standards that the enterprise should follow.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Mandate Matrix is used in the following ways:
as input to determine what kind of policies (GV.030) would be relevant to the enterprise
as input to determine organizational impact (GV.040)
Distribute the Mandate Matrix as follows:
to enterprise stakeholders that should review the results
to individuals that are involved in the new Governance activities
Back to Top
QUALITY CRITERIA
Do the regions and business areas depicted in the Mandate Matrix reflect the enterprises business?
Has the level of expected compliance (or portion) for each legislative driver, standard or leading practice been indicated by region and business area?
Is there clear traceability between each business or IT objectives, and the individual legislative driver, standard, or leading practice included in the Mandate Matrix?
If an identified legislative driver, standard, or leading practice is not to be followed, has the reason been documented?
Back to Top
GV.030 - DISCOVER OR DEFINE POLICIES
During this task, you review various sources and interview the client to determine what kind of polices already exist in the enterprise. You also review the Mandate Matrix
(GV.020). This covers regulations, policies and regulatory standards, internal and external, to which the business needs to adhere/comply, and that are relevant for the
engagement. Based on your review, you identify necessary changes to existing policies, and what kind of new policies should be created. You also determine which
asset types need to be captured in an Enterprise Repository to support these policies and may require (changes to) meta data descriptions. The actual determination of
the meta data descriptions is done using other OUM tasks.
Some examples of policies follow:
Compliance policies (such as Basel2, IFX for banking sector, ACORD for Insurance)
Business policies (process policies, SLAs, performance metrics and criteria, funding policies)
This task may be used to discover or define policies related to various types of Governance, for example, IT Governance, Project Governance, SOA Governance, etc.
Some examples of IT assets that may need to be captured in an Enterprise Repository are:
projects
applications
services
requirements
standards
ACTIVITY
GV.030.1
GV.030.2
Back to Top
WORK PRODUCT
Governance Policies Catalog - The Governance Policies Catalog lists all policies and standards that are relevant for the enterprise and the engagement. For each
policy/standard, define the areas of impact , as well as which types of IT assets will be managed by means of an Enterprise Repository. The Enterprise Repository may
consist of a (series) of spreadsheets containing meta data about IT assets or may be implemented by dedicated software.The Governance Policies Catalog indicates
when a new policy or a change to an existing policy requires the introduction or use of a dedicated Enterprise Repository.
Back to Top
TASK STEPS
1 Review relevant sources for relevant polices. List of Sources The List of Sources documents sources as well as stakeholders representing different
perspectives and IT domains.
2 For each relevant existing policy/standard
determine impact.
Existing Policies The Existing Policies lists any current existing policies and standards.
3 Determine required new policies. New Required
Policies
The New Required Policies is a list of any required new policies.
4 Prioritize policies. New Required
Policies
The New Required Policies is updated to show a priority for the policies to indicate which are the
most critical to implement first.
5 Determine IT asset types to manage. IT Asset Types The IT Asset Types is a list of (main) IT asset types that require management by means of an
Back to Top
APPROACH
Review Relevant Sources
Review relevant sources for relevant polices. Review the Mandate Matrix (GV.020) to identify relevant policies. Also review the Governance Strategy (GV.010) and the
Envision Engagement Strategy (ER.020). Ask the enterprise representatives about existing polices they follow that should be considered. Preferably, ask persons with
different perspectives (business, technical) as they may have a different viewpoint and think of different policies/standards. Ask if there are any new policies expected to
come. You need to speak to a subject matter expert for each relevant internal IT domain (infrastructure, software development, etc.).
Determine Impact
Determine the impact for each relevant existing policy/standard. For each existing policy or standard that is relevant for Governance and the engagement in question,
indicate the areas of impact, and an indication of what will be required to follow the policy/standard. Verify whether there will be needed to make some changes to the
policies.
Determine New Policies
Determine required new policies. If there are any relevant regulatory and business mandates that are not covered by any of the existing policies, determine what kind of
new policies will be required. Document the purpose of each of the new policies, as well as the stakeholders for each policy. Consider the following ITIL Service Support
related policies example:
Customers should experience excellent service support (customers here are internal customers to IT).
Incidents should be classified indicating both severity and urgency.
Enhancements should be classified by indicating desirability and urgency.
Prioritize Policies
Prioritize the policies. This is particularly important if not all policies/standards can be implemented all at once, to indicate which are the most critical to implement first. It
is also important because there are many situations where you cannot comply to all of the policies or standards. Therefore, you need to know which ones are the most
important.
Use the MoSCoW principles for prioritizing the policies. This allows you to immediately understand to which policies the enterprise must adhere and implement, as well as
those that are important to implement, but are not critical.
Determine IT Asset Types to Manage
Review each policy and determine if it requires support of managing IT assets through an Enterprise Repository. Determine which asset types would be needed to
support the policy. For example, proper SOA Governance is not possible without capturing data about existing and planned SOA services. At this point it should be
sufficient to list the main asset types needed. During the actual determination of the meta models of these asset types, other related asset types may be discovered. In
some cases, this may require an update of one or more policies, which then implies another instantiation of this task. The tasks in which the actual meta data descriptions
are determined are:
GV.092 - Determine Projects Meta Data Descriptions
GV.094 - Determine Applications Meta Data Descriptions
GV.096 - Determine Services Meta Data Descriptions
GV.098 - Determine Other Meta Data Descriptions
engagements.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Compile Governance Policies Catalog. 20 (EA)
80
(BAR)
Client Enterprise Architect Assist in the discovery process. *
Back to Top
PREREQUISITES
GV.030.1
Prerequisite Usage
Envision Engagement Strategy (ER.010) Use the Envision Engagement Strategy to understand the nature of the engagement and the enterprise as an input to
understand what kind of policies may be suitable.
Governance Strategy (GV.010) Use the Governance Strategy to understand the Governance objectives, and how it is intended to achieve these objectives.
Standards (EA.010.1)
Use the Architecture Principles, Guidelines and Standards to understand current standards and guidelines as they apply to
the enterprise.
Mandate Matrix (GV.020.1) Use the Mandate Matrix that contains legislative drivers, standards, and leading practices that the business decides to use
or needs to adhere to as an input to identify relevant policies.
GV.030.2
Prerequisite Usage
Architecture Principles, Guidelines
and Standards (EA.010.2)
Use the Architecture Principles, Guidelines and Standards to understand current standards and guidelines as they apply to
the enterprise.
Mandate Matrix (GV.020.2) Use the legislative drivers, standards, and leading practices that the business decides to use (or needs to adhere to) as
documented in the Mandate Matrix as an input to identifying relevant policies.
Governance Policies Catalog
(GV.030.1)
Use the Governance Policies Catalog to understand the policies determined during the previous iteration, and based on that
determine what kind of updates or new policies are required.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Governance Policies Catalog is used in the following ways:
to show the impacts on existing policies, how they need to change, and what new policies are required
as input to the Policy Implementation Processes (GV.050) and Governance Policy Tooling (GV.060) to understand which policies should be implemented
to show which assets are required to support the policies
Distribute the Governance Policies Catalogue as follows:
to stakeholders of the policies for review
to individuals that should implement the policies
Back to Top
QUALITY CRITERIA
Have stakeholders been identified for each policy in the catalog, and have stakeholders been identified for all relevant perspectives and domains?
Has the impact to existing policies or standards been determined?
Has the reason for change been documented?
Has the reasoning for each policy been documented?
Have the policies been prioritized?
Have IT assets required to support each policy been documented?
Has each of the IT assets been linked back to the policy or policies they support?
Back to Top
GV.040 - DETERMINE ORGANIZATIONAL IMPACT OF
GOVERNANCE
This task is used to determine the organizational impact for various types of Governance, for example, IT Governance, Project Governance, SOA Governance, etc. In the
following guidelines, IT Governance is assumed, however, they can also be applied in the context of other types of Governance.
The organizational impact may include changes or additions to the current organization, such as, the creation of new organizational units for Governance or the
identification of new roles and responsibilities. The definitions of any new processes to support the organizational changes will be done as part of the task, Define Policy
Implementation Processes (GV.050).
The degree of organizational changes to be suggested will vary between engagements. If the suggested change is expected to be substantial, then you should review the
Organizational Change Management process (EOCM) , and in particular the task EOCM.050 Conduct Organizational Change Capability Scoping as an alternative to, or
to be executed in combination with, this GV.040 task. It may also be that in the process of executing this task, you realize that the organizational changes required will be
non-trivial. If that is the case, you should consider using the EOCM process for any further work in this area.
ACTIVITY
Back to Top
WORK PRODUCT
Impact Study and List of Proposed Organizational Changes - The Impact Study and List of Proposed Organizational Changes describes the impact of the proposed
Governance on the organization. It also contains a list of proposed changes, including a description of how each proposed change will benefit the implementation of
Governance.
Back to Top
TASK STEPS
1 Determine the organizational impact
of the proposed IT Governance.
Impact Study The Impact Study describes how the new Governance will impact the organization.
2 Identify any necessary
organizational changes to support
IT Governance.
List of Proposed
Changes
The List of Proposed Changes describes which organizational changes are recommended to best support
the implementation of the new Governance.
3 Identify roles and responsibilities. Roles and
Responsibilities
The Roles and Responsibilities describes all the roles that are required to support the Governance
structures and what their responsibilities are. It also describes what kind of skills are required to fulfill a
given role.
4 Perform competency mappings. Competency
Mappings
The Competency Mappings describes the required competencies and how they map to the current
competencies within the organization.
5 Identify potential resistance and
conflict areas.
Potential
Resistance and
Conflict Areas
Potential Resistance and Conflict Areas describes what kinds of conflicts or resistance are expected as a
result of the organizational changes, including mitigation strategies for either prevention or response.
Back to Top
APPROACH
Determine the Organizational Impact
Determine the organizational impact of IT Governance on the existing organization. Review the Governance Strategy (GV.010), the Current Governance Model (GV.015),
the Mandate Matrix (GV.020) and the Governance Policies Catalog (GV.030) to determine what kind of impact the proposed Governance will have on the existing
organization. Identify the gaps between the Current Governance Model and the proposed Governance Model to see how this may impact the organization. The nature of
the organizational gaps may vary, but typically they concern lacking or superfluous organizational groups/units, lacking or unclear roles or responsibilities, lacking or
insufficient competencies, etc.
Identify Organizational Changes
Identify organizational changes to support IT Governance. Identify any required changes to the current organization based on the organizational impact you determined in
the previous step. This step may e executed along with the next step where you identify the roles and responsibilities.
Review the gaps in the Impact Study you have created in order to see what kind of organizational structures can best support the proposed Governance Model and what
kind of responsibilities and competencies are required. The change could be anything from changing or adding responsibilities to current organizational groups to creating
new groups (or even removing existing groups) to support Governance. For example, you may decide that there is a need for a group to maintain and measure the
effectiveness of the policy processes.
Identify Roles and Responsibilities
Identify and define all roles that are required to fully support the Governance Model. For each role, identify the responsibilities and the associated required competencies.
The role definition defines the expected outcome and responsibilities for each identified organizational role, which state what results and tasks are to be attained within a
timeframe. A role definition should not be seen as a job-description, but only highlight unique aspects of the role. This is important to ensure that everyone understands
his or her responsibilities related to IT Governance. It is likely that some existing roles will get additional responsibilities to ensure a proper policy execution. A completed
role definition aids in identifying where there may be tension between current and future roles.
Perform Competency Mappings
When the required responsibilities and competencies have been identified for the different roles, you should map this requirement to the current competencies of the
individuals that should fulfill the given role. Preferably, the individuals themselves should indicate their competency level, as well as their direct manager, or another
manager knowing the skills of the individual. The latter is important to prevent too many inconsistencies in the mapping, as some individuals tend to overrate themselves,
while others underrate. It must be made clear that the Competency Mapping is not intended as an employee evaluation, but rather as a mapping exercise to understand
the organizations competency within a given area, and that lagging competency may be compensated through proper training. In the areas where there are lagging
competencies, actions should be added to the List of Proposed Changes. Typical actions may be:
Train individuals.
Hire new people with the right competencies.
Apply temporary external assistance with the purpose of training people.
Shift individuals within the organization.
Identify Potential Resistance and Conflict Areas
Any organizational change may lead to resistance and conflicts. Attempt to identify those areas where you would expect resistance or conflicts to occur. Areas where you
typically can expect resistance or conflict are when:
Individuals are forced to change jobs.
Groups are removed (and individuals are moved to different areas within the organization).
Individuals lose responsibilities.
Some legacy competency is no longer required.
Individual are given more responsibilities.
The benefits of changes have not been made clear or have not been communicated.
These are just some examples, and what causes resistance or conflicts is often due to the way in which the organizational changes are implemented, how they are
communicated, but also dependent on the individuals themselves. As you can see from the list above, conflicts may be due to both losing and gaining responsibilities,
depending on the type of person who is loosing or gaining it. Therefore, when identifying the areas of resistance or conflict, it is useful to get an understanding of what
kind of persons will be impacted by the changes. This is vital input in determining the most appropriate implementation procedures.
DEFINE RESISTANCE AND CONFLICT HANDLING PROCEDURES
Review the potential resistance and conflict areas and define how resistance and conflicts should be handled. Review all the proposed changes and the identified
potential resistance and conflict areas, and determine how potential resistance or conflict best may be handled. Indicate per proposed change the recommended
procedures for handling them. If possible, define one generic procedure for resistance and conflict handling that may be used for most areas, as well as unforeseen
resistance or conflicts.
engagements.
Back to Top
Cloud Roadmap
Back to Top
Conduct Impact Study and develop proposals for organizational changes. 30 (EA)
70
(BAR)
Client Enterprise Architect Collaborate to develop proposals for organizational changes. *
Back to Top
PREREQUISITES
Prerequisite Usage
Governance Strategy (GV.010) Use the Governance Strategy to understand potential organizational impact.
Structures (BA.020)
Use the Enterprise Organization Structures as an input to understand the current organization structures that may need to change
due to the new Governance Model.
Current Governance Model
(GV.015)
Use the Current Governance Model to understand the current situation.
Mandate Matrix (GV.020) Use the Mandate Matrix to understand the legislative drivers, standards and best practices to which the business has decided to use
or needs to adhere and that may cause organizational change.
Enterprise Function or Process
Model (BA.040)
Use the Enterprise Function or Process Model to understand how the organization executes its business.
(GV.030)
Use the Governance Policies Catalog to understand what kind of policies the organization should adhere and how this may have an
impact on the organization.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Impact Study and List of Proposed Organizational Changes is used in the following ways:
to show how the new Governance impacts the organization
to show potential organizational changes and related actions to take to support the implementation of the new Governance Model (GV.100)
o determine whether the degree of required organizational changes require further detailing and implementation through the use of EOCM tasks, or whether they
are limited enough to be detailed and implemented through the use of remaining GV tasks
to show potential resistance and conflicting areas related to organizational changes.
Distribute the Impact Study and List of Proposed Organizational Changes as follows:
to management responsible for organizational changes
to the persons responsible for further detailing and implementing the organizational changes
Back to Top
QUALITY CRITERIA
Does the Impact Study describe the nature of each impact?
Does it describe what groups and individuals are impacted by the change?
Have roles, responsibilities and required competencies per role been described clearly?
Does it include a gap analysis between current and required competencies?
Does it include a list of proposed changes?
Does every proposed change include a reference to a preferred conflict handling procedure?
Have potential resistance and conflict areas been identified?
Back to Top
GV.050 - DEFINE POLICY IMPLEMENTATION PROCESSES
During this task, you define the processes that should be put in place in order to adhere to the defined Governance policies. Use the Governance Polices Catalog
(GV.030) to see what kind of policies and standards need processes for implementation.
ACTIVITY
GV.050.1
GV.050.2
Back to Top
WORK PRODUCT
Policy Implementation Processes - The Policy Implementation Processes document the processes that are required for the implementation of the policies documented
in the Governance Polices Catalog (GV.030). The processes describe the steps that should be performed, what assets will be required to support the processes, and
who is responsible for the processes as a whole, as well as who is executing each individual step of the process. The actual implementation of the processes is a part of
the Governance Implementation (GV.100).
Back to Top
TASK STEPS
1 Review prerequisite documents. None
2 Determine groups and individuals
impacted by the policies.
Policy Process Actors The Policy Process Actors describes which groups and individuals take part of a given Policy
Implementation Process, including their responsibilities.
3 Define Policy Implementation
Processes.
Policy Implementation
Processes
For each process, the Policy Implementation Processes documents the steps of the policy.
4 Review the Policy Implementation
Processes.
Review Results The Review Results records the results of the review for each process and reviewer.
Back to Top
APPROACH
Review Prerequisite Documents
Review the Governance Strategy (GV.010) to see whether there are specific rules for process definition and how the processes should be reviewed to ensure you start off
correctly.
Review the Governance Polices Catalog (GV.030) to determine which policies need process descriptions. If the polices have been prioritized, start with the process with
the highest given priority. Review the rest of the list to see whether there are other polices/standards that are related, and therefore best could be included in the same
implementation process.
Determine Groups and Individuals Impacted by the Policies
It is important that you get an understanding of which groups and individuals are impacted by the policies. For larger groups, identify individuals that may represent the
group. For the success of the implementation of Governance policies, it is important to adjust the process to best fit the current internal processes and culture within the
organization to prevent resistance as much as possible . If the organizational changes are substantial, significant resistance or large conflicts are expected. It is
recommended that you handle the organizational changes by using the Organizational Change Management process within OUM, with resources that are trained
Organizational Change Management professionals.
Define Policy Implementation Processes
To define the policy implementation process, it is recommended that you execute one or multiple workshops with a group of stakeholders that are impacted by the policy
or policies to be implemented. Ensure that the owner of the policy is attending as well so that the background of the policy may be explained.
For each policy requiring a process, you should eventually define the steps that will be taken to implement the policy. Within the workshop, ask the participants how they
think the policies best can be implemented. Make them aware that policy implementations may be partly or fully automated whenever that is an option. If a policy is
automated, indicate the methodology that will be used to manage the design and implementation of the policy (for example, OUM). Also, review the assets that support
the policy as they have been identified for each policy. Ask how they are used to support the process, and for each asset when and who creates it, who makes decisions
regarding it, and who makes updates to it. It may be that you discover new assets as part of this process. If so, you should execute another iteration of the Governance
Policy Catalog (GV.030) to ensure consistency.
It is recommended that ahead of the workshop you look into the current internal working processes relevant for the given policy or policies, and how the each may be
implemented with as little change as possible to the status quo. First of all, you will have a better understanding of the current situation by doing this. In addition workshop
attendees will typically provide more feedback of greater quality when given something to react to instead of starting from a blank slate. Therefore, it is recommended that
you prepare suggested Implementation Processes, as wall as potential alternatives.
You may want to distribute this to the participants before the workshop so that they might review it before the workshop. However, you want to avoid creating resistance
by giving the impression that the work is already done. If there is resistance, it is difficult to keep the progress within the workshop and to reach the goal of the
workshop.
When preparing the process, ensure that it follows the guidelines in the Governance Strategy (GV.010). Also, ensure that they are focused on establishing the right level
of bureaucracy fit for purpose. Too much bureaucracy slows down the process and makes it unnecessarily complex, while too little makes it too easy to avoid. Also,
introducing a high level of bureaucracy to an organization with little bureaucracy may cause unnecessary resistance.
Review Policy Implementation Processes
The Policy Implementation Processes are typically created through a number of iterations in cooperation with enterprise stakeholders impacted by the process. When the
processes have reached a final state and are ready for implementation, a final review should be performed for each process. Representatives of each type of stakeholder
should review the process. It should be reviewed on relevance, effectiveness and how realistic it can be implemented.
Back to Top
Cloud Roadmap
Back to Top
Determine how policies will be implemented and define policy steps. 60 (EA)
40
(BAR)
Back to Top
PREREQUISITES
Prerequisite Usage
Governance Strategy (GV.010) Use the Governance Strategy to see whether there are specific rules for process definition and how the processes should be reviewed
to ensure you start off correctly.
(GV.030)
Use the Governance Policies Catalog to determine which policies need process descriptions.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Policy Implementation Processes are used in the following ways:
to show how policies should be implemented when starting the Governance Implementation (GV.100)
to show how the implementation of the policies impact the current processes
to show who, groups and individuals, are impacted by the policy implementation to allow for proper communications and training as part of the Governance
Implementation (GV.100)
to determine whether the degree of required organizational changes require further detailing and implementation through the use of EOCM tasks, or whether
detailing and implementation through the use of remaining GV tasks is sufficient
to show which assets are created or impacted by the processes, and that may need further detailing
Distribute the Policy Implementation Processes as follows:
to stakeholders of the processes for review
to all individuals impacted by the processes [controlled as part of the Governance Implementation (GV.100)]
to the individuals that will participate in the implementation of the new Governance Model
Back to Top
QUALITY CRITERIA
Have all individuals and groups impacted by the policies been identified?
For larger groups, have representatives been identified?
Have the processes been defined in collaboration with the stakeholders?
Have the processes been reviewed and have comments been handled properly?
Have Policy Implementation Processes been identified for all highly prioritized policies (GV.030)?
Have the Policy Implementation Processes been made in accordance with the Governance Strategy (GV.100)?
Back to Top
GV.060 - DEFINE POLICY IMPLEMENTATION TOOLING
During this task, you identify the appropriate framework or tooling for supporting policies. An example of using a framework for policy implementation would be the use of
an Information Technology Infrastructure Library (ITIL). An example of using a tool for policy implementation would be the use of an Enterprise Repository to contain
meta data about IT assets and their relationships.
ACTIVITY
GV.060.1
GV.060.2
Back to Top
WORK PRODUCT
Governance Policy Tooling - The Governance Policy Tooling describes the choice of the actual framework or tooling that will be used to store, and maintain the
identified policies. It describes the policy or monitoring procedures that will be automated, and the tooling functions that should be used for this automation. Along with the
actual framework or tooling, a supplemental document is produced explaining the usage of each framework/tooling.
In practice the tooling may consist of a series of different tools that can have a great variety of implementation. For example, the result of implementing ITIL may consist
of a series of documents describing procedures and policies regarding System Operations and Support. For tooling regarding meta data about IT assets, it may be
determined that the IT assets have their own asset-specific attribution, and thereby dispersed tooling, or a strategic decision could be made to capture all meta data in
one, integrated Enterprise Repository. The Governance Policy Tooling work product defines and motivates the tooling of choice for a Governance domain (for example,
IT Portfolio Management, Architecture Governance, SOA Governance, etc.), and is not the collection of the actual tools.
Back to Top
TASK STEPS
1 Review background material. None
2 Determine tooling options. Tooling Options The Tooling Options lists all relevant options and the pros and cons of each option.
3 Choose and document the tooling options. Tooling Options The final Tooling Options provides a description, use and purpose for each chosen tooling option.
Back to Top
APPROACH
Review Background Material
Review the Mandate Matrix (GV.020), the Governance Policies Catalog (GV.030), the Impact Study and List of Proposed Organizational Changes (GV.040), and the
Policy Implementation Processes (GV.050) to understand the legislative drivers, standards and best practices, the proposed organizational changes, the new or updated
policies, and the Policy Implementation Processes as a basis to determine the tooling needs. Also review the Governance Strategy (GV.010) to understand what level of
automation is desired for both the policy repository and policy implementation.
Determine Tooling
Determine relevant tooling options that fit the need, and determine the pros and cons for the different tooling options.
For example, regarding System Operations and Support, you may consider ITIL, but you also want to consider an alternative such as ITSM, or CMMI or some
combination.
There are various COTS Enterprise Repository tool solutions (for example, the Oracle Enterprise Repository) that can be considered. As with other types of software tool
selection processes, a list of (preferably weighted) requirements can be defined. For each tool, determine if the tool supports a requirement and to what level so that the
tools can be compared to each other. Some COTS Enterprise Repository tooling may come with an out-of-the-box configuration that already covers most of the
requirements, and some tools allow for custom configuration. An important requirement to consider is the ability to support the established meta data models for the
various IT assets, as captured by the Projects Meta Model Descriptions (GV.092), the Applications Meta Model Descriptions (GV.094), and the Services Meta Model
Descriptions (GV.096). Also consider the IT Asset Management technique for meta models and life cycles of IT assets. It is also important to consider the ability to
publish meta data for IT assets in the enterprise, and support the queries that will be made by the stakeholders (such as the ability to find SOA services using keywords,
etc.). Finally, support for authorizing and reviewing changes made to the Enterprise Repository is also likely to be important.
Choose and Document the Tooling Options
Choose the best tooling options after considering the requirements and capture the motivation to choose each specific tool. Describe the use of each tooling option. For
each chosen tooling option, describe the use of each, for example, a tool to store and maintain all the identified polices, as well as how the tooling option is to be used for
the specific purpose.
The result of this task may trigger a need to go back and update the Policy Implementation Processes (GV.050) to make them fit the chosen automation option for the
process.
Back to Top
Enterprise Architect Present recommended tooling to client. 20
Solution Architect Provide tooling options to enterprise architect with benefits and prerequisites. 80
Back to Top
PREREQUISITES
Prerequisite Usage
Governance Strategy (GV.010) Use the Governance Strategy to understand the strategy for automation of procedures.
Mandate Matrix (GV.020) Use the Mandate Matrix that contains legislative drivers, standards, and best practices that the business decides to use
(or needs to adhere to) as an input to determine the tooling requirements.
Governance Policies Catalog (GV.030) Use the Governance Policies Catalog to understand which policies the organization should follow.
Impact Study and List of Proposed
Organizational Changes (GV.040)
Use the Impact Study and List of Proposed Organizational Changes to review the proposed changes and see how the
changes can be supported through tooling.
Policy Implementation Processes (GV.050) Use the Policy Implementation Processes to understand the processes to be implemented, and how the tooling can
support this.
Projects Meta Data Description (GV.092) Use the Projects Meta Data Description to determine the requirements for capturing the meta data about projects and
programs.
Applications Meta Data Description
(GV.094)
Use the Applications Meta Data Description to determine the requirements for capturing the meta data about
applications.
Services Meta Data Description (GV.096) Use the Services Meta Data Description to determine the requirements for capturing the meta data about services.
Other Meta Data Descriptions (GV.098) Use the Other Meta Data Descriptions to determine the requirements for capturing the meta data other than what is
needed for projects, programs, applications or services.
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique to determine requirements regarding the tool selection of Enterprise Repository tooling.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Governance Policy Tooling is used in the following ways:
to show how Governance may be supported through tooling, such as how to
store and maintain identified policies
how policy monitoring should be automated
to describe the motivation for each selected tool
Distribute the Governance Policy Tooling as follows:
to stakeholders of the Governance processes for review
to individuals responsible for the Governance Implementation (GV.100)
Back to Top
QUALITY CRITERIA
Is it clearly documented for which purpose the tool is recommended?
Is it clear for which Governance domain the tool should be used?
Have the pros and the cons been documented for the various tooling options?
Back to Top
GV.070 - DEFINE POLICY METRICS
During this task, you define the measurements that are used to objectively define the fulfillment of the business policies and objectives. The metrics should be
quantifiable. Typical metrics are business metrics, process metrics, financial metrics, usage and performance metrics. The metrics should match with the Strategy and
Standards component already defined in the Governance Strategy (GV.010).
When defining the metrics, keep in mind that the metrics should provide a basis for future decisions. Therefore, each metric should address the success of the
procedures and polices that have been put in place. In particular, you should be able to verify the effectiveness of the strategy that each policy or procedure implements.
ACTIVITY
GV.070.1
GV.070.2
Back to Top
WORK PRODUCT
Measurements Portfolio - The Measurements Portfolio contains exact measurements, including success and failure levels, for each business policy and objective that
should be implemented.
Back to Top
TASK STEPS
1 Review prerequisite documents. Measurements Portfolio -
Objective-Mandate-Policy
The Objective-Mandate-Policy shows the link between each objective with the related
mandate and policy.
2 Determine relevant measurements. Measurements Portfolio -
Measurement
The Measurement describes the identified KPIs with all the relevant measurement options.
3 Determine success/failure levels. Measurements Portfolio -
Success/Failure Levels
The Success/Failure Levels section describes for each KPI, the success/failure levels.
4 Review the Measurements Portfolio
with enterprise management.
Approved Measurements
Portfolio
The Approved Measurements Portfolio is the complete Measurements Portfolio approved and
accepted b the KPI owners and senior management of the enterprise.
Back to Top
APPROACH
Review Prerequisite Documents
Review the Governance Strategy (GV.010), the Mandate Matrix (GV.020) and the Governance Policies Catalog (GV.030). For each objective and principle identified in the
Governance Strategy, determine the related mandate (GV.020) and policy (GV.030) and determine if the specific policy addresses that objective or principle.
Determine Relevant Measurements
Determine how each objective-mandate-policy can be measured. It is important that each measurement can be quantified. Therefore, for each business objective within
the scope of the engagement, work with the enterprise stakeholders to identify key performance indicators (KPIs) to a level that can be measured. These levels will reflect
the target benefits and return on investment (ROI) goals expected. If the IPI is a measurement for improvement, it is important to indicate the timeframe in which the KPI
should have been achieved.
It may be difficult to identify appropriate KPIs for each objective and the proposal for actual measurement may cause some resistance. It is important that the people
#TOP #TOP
responsible for achieving the KPIs have realistic possibilities to impact the results. If the responsible manager/department is meant to be measured against a certain KPI,
but have no realistic possibilities to impact the results, obviously, this will cause resistance. In such situations, the related objective typically is not truly owned by the
manager/department. This may be due to that the fact that the objective has another owner, that the objective is wrongly phrased, or that the objective is documented at
too high a level, and therefore needs to be detailed to properly fit the responsibilities.
For example, if the business objective is to increase internal customer satisfaction for internal support, depending on the size of the organization, this objective should be
split into a number of detailed objectives that would be relevant for different responsible persons. For example, those being responsible for the support call center could
have an objective to reduce the average waiting time to less than 10 minutes when an employee makes a call. Other persons may be responsible for delivering service
on physical objects, such as laptops, mobile phones, etc. These people may have an objective to shorten the waiting time for the employee to actually have the item
fixed, or reduce the wait time until a replacement is received. In this way, you set objectives that each of the responsible managers or departments can own, and these
objectives will be easier to identify quantifiable measurements.
Some types of measurements can be automated. For example, in the call center situation, internal customer satisfaction can have one measurement indicating the
average waiting time when a customer calls during certain time intervals. At the end of each call another type of measurement can be done by automating the number of
questions asked to get an understanding of the quality of experience during the call. Another type of measurement can be done through periodic (internal) surveys. For
example, if one objective is to improve the level of satisfaction on how IT as a whole services the business, you may need to periodically ask representatives from the
business for feedback, and compare the results between surveys.
Determine Success/Failure Levels
Indicate the success and failure levels for each measurement: For each measurement, indicate the quantities that reflect a success, improvements required or failure. For
example, for the call center, a success measurement could be an average waiting time less than one minute when an employee calls between 2pm and 4pm, and a
failure measure could be an average waiting time more than ten minutes within the same timing interval.
If the implementation of a certain policy is expected to improve or increase some kind of measure, it is important to have a baseline that documents the current level.
Therefore, you should establish a baseline value for each of the identified Key Performance Indicators (KPIs), as well as target values to be gained within a given
timeframe or period as a result of the completion of a given IT Portfolio program or project. A KPI monitoring strategy and means of measuring improvement should be
determined in advance.
Review Measurements Portfolio with Enterprise Management
Review the metrics of each specific policy with the appropriate representatives in the enterprise.
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Compile Measurements Portfolio. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Governance Strategy (GV.010)
Mandate Matrix (GV.020)
Metrics Collection and Reporting Strategy (BA.017)
Use these work products to determine the objectives-mandates-policies to be measured.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Measurements Portfolio is used in the following ways:
as input to determine what kind of policy monitoring processes (GV.080) will be required
to understand what kind of measurements can support the business policies and objectives to be implemented
Distribute the Measurement Portfolio as follows:
to enterprise stakeholders that own the business policies and objectives to be measured
to enterprise stakeholders that will be impacted by the measurements
to individuals that should be involved determining the policy monitoring processes
Back to Top
QUALITY CRITERIA
Is there clear traceability between objectives and related mandates or policies?
Is there clear traceability between objectives and measurements?
Have the objectives been detailed into quantifiable KPIs?
Have success and failure levels been described for each measurement?
Has the timeframe for each success level been established?
Have the measurements been determined in collaboration with the objective owners?
Back to Top
GV.080 - DEFINE POLICY MONITORING PROCESSES
During this task, you define the monitoring processes necessary to measure compliance for a given policy. Metrics associated with the given policy and related objective
are used to ultimately determine compliance.
The following are some examples of objectives and possible measurements:
Objective Measurement
Customer satisfaction with IT
spending
Perform customer satisfaction surveys on a regular basis.
Increased productivity of the IT
staff
Evaluate each IT project and see if the amount of money spent per function point (or any other appropriate unit of measurement)
decreases over time.
In some cases, a third party may need to be involved to monitor the effectiveness of a given policy. For example, a company specializing in creating and performing
surveys to measure an increase in customer satisfaction in a reliable way.
Some policy monitoring can successfully be partly or fully automated. If this is the case, you may need to go back and update the Governance Policy Tooling (GV.060),
unless the required tooling was already specified for monitoring purposes. In some situations, the automation of the monitoring processes may be a substantial task. If so,
you should indicate what is required, and what method should be used for the automation of the processes.
ACTIVITY
GV.080.1
GV.080.2
Back to Top
WORK PRODUCT
Policy Monitoring Processes - The Policy Monitoring Processes contains all the processes that should be used to monitor and measure the policies to be implemented.
Each process describes the steps that are required for monitoring purposes, how this relates to the metrics defined for each policy to be measured, and how each
monitoring process should be implemented.
Back to Top
TASK STEPS
1 Identify monitoring processes. Policy Monitoring Processes
- Monitoring Processes
The Monitoring Processes is a list of each policy or objective that should be monitored, the
related metrics and the monitoring options identified for each metric.
2 Determine monitoring processes
implementation.
Policy Monitoring Processes
- Implementation
The Implementation component describes how the monitoring processes are to be
implemented.
3 Review the Policy Monitoring
Processes with enterprise
stakeholders.
Approved Policy Monitoring
Processes
The Approved Policy Monitoring Processes is the final work product, reviewed and
approved by the enterprise stakeholders owning each of the different policies.
4 Involve third parties. None
Back to Top
APPROACH
#TOP #TOP
Identify Monitoring Processes
For each policy defined in the Governance Policies Catalog (GV.030), using the metrics defined in the Measurement Portfolio (GV.070), identify a monitoring process that
can be used to monitor the effectiveness of the policy. Measurement options should be indicated as part of the Measurement Portfolio. Revisit the measurement options
and determine the monitoring processes necessary to implement each policy.
For example, for a call center, with a policy to increase customer satisfaction, you may need a monitoring process that measures the time between the time an employee
is calling support service, until the time when a call is answered by a representative. You may also decide to monitor the length of each call, or the satisfaction of each
customer after a call has been completed.
Describe the monitoring processes in a table similar to the following example:
Policy (GV.030) Objective
(GV.030)
KPI (GV.070) Measurement
Option
(GV.070)
Monitoring Process (GV.080)
Customers should experience
Excellent Service Support
(customers here are internal
customers to IT).
Increase
customer
satisfaction
Reduce Call Center
waiting time to be
less than 30
seconds on
average within end
of year.
Calculate
average wait
time for
incoming
calls.
Starting with the event that an employee calls the call center, records the time
the call is received, waits until the call is answered, and records the time.
Calculate the total time, and include in the current average. Monitors whether
average is higher than the maximum target average (30 sec). Alerts when
average becomes 20% higher than target average.
Overall satisfaction
rating of call
results to be
scored at an
average of 7 or
higher (scale 0-10)
Offer voluntary
survey at the
end of each
call.
Starting with the completion of a call, asking the employee to answer some
questions to what level (s)he was helped during the call. Calculates the
average, and monitors whether average rating is the same or lower than the
target average (7). Alerts when average become lower than target average.
99.5% availability of
online world wide
support service
Calculate
online
availability.
Continuous monitoring of online support services. Monitoring downtime and
calculating hourly overall availability. Provides Alerts each downtime when
passing 5 minutes, and provides notification when average availability falls
below target.
Incidents should be classified
indicating severity.
Ensure
handling of
incidents and
enhancements
following
proper
priorities
Incidents should
receive
classification of
severity
immediately when
they are known
No incidents
are to be
reported
without
classification.
Ensure that no incidents are handled without being classified according to the
classification system.
Incidents of highest severity
should be forwarded to
responsible person within 5
minutes after the incident has
been recorded with the highest
severity.
Calculate
average
forwarding
time for each
incident of
highest
severity.
Starting with the event in which an incident has received the highest severity,
warning the current owner of the incident and immediate need of forwarding,
and measuring the time before the incident has been acknowledged, and
received the status in progress.
Determine Monitoring Processes Implementations
Determine how each monitoring process should be implemented. An implementation may be manual, automatic or a combination of the two.
Consider extending the example table from the prior section by adding a column describing how each monitoring process should be implemented, as shown in the
following example:
Policy (GV.030) Objective
(GV.030)
KPI (GV.070) Measurement
Option
(GV.070)
Monitoring Process (GV.080) Implementation (GV.080)
Customers should
experience Excellent
Service Support
(customers here are
internal customers to
IT).
Increase
customer
satisfaction
Reduce Call
Center
waiting time
to be less
than 30
seconds on
average
within end of
year.
Calculate
average wait
time for
incoming
calls.
Starting with the event that an employee calls the
call center, records the time the call is received,
waits until the call is answered, and records the
time. Calculate the total time, and include in the
current average. Monitors whether average is
higher than the maximum target average (30 sec).
Alerts when average becomes 20% higher than
target average.
Complete required automated
implementation . Send immediate Alerts
by email to targeted individuals. Prepare
reports on results and send by email to
targeted individuals at 3pm each Friday.
Overall
satisfaction
rating of call
results to be
scored at an
average of 7
or higher
(scale 0-10)
Offer
voluntary
survey at the
end of each
call.
Starting with the completion of a call, asking the
employee to answer some questions to what level
(s)he was helped during the call. Calculates the
average, and monitors whether average rating is
the same or lower than the target average (7).
Alerts when average become lower than target
average.
Immediately, instruct the call center
representatives to ask the customer the
specified questions, and ask them to
record the results into a spreadsheet that
is sent for collection at the end of the
day.
In the long term, include an automated
service so that the customer receives a
call directly after ending the call, and is
asked to evaluate the service. Send
alerts by email to targeted individuals at
11pm each working day.
Provide reports on results sent by email
to targeted individuals at 3pm each
Friday.
99.5%
availability of
online world
wide support
service
Calculate
online
availability.
Continuous monitoring of online support services.
Monitoring downtime and calculating hourly overall
availability. Provides Alerts each downtime when
passing 5 minutes, and provides notification when
average availability falls below target.
Automatically monitor online renewal
service.
Immediately send Alerts to targeted
individuals.
Send reports on the results by email to
Incidents should be
classified indicating
severity.
Ensure
handling of
incidents and
enhancements
following
proper
priorities
Incidents
should
receive
classification
of severity
immediately
when they
are known
No incidents
are to be
reported
without
classification.
Ensure that no incidents are handled without being
classified according to the classification system.
The form that is used to record incidents
should not allow for incidents to be
saved without classification information.
Monitor check outs of code (already in
production) without reference to an
incident, or enhancement to prevent
working on code modifications for non-
recorded incidences/enhancements.
Immediately, send Alerts to responsible
manager for each incident.
Incidents of highest
severity should be
forwarded to
responsible person
within 5 minutes after
the incident has been
recorded with the
highest severity.
Calculate
average
forwarding
time for each
incident of
highest
severity.
Starting with the event in which an incident has
received the highest severity, warning the current
owner of the incident and immediate need of
forwarding, and measuring the time before the
incident has been acknowledged, and received the
status in progress.
When the support engineer (or employee
through the online service) has entered
an incident with highest severity, the
owner of the incident should receive
immediate warning about the incident.
Repeat the warning once every 30
minutes until the incident has been set to
in progress.
Record the time when the incident
received the highest severity, and when
the status of the incident changes to in
progress. Calculate the average time.
Send reports on results by email to
Note: The above example is a specification of business rules and required actions to be taken.
When determining the implementation for the monitoring processes, ensure that you allow for the parameters to change without making any changes to code. When the
monitoring processes are first identified, including the alerts, often limits could change, or the frequency on the alerts could change. Also, it should be possible to
dynamically change the recipients of the alerts.
If the actual programs or supporting software is known, then you should include this type of information as well. You may also identify candidate services to support the
implementation, where you see that the same type of implementations will be required for multiple monitoring processes. If it has been decided that BPM (Business
Process Management) tools will be used, then provide information on where and how this can best be applied in the various situations.
Review Policy Monitoring Processes with Enterprise Stakeholders
Review each of the suggested process with the appropriate stakeholders within the enterprise.
Involve Third Parties
If necessary, involve third parties in the policy implementation and execution. Make arrangements with third-party stakeholders that need to be involved to implement the
processes. The actual implementation of the processes is done during Governance Implementation (GV.100)
Back to Top
Cloud Roadmap
Back to Top
Enterprise Architect Establish and agree on monitoring process for successful Governance. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Governance Policy Tooling (GV.060)
Measurements Portfolio (GV.070)
Metrics Collection and Reporting Strategy (BA.017)
Use these work products to determine the policies-metrics to be monitored.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Policy Monitoring Processes work product is used in the following ways:
to show what kind of monitoring processes should be used to monitor the compliance to policies
to show what kind of alert mechanisms are suggested when the results fall outside the defined measure limits
as input to Governance Implementation (GV.100)
Distribute the Policy Monitoring Processes as follows:
to stakeholders of the policies
to individuals that should implement the monitoring processes
Back to Top
QUALITY CRITERIA
Have the monitoring processes and related implementations been reviewed and approved by the policy owners within the enterprise?
Is there a clear trace between policies and the monitoring processes and the implementations?
Have for each monitoring process alerting mechanisms been described that indicate who, how and when should be alerted?
Back to Top
GV.090 - DETERMINE FUNDING MODEL
During this task, you review an existing Funding Model, if present, validate this against new findings, and establish the Funding Model that should cover all required
funding for the IT spending required within a given timeframe.
ACTIVITY
GV.090.1
GV.090.2
Back to Top
WORK PRODUCT
Funding Model - The Funding Model is a description of sources of funds, how they can be procured, and a methodology for allotment and expenditures that provides for
an effective and efficient IT program that meets the organization's Business Strategy and Objectives.
Back to Top
TASK STEPS
1 Identify existing funding process. Existing Funding
Process Description
The Existing Funding Process Description describes how the funding is obtained in the current situation.
It should describe both capital expenditures and operating expenses.
2 Identify or determine asset
owners.
Asset Owners The Asset Owners component describes the financial owners for each IT asset of relevance.
3 Capture Expenditures Approval
Process.
Expenditures
Approval Process
The Expenditures Approval Process documents how expenditures are currently approved.
4 Discover any issues related to the
existing funding process.
Funding Issues The Funding Issues documents potential issues related to the current funding or approval processes.
5 Prioritize issues. Prioritized Funding
Issues
The Prioritized Funding Issues are the Funding Issues listed in a prioritized order.
6 Develop new Funding Model to
resolve issues.
Future Funding Model The Future Funding Model is a description of the funding model that can best support the organization's
Business Strategy and Objectives.
Back to Top
APPROACH
A balanced, sustainable Funding Model should provide the organization with a consistent focus on maximizing its resources to ensure that the IT spending are inline with
the Business Strategy (BA.010). It should allow for planning ahead, and should provide a targeted minimum level of service to the various organization units.
Identify Existing Funding Process
Identify how the current IT funding process is within the organization. Identify the sources of funds, and how they can be procured. Ensure that you capture the IT funding
on two planes, both capital expenditures and operating expenses. Capture how the individual business units fund each type of IT expense.
Identify or Determine Asset Owners
For the IT asset of relevance, identify the asset owner, i.e. who makes the decision about funding related to the asset.
Capture Expenditures Approval Process
Document how the IT expenditures are approved and the costs are allocated. Identify how costs are shared or centralized for shared IT capabilities and services, and
how the cost allocation is transferred to the business, if at all.
Discover Any Issues Related to Existing Funding Process
It is important that the Funding Model reflect the level of agility of the organization, and support the organizations Business Strategy and objectives. It must also support
the Enterprise IT Strategy and objectives that result from the business vision and strategy. Identify any issues related to the current funding processes, or ownerships that
may be a problem for realizing the strategies and objectives at hand.
Prioritize Issues
Prioritize the identified issues in collaboration with the business and IT stakeholders. Use the MoSCoW principle to identify the vital changes as Must Haves.
Develop New Funding Model to Resolve Issues
In developing a new Funding Model, ensure that you target the highest prioritized issues first.
Consider various approaches depending on the situation. Typically, consider if you will use a centralized or decentralized model, or a combination of the two. Keep in
mind, the nature of the business and how rapid changes are going to be implemented (the agility of the organization), as this should impact the Funding Model. The more
agile the organization, the more agile the Funding Model needs to be.
Often a centralized Funding Model where the IT management performs all spending decisions is less agile, but on the other hand, keeping it centralized makes it easier
to ensure that all IT spending will be in line with the overall Business Strategy and objectives. If you decide to use a decentralized Funding Model where each business
unit makes the decisions for their own IT spending, consider introducing a mechanism to ensure that the spending will be inline with the Business Strategy. Determine the
pros and cons for the various models. In most models, the IT management decides the IT spending impacting multiple business units.
Also, keep in mind, that the more service oriented the organization becomes, the more impact on the Funding Model. Typically, there is a need for a centralized enabling
technology infrastructure with enterprise-wide services shared by all business units. However, some services may originate from a single business unit and at a later
point of time be promoted to an enterprise service. The Funding Model must be able to handle funding changes that occur throughout the lifecycle of a service.
Back to Top
Cloud Roadmap
Back to Top
Discuss funding model options with client enterprise architect and client project sponsor. Make recommendation. 100
Client Enterprise Architect Participate in discussion. Provide assistance, as appropriate. *
Client Project Sponsor Participate in discussion. *
Client CIO *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business vision, goals and objectives.
Enterprise IT Strategy
(EA.065)
Use the Enterprise IT Strategy to understand the IT strategy supporting the Business Strategy and the corresponding IT goals and
objectives.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Funding Model is used in the following ways:
to illustrate issues that exist in the current Funding Model that need to be resolved in order to be able to support the business goals and objectives
to show what kind of changes are required to support the strategies
as input to Governance Implementation (GV.100) where the Funding Model will be implemented
Distribute the Funding Model as follows:
to senior management and other key stakeholders for review
to individuals that should implement the Governance
Back to Top
QUALITY CRITERIA
Have the issues related to the current Funding Model been documented?
Have the issues been prioritized?
Has a Future Funding Model been described that supports the organizations Business Strategy and objectives?
is there clear traceability to the objectives?
Is it expected that all the highest prioritized issues (the Must Haves) will be resolved through the implementation of the new Funding Model?
Back to Top
GV.092 - DETERMINE PROJECTS META DATA DESCRIPTION
In this task, you determine the meta data description to be used for the programs and projects in the configured Enterprise Repository, which is the basis for the IT Project
Portfolio. This meta data description includes a description of the properties, as well as a taxonomy, the lifecycle for projects (when having a specific project taxonomy
and lifecycle is useful for the enterprise), and the reporting requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Projects Meta Data Description - The Projects Meta Data Description consists of a listing and description of the properties of programs and projects, as well as the
taxonomy and lifecycle to be used for projects. Each property should have a sufficient description and an indication of whether it is optional or not for the program or
project. If the property uses a set of predefined values, those values are defined as well. Any associations that can exist between projects and other IT assets in the
Enterprise Repository are also identified. Furthermore, reporting requirements are captured, as well as what roles are authorized to retrieve and modify the information for
Back to Top
TASK STEPS
1 Determine project lifecycle. Project Lifecycle
Definition
This component identifies the lifecycle that projects can have in the enterprise.
2 Determine project
taxonomy.
Project Taxonomy This component defines the classification schema that is used to classify projects.
3 Determine program
properties.
Program Property
Definitions
This component defines the properties that will be captured for programs, including a description of each
property, whether it is optional or not, and a list of acceptable values for the property, where applicable.
4 Determine project
properties.
Project Property
Definitions
This component defines the properties that will be captured for projects, including a description of each
property, whether it is optional or not, and a list of acceptable values for the property, where applicable.
5 Determine project-IT asset
associations.
Project Associations This component identifies all associations that can be made between projects and other IT assets in the
6 Determine reporting
requirements.
Reporting
Requirements
This component describes the reports for providing information about the programs and projects.
7 Determine program and
project authorization
model.
Program and Project
Authorization Model
This component describes what roles in the organization should be able to retrieve and modify information for
Back to Top
APPROACH
The Projects Meta Data Description should support a proper capturing, classifying and tracking of projects. In a smaller enterprise, a simple spreadsheet may suffice.
However, as soon as maintaining an IT Project Portfolio is taken more seriously, a spreadsheet might soon be inadequate to sufficiently track the projects and the IT
assets to which they are related, and other type of software become a better option. Preferably, an Enterprise Repository is used that allows for configuration of the meta-
data that can be changed over time as the requirements change. Ideally, creating a project portfolio is done based upon tooling that support these kind of changes in
configuration, taking the features as well as limits of the tooling into account. Migrating from a spreadsheet to dedicated tooling afterwards may prove to be a relatively
time-consuming exercise otherwise.
The Projects Meta Model is best determined in a workshop involving the proper enterprise stakeholders. A list of possible stakeholders has been provided in the Roles
and Responsibilities section below. As a starting point, refer to the IT Asset Management technique for more details.
To ensure that the Enterprise Repository is populated properly and maintained afterwards, it is important to have sufficient buy-in from the stakeholders. Therefore it
should be clearly discussed what the goals of the enterprise are for having an IT Project Portfolio and what the information needs are to support those goals. These goals
normally have been captured in the Governance Strategy (GV.010). Try to prevent overkill, because that will likely result in data being captured poorly, resulting in
incomplete or incorrect information and may even result in the decommissioning of the program and project repository.
Determine Project Lifecycle
Consider a project lifecycle that can be used to indicate the status of every type of IT project in the enterprise and the state changes that can occur. Governing projects
and communicating about their status is easier when these statuses with their state changes have been properly defined.
Determine Project Taxonomy
Consider a Project Taxonomy that can be used to clearly classify the type of IT projects in the enterprise. Having a proper taxonomy defined, helps in Governance of
projects and communicating about them. The taxonomy is in particular helpful in scoping discussions about projects and assessing their value to the enterprise.
There can be various dimensions in a Project Taxonomy that may be helpful, including:
Project size (in budget and people involved)
Strategic significance for the business
Internal only or external people involved
Custom build, COTS or a combination
Determine Program Attributes
Consider using the properties as they have been suggested in the Projects Meta Data Description. You can use these as a starting point to discuss the program
properties that make sense for the enterprise.
Determine Project Attributes
Consider using the properties as they have been suggested in the Projects Meta Data Description. You can use these as a starting point to discuss the project properties
that make sense for the enterprise.
Determine Project Associations
Among the obvious candidate associations for projects with other IT assets are:
Related Program
Application Created
Required Applications
Impacted Applications
Stakeholders
Required Services
Produced Services
Determine Reporting Requirements
The Reporting Requirements should have a clear relation with the goals and associated information requirements for having an IT Project Portfolio. Making the Reporting
Requirements specific, for example, by means of prototyped reports and screens, will help in validating the set of properties that have been determined.
Determine Program and Project Authorization Model
Make sure that it is clear what roles in the organization are allowed to modify and retrieve the information about projects. This can have a considerable impact on how the
repository needs to be structured. The Authorization Model should be in line with all Governance policies from the Governance Policy Catalog (GV.030). Especially where
it concerns financial data, it should be made clear that access is compliant with these policies to prevent issues.
The roles should come from the Enterprise Stakeholder Inventory (BA.015). When dedicated tooling is used, these roles and their authorization should be configured in
the repository as well.
Back to Top
Enterprise Architect Organize the workshop and capture the requirements for the Projects Meta Model and provide information about the options of
the repository tooling so that it can be properly supported.
100
Client Enterprise Architect Provide requirements for the Project Taxonomy. *
Client Solution Architect Provide requirements for the Project Taxonomy. *
Client Project Manager Provide requirements for the Project Taxonomy. *
Client CIO Provide requirements for the Project Taxonomy. *
Back to Top
PREREQUISITES
Prerequisite Usage
(BA.015)
Use the Enterprise Stakeholder Inventory to determine the list of roles that need to be authorized for access to the program and
project information in the repository.
Governance Policy Catalog
(GV.030)
Use the Governance Policy Catalog to make sure that the Authorization Model for programs and projects is aligned with the
Governance policies.
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique as a reference for program and project meta data descriptions.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Projects Meta Data Description is used in the following ways:
to show what kind of properties are important to understand regarding project, programs and related assets
to understand the project and program lifecycles, and how they change throughout the lifecycle of the enterprise
to understand how projects and programs relate to other assets
as an input to the setup of an Enterprise Repository
as an input for Governance Implementation (GV.100)
Distribute the Projects Meta Data Description as follows:
to individuals setting up the Enterprise Repository supporting the Governance Implementation
to stakeholders that are involved in the creation or changing of project or program and related assets [controlled as part of the Governance Implementation
(GV.100)]
Back to Top
QUALITY CRITERIA
Have the statuses of the project lifecycle been clearly defined?
Has the Project Taxonomy been clearly defined?
Have all program and project properties been clearly defined, including which properties are mandatory for each status?
Have the appropriate associations with other IT assets been identified?
Back to Top
GV.094 - DETERMINE APPLICATIONS META DATA
DESCRIPTION
In this task, you determine the meta data description to be used for the applications in the configured Enterprise Repository, which is the basis for the IT Application
Portfolio. This meta data description includes a description of the properties, as well as a taxonomy, the lifecycle for applications, and the reporting requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Applications Meta Data Description - The Applications Meta Data Description consists of a listing and description of the properties of applications, as well as the
taxonomy and lifecycle to be used for applications. Each property should have a sufficient description and an indication of whether it is optional or not for the application.
If the property uses a set of predefined values, those values are defined as well. Any associations that can exist between applications and other IT assets in the
Enterprise Repository are also identified. Furthermore, reporting requirements are captured, as well as what roles are authorized to retrieve and modify the information for
applications.
Back to Top
TASK STEPS
1 Determine application
lifecycle.
Application
Lifecycle
Definition
This component identifies the lifecycle that applications can have in the enterprise.
2 Determine applications
taxonomy.
Application
Taxonomy
This component defines the classification schema that is used to classify applications.
properties.
Application
Property
Definitions
This component defines the properties that will be captured for applications, including a description of each property,
whether it is optional or not, and a list of acceptable values for the property, where applicable.
4 Determine application -
IT asset associations.
Application
Associations
This component identifies all associations that can be made between applications and other IT assets in the Enterprise
Repository.
5 Determine reporting
requirements.
Reporting
Requirements
This component describes the reports for providing information about the applications.
authorization model.
Application
Authorization
Model
This component describes what roles in the organization should be able to retrieve and modify information for
applications.
Back to Top
APPROACH
The Applications Meta Data Description should support a proper capturing, classifying and tracking of applications. In a smaller enterprise, a simple spreadsheet may
suffice. However, as soon as maintaining an Application Portfolio is taken more seriously, a spreadsheet might soon be inadequate to sufficiently track the applications
and the IT assets to which they are related, and other type of software become a better option. Preferably, an Enterprise Repository is used that allows for configuration
of the meta-data that can be changed over time as the requirements change. Ideally, creating a application portfolio is done based upon tooling that support these kind of
changes in configuration, taking the features as well as limits of the tooling into account. Migrating from a spreadsheet to dedicated tooling afterwards may prove to be a
relatively time-consuming exercise otherwise.
The Applications Meta Model is best determined in a workshop involving the proper enterprise stakeholders. A list of possible stakeholders has been provided in the
Roles and Responsibilities section below. As a starting point, refer to the IT Asset Management technique for more details.
To ensure that the Enterprise Repository is populated properly and maintained afterwards, it is important to have sufficient buy-in from the stakeholders, especially the
application administrators. Therefore it should be clearly discussed what the goals of the enterprise are for having an Application Portfolio and what the information needs
are to support those goals. Try to prevent overkill, because that will likely result in data being captured poorly, resulting in incomplete or incorrect information and may
even result in the decommissioning of the program and application repository.
Determine Application Lifecycle
Consider an application lifecycle that can be used to indicate the status of every type of application in the enterprise and the state changes that can occur. Different types
of applications may require a different kind of lifecycle. For example, standard desktop applications normally have a simpler lifecycle than homegrown applications.
Governing applications and communicating about their status is easier when these statuses with their state changes have been properly defined.
Determine Application Taxonomy
Consider an Application Taxonomy that can be used to clearly classify the type of application in the enterprise. Having a proper taxonomy defined, helps in Governance
of applications and communicating about them. The taxonomy is in particular helpful in assessing their owners and value to the enterprise.
There can be various dimensions in a Application Taxonomy that may be helpful, including:
Strategic significance for the business
Desktop, administration, developer, etc.
Custom build, COTS or a combination
Determine Application Properties
Consider using the properties as they have been suggested in the Applications Meta Data Description. You can use these as a starting point to discuss the application
properties that make sense for the enterprise.
Determine Application Associations
Among the obvious candidate associations for applications with other IT assets are:
Dependant Applications
Depending Applications
Stakeholders
Provided Services
Impacting Projects
The Reporting Requirements should have a clear relation with the goals and associated information requirements for having an Application Portfolio. Making the
Reporting Requirements specific, for example, by means of prototyped reports and screens, will help in validating the set of properties that have been determined.
Determine Application Authorization Model
Make sure that it is clear what roles in the organization are allowed to modify and retrieve the information about applications. This can have a considerable impact on how
the repository needs to be structured. The Authorization Model should be in line with all Governance policies from the Governance Policy Catalog (GV.030). Especially
where it concerns financial data, it should be made clear that access is compliant with these policies to prevent issues.
the repository as well.
Back to Top
Enterprise Architect Organize the workshop and capture the requirements for the Applications Meta Model and provide information about the
options of the repository tooling so that it can be properly supported.
100
Client Enterprise Architect Provide requirements for the Application Taxonomy. *
Client Solution Architect Provide requirements for the Application Taxonomy. *
Client CIO Provide requirements for the Application Taxonomy. *
Back to Top
PREREQUISITES
Prerequisite Usage
(BA.015)
Use the Enterprise Stakeholder Inventory to determine the list of roles that need to be authorized for access to the application
information in the repository.
Governance Policy Catalog
(GV.030)
Use the Governance Policy Catalog to make sure that the Authorization Model for applications is aligned with the Governance
policies.
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique as a reference for applications meta data descriptions.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Applications Meta Data Description is used in the following ways:
to show what kind of properties are important to understand about applications and related assets
to understand the application lifecycles, and how they change throughout the lifecycle of the enterprise
to understand how applications relate to other assets
as an input for Governance implementation (GV.100)
Distribute the Applications Meta Data Description as follows:
to stakeholders that are involved in the creation or modification of applications and related assets [controlled as part of the Governance Implementation (GV.100)]
Back to Top
QUALITY CRITERIA
Have the statuses of the application lifecycle been clearly defined?
Has the Application Taxonomy been clearly defined?
Have all application properties been clearly defined, including which properties are mandatory for each status?
Back to Top
GV.096 - DETERMINE SERVICES META DATA DESCRIPTION
In this task, you determine the meta data description to be used for the service-oriented architecture (SOA) services, which is the basis for the Service Portfolio. This meta
data description includes a description of the services and service-related assets, and their properties, as well as the taxonomies, the lifecycle for the services, and the
reporting requirements. A proper Service Portfolio plays a crucial role in service identification and discovery, which in turn is crucial to achieve the true benefit from a
SOA.
This task is only applicable when service-oriented architecture (SOA) is involved in some form.
ACTIVITY
Back to Top
WORK PRODUCT
Services Meta Data Description - The Services Meta Data Description consists of a listing and description of the service-related asset types and their properties as used
in service engineering, as well as the taxonomy and lifecycle for each of those asset types. This is done in terms of meta data description describing a service or service-
related asset with respect to an enterprise-level approach to service engineering. The service-related asset types may include the following:
SOA Realization Plan
Service
Service Contract
Service Implementation
Service Interface
Service Package
Service Test Case
Service Test Plan
Service Usage Agreement
Each asset type and each property of that asset type should have a sufficient description for people to know how to use it for asset management. Each property is
documented with an indication of whether it is optional or not. If the property uses a set of predefined values, those values are defined as well. Any relationships that can
exist between the assets types in the repository are also identified. Furthermore, reporting requirements are captured, as well as what roles are authorized to retrieve and
modify the information for the services. In particular, the Services Meta Data Description should support effective service identification and discovery and service
engineering.
Back to Top
TASK STEPS
1 Determine
service
taxonomies.
Service
Taxonomies
This component defines the classification schemas that are used to classify SOA services.
2 Determine
service
lifecycle.
Service
Lifecycle
Definition
This component identifies the lifecycle that SOA services can have in the enterprise.
3 Determine
service-
related asset
types.
Service-
Related Asset
Type
Definitions
This component defines the service-related asset types that will be captured for SOA service engineering, including a description of
each property, whether it is optional or not, and a list of acceptable values, where applicable.
4 Determine
asset
properties.
Asset
Properties
This component defines the properties of each type of asset that has been identified in the previous step.
5 Determine
asset
relationships.
Asset
Relationships
This component identifies all relationships that can be made between assets of the same or different type as identified in step 3 or
any of the asset types defined in the Projects Meta Data Description (GV.092), Applications Meta Data Description (GV.094). When
these work products are not available, existing relationships between IT assets might be determined from the Maintained Repository
of Artifacts (IP.080).
#TOP #TOP
6 Determine
reporting
requirements.
Reporting
Requirements
This component describes the reports for providing information about the services or service-related assets.
7 Determine
authorization
model.
Authorization
Model
This component describes what roles in the organization should be able to retrieve and modify information for services and service-
related assets.
Back to Top
APPROACH
The Services Meta Data Description should support a proper capturing, classifying and tracking of SOA service-related assets in a Service Portfolio. In a smaller
enterprise, a simple spreadsheet may suffice. However, as soon as maintaining an Service Portfolio is taken more seriously, a spreadsheet might soon be inadequate to
sufficiently track the services and related assets, and other type of software become a better option. Preferably, an Enterprise Repository is used that allows for
configuration of the meta-data that can be changed over time as the requirements change. Ideally, creating a Services Meta Model is done based upon tooling that
support these kind of changes in configuration, taking the features as well as limits of the tooling into account. Migrating from a spreadsheet to dedicated tooling
afterwards may prove to be a relatively time-consuming exercise otherwise.
The Services Meta Data Description is best determined in a workshop involving the proper enterprise stakeholders. A list of possible stakeholders has been provided in
the Roles and Responsibilities section below. As a starting point, see the Techniques section below to refer to the SOA Service Lifecycle technique for more details.
should be clearly discussed what the goals of the enterprise are for having a Service Portfolio and what the information needs are to support those goals. As a Service
Portfolio plays a crucial role in service identification and discovery as well as service engineering, the rationale to have one, and the Services Meta Data Description for
that matter, should not be too hard to identify. Try to prevent overkill, because that will likely result in data being captured poorly, resulting in incomplete or incorrect
information and may even result in jeopardizing the Service Portfolio.
Determine Service Taxonomies
Consider Service Taxonomy that can properly support service identification and discovery and service engineering. For example, when business analysts want to
discover already available services, their view on the Service Portfolio should provide a folder-like structure compliant with the Function Model that allows them to follow
their decomposition path in the repository to discover assets already available on a specific level.
There can be various taxonomy dimensions that may be helpful, including:
Business Category (path in the Function Model)
Scope (strategic significance for the business)
Type (for example, presentation, business process, business activity, data, access, utility)
To identify taxonomies, you need to understand the ways different stakeholders organize assets related to them. A business analyst may organize business functions
along the business Function Model. A Service Portfolio manager may organize the Service Portfolio along the scope to understand impact of any change to the Service
Portfolio. An architect organizes services along the logical layers of the SOA Reference Architecture. The taxonomies should help the different stakeholders to
collaborate by allowing them to use their own organizational model to identify assets of other stakeholders as well.
Carefully distinguish between taxonomies and other properties. Think of each taxonomy as if you were creating a folder structure on a shared hard disk, where the
taxonomy should help you navigate. If navigation is not needed, but its more similar to expressing flavors, or if it just applies to a single asset type, consider implementing
a normal property instead.
In order to implement taxonomies in an Enterprise Repository, each of them can be represented as a property to the applicable assets. Typically, each asset should allow
the classification against all taxonomies available. If an asset cannot be classified within a specific taxonomy, ensure that the stakeholders associated with the taxonomy
do not have an interest in that asset. Otherwise, review the design of the taxonomy chosen.
Determine Service Lifecycle
Consider a project lifecycle that can ensure that versioning of services is properly supported, allowing for multiple versions of the same service to run in parallel to prevent
that all consumers need to switch to the new version at the same time. Governing services and communicating about their status is easier when these statuses with their
state changes have been properly defined. See the SOA Service Lifecycle technique for more details.
Review the Service Engineering approach to understand the various touch points of a service lifecycle within the software delivery process. This will be needed in the
next step to understand the assets that might be needed along the lifecycle.
Determine Service-Related Asset Types
For each object of interest in the context of the service lifecycle, consider defining an asset type. For services, you may use the asset types as they have been suggested
in the Services Lifecycle technique Assets and the Service Lifecycle. See the SOA Service Lifecycle technique for more details.
Other asset types are discussed in the Projects Meta Model (GV.092), and the Applications Meta Model (GV.094), or can be derived from the Maintained Repository of
Artifacts (IP.080). A complete set of IT asset type descriptions can be found in the IT Asset Management technique. See the IT Asset Management technique for more
details.
As a starting point to discuss asset types that make sense for the enterprise, refer to the IT Asset Management technique for more details. Try to understand where the
asset needs to be created in the software development process and where it will be updated or used as input. Keep in mind that SOA is about creating reuse across the
enterprise, not for just one project.
To prevent over design, make sure there is a clear need for each of the asset types in the Services Meta Model.
Determine Asset Properties
To support proper reuse of a service, determine what information is relevant to other projects having an interest in them. To prevent information overload during service
identification and discovery and service engineering, make sure that each property addresses a clearly identified information need.
Determine Asset Relationships
Review the asset types defined and discover the relationships between them. Review the requirements regarding impact analysis and information flow tracking. Try to
understand how the assets are used in the software development process in relation to each other.
The Reporting Requirements should have a clear relation with the goals and associated information requirements for having a Service Portfolio. Making the Reporting
Requirements specific, for example, by means of prototyped reports and screens, will help in validating the set of asset types with their properties that have been
determined.
Determine Service Portfolio Authorization Model
Make sure that it is clear what roles in the organization are allowed to modify and retrieve the information about the Service Portfolio. This can have a considerable
impact on how the repository needs to be structured. The Authorization Model should be in line with all Governance policies from the Governance Policy Catalog
(GV.030). Especially where it concerns financial data, it should be made clear that access is compliant with these policies to prevent issues.
the repository as well. Assert that all roles using a property along the software development process will have the rights needed to access the assets in the appropriate
way.
Back to Top
Back to Top
Enterprise Architect Organize the workshop and capture the requirements for the various stakeholders and provide information about the options of
the repository tooling so that it can be properly supported, ensuring consistency and applicability of the meta data description.
100
Client Enterprise Architect Provide requirements. *
Client Solution Architect Provide requirements. *
Client Software
(SDLC) Staff
Provide requirements. *
Client CIO Provide requirements. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise
Stakeholder
Inventory
(BA.015)
Use the Enterprise Stakeholder Inventory to determine the list of roles that need to be authorized for access to the service repository.
Governance
Policy
Catalog
(GV.030)
Use the Governance Policy Catalog to make sure that the Authorization Model for services is aligned with the Governance policies.
Technology
Reference
Architectures
(EA.075)
The Technology Reference Architecture for SOA may provide input regarding the definition of a service and its components, taxonomies and
properties used in architecture, architectural policies that should be managed with the repository and sometimes the Technology Reference
Architecture for SOA already includes a definition of the Service Lifecycle and the Versioning strategy, that needs to be transferred into the Services
Meta Data Description.
Projects Meta
Data
Description
(GV.092)
If available, the Projects Meta Data Description is used to identify the relationships between the services with related assets on one hand and projects
on the other.
Applications
Meta Data
Description
(GV.094)
If available, the Application Meta Data Description is used to identify the relationships between the services with related assets on one hand and
applications on the other.
Maintained
Repository of
Artifacts
(IP.080)
If available, the Maintained Repository of Artifacts can be used to determine the relationships between other related assets and asset types.
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique as a reference for services meta data descriptions.
Service Architecture Use this guide to understand the architecture standards and guidelines that apply to SOA services.
SOA Service Lifecycle Use this guide to understand the SOA service lifecycle.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Services Meta Data Description is used in the following ways:
to show what kind of properties are important to understand about services and related assets
to understand the service lifecycle, and how it changes throughout the lifecycle of the enterprise
to understand how a service relates to other assets
Distribute the Services Meta Data Description as follows:
to individuals setting up the Enterprise Repository in support of the Governance Implementation
to stakeholders that are involved in the creation or modification of services and related assets [controlled as part of the Governance Implementation (GV.100)]
Back to Top
QUALITY CRITERIA
Have the statuses of the service lifecycle been defined clearly?
Does the service lifecycle support versioning of services?
Has the Service Taxonomy been clearly defined?
Does the Service Taxonomy effectively support service identification and discovery?
Does the Service Taxonomy effectively support service engineering?
Have all service-related asset types been clearly defined, including which properties are mandatory for each status?
Back to Top
GV.098 - DETERMINE OTHER META DATA DESCRIPTIONS
In this task, you determine the lifecycles and meta data descriptions to be used for IT asset types other than than programs and projects (covered by GV.092),
applications (covered by GV.094) and SOA services (covered by GV.096). For each asset type, the meta data descriptions includes a definition of the asset type and its
properties, its lifecycle, the relationships with other asset types, taxonomies and reporting requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Other Meta Data Descriptions - The Other Meta Data Descriptions consists of a listing and description of the asset types other than programs, projects, applications and
SOA services. The asset types to capture have been identified in the Governance Policy Catalog (GV.030). The description for each asset type consists of a definition, a
description of usage of the asset type and their properties, the lifecycle of the asset type, relationships to other asset types, taxonomies that may apply, and all reporting
requirements on the assets. Example of assets types are:
systems
standards
policies
requirements
models
use cases
stakeholder definitions
entities
database schemas
infrastructure platforms
viewpoints and view
reference architectures
implementations
test scenarios
test cases
change requests
Each asset type and each property of that asset type should have a sufficient description for people to know how to use it for asset management. Each property is
documented with an indication of whether it is optional or not. If the property uses a set of predefined values, those values are defined as well. Any relationships that can
exist between the assets types in the repository are also identified. Furthermore, reporting requirements are captured, as well as what roles are authorized to retrieve and
modify the information for the assets . In particular, the Other Meta Data Description should support effective service identification and discovery of assets.
Back to Top
TASK STEPS
1 Determine
taxonomies.
Asset Type
Taxonomies
This component defines the classification schemas that are used to classify the asset types.
2 Determine
lifecycle.
Asset Type
Lifecycle
Definition
This component identifies the lifecycle that an asset can have in the enterprise.
3 Determine
reporting
requirements.
Reporting
Requirements
This component describes the reports for providing information about the assets.
4 Determine
properties.
Asset Type
Properties
This component defines the properties of each type of asset that has been identified in the previous step.
5 Determine
relationships
Asset Type
Relationships
This component identifies all relationships that can be made between assets of the same or different type as identified in step 4 or
any of the asset types defined in the Projects Meta Data Description (GV.092), Applications Meta Data Description (GV.094), or
Services Meta Data Description (GV.096).
6 Determine
authorization
model.
Authorization
Model
This component describes what roles in the organization should be able to retrieve and modify information for these assets.
Back to Top
APPROACH
The Other Meta Data Descriptions should support a proper capturing, classifying and tracking of assets in the Enterprise Repository. In a smaller enterprise, a simple
spreadsheet with a tab for each asset type may suffice. However, as soon as maintaining IT assets is taken more seriously, a spreadsheet might soon be inadequate,
and another type of software becomes a better option. Preferably, dedicated Enterprise Repository software is used that allows for configuration of the meta data that can
be changed over time as the requirements change. Ideally, creating meta models is done based upon tooling that support these kind of changes in configuration, taking
the features as well as limits of the tooling into account. Migrating from a spreadsheet to dedicated tooling afterwards may prove to be a relatively time-consuming
exercise otherwise.
The Other Meta Data Descriptions is best determined in a workshop involving the proper enterprise stakeholders. A list of possible stakeholders has been provided in the
Roles and Responsibilities section below, but the actual participants will depend on the type of assets being defined.
should be clearly discussed what the goals of the enterprise are for having a Enterprise Portfolio and what the information needs are to support those goals. This should
already have been captured in the Policy Implementation Processes (GV.050), but should be pointed out at this stage. Try to prevent overkill in capturing data, because
that will likely result in data being captured poorly, resulting in incomplete or incorrect information and may even result in jeopardizing the usage of the Enterprise
Repository. Therefore, clearly capture the purpose of each property.
Determine Taxonomies
Consider Taxonomies that can properly support identification and discovery of assets. For example, when business analysts want to discover existing entities owned by a
specific business domain, their view on the entities should provide a folder-like structure where entities are organized by business domain
There can be various taxonomy dimensions that may be helpful, including:
Business Category (path in the Function Model)
Scope (strategic significance for the business)
Type
To identify taxonomies, you need to understand the ways different stakeholders organize assets related to them. A business analyst may organize business functions
along the business Function Model. An architect organizes assets along his architectural domain. The taxonomies should help the different stakeholders to collaborate by
allowing them to use their own organizational model to identify assets of other stakeholders as well.
Carefully distinguish between taxonomies and other properties. Think of each taxonomy as if you were creating a folder structure on a shared hard disk, where the
taxonomy should help you navigate. If navigation is not needed, but its more similar to expressing flavors, or if it just applies to a single asset type, consider implementing
a normal property instead.
In order to implement taxonomies in an Enterprise Repository, each of them can be represented as a property to the applicable assets. Typically, each asset should allow
the classification against all taxonomies available. If an asset cannot be classified within a specific taxonomy, ensure that the stakeholders associated with the taxonomy
do not have an interest in that asset. Otherwise, review the design of the taxonomy chosen.
Determine Lifecycle
Consider a project lifecycle that can ensure that versioning of assets is properly supported, allowing for multiple versions of the same asset to run in parallel to prevent
that all users need to switch to the new version at the same time. Governing assets and communicating about their status is easier when these statuses with their state
changes have been properly defined.
The Reporting Requirements should have a clear relation with the goals and associated information requirements for capturing information about assets. Making the
Reporting Requirements specific (for example, be means of prototype reports and screens) helps in validating the set of asset types with their properties.
Determine Properties
To support proper reuse of an asset, determine what information is relevant to other stakeholders having an interest in them. To prevent information overload during
discovery, make sure that each property addresses a clearly identified information need. The best way to do this is by starting with Reporting Requirements and only
capturing data for which there is a requirement on which to report (either on a screen or in an actual report).
Determine Relationships
Review the asset types defined and discover the relationships between them. Review the requirements regarding impact analysis and information flow tracking. Try to
understand how the assets are used in the software development process in relation to each other.
Determine Authorization Model
Make sure that it is clear what roles in the organization are allowed to modify and retrieve the information about a specific asset type. This can have a considerable
impact on how the repository needs to be structured. The Authorization Model should be in line with all Governance policies from the Governance Policy Catalog
(GV.030). Especially where it concerns financial data, it should be made clear that access is compliant with these policies to prevent issues.
the repository as well. Assert that all roles using a property along the software development process will have the rights needed to access the assets in the appropriate
way.
Back to Top
Enterprise Architect Organize the workshop and capture the requirements for the various stakeholders and provide information about the options of
the repository tooling so that it can be properly supported, ensuring consistency and applicability of the meta data descriptions.
100
Client Enterprise Architect Provide requirements. *
Client Solution Architect Provide requirements. *
Client Software
(SDLC) Staff
Provide requirements. *
Client CIO Provide requirements. *
Back to Top
PREREQUISITES
Prerequisite Usage
(BA.015)
Use the Enterprise Stakeholder Inventory to determine the list of roles that need to be authorized for access the asset types.
Governance Policy Catalog (GV.030) Use the Governance Policy Catalog to make sure that the Authorization Model for each IT asset is aligned with the
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique as a reference for other meta data descriptions.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Other Meta Data Descriptions is used in the following ways:
to show what kind of properties are important to understand about any other unknown assets such as project, program, services or applications and their related
assets
to understand the lifecycles of the other assets, and how they change throughout the lifecycle of the enterprise
to understand how the assets relate to other enterprise assets
Distribute the Other Meta Data Descriptions as follows:
to stakeholders that are involved in the creation or changing of the assets and their related assets [controlled as part of the Governance Implementation (GV.100)]
Back to Top
QUALITY CRITERIA
Have the statuses of the lifecycles been clearly defined
Does the lifecycle support versioning of assets?
Have the taxonomies been clearly defined?
Do the taxonomies effectively support identification and discovery?
Have the appropriate associations with other IT asset types been identified?
Is it clear which stakeholders are allowed update asset types and their properties?
Back to Top
GV.100 - IMPLEMENT GOVERNANCE
During this task, you roll-out the Policy Implementation Processes (GV.050) and the Policy Monitoring Processes (GV.080) previously defined for the enterprise. This
includes the following activities:
Publish new or updated Governance processes.
Install (updates of) supporting Governance tooling.
Train people in the enterprise on the Governance processes and supporting tooling.
Activate the Governance monitoring mechanisms.
Normally, this task does not concern activities such as developing Governance tooling or configuring an Enterprise Repository or the migration of existing data into the
Enterprise Repository. These types of activities would be covered by one or more Implement projects. However, in the case where configuring the supporting tooling
does not involve a significant effort and there is not a significant amount of existing data to acquire, you may consider including it within the scope of this task.
ACTIVITY
GV.090.1
GV.090.2
Back to Top
WORK PRODUCT
Governance Implementation - The Governance Implementation is the actual implementation of the Governance policies the organization should follow. It also includes
the transition of developed supporting tooling, and activation of the monitoring mechanisms that should be put in place to monitor the efficiency of the policy
implementations.
An important part of any Governance implementation is the introduction of an Enterprise Repository. This is a design-time repository containing information about IT
assets (rather than containing the assets themselves) with the purpose of retrieving information about those assets in an effective way. Typically, an Enterprise
Repository is implemented using dedicated tooling, but may consist of a set of spreadsheets. However, spreadsheets that contain information that is only accessible via
the individuals maintaining them, do not qualify as (part of) an Enterprise Repository.
When configuring the Governance tooling, data acquisition, or testing is expected to take a considerable amount of time. Therefore these activities are typically not part of
this task. Instead a separate Implement project should be executed to cover configuration, data acquisition and testing. This will also support proper estimation of such an
effort.
Back to Top
TASK STEPS
1 Implement
Funding Model
Implemented
Funding Model
The Implemented Funding Model contains a record of how the Funding Model has actually been implemented.
2 Implement
organizational
changes.
Implemented
Organizational
Changes
The Implemented Organizational Changes contains a record of all the organizational changes that have been executed,
when the change was completed, and documents the results of each change.
3 Configure tooling. Configured
Governance
Tooling
The Configured Governance Tooling consists of the actual tools being configured to support the requirements of the related
This step would only be performed If there is new tooling to be configured or changes required to existing tooling.
4 Acquire existing
data.
Governance
Tooling Populated
with Data
This component consists of the actual Governance tooling being populated with existing data.
5 Transition policy
infrastructure.
Policy Infrastructure
in Production
The Policy Infrastructure in Production consists of the actual infrastructure supporting the Governance policies, that is, the
frameworks and tooling described in the Governance Policy Tooling (GV.060) being fully supported and operational and
being successfully used for its established Governance purpose.
6 Train people. Trained People Trained People have learned what they need to succeed with the new Governance Implementation and are ready to
adhere to the new policies. The component provides a list of all people that have been trained, as well as which training
they received and on what date.
7 Activate
Governance
monitoring
mechanisms.
Activated
Governance Policy
Monitoring
Processes
The Activated Governance Policy Monitoring Processes is the actual monitoring procedures being put into production to
measure and monitor how the enterprise complies to the established Governance policies.
Back to Top
APPROACH
Implement Funding Model
Ensure that the Funding Model is implemented and communicated as required. The Funding Model should be implemented as documented in the Funding Model
(GV.090).
Implement Organizational Changes
Ensure that the required changes are performed. Ensure that everyone knows his or her roles and responsibilities, and that the communication is performed properly.
This could be a substantial task, and in some situations would be better handled as a separate (sub) project. Refer to the Organizational Change Management process
for more information and related tasks.
Configure Tooling
Some Governance policies are supported by related tooling. For example, the policies may require an Enterprise Repository be established. This may be supported by (a
set of) spreadsheets to configure, or by a dedicated Enterprise Repository tooling for which meta data structures and their relationships need to be set up and configured.
In the case the tooling required minimal configuration, you may consider doing this within the scope of this task. When configuration of the tooling requires a considerable
amount of effort, and involves development and testing, this is better done as part of an Implementation project.
Acquire Existing Data
Some types of Governance tooling need to be populated with data. In the context of this task, acquiring existing data concerns manual data entry of a limited amount of
such data.
When acquiring data concerns a significant amount of data or a conversion of data, this is better done as part of an Implement project. For example, an organization that
already has a significant amount of planned or implemented SOA Services may need a considerable amount of time to harvest the data of these services. Especially
when a feature to automatically harvest data of runtime artifacts is used, this very often results in data being harvested that has no value to manage through an
Enterprise Repository (because there is no foreseen reuse of meta data by several stakeholders, nor does it add value to an impact analysis). In that case, time may be
needed to remove superfluous data from the Enterprise Repository. Other organizations may need to create custom code to migrate existing spreadsheets to the
Transition Policy Infrastructure
Setup the frameworks and tooling, as described in the Governance Policy Tooling (GV.060). Examples range from rolling out a framework such as ITIL to transitioning
tools such as a configured Enterprise Repository, Oracle Web Service Manager, or a runtime service registry (UDDI).
When the implementation of some Governance tool is the result or product of an Implementation project (such as configuring and populating the Enterprise Repository),
the Implementation project should cover the transition from development to production, including an acceptance testing process. In such cases, this Transition Policy
Infrastructure task step is limited to co-coordinating this transition activity with other, related Governance Implementation activities, and covers the final acceptance of the
product of that Implement project.
Train People
To train people on the Governance Policies and Procedures is a crucial step in the Governance Implementation. This is an opportunity to:
Explain the reasoning behind the change, and the need for everyone to be a part of the implementation in order to be successful.
Explain the roles and responsibilities of all stakeholders, and which role applies to each individual.
Explain what kind of measuring and monitoring mechanisms will be used to measure the effectiveness of the Governance Implementation. It is important to prevent
resistance, so the latter must be explained carefully.
Train people on the Governance tooling, for example, how to use the Enterprise Repository in the context of the established Governance policies.
If the implementation of some Governance tool is the product of an Implement project, the training on that tooling is typically covered by the Implement project itself. In
that case, this task step is limited to co-coordinating this training activity with other Governance-related training.
Activate Governance Monitoring Mechanisms
Initiate procedures that monitor how the enterprise complies to the established Governance policies. Monitoring can range from (ad-hoc) reviews of how people comply
with those policies, to activating tooling that automatically alerts the appropriate people if policy violations occur.
Back to Top
Back to Top
Enterprise Architect Assist the client enterprise architect in implementing the Funding Model and the Organizational Changes for Governance. 100
Client Enterprise Architect Implement the Funding Model and the Organizational Changes for Governance. *
Back to Top
PREREQUISITES
Prerequisite Usage
Policy Implementation Processes (GV.050)
Measurements Portfolio (GV.070)
Policy Monitoring Processes (GV.080)
These work products detail the procedures and metrics that are part of the Governance Implementation.
Governance Policy Tooling (GV.060) Use the Governance Policy Tooling to configure any tooling that is part of the Governance Implementation.
Funding Model (GV.090) Use the Funding Model to implement the Funding Model that is part of the Governance Implementation.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Governance Implementation contains a record of the steps and results of the actual implementation of the Governance. This is used in the following ways:
as a record of what was included in the particular roll-out
as a record of how this particular roll-out was implemented
as input to lessons learned that may be used when Governance should be updated or implemented for other Governance areas
Distribute relevant parts of the Governance Implementation results as follows:
to senior management as information about the completion of the Governance implementation
to any other involved parties as relevant in all or part
Back to Top
QUALITY CRITERIA
Has the Funding Model been implemented as documented in the Funding Model (GV.090) or have discrepancies been documented including reasons?
Have the organizational changes been implemented as documented in the Impact Study and List of Proposed Organizational Changes (GV.040), or have
discrepancies been documented including reasons?
Have the policies been implemented following the policy implementation procedures (GV.050), or have discrepancies been documented including reasons?
Has any tooling been implemented following the Governance Policy Tooling (GV.060), or have discrepancies been documented including reasons?
Have policy monitoring processes been implemented as intended (GV.080), or have discrepancies been documented including reasons?
Have all employees impacted by the new Governance been appropriately trained?
Back to Top
GV.110 - MONITOR AND ANALYZE GOVERNANCE PROCESSES
During this task, you monitor the Governance Implementation that has been rolled out and analyze its performance against the predefined metrics, and define proposals
for improvement wherever necessary or possible.
ACTIVITY
Back to Top
WORK PRODUCT
Governance Implementation Improvement Proposal - The Governance Implementation Improvement Proposal contains an evaluation of the effectiveness of the
Governance Implementation that has been rolled out. Where there is low effectiveness, it describes possible reasons and actions that should be taken to improve the
processes.
Back to Top
TASK STEPS
1 Determine Governance
Implementation effectiveness.
Review
Results
The Review Results contains the results of the evaluation of the effectiveness of the Governance
Implementation rolled out.
2 Identify issues. Issue Log The Issue Log lists each issue that received an unfavorable result . For each issue it includes the nature of the
issue, what it impacts and what potentially caused the issue.
3 Define Governance Implementation
Issue
Resolution.
The Issue Resolution lists suggested actions that should be taken to resolve each issue as well as the urgency
of resolving each issue.
Back to Top
APPROACH
Determine Governance Implementation Effectiveness
For each policy defined in the Governance Policy Catalog (GV.030), determine the effectiveness of the policy using the metrics as defined in the Measurements Portfolio
(GV.070).
Identify Issues
Identify any issues with any Governance policy.
If the issue with a policy is that it is not being followed properly, reasons can be various but most commonly will be one or a combination of the following:
The policy has not been properly communicated to the people that should follow it. If this is the case, identify actions to improve communication.
The policy is meeting resistance from the people that should follow it. If this is the case, try to discussing what the reasons for resistance are. Perhaps people find it
difficult or impractical to follow the policy which might provide a reason to adjust it.
The policy is being used properly, but nevertheless, is not effective. In this case, the policy should be adjusted in a way that it becomes effective. One result might
even be to decommission the policy altogether.
Define Governance Implementation Improvement Options
Define an improvement proposal for any issue discovered against any policy in close collaboration with the key stakeholders. In the case of lack of communication or
resistance as the cause of the Governance Implementation failing, consider defining an organizational change management activity to address these issues (once again,
refer to the Organizational Change Management process).
Back to Top
Enterprise Architect Collaborate with the client enterprise architect to evaluate the effectiveness of current Governance Implementation and
propose improvements.
100
Client Enterprise Architect Evaluate the effectiveness of current Governance Implementation and propose improvements. *
Back to Top
PREREQUISITES
Prerequisite Usage
Measurements Portfolio (GV.070) Use the Measurements Portfolio to determine the method and metrics for measuring the success of the Governance
Implementation.
(GV.100)
The current Governance Implementation is the subject of the assessment and improvement proposals.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Governance Implementation Improvement Proposal is used in the following way:
to determine improvements to the Governance Implementation, such as:
Refine or change policies or policy implementation processes, i.e. another iteration of GV.030 Discover or Define Polices, or GV.050 Define Policy
Implementation Processes. This is typically the case if the issues are caused by ineffective polices or processes.
Execute another iteration of the Governance Implementation (GV.100). This is typically necessary if the issues are caused by poor communications or
resistance to change.
to improve tooling support, which means another iteration of GV.060 Define Policy Implementation Tooling
to improve or change metrics and/or the processes monitoring the policies - This would be the case if the measures do not provide sufficient information, or the
information does not reflect the actual situation. This would mean executing another iteration of GV.070 Define Policy Metrics and/or GV.080 Define Policy
Monitoring Processes.
Back to Top
QUALITY CRITERIA
Have all policies documented in GV.030 been evaluated, or is there a documented reason why not?
Do the Review Results document measurements of which policies are effective, and which should be further investigated?
Does the Issue Log describe what the nature of the issue is, what it impacts, and what likely caused the issue?
Do the Issue Resolutions clearly define suggested actions for each issue, including an indication of the urgency of each issue?
Back to Top
IMPLEMENT
INTRODUCTION
The Implement focus area provides a framework to develop and implement Oracle-based business solutions with precise development and rapid deployment.
Scope
The core framework of the OUM Implement focus area is to be applied to information technology projects based on Oracle Fusion technology and the Oracle product
stack. OUM documents the execution processes. Management processes are documented in Oracles Project Management Method (PJM), which is part of the OUM
Manage focus area
OUM Approach
The OUM implementation architecture provides a rapid, adaptive, and business-focused, approach to Implementation. These features are embodied within a framework
that supports the complete software development and implementation lifecycle.
The diagram below illustrates a typical OUM project, with a typical number of iterations. The relative amount of effort performed in each process, during each iteration is
represented by the height of the colored bars for each process. The number of iterations performed and the amount of effort required for a particular project will vary
depending upon a number of a factors including scope, technical and programmatic risk, system size, team size, etc. The number of iterations can vary from as few as 3
(for example: 1 - Elaboration, 1 - Construction, 1 - Transition) to as many as 12 or more (for example; 1 - Inception, 3 - Elaboration, 5 - Construction, 2 - Transition, 1 -
Production). Projects may also employ multiple production releases, and therefore, multiple iterations of the entire lifecycle to fulfill all of the business requirements.
Timeboxing is a powerful planning and controlling technique for some objectives. For example, it is useful to set timeboxes for use case refinements, for some prototypes,
for some architectural discussions, testing, and for post-production support. It is a technique that reduces the risk of "analysis paralysis."
OUM and UML
OUM technology implementation employs the Unified Modeling Language (UML) as the basis for modeling business processes, software systems, and technical
architectures. UML enables OUM to support modeling of the application architecture, structure and behavior. Today, OUM recognizes the well-proven advantages of an
iterative and incremental approach to development and deployment of information systems. As the software industry continues to mature, Oracle will continue to
evaluate new techniques for inclusion in OUM. Some techniques from Extreme Programming (XP) and Agile Software Development are already included in OUM. For
further reading on Extreme Programming, see Extreme Programming Explained. For further reading on Agile Software Development, see Agile Software Development.
The diagram below illustrates the how the UML models developed during an OUM project are related.
OUM was created with Process Models and UML Models in these Tasks:

OUM Implementation and Blended Delivery
OUM was created with the option of Traditional delivery (staffing with Onsite resources), or with Blended Delivery (staffing with Onsite resources and with Offshore Onsite
and Offshore Remote resources). Many of the Business Requirements (RD) and Requirement Analysis (RA) tasks are completed during workshops with client
involvement. When Blended Delivery channels are used, additional review tasks are added for the offshore resources in the Inception and Elaboration phases. With
Blended Delivery, these review tasks with the offshore team are critical.
The creation of more detailed models and specifications also becomes more critical for the onsite team when blended delivery is used. For more information on applying
Blended Delivery to a OUM project, see the Blended Delivery guidelines.
Back to Top
PHASES
OUM organizes the delivery of software implementation projects along several phases - indicators of the progress of the project. Each of these phases culminates in an
anchor point milestone. These milestones, adopted as phase gates by the Unified Process and by Oracle Unified Method, were taken directly from the Spiral Model
Anchor Point Milestones that were initially developed in a series of workshops by the USC Center for Software Engineering and its government and industrial affiliates.
For further reading on milestones, see "Anchoring the Software Process."
The milestones serve to establish exit criteria for each phase and provide an opportunity to evaluate the project's progress and the readiness of the project to commit
resources to begin the subsequent phase. Where the Unified Process has four (4) phases: Inception, Elaboration, Construction, and Transition, OUM adds a 5th phase,
Production to better cover the software engineering lifecycle.
This section provides a brief overview of the five Oracle Unified Method phases:
[A] Inception Phase
[B] Elaboration Phase
[C] Construction Phase
[D] Transition Phase
[E] Production Phase
[A] Inception Phase
The overriding goal of the Inception phase is to have concurrence among all stakeholders on the lifecycle objectives for the project. The Inception phase delivers the
Lifecycle Objective Milestone. Therefore, the Inception phase is critical for all projects because the scope of the effort, the high-level requirements and the significant risks
must be understood before the project can proceed.
The business objectives, goals, and scope of the project are defined and the project's feasibility is established during requirements gathering activities, which produce the
high-level business models. As requirements are defined they are also prioritized in relation to their business benefits. Where applicable and possible, the functionality is
partitioned to enable parallel development by separate teams of ambassador users and highly skilled Information Technology professionals. Risks and mitigation
strategies are identified. An Iteration Workplan is developed to define the details of the work to be performed in the first Iteration of the Elaboration phase.
For projects focused on enhancements to an existing system, the Inception phase is more brief but is still focused on validating that the project is both worth doing and
reasonable.
[B] Elaboration Phase
The goal of the Elaboration phase is to move development of the solution from the scoping and high-level requirements done during the Inception phase to developing
the detailed requirements, partitioning the solution, creating and necessary prototypes, and baselining the architecture of the system to provide a stable basis for the
design and implementation effort in the Construction phase. The Elaboration phase delivers the Lifecycle Architecture Milestone.
The architecture evolves from the most significant requirements -- those that have a great impact on the architecture of the system -- and an assessment of risk. The
stability of the architecture is evaluated through one or more architectural prototypes. During the Elaboration phase, the development team's understanding of the client's
business requirements is verified to reduce development risk.
[C] Construction Phase
The goal of the Construction phase is to take the solution from detailed requirements models, through configuration of standard packaged software functionality,
development and testing of custom components, and integration to a system that is ready for a first release that goes into production, often a limited release and often
called a beta release. In short, we complete the development of the application system, validate that all components fit together, and prepare the system for the
Acceptance Test and deployment. The Construction phase delivers the Initial Operational Capability Milestone.
In more detail, the Construction Phase clarifies the remaining requirements and completes the development of the system based upon the baseline architecture. In one
sense, and particularly for the custom developed components of the overall business solution, the Construction phase is a manufacturing process, where emphasis is
placed on managing resources and controlling operations to optimize costs, schedules, and quality. At this point, the management mind-set changes from the
development of intellectual property during Inception and Elaboration, to the development of deployable products during Construction and Transition. The application
system is completed within a pre-defined number of iterations. Updates are made to each of the models (Use Case Model, Design Model, Architectural Implementation,
etc.), as the requirements are progressively refined. For each iteration, every developer works with a given set of prioritized use cases and based on this develop and
unit-test the components following the order of the priorities. When the development timebox has reached its end, the developer walks through the changes with the
users. The users validate and refine the requirements, and provide MoSCoW priorities for each changed or new requirement. The modified or new requirements are fed
back to the requirement models in the business layer. All changed or new requirements are evaluated to make certain there has not been a scope change, and the result
provides the input for the next iteration of the partition. Once the team is comfortable with the approach, the formal and sequential nature of development followed by walk
through, followed by evaluation can be replaced with a more informal and continuous approach. When all of the planned iterations have been completed for each
partition, the complete application system is tested. The tested system is the end goal of the phase.
[D] Transition Phase
The goal of the Transition phase is to take the completed solution from installation onto the production system through the Acceptance Test to launch of the live
application, open and ready for business. Validate that the system is tested systematically and is available for end users. During this phase, the new system is accepted
by the client organization, the organization is made ready for the new system, and the system is put into production and, if the new system replaces an old one, a smooth
cutover to the new application is provided. The Transition phase delivers the System Production Milestone.
The Transition phase can span several iterations, and includes testing the new system in preparation for release, and making minor adjustments based on user feedback.
At this point in the lifecycle, user feedback should focus mainly on fine-tuning the product, configuration, installation, and usability issues. All the major structural issues
should have been resolved earlier in the project lifecycle.
[E] Production Phase
The goal of the Production phase is to operate the newly developed system, assess the success of the system and monitor and address system issues. This includes
monitoring the system and acting appropriately to maintaine continued operation, measuring system performance, operating and maintaining supporting systems,
responding to help requests, error reports and feature requests by users, and managing the applicable change control process so that defects and new features may be
prioritized and assigned to future releases and put into a plan for future enhancements to the application system, as well as determining, developing and implementing
required updates.
The Production phase delivers the Sign-Off Milestone.
Back to Top
MILESTONES
Each phase should finish with a well-defined milestone. It is important to communicate the milestone to all the stakeholders since it is a point in time where critical
decisions should be made and goals evaluated. Each phase has an anchor point milestone that is explained below:
Lifecycle Objective Milestone
The first key milestone is the Lifecycle Objective Milestone and it is produced at the end of the Inception phase. The following criteria can be used to evaluate this
milestone:
Is there agreement on the business objectives and have the goals of the project been confirmed by all the stakeholders?
Have the main risks been identified, prioritized and have mitigation strategies been developed?
Does our knowledge of the project and possible solutions allow us to estimate the project within a certain error margin?
Are schedule and cost estimates for the remaining phases prepared and communicated?
Has the project team been identified and prepared?
Is it feasible to proceed?
Lifecycle Architecture Milestone
The Lifecycle Architecture Milestone is the second key milestone of the project. It is typically expected at the end of the Elaboration phase. At this point, most of the
requirements should be analyzed and designed. At this time, the architecture should be stabilized. The following criteria can be used to evaluate this milestone:
Is the application architecture, technical architecture, and data architecture stable?
Have all the architecturally-significant use cases been identified?
Have all the architecturally-significant use cases been analyzed to reveal possible affects on the architecture?
Have key configuration decisions been documented and tested?
Have the architectural risks been mitigated?
Are schedule and cost estimates for the remaining phases adjusted for new information and prepared and communicated?
Is there a refined estimate for the Construction phase?
Is a well-defined plan for the Construction phase in place?
Are we certain enough about the solution that we can commit more resources to begin implementation?
Are we ready to produce code efficiently and with quality?
Initial Operational Capability Milestone
The Initial Operational Capability Milestone is the third key project milestone produced at the end of the Construction phase. At this point, a decision is made on whether
the application, infrastructure and users are ready to move to operation. The Initial Operation Capability Milestone is also considered a "beta" release.
In order to evaluate this milestone, the following criteria can be used:
Have the users been properly involved to verify the implementation of the functional requirements?
Are the non-functional requirements, such as security, reliability, etc. being adequately addressed?
Is the system ready for the User Acceptance Test?
Has all supporting documentation been developed?
Are all stakeholders ready for the Transition phase?
System in Production Milestone
The System in Production Milestone is produced at the end of the Transition phase. At this point, the stakeholders decide if the goals and objectives set for the project
have been met and if a new increment should begin. In order to evaluate this milestone, the following criteria can be used:
Have the application and database administration and staff members been properly trained?
Are the ambassador users able to deliver the application properly to the rest of the organization for internal acceptance?
Have arrangements been made for application support and have staff members been properly trained for this task?
Does the application system meet the performance requirements?
Are the stakeholders satisfied with the project?
Sign-Off Milestone
The Sign-Off Milestone is produced at the end of the Production phase (as far as the engagement goes). This is the last key project milestone. At this point all the
contractual agreements are closed and staff and physical resources are released or a new project is begun to address additional business requirements within the
software system. In addition, all the intellectual property is preserved. In order to evaluate this milestone, the following criteria can be used:
Have you obtained management sign-off?
Have critical operational issues been addressed with the stakeholders?
Has a Future Enhancement Plan been developed?
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 meet 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.
Every full lifecycle involves most if not all of the following processes, whether they are the responsibility of the development team, the users, the IS staff, a third party, or
some combination thereof. Most processes overlap in time with others, and are interrelated through common tasks.
This section describes the key OUM processes.
[RD] Business Requirements Process
[RA] Requirements Analysis Process
[MC] Mapping and Configuration Process
[AN] Analysis Process
[DS] Design Process
[IM] Implementation Process
[TA] Technical Architecture Process
[TE] Testing Process
[PT] Performance Management Process
[CV] Data Acquisition and Conversion Process
[DO] Documentation Process
[OCM] Organizational Change Management
[TR] Training
[TS] Transition Process
[PS] Operations and Support Process
[RD] Business Requirements Process
In the Business Requirements process, you define the business needs of the application system. The business requirements for the proposed system or new
enhancements are identified, refined and prioritized by a tightly integrated team of empowered ambassador users and experienced analysts. The process often begins
from an existing high-level requirements document and a scope document, such as the Project Management Plan, Validated Scope (PJM SM.010). However, it is
possible to begin from an agreed on scope and objectives before requirements have been defined.
The Business Requirements process delivers a set of requirements models and a prioritized list of requirements as a basis for system development. Both the models and
requirements list are dynamic and may change as the understanding of the team develops with the system.
The main outputs of this process are: the business objectives and goals, the list of functional requirements and the supplemental requirements.
[RA] Requirements Analysis Process
In the Requirements Analysis process, the functional and supplemental requirements identified and prioritized during the Business Requirements process are analyzed
further into a Use Case Model that is further refined by adding use case details in order to establish a more precise understanding of the requirements. The Use Case
Model is used as the basis for the solution development. This process helps provide structure and shape to the entire solution. The Use Case Model is used to document
in detail the requirements of the system in a format that both the client and the developers of the system can easily understand.
The main outputs of this process are the Use Case Model, a prototype of the user interface, and a high-level description of the software architecture.
[MC] Mapping and Configuration Process
In the Mapping and Configuration process, the key business data structures and associated values are defined and established within a prototype environment. The
business requirements are assessed and mapped to the standard application and system features. A prototype environment is updated with detailed setup parameters,
and an iterative series of workshops are conducted in order to validate that the prototype meets the business requirements. Resolutions to any gaps between the
business requirements and the standard application features and functions are defined, along with the documentation of detailed setup parameters.
The main outputs of this process are the Application Setups and the Validated Configuration.
[AN] Analysis Process
During the Analysis process, the captured requirements are analyzed and mapped onto the chosen commercial-off-the-shelf (COTS) product set, if any, to ascertain
which requirements can be met directly by configuring the products capabilities and which requirements will require extending the product capabilities through the
development of custom application software or custom extensions. Beyond product mapping, the purpose of Analysis is to refine and structure the requirements via a
conceptual object model, called the Analysis Model. Most simply put, the Analysis Model is the collection of all of the analysis related artifacts, just as the Use Case
Model documents the systems functional requirements. The Analysis Model provides a more precise understanding of the requirements and provides details on the
internals of the system. The Analysis Model is described using the language of the developers as opposed to the requirements obtained in the Business Requirements
and Requirements Analysis processes where the emphasis is on the functionality of the system expressed in the language of the client. Thus, it contributes to a sound
and stable architecture and facilitates an in-depth understanding of the requirements. Many of the outputs produced during the Analysis process describe the dynamics of
the system as opposed to the static structure. The Analysis Model is also considered the first cut of the Design Model, since it contains the analysis classes that will be
further detailed during the Design process.
The main output of the Analysis process is the Reviewed Analysis Model that includes a set of analysis classes (class diagrams) that realize the use cases. In addition,
new software architecture views are added to the Architecture Description initially developed in the Business Requirements process and further enhanced in the
Requirements Analysis process.
[DS] Design Process
In the Design process, the system is shaped and formed to meet all functional and supplemental requirements. This form is based on the architecture created and
stabilized during the Analysis process. Thus, the outputs produced during Analysis are an important input into this process. Design is the focus during the end of
Elaboration phase and the beginning of Construction iterations. The major outputs created in this process ultimately combine to form the Design Model that is used during
the Implementation process. The Design Model can be used to visualize the implementation of the system.
The main output of this process is the Reviewed Design Model that includes an object model that describes the design realization of the use cases and design classes
that detail the analysis classes outlined in the Analysis Model. In addition, the Architecture Description, initially developed in the Business Requirements process and
enhanced in both the Requirements Analysis and Analysis processes, is enriched with the new Module and Execution Views.
[IM] Implementation Process
Through a number of steps, mostly iterative, the final application is developed within the Implementation process. The results from the Design process are used to
implement the system in terms of source code for components, scripts, executables, etc. During this process, developers also implement and perform testing on software
components.
Implementation is the main focus of the Construction phase, but it starts early in the Inception phase in order to implement the architecture baseline (trial architecture and
prototype). During Transition, it occurs in order to handle any defects or bugs discovered while testing and releasing the system.
The main output of this process is the final iteration build that is ready to be tested. In addition, the High-Level Software Architecture Description initially developed in the
Requirements Analysis process is also enriched with the Implementation View to create the Architectural Implementation.
[TE] Testing Process
The Testing process is an integrated approach to testing the quality and conformance of all elements of the new system. Therefore, it is closely related to the review
tasks in the Quality Management (QM) process of PJM and to the definition and refinement of requirements in the Business Requirements process. It addresses mainly
functional testing. It also includes systems integration testing for projects with requirements for interfaces to external systems.
Testing activities are a shared responsibility of developers, quality assurance engineers, and ambassador users, working together as an integrated project team. The
Testing process presupposes that there is a highly visible user interface from which system events can be driven and results validated. The higher proportion of artifacts
that are visible to the ambassador users (for example, user interfaces and reports) the more they will be able to participate in the Testing process.
[PT] Performance Management Process
The objective of the Performance Management process is to proactively define, construct, and execute an effective approach to managing performance throughout the
project implementation lifecycle in order to validate that the performance of the system or system components is aligned with the user's requirements and expectations
when the system is implemented. Performance Management is not limited to conducting a performance test or an isolated tuning exercise, although both those activities
may be part of the overall Performance Management strategy. The requirements that drive Performance Management also impact Technical Architecture (TA) and the
two processes are closely related.
The Performance Management team defines the scope of testing and relates it to point-in-time snapshots of the transactions expected in the real production system.
Technical analysts create or set up transaction programs to simulate system processing within the scope of the test and populate a volume test database against which
to execute the transactions. Once the system and database administrators have created the test environment, the project team executes the test and the final results are
documented.
[TA] Technical Architecture Process
The goal of the Technical Architecture process is to design an information systems architecture to support and realize the business vision. The tasks in the Technical
Architecture process identify and document the requirements related to the establishment and maintenance of the application and technical infrastructure environment for
the project. Processes and procedures required to implement, monitor and maintain the various environments are established and tested.
The Technical Architecture process specifies elements of the technical infrastructure of the development project. It assumes that the business already has an information
system strategy and that these elements fit within that strategy. There must be a sharp focus on the technical infrastructure in a OUM-based solution deployment project.
By exposing its business systems to the Web, a business is exposing itself to unpredictable load levels and, sometimes, a hostile security environment. Therefore, the
importance of the technical infrastructure cannot be overstated.
[CV] Data Acquisition and Conversion Process
The objective of the Data Acquisition and Conversion process is to create the components necessary to extract, transform, transport and load the legacy source data to
accommodate the information needs of the new system. The data that is required to be converted is explicitly defined, along with its sources. This data may be needed
for system testing, training, and acceptance testing as well as for production. In some cases, it is beneficial to convert (some) data at earlier stages to provide as realistic
as possible reviews of the components during the development iterations.
The amount of effort involved with conversion greatly depends on the condition of the data and the knowledge and complexity of the data structure in legacy systems and
existing applications. For large projects, where large existing systems will be replaced, and most all of the data needs to be converted, you should consider running this
as a separate project in parallel to the development project. In such situations, you need to thoroughly analyze the existing systems, map them to the new data model,
and build multiple conversion modules of various complexities. The process includes designing, coding, and testing any conversion modules that are necessary as well
as the conversion itself. The cleaning of legacy data is visibly identified as a user and client project staff task so that it can be staffed and scheduled. If data anomalies
exist in the current system(s), or there are an unusual number of exceptions, you should recommend data clean-up to the project sponsor.
[DO] Documentation Process
Quality documentation is a key factor in the transition to production, gaining user acceptance, and maintaining the ongoing business process. The requirements and
strategy for this process vary based upon project scope, technology, and requirements.
For projects that include Oracle Application products, the Oracle Application manuals are the foundation of implementation documentation. The Documentation process
will develop documentation to augment the standard Oracle Application products manuals with specific information about the organization's custom software extensions
and specific business procedures.
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.
[TR] Training Process
The objective of the Training process is to make sure that the project team is adequately trained to begin the tasks necessary to start the project and the users are
adequately trained to take on the tasks of running the new application system.
[TS] Transition Process
The goal of the Transition process is to install the solution (which includes providing installation procedures) and then take it into production. It begins early in the project
by defining the specific requirements for cutover to the new application system. It then includes tasks to carry out the elements of that strategy such as developing an
Installation Plan, preparing the Production Environment, performing the cutover, and decommissioning any legacy systems.
[PS] Operations and Support Process
The goal of the Operations and Support process is to monitor and respond to system problems, upgrade the application to fix errors and performance problems, evaluate
the system in production and plan enhancements for increased functionality, improved performance, and tighter security.
The development project does not come to an abrupt end when the team installs the application system into production. In fact, the months following that milestone can
determine the real success or failure of the project. Internal auditors have not yet produced the System Evaluation, and users most likely still have a few problems to
uncover. There are certain to be requirements with lower priorities that have not been implemented. The Could Have requirements and any remaining Should Haves can
now be re-prioritized into an Enhancement Plan, from which upgrades can be defined.
Back to Top
ACTIVITIES
OUM tasks are further refined into activities to better represent the OUM Project lifecycle.
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 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 OUM phases, the following major activities have been identified:
Inception Phase Activities
Gather Business Requirements - Inception
Establish Current Business Baseline
Gather Solution Requirements
Perform Software Upgrade Impact Analysis
Consolidate Solution Requirements
Create Conceptual Prototype - Inception
Gather Supporting Requirements
Specify Key Structure Definition
Create and Manage Ad Hoc Communications
Conduct Executive Alignment Workshop
Train Project Team
Conduct Alignment Workshops - Inception
Conduct Change Readiness Assessment
Deploy Change Management Roadmap / Communication Campaign - Inception
Elaboration Phase Activities
Define Project Strategy
Define Infrastructure
Prepare Environments - Elaboration
Gather Business Requirements - Elaboration
Develop Test Plans
Specify Software Configuration
Prototype and Validate Configuration
Perform Gap Analysis
Develop Use Case Model
Create Conceptual Prototype - Elaboration
Consolidate Specification
Baseline Software Architecture
Develop Use Case Details
Analyze Elaboration
Design Elaboration
Develop Custom Component Test Scripts - Elaboration
Develop System Test Scenarios - Elaboration
Develop and Validate Custom Software Prototypes
Perform Custom Component Testing - Elaboration
Perform System Test - Elaboration
Validate Upgrade Process - Elaboration
Plan Performance Management
Prepare to Acquire and Convert Data - Elaboration
Prepare Business Process Impact Inventory
Deploy Change Management Roadmap / Communication Campaign - Elaboration
Construction Phase Activities
Finalize Requirements
Analyze - Construction
Design - Construction
PTP Perform Test Planning
Prepare Environments - Construction
Develop Custom Components Test Scripts - Construction
Develop System Test Scenarios - Construction
Develop Systems Integration Test Scenarios
Implement Custom Components
Perform Custom Component Testing - Construction
Prepare for System Test
Perform System Test - Construction
Perform Systems Integration Test
Prepare for Performance Testing
Prepare for Transition
Prepare for Cutover
Test Infrastructure
Prepare to Acquire and Convert Data - Construction
Acquire and Convert Data - Construction
Validate Upgrae Process - Construction
Produce Documentation
Deploy Change Management Roadmap / Communication Campaign - Construction
Conduct Job Impact Analysis
Conduct Managers' Alignment Workshop - Construction
Design End-User Training
Build End-User Training
Train End Users - Construction
Transition Phase Activities
Support User Acceptance Test
Conduct Performance Test
Prepare Production Environment
Convert Data - Transition
Deploy Change Management Roadmap / Communication Campaign - Transition
Conduct IT Alignment
Train End Users - Transition
Finalize Documentation
Go Production
Production Phase Activities
Manage Production System Performance
Evaluate Production System
Resolve Production Problems
Deploy Change Management Roadmap / Communication Campaign - Production
Plan for Future
Deploy IT Transition Plan
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
[A] Inception
The overriding goal of the Inception phase is to have concurrence among all stakeholders on the lifecycle objectives for the project. The Inception phase is critical for all
projects because the scope of the effort, the high-level requirements and the significant risks must be understood before the project can proceed.
The Inception phase is used to kick off a project, review the strategic direction of the business, and confirm, document, and prioritize the high-level business requirements
for the project. It is also the time to begin assembling and integrating the project team, to scope the entire engagement, and develop the initial project plan.
The business objectives, goals, and scope of the project are defined and the projects feasibility is established during requirement gathering activities that produce the
high-level business models. As requirements are defined, they are also prioritized in relation to their business benefits. Where applicable and possible, the functionality is
partitioned to enable parallel development by separate teams of ambassador users and highly skilled Information Technology (IT) professionals. Potential risks are
identified and and mitigation strategies for each risk are developed. The Project Management Plan is used to define the overall work to be performed on the project. An
Iteration Workplan is developed to define the details of the work to be performed in the first Iteration of the Elaboration phase.
For projects focused on enhancements to an existing system, the Inception phase is more brief but is still focused on validating that the project is both worth doing and
reasonable.
The Inception phase finishes with the Lifecycle Objective Milestone. Review and be familiar with the objectives of this milestone before you begin this phase and make
sure you have met these objectives before you move to the Elaboration phase.
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
Confirm business objectives. Obtain a clear understanding of the business benefits that should be achieved by the project in order to take decisions that are
beneficial to the business. Gain agreement on the business objectives by all relevant stakeholders. Define, document, prioritize, and gain agreement on the high-
level business requirements of the project.
Confirm project scope. Clearly define the project scope, and if possible, partition and prioritize the work that is in scope. Confirm the goals of the project by all
stakeholders.
Define risks. Identify the main risks, prioritize them and identify mitigation strategies.
Estimate cost and plan. Prepare and communicate schedule and cost estimates for the remaining phases.
Staff and prepare project team. Identify the project team. Identify appropriate and qualified ambassador users who will be involved during the entire project
lifecycle. Educate all project stakeholders in the OUM approach and explain the organizational impact of choosing this approach, as well as their respective roles
and responsibilities in the project. Begin to build an integrated project team of IT professionals and ambassador users
The Inception Phase / Lifecycle Objective (LO) Milestone Checklist is available to assist with determination of completeness for this phase.
Back to Top
PROCESSES
Business Requirements (RD)
Requirements Analysis (RA)
Mapping and Configuration (MC)
Implementation (IM)
Testing (TE)
Performance Management (PT)
Technical Architecture (TA)
Data Acquisition and Conversion (CV)
Documentation (DO)
Organizational Change Management (OCM)
Training (TR)
Back to Top
KEY WORK PRODUCTS
Refer to Key Work Products for a complete list of key work products for OUM.
Back to Top
TIPS AND TECHNIQUES
This section discusses the primary techniques that may be helpful in conducting the Inception phase. It also includes advice and commentary on each process.
Business Requirements
Within this process you define the high-level functional and supplemental requirements, and determine the scope and prioritize it. Use workshops for all these activities.
The workshops that are used in this phase will be high-level facilitated workshops where a lot of brainstorming occurs. Therefore, techniques that allow this kind of activity
can be successfully used (for example, brown bag sessions). The preparation of the workshops is vital to their success. The facilitator (workshop leader) should perform
some investigation prior to the workshops to make them as effective as possible. More information about workshop techniques can be found in the Workshop Techniques
Handbook.
It is also important to understand the organization's culture. For example, are they used to speaking out, or are there normally a lot of political factors that restrict the free
exchange of ideas. Prepare the workshop appropriately (for example, an open approach will provide very little input in an atmosphere where speaking out is restrictive). It
is important that the participants feel secure during the session. The high-level requirements should be prioritized following the MoSCoW principle, resulting in a
MoSCoW List that that contains the prioritized requirements. The MoSCoW List contains the Must Have, Should Have, Could Have and Won't Have requirements. The
Must Have functionality is the functionality that is vital to the business and hence Must be developed. The Should Have functionality is important, but not vital, the Could
Have functionality is the functionality that is nice to have, but not really important, and the Won't Have functionality is functionality that should not be developed as part of
this project. There is a sample Use Case Model, accessible from the RA.023 task overview that can be used to accelerate the requirements gathering process.
Requirements Analysis
In the Requirements Analysis process, the requirements captured during Business Requirements are analyzed and the functional requirements are transformed and
structured into a Business Use Case Model. Use Case Models are used to document the requirements of the system in detail, for the business as well as the project
team. During the Inception phase, you should not describe every use case in detail. This is neither necessary nor reasonable, as many use cases will evolve through the
phases. The users should be involved in developing the Business Use Case Model, as it they can provide the best input to give a more precise understanding of the
requirements. It might be useful to use workshops to collect the missing pieces in the requirements that we need to form the Business Use Case Model. It all depends on
the level of detail and accuracy of the requirements captured in the Business Requirements process.
Mapping and Configuration
In the Mapping and Configuration process, you establish the values for the key structural elements in the applications (for example, Multi-Org, Trading Community
Architecture (TCA), Chart Of Accounts (COA) structures) that are relevant to your particular implementation.
Implementation
Most of the work in the Implementation process is performed in the Construction phase, however it is important to try to show the users our early understanding of the
requirements. This can be done by creating one or more Conceptual Prototypes. In larger projects, probably more prototypes will be created (for example, one for each
subsystem). A Conceptual Prototype is a mockup prototype that reflects the functional requirements known at the time, based on the decisions made during the
workshops. There might very well be known requirements with lower priorities that have not been prototyped, because the end of the timebox was reached before the
completion of these requirements. The Conceptual Prototype is used as a communication tool between the ambassador users and the project team to determine any
additional requirements and to verify the implementation team's understanding of existing requirements. At this point, the prototype may consist of drawings using, for
example, PowerPoint slides, illustrating the user interface, what kind of functionality the application will provide, and so on. Moreover, some programming work may occur
in this phase, for example, to create "proof of concept" prototypes, to do programming experiments for key technical questions, to validate technical ideas or to explore
the technical feasibility of special requirements.
Testing
This process emphasizes a common planning approach to testing the business requirements embodied in the new application system. It advocates the reuse of testing
scripts and test data in successively larger and larger portions of the application system. The intent of the Testing process is to provide a formal and effective approach to
the challenge of testing. The Testing approach is integral to the entire development effort, for example by performing unit testing, and structuring it to build upon itself. If
done well, it results in high quality software and early delivery of a dependable system, delivering real business benefits.
The Testing process first identifies the Testing Requirements (such as the form and scope of test reports) and then refines them through to the end of the project. It
attempts to take full advantage of all opportunities that contribute to the identification of the Testing Requirements. For example, you identify business scenarios while
developing the Use Case Models, and they contribute to system, and systems integration testing. Functional modeling produces testing requirements that are specific to
a detailed use case or business process. User interface testing is performed with reference to the Validated User Interface. The Supplemental Requirements work
product identifies supplemental requirements in such areas as security, from which you plan supplemental testing of partitions and the complete system. The Testing
Requirements should also include requirements related to acceptance testing including statements concerning the implications for acceptance testing.
At the earliest possible date, the lead tester should initiate a procurement process for testing tools. This issue is best raised in response to the client organization's
statement of testing requirements.
Performance Management
project implementation lifecycle in order to ensure that the performance of the system or system components meet the user's requirements and expectations when the
system is implemented. Performance Management is not limited to conducting a performance test or an isolated tuning exercise, although both those activities may be
part of the overall Performance Management strategy.
Performance Management starts off with conducting a Performance Management Workshop. The Performance Management workshop familiarizes the client with the
concepts of proactive performance management, the need to define performance requirements for business critical transactions, establishment of metrics and monitoring
related to performance management, Service level Agreements (SLA) and the appropriate use of performance testing. The workshop also provides a mechanism to
gather information on performance needs and expectations that should be used to develop the Performance Management Requirements and Strategy (PT.020).
The Technical Architecture process starts off by conducting a Technical Architecture Workshop. The workshop is intended to familiarize the client with the reference
architectures already established, options and features available and to gather high level architecture, availability, integration, reporting, backup and recovery, security
and disaster recovery requirements. The workshop also provides a mechanism to gather information on architecture in place and any strategic initiatives or enterprise
standards that the project architecture must fit within.
Data Acquisition and Conversion
This process relies on the work products from the Business Requirements process. If possible, members of the conversion team should actively participate in this
process to establish a good understanding of future business requirements. In addition, this team needs to look into the existing systems that should be converted.
Document the Data Conversion Requirements in this phase. Data conversion can be a costly and labor-intensive effort. Raise conversion exceptions as management
issues. They should not be solved prior to understanding their benefit to the business.
Documentation
Quality documentation is a key factor in supporting the transition to production, achieving user acceptance, and maintaining the ongoing business process. During
Inception, this process gets started with the documenting of the Documentation Requirements and Strategy. This work product will drive this process throughout the
project.
Organizational Change Management focuses on the use and acceptance of new application system by all users and the optimization of organizational performance.
Inherent in every technology change is the opportunity to become a stronger, more cohesive organization; a more efficient performer; a more agile competitor.
During Inception, communication is started quickly to keep stakeholders informed. Various workshops with targeted audiences are conducted to start preparing the
organization for the adoption of the new system. Organizational Change Management provides a structured approach that addresses the human and organizational
acceptance and use of new applications. Organizational Change Management increases the organizations return on investment by reducing the risks of implementing
applications, increasing the productivity of all user groups, and assisting the organization to reach peak performance with the new business system. The more quickly and
effectively the business can adopt new technology, the more productive and competitive is the organization. A Sponsorship Program is put in place to cascade (or
sponsor) the involvement throughout the organization and an Change Readiness Assessment is conducted. Ongoing throughout the project and starting in the Inception
phase, change and communication events targeted to specific audiences with the goal of mitigating identified risks and challenges are conducted.
Training
During Inception, the objective of the Training process is to train the project team to begin the tasks necessary to start the project.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project Using Scrum technique. You can also go directly to the Inception phase Scrum guidance within this
technique.
Back to Top
RD.001 Detail Business And System Objectives Business and System Objectives
RD.003 Identify Viewpoints Viewpoints List
RD.005 Create System Context Diagram System Context Diagram
RD.011.1 Develop Future Process Model Future Process Model
RD.012 Document Present And Future Organization Structures Present And Future Organization Structures
RD.015 Determine KPI Collection and Reporting Strategy Key Business Strategies and Objectives
RD.020 Obtain High-Level Business Descriptions High-Level Business Descriptions
RD.030 Develop Current Business Process Model Current Process Model
RD.034 Document Current Business Baseline Metrics Current Business Baseline Metrics
RD.042.1 Develop Glossary Glossary
RD.045.1 Prioritize Requirements (MoSCoW) Moscow List
RD.055 Detail Supplemental Requirements Supplemental Requirements
RD.065 Develop Domain Model (Business Entities) Domain Model
RD.070 Determine Audit and Control Requirements Audit and Control Requirements
RD.130.1 Develop Baseline Architecture Description Architecture Description
RD.134 Identify New Software Release Changes Software Release Changes Summary
RD.136 Perform Custom Extension Impact Analysis Custom Extension Impact Analysis
RD.138 Perform Data Impact Analysis Data Impact Analysis
RD.140.1 Create Requirements Specification Requirements Specification
RD.150.1 Review Requirements Specification Reviewed Requirements Specification
RA.010 Simulate Business Process Business Process Simulation
RA.015 Develop Business Use Case Model Business Use Case Model
RA.019 Define Project Reference Architecture Project Reference Architecture
RA.021.1 Capture User Stories User Story
RA.023.1 Develop Use Case Model Use Case Model
RA.025.1 Identify Candidate Services Service Portfolio - Candidate Services
RA.027.1 Identify Candidate Business Rules Candidate Business Rules
RA.028.1 Populate Business Rules Repository Populated Business Rules Repository
RA.030.1 Validate Conceptual Prototype Validated Conceptual Prototype
MC.010.1 Define Business Data Structures Business Data Structures
MC.020 Define Business Data Structure Setups Business Data Structure Setups
MC.090.1 Conduct Reporting Fit Analysis Reporting Fit Analysis
Implementation
IM.005.1 Develop Conceptual Prototype Conceptual Prototype
Testing
TE.005.1 Determine Testing Requirements Testing Requirements
PT.010 Conduct Performance Management Workshop Performance Management Workshop Results
TA.004 Perform Technical Architecture Impact Analysis Technical Architecture Impact Analysis
TA.010 Conduct Technical Architecture Workshop Technical Architecture Workshop Results
CV.010 Define Data Acquisition and Conversion Requirements Data Acquisition and Conversion Requirements
Documentation
DO.010 Define Documentation Requirements and Strategy Documentation Requirements and Strategy
Training
TR.010.1 Define Training Strategy Education and Training Strategy
TR.020 Prepare Project Team Learning Plan Project Team Learning Plan
TR.030 Prepare Project Team Learning Environment Project Team Learning Environment
TR.040 Develop Project Team Learningware Define Training Strategy
TR.050 Conduct Project Team Learning Events Skilled Project Team
Back to Top
Back to Top
MANAGING RISK
The most likely areas of risk in the Inception phase are the following:
Undocumented or Undeveloped Business Strategies: In order to create a successful business, the strategic goals from which the project came, need to be
documented. Be sure that there is a strategic plan, along with the other pre-requisites, is in place to govern development of the Oracle solution.
No Representation of the Creative Design Discipline on the Project Team: This could be because these requirements have not been considered or because
the client has a separate agreement with a creative design firm. In either case, a user-centric development effort will fail if the creative discipline is not a part of the
integrated project team.
Misunderstood or Missing Requirements: These can be particularly difficult if they are in the area of integration with existing systems or solution partitions being
developed in parallel. Facilitated workshops are the preferred means for accelerating business planning and development. Workshops enable the exchange of
information between a group of key individuals and allow the group to reach decisions that are mutually acceptable
No Single Point of Authority/Inability to Make Decisions: The inability of the client project team to make decisions regarding the Oracle solution without
consulting their executive management can severely hamper progress on the development effort. Ensure that, as part of the Inception phase, a project sponsor --
a single point of authority empowered to take decisions -- is identified. The project sponsor must then empower the ambassador users -- the client project team --
to make decisions within their area of responsibility.
The Definition of Project Scope is Unclear or Imprecise: If the project scope is not clear, there is a large risk for scope creep and the project may then have
difficulties in delivering on time and within budget. To prevent this, it is important to define of a clear and unambiguous scope that can easily be used as a
reference when new requirements emerge. The high-level requirements and the MoSCoW List are often used as a basis to form the scope.
Insufficient Number and Quality of Skilled Staff Resources (including Object-Oriented Analysts and Developers): If the project does not include the right
amount of qualified resources (both client and Oracle resources), there is a risk that the work products produced will not be delivered on time, with the correct level
of detail/and or with sufficient quality. If there are lesser-experienced people on the project, this must be reflected in the schedule to allow for training on the job
and coaching. It's best, if possible, that the staff be trained prior to the project.
Back to Top
clear understanding of the OUM approach
communication skills of the participants
active participation and commitment from the client sponsor organization
clear agreement on project scope
availability of qualified ambassador users
availability of qualified developers
frequent and effective interactive with the creative design team
Back to Top
A.ACT.GBRI - GATHER BUSINESS REQUIREMENTS -
INCEPTION
This activity serves to detail the business and system objectives.
*This activity has Application Implementation supplemental activity guidance.
Back to Top
OBJECTIVES
The objective for this activity is to gather business and system requirements, document the key business benefits, develop use case models and domain model of the
proposed system.
Back to Top
TASKS
ID Task Name
RD.001 Detail Business and System Objectives
RD.003 Identify Viewpoints
RD.005 Create System Context Diagram
RD.011.1 Develop Future Process Model
RD.020 Obtain High-Level Business Descriptions
RA.010 Simulate Business Process
RA.015 Develop Business Use Case Model
RD.065 Develop Domain Model (Business Entities)
RD.012 Document Present and Future Organizational Structures
RD.015 Determine KPI Collection and Reporting Strategy
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to gather business requirements. Requirements can be gathered in several different ways, interviews, meetings, workshops, as well as a
combination of these methods or a series of meetings and workshops depending on the size of the solution being developed. During this activity, you should develop the
business process models, use case models, domain models and document the future organizational structures. This activity serves to detail the business and system
objectives.
Supplemental Guidance for Application Implementations
This activity has supplemental guidance that should be considered if you are doing an application implementation. Use the OUM Application Implementation
Supplemental Guide to access all application implementation supplemental information. You can also go directly to the activity-specific supplemental guidance.
Back to Top
PREREQUISITES
A.ACT.TPT - Train Project Team
Back to Top
A.ACT.ECBB - ESTABLISH CURRENT BUSINESS BASELINE
This activity is aimed at gaining an understanding of and documenting the main activities that keep the organization operating today. It is only done when an analysis of
the client's current business processes and functions is required.
Back to Top
OBJECTIVES
The objective for this activity is to gain an understanding of the client's current business processes and functions.
Back to Top
TASKS
ID Task Name
RD.030 Develop Current Business Process Model
RD.034 Document Current Business Baseline Metrics
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to collect information on current processes and functions. Information can be gathered in several different ways, interviews, meetings,
workshops, as well as a combination of these methods or a series of meetings and workshops depending on the size of the solution being developed. During this activity,
you may develop or acquire the current business process model and document and map the current business processes.
Back to Top
PREREQUISITES
A.ACT.GBRI Gather Business Requirements - Inception
Back to Top
A.ACT.GR - GATHER SOLUTION REQUIREMENTS
This activity includes gathering other requirements that support the business and system objectives.
Back to Top
OBJECTIVES
The objective for this activity is to collect the requirements that support the solution being prepared.
Back to Top
TASKS
ID Task Name
RD.042.1 Develop Glossary
RD.045.1 Prioritize Requirements (MoSCoW)
RD.055 Detail Supplemental Requirements
RD.130.1 Develop Baseline Architecture Description
RA.019 Define Project Reference Architecture
RA.021.1 Capture User Stories
RA.023.1 Develop Use Case Models
RA.025.1 Identify Candidate Services
RA.027.1 Identify Candidate Business Rules
RA.028.1 Populate Business Rules Repository
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prioritize the requirements, detail the supplemental requirements and develop use case models that describe the solution requirements.
Back to Top
PREREQUISITES
Back to Top
A.ACT.PSUIA - PERFORM SOFTWARE UPGRADE IMPACT
ANALYSIS
This activity serves to assess the impact of the new system on the existing IT environment.
Back to Top
OBJECTIVES
The objective for this activity is to analyze the existing system architecture and associated software custom extensions, extensions and data in order to determine the
impact of implementing the new system.
Back to Top
TASKS
ID Task Name
TA.004 Perform Technical Architecture Impact Analysis
RD.134 Identify New Software Release Changes
RD.136 Perform Custom Extension Impact Analysis
RD.138 Perform Data Impact Analysis
MC.090.1 Conduct Reporting Fit Analysis
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity involves reviewing the existing IT architecture in order to determine the impact of implementing technologies associated with the new system.
The activity also involves an assessment of new system functionality and its impact on existing custom extensions and extensions with a view to replacing as many of the
existing changes as possible with standard functionality.
Back to Top
PREREQUISITES
A.ACT.GBRI - Gather Business Requirements - Inception
Back to Top
A.ACT.CR - CONSOLIDATE SOLUTION REQUIREMENTS
This activity consolidates the information from the Gather Business Requirements - Inception and Gather Solution Requirements activities.
Back to Top
OBJECTIVES
The objective for this activity is to consolidate the solution requirements into a single work product and perform peer review of the resulting software requirement
specification.
Back to Top
TASKS
ID Task Name
RD.140.1 Create Requirements Specification
RD.150.1 Review Requirements Specification
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to consolidate the requirements into a single work product and perform peer review of the software specifications.
Back to Top
PREREQUISITES
A.ACT.GR Gather Solution Requirements
Back to Top
A.ACT.CCPI - CREATE CONCEPTUAL PROTOTYPE -
INCEPTION
B.ACT.CCPE - CREATE CONCEPTUAL PROTOTYPE -
ELABORATION
These activities consists of developing and validating the Conceptual Prototype.
Back to Top
OBJECTIVES
The objective for these activities is to develop a conceptual prototype in order to communicate requirements. Through these activities, you confirm early requirements and
show the users your understanding of an agreed set of requirements. The prototype is improved upon through the iterations where it finally shows a satisfactory result for
both parties. See the guidelines for IM.005 - Create Conceptual Prototype for more details about this.
Back to Top
TASKS
The tasks included in these activities are:
ID Task Name
IM.005 Develop Conceptual Prototype
RA.030 Validate Conceptual Prototype
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to these activities is to develop a Conceptual Prototype that assists in defining business requirements and user interface requirements early in the project.
Back to Top
PREREQUISITES
A.ACT.CCPI - Create Conceptual Prototype - Inception
B.ACT.CCPE - Create Conceptual Prototype - Elaboration
B.ACT.DUCM Develope Use Case Model
Back to Top
A.ACT.GSP - GATHER SUPPORTING REQUIREMENTS
This activity includes gathering supporting requirements that are not related to the business and system objectives.
Back to Top
OBJECTIVES
The objective for this activity is to gather all requirements needed to support development of the new system.
Back to Top
TASKS
ID Task Name
CV.010 Define Data Acquisition and Conversion Requirements
TE.005.1 Determine Testing Requirements
PT.010 Conduct Performance Management Workshop
TA.010 Conduct Technical Architecture Workshop
DO.010 Define Documentation Requirements and Strategy
RD.070 Document Audit and Control Requirements
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to develop Data Conversion, Testing, Performance Management, Architecture and Documentation requirements. This is done in a series
of workshops or small meetings, depending on the size of the solution being supported.
Back to Top
PREREQUISITES
Back to Top
A.ACT.SKSD - SPECIFY KEY STRUCTURE DEFINITION
This activity includes the design of key business structures, which have an impact across the entire application system. It also includes the definition of the data/values
needed to configure those key business structures.
Back to Top
OBJECTIVES
The objective for this activity is to identify those key structural elements in the applications (for example, Multi-Org, Trading Community Architecture (TCA), Chart Of
Accounts (COA) structures) that are relevant to your particular implementation and define the structures for those elements across all applications.
Back to Top
TASKS
ID Task Name
MC.010.1 Define Business Data Structures
MC.020 Define Business Data Structure Setups
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to design and define the key business structures and define the data/values needed to configure those key business structures.
Back to Top
PREREQUISITES
Back to Top
A.ACT.CMAHC - CREATE AND MANAGE AD HOC
COMMUNICATIONS
This activity consists of selecting, creating and managing the Ad Hoc Communications for the project.
Back to Top
OBJECTIVES
The objective for this activity is to create and manage the Ad Hoc Communication. The Ad Hoc Communications are the first initiative of the project communications. They
demonstrate that the project is well organized by having the first communication ready for the project start. They are also part of the project kickoff and include the first
key messages from the project sponsor and key leaders of the project. The Ad Hoc Communications consist of a series of key communication events well known for the
efficiency in the project start up (e.g., launched newsletter, project presentation that the core project team can use, kickoff event read).
Back to Top
TASKS
ID Task Name
OCM.010 Create and Manage Ad Hoc Communications
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to conduct brief interviews with the client project sponsor and Oracle leadership in order to obtain input for initial messages, timing and key
information that the audience will need to know prior to the formal communication campaign development; then select, create and implement the Ad Hoc
Communications.
Back to Top
PREREQUISITES
Back to Top
A.ACT.CEAW - CONDUCT EXECUTIVE ALIGNMENT
WORKSHOP
This activity focuses on preparing and conducting the Executive Alignment Workshop and building and deploying the Sponsorship Program.
Back to Top
OBJECTIVES
The objective for this activity is to capture the decisions made about project vision, objectives, and success criteria in order to communicate them to the project team so
that they can then provide direction to middle managers and end users. This activity also helps manage the project's impact on the organization as well as to mitigate
organizational risks. 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
ID Task Name
OCM.020 Prepare for Executive Alignment Workshop
OCM.030 Conduct Executive Alignment Workshop
OCM.040 Build and Deploy Sponsorship Program
Back to Top
ITERATIONS
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
A.ACT.GBRI - Gather Business Requirements - Inception
Back to Top
A.ACT.TPT - TRAIN PROJECT TEAM
This activity focuses on preparing and executing the Project Team Learning Plan. It includes preparation of the Project Team Learning Plan based on the requirements of
the engagement and project team background and experience, establishment of the Project Team Learning Environment (if required) and the administration of project
team learning events. This activity builds on the Staff Training Plan (STM.020) developed during the PJM Start Up phase.
Back to Top
OBJECTIVES
The objective for this activity is to prepare a learning plan for the project team who will be developing the solution, as well as establish the learning environment and lastly,
put the plan into action by conducting the team learning events.
Back to Top
TASKS
ID Task Name
TR.010.1 Define Training Strategy
TR.020 Prepare Project Team Learning Plan
TR.030 Prepare Project Team Learning Environment
TR.040 Develop Project Team Learningware
TR.050 Conduct Project Team Learning Events
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the training strategy as it pertains to the project team, to develop a plan for required skill development and orientation and
execute that plan so that the team can begin the project with the knowledge they require, in order to be able to develop the solution.
Back to Top
PREREQUISITES
Back to Top
A.ACT.CAWI - CONDUCT ALIGNMENT WORKSHOPS -
INCEPTION
This activity focuses on preparing and conducting the Team-Building Workshop, the Managers' Project Alignment Workshop and the Change Agent Workshop.
Back to Top
OBJECTIVES
The objective for this activity is to align core project team members, managers and change agents with the vision, direction and strategies of the project and obtain their
commitment.
Back to Top
TASKS
ID Task Name
OCM.050 Prepare for Team-Building Workshop
OCM.060 Conduct Team-Building Workshop
OCM.070 Design Managers' Project Alignment Workshop
OCM.080 Conduct Managers' Project Alignment Workshop
OCM.090 Design Change Agent Workshop
OCM.100 Conduct Change Agent Workshop
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the materials for each workshop and then conduct the workshops.
Back to Top
PREREQUISITES
A.ACT.CEAW Conduct Executive Alignment Workshop
Back to Top
A.ACT.CCRA - CONDUCT CHANGE READINESS ASSESSMENT
This activity focuses on creating the Change Readiness Assessment Strategy and Tools, gathering and analyzing assessment data and developing the Change
Management Roadmap for the project.
Back to Top
OBJECTIVES
The objective for this activity is to assess the organization's readiness for change and to design change management activities, events and communications to facilitate
the desired change.
Back to Top
TASKS
ID Task Name
OCM.110 Develop Change Readiness Assessment Strategy and Tools
OCM.120 Conduct Change Readiness Assessment and Analyze Data
OCM.130 Build Communication Strategy and Change Management Roadmap
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the Assessment Strategy, create the Assessment Tools and use the tools to gather the assessment data. The Change
Readiness Assessment data is analyzed and used to develop change management activities that support a successful implementation.
Back to Top
PREREQUISITES
Back to Top
A.ACT.DCMRCCI - DEPLOY CHANGE MANAGEMENT
ROADMAP/COMMUNICATION CAMPAIGN - INCEPTION
This activity consists of developing the essential communication components of the Change Management Roadmap/Communication Campaign and then rolling out the
Change Management Roadmap/Communication Campaign by successfully deploying the key communications, events and activities as scheduled.
Back to Top
OBJECTIVES
The objective for this activity is to successfully roll out the Change Management Roadmap/Communication Campaign in alignment with the overall project phases,
milestones and timelines. The purpose of the Change Management Roadmap/Communication Campaign is to prepare end-users to successful adapt to the proposed
change. By utilizing techniques such as effective communication timing, various media sources, and participant feedback tools, the Change Management
Roadmap/Communication Campaign helps manage stakeholders concerns, fears, expectations, and information needs. The detailed Change Management
Roadmap/Communication Campaign includes activities and a two-way process organized by audience, expectations, issues, and preferred communication channels to
ensure that the right information is communicated to the right people using the right vehicle at the right time. The communication is tailored to the organizations culture
and communication style.
Back to Top
TASKS
ID Task Name
OCM.140 Develop Communication Campaign
OCM.150.1 Conduct Change Management Roadmap/Communication Campaign
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach for this activity is to define and add the essential communication components and add them to the Change Management Roadmap/Communication
Campaign and then to roll out the activities, events and communications listed in the Change Management Roadmap/Communication Campaign at the established
project milestones.
Back to Top
PREREQUISITES
A.ACT.CCRA Conduct Change Readiness Assessment
Back to Top
A.ACT.LCOB - LIFECYCLE OBJECTIVE MILESTONE SUMMARY
In OUM, each phase finishes with a well-defined milestone. It is important to communicate the milestone to all the stakeholders since it is a point in time where critical
decisions should be made and goals evaluated. Each phase has a main milestone. The first key milestone is the Lifecycle Objective Milestone and it is produced at the
end of the Inception phase.
Back to Top
OBJECTIVES
Confirm business objectives.
Confirm project scope.
Define risks.
Estimate cost and plan.
Staff and prepare project team.
Back to Top
ACTIVITIES
The following activities are included in this milestone:
A.ACT.ECBB Establish Current Business Baseline
A.ACT.PSUIA Perform Software Upgrade Impact Analysis
A.ACT.CR Consolidate Solution Requirements
A.ACT.CCPI Create Conceptual Prototype - Inception
A.ACT.GSP Gather Supporting Requirements
A.ACT.SKSD Specify Key Structure Definition
A.ACT.CMAHC Create and Manage Ad Hoc Communications
A.ACT.TPT Train Project Team
A.ACT.CAWI Conduct Alignment Workshops - Inception
A.ACT.CORA Conduct Organizational Readiness Assessment
A.ACT.DCMRCCI Deploy Change Management Roadmap / Communication Campaign - Inception
Back to Top
ACTIVITY CHECKLISTS
The following checklist is available to assist with determination of completeness for this activity:
Checklist Name Comments
Inception Phase / Lifecycle Objective (LO) Milestone Checklist MS Word
Back to Top
[B] ELABORATION
The goal of the Elaboration phase is to move development of the solution from the scoping and high-level requirements done during the Inception phase to developing the detailed requirements,
partitioning the solution, prototyping (where necessary), and baselining the architecture of the system to provide a stable basis for the design and implementation effort in the Construction phase. The
architecture evolves from the most significant requirements -- those that have a great impact on the architecture of the system -- and an assessment of risk. The stability of the architecture is evaluated
through one or more architectural prototypes. During the Elaboration phase, the project team's understanding of the business requirements is verified to reduce development risk.
The Elaboration phase finishes with the Lifecycle Architecture Milestone. Review and be familiar with the objectives of this milestone before you begin this phase and make sure you have met these
objectives before you move to the Construction phase.
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
Identify and validate architecture (i.e., the architecturally-significant requirements). Refine the business requirements and analyze the requirements and formulate these in an appropriate
format (i.e. business process models, use cases, etc.) Obtain a detailed understanding of the business processes and use cases defined for the project. Ensure that the most architecturally
significant requirements are analyzed to reveal possible effects on the architecture. Prioritize the functional and supplemental requirements to maximize the business benefit and provide the
flexibility you need for developing in timeboxes. Agree on the visual approach to be applied to the user interface. Create a stable application architecture, technical architecture, and data
architecture.
Identify key configuration decisions. Define and document all setup information to be used in configuring the standard application functionality, as well the various other application environments
established for development, testing and documentation.
Estimate cost and plan. Recalculate the estimate in order to take into account information acquired during the first two phases. Prepare a well-defined plan for the Construction phase.
Prepare project environment. Prepare all environments needed to support the project.
Mitigate risks. Mitigate all critical risks and investigate all other significant risks. Create a mitigation plan, if necessary.
The Elaboration Phase / Lifecycle Architecture (LA) Milestone Checklist is available to assist with determination of completeness for this phase.
Back to Top
PROCESSES
Analysis (AN)
Design (DS)
Implementation (IM)
Testing (TE)
Documentation (DO)
Training (TR)
Transition (TS)
Back to Top
KEY WORK PRODUCTS
Back to Top
TIPS AND TECHNIQUES
This section discusses the primary techniques that may be helpful in conducting the Elaboration phase. It also includes advice and commentary on each process.
A number of requirements workshops are used to determine and detail the requirements for the OUM solution. The information that was gained during the Inception phase is used as input for the
preparation of the workshops. All the requirements are consolidated into the Requirements Specification. All these requirements should also be prioritized following the MoSCoW principle. The users
should do the prioritizing, but you need to help and advise them in the process. Monitor whether the priorities provided are reasonable.
One of the objectives of the Elaboration phase is to create a sound application architecture. In the Inception phase, you created an initial Architecture Description. You need to analyze the requirements to
determine whether there are factors that may influence the application architecture.
Based on the information gained in the requirements workshops, use the defined requirements to develop the Use Case Model and detail a number of selected use cases. The use cases you detail are
those that seem to be most vital to the new system. One aim is to achieve a stable architecture foundation at the end of the Elaboration phase, therefore, focus on identifying the use cases that may have
the most impact on how the architecture is built. Another aim is to mitigate significant risks, therefore, pick those use cases where the most risk is involved. This is a way of investigating the risk as soon
as possible, and thereby taking action to mitigate these risks as early as possible. If you have partitioned the system/project, you will perform this activity for all of the partitions.
The use cases are used as input to create the Functional Prototype in the Implementation process. When the prototype is ready, a walkthrough (RA.085 - Validate Functional Prototype) is performed with
the users. This is a workshop where the user interface designer walks the users through the design to demonstrate the design team's understanding of the agreed on requirements. Therefore, the
Functional Prototype is mainly a means of communication, by which to refine, adjust and add missing requirements. This validation is a major activity in the Elaboration phase, and the output provides the
input for the next phase, or iteration. Allow sufficient time for the validation. Again use the MoSCoW principle to prioritize the functionality as well as to prioritize how the time is used during the workshop.
In the Mapping and Configuration process, the values for the key structural elements in the applications established in Inception are further refined. The business requirements are mapped to the COTS
application. Setup Information, Application Setups and the Functional Security Setup are gathered, defined and documented. Configuration Prototyping workshops are conducted with the organization to
validate the configuration. Once the configuration has been validated and gaps have been defined, alternatives for resolving the gaps are defined and estimated and ultimately an alternative is selected.
Alternatives that require custom extensions are resolved through use cases.
Analysis
In the Analysis process, you take the use cases that have been detailed in the Requirements Analysis process a step further. In the Elaboration phase we focus on those use cases that are architectural
significant and more complex to gain an understanding of the complexity of the requirements. We analyze the use cases and structure them via various conceptual components and models. All of the
Analysis components are organized into the Analysis Model. The Analysis Model provides the developers with an understanding of the requirements and the details on the internals of the system. The
Analysis Model components use the language of the developers as opposed to Requirements where the emphasis is on the functionality of the system expressed in the language of the business. It thus
contributes to a sound and stable architecture and facilitates an in-depth understanding of the requirements. The Analysis Model is also considered the first cut of the Design Model, since it contains the
analysis classes that will be further detailed during the Design process.
Design
During the Design process, the system is shaped and formed to meet functional and supplemental requirements. At this stage the focus is on an architectural level. The architecturally-significant use
cases that have been analyzed in the Analysis process are taken further to design architectural significant classes, software components and their interfaces. You will also create an initial Logical
Database Design, applying the rules and principles of relational system design.
Implementation
During the Elaboration phase, three significant work products are produced in the Implementation process; the Functional Prototype, the Architectural Prototype, and the User Interface Standards
Prototype. To create the Functional Prototype, the use cases that are most critical are prototyped and validated by the users (as part of the Requirements Analysis process). The Architectural Prototype is
based on the use cases that have been identified to be most architecturally challenging. The prototype should take the form of how the major components should be built. This helps in mitigating
technological risks that may be encountered by trying out the pieces of technology to be used in developing the system. The biggest technological risks are inherent in how the components of a design fit
together rather than in the components themselves. The User Interface Standards Prototype defines the user interface standards for the application. It is beneficial if the task is performed as early as
possible in the Elaboration phase, so that the standards are defined and can be used as early as possible.
Testing
There is always a temptation to avoid component and module testing in the interest of assembling the solution more quickly. This is contrary to the principle that "Testing is integrated throughout the
lifecycle." Developers must take the time to test new modules and components as they are produced. The cost to correct defects increases markedly as the project proceeds. On the other hand, if
modules are in a prototype-state for the purpose of verification of functionality or design rather than in a final component-state, testing should be limited to a minimum, as the module probably will change
anyway, as a result of the validation by the users. Therefore, for each module or component that is developed, keep in mind in what state they are in to determine the appropriate testing effort.
Peer reviews of source code are also encouraged. These reviews should be kept brief and structured, yet informal and should include a team leader and one other developer, and may include an
ambassador user. Peer reviews serve three purposes:
to remove obvious code defects
to ensure conformance of the code to established standards
to cross train developers
The testing of executable components should be a final step in prototype creation. The scenarios that should be tested should be based on the use cases that are prototyped. Needed test cases and
scenarios are identified, and test procedures are created that should be used during the test. These scenarios, test cases and test procedures will be updated throughout the project whenever necessary.
New ones will be added when new functionality has been developed until a final set of Test Scenarios has been created for the final System Test performed in the Construction phase.
By implementing the Performance Management process, you can establish the performance of the system or component under test and use the results to make decisions on whether the performance is
acceptable to the business. If the performance characteristics you measure in the test prove to be unacceptable, you can make tuning efforts to improve the performance quality, or more drastically,
propose a change in the architecture of the system to provide the improvement needed. Performance Management is closely related to the Technical Architecture (TA) process and both are mutually
interdependent. You can manage the performance quality of the system you are implementing through various project practices and methods, but the only means of getting direct information about the
likely performance characteristics of your new system is to do a performance test.
The Architecture and Requirements Strategy is created at the beginning of this phase. If untried technology is introduced to the solution stack, it should be identified as a risk area and addressed in the
Architectural Prototype in the Implementation process. It may also be advisable to perform a benchmarking exercise on new hardware or software components as early as possible to make sure the
capacity requirements of the system can be fulfilled. Leaving this until later in the development significantly increases the risk level of the development.
If there are any required components not familiar to the team, have these reviewed by qualified technical experts before including them in the architecture. The ultimate success of any Internet-deployed
application is as much dependent on an appropriate technical infrastructure as on any other factor. Special care must be taken in developing an appropriate Security and Control Strategy.
Internet site security is much more than object level database security. This is of particular importance when, for example, customer credit cards are involved or when there is integration with one or more
core data processing systems. Security must be defined at the database level, at the application level, and at the network level. Relying on SSL as the sole security mechanism is a false economy.
In order to avoid delays and to achieve better data quality, the first data should be converted as early as possible in the project. The amount of effort involved with conversion greatly depends on the
condition of the data and the knowledge and complexity of the data structure in legacy systems and existing applications. Therefore, in the Elaboration phase you start the Data Acquisition and
Conversion process by determining an appropriate Data Conversion Strategy. In OUM, the cleaning of legacy data is visibly identified as a user and client project staff member task, so that it can be
staffed and scheduled.
Documentation
From the Documentation Requirements and Strategy developed in Inception, a Documentation Standards and Procedures (DO.020) is developed to guide the documentation work products to be
produced. In addition, you prepare the Documentation Environment during Elaboration.
During Elaboration, you prepare the Business Process Impact Inventory that you will use in Construction to complete OCM tasks. Ongoing throughout the project, change and communication events
targeted to specific audiences with the goal of mitigating identified risks and challenges are conducted.
Training
During Elaboration, the Education and Training Strategy is updated for user training.
Transition
In a project using the OUM approach, the business organization becomes familiar with, and progressively accepts, the new system as it is developed. Transfer of knowledge about the system to the
business staff is an integral part of the development process. The Transition team should involve the same ambassador users who have been involved from the start.
In the situations where you replace an old system, there are a number of techniques for going production:
phased
parallel
replacement
In the phased technique, partitions of the new system enter production use one at a time, while the legacy system's corresponding subsystems are shutdown in the same sequence. This allows for a
gradual move to the new system causing disruption in fewer internal user groups at once. This can also allow newly trained users to use their part of the system while other users are still being trained. A
side effect may be that you may need to develop temporary solutions to make the old and new parts work together as a whole.
In the parallel technique for going production, the new system goes production while the old system is still running. The users can use both systems at once. This can cause consistency problems if data
is not consistently entered in both systems. However, running the legacy system in a read-only mode is a common practice. There is also a lower risk, as there is a backup option if something should go
wrong. Another parallel option is to pick a group of users, or a single or a few offices to be a pilot for the new system, while other groups still are using the old system. This may be a good option when
there is a large number of user groups that work as separate units. This may also be a benefit when converting data as you may not need to convert all data immediately, but only the data that is relevant
for that user group. The downside of this method is that you may need to build new interfaces between the old and the new system, similar to the phased technique.
With the replacement technique, the legacy system is shut down when the new system goes production. This saves resources since you do not need both the new and old systems at the same time. This
is riskier than the other options because it means that you do not have access to the old system if anything should go wrong.
The type of rollout that you plan affects the design of the data conversion programs. A phased rollout requires data to be converted in steps -- a different problem than converting all data at once. If the
transition strategy is not stable, it is better to proceed with a phased transition approach, either by business unit or geographical location. This approach still leaves open the possibility of replacement
rollout.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project Using Scrum technique. You can also go directly to the Elaboration phase Scrum guidance within this technique.
Back to Top
RA.024.1 Develop Use Case Details Use Case Specification
RA.026.1 Populate Services Repository Populated Services Repository
RA.035 Develop High-Level Software Architecture Description Architecture Description
RA.055.1 Document Business Procedures Business Procedure Documentation
RA.085 Validate Functional Prototype Validated Functional Prototype
RA.095 Validate User Interface Standards Prototype Validated User Interface Standards Prototype
RA.160 Conduct Business Data Source Gap Analysis Business Data Source Gap Analysis
RA.170.1 Conduct Data Quality Assessment High-Level Data Quality Assessment
RA.180.1 Review Use Case Model Reviewed Use Case Model
MC.030 Map Business Requirements Mapped Business Requirements
MC.040 Gather Setup Information Setup Information
MC.050.1 Define Application Setups Application Setup Documents
MC.060 Document Functional Security Functional Security Setup
MC.070 Prepare Configuration Prototype Environment Configuration Prototype Environment
MC.080 Conduct Configuration Prototyping Workshop Validated Configuration
MC.100 Define and Estimate Application Extensions Application Extension Definition and Estimates
MC.110 Define Gap Resolutions Gap Resolutions
Analysis
AN.035.1 Update Existing Analysis Specification Updated Analysis Specification
AN.040.1 Develop Analysis Architecture Description Architecture Description
AN.050.1 Analyze Data Data Analysis
AN.060.1 Analyze Behavior Behavior Analysis
AN.070.1 Analyze Business Rules Business Rules Analysis
AN.080.1 Analyze Services Service Portfolio - Proposed Services
AN.085.1 Define Service Service Definition
AN.090.1 Analyze User Interface User Interface Analysis
AN.100.1 Prepare Analysis Specification Analysis Specification
AN.110.1 Review Analysis Model Reviewed Analysis Model
Design
DS.020 Define Application Extension Strategy Application Extension Strategy
DS.035.1 Update Existing Design Specification Updated Design Specification
DS.040.1 Develop Design Architecture Description Architecture Description
DS.050 Determine Design and Build Standards Design and Build Standards
DS.060 Define Business Rules Implementation Strategy Business Rules Implementation Strategy
DS.070 Define SOA Implementation Strategy SOA Implementation Strategy
DS.080.1 Design Software Components Software Component Design
DS.090.1 Design Data Component Data Design
DS.100.1 Design Behavior Component Behavior Design
DS.110.1 Design Business Rules Business Rules Design
DS.120.1 Design Services Service Design
DS.130.1 Design User Interface User Interface Design
DS.140.1 Prepare Design Specification Design Specification
DS.150.1 Develop Database Design Logical Database Design
DS.160.1 Review Design Model Reviewed Design Model
Implementation
IM.007.1 Prepare Development Environment Development Environment
IM.010 Develop Functional Prototype Functional Prototype
IM.020 Develop Architectural Foundation Architectural Foundation
IM.040.1 Implement Database Implemented Database
IM.053.1 Register Services Populated Services Registry
IM.055.1 Perform Business Rules Implementation (Rules Engine) Implemented Business Rules (Rules Engine)
IM.060.1 Perform Component Review Component Review Results
IM.085 Develop User Interface Standards Prototype User Interface Standards Prototype
Testing
TE.010 Develop Testing Strategy Testing Strategy
TE.015.1 Develop Integration Test Plan Integration Test Plan
TE.018.1 Prepare Static Test Data Static Test Data
TE.020.1 Develop Unit Test Scripts Unit Test Scripts
TE.025.1 Create System Test Scenarios System Test Scenarios
TE.030.1 Perform Unit Test Unit-Tested Components
TE.035.1 Create Integration Test Scenarios Integration Test Scenarios
TE.038.1 Prepare Integration Test Environment Integration Test Environment
TE.040.1 Perform Integration Test Integration-Tested Components
TE.050.1 Develop System Test Plan System Test Plan
TE.060.1 Prepare System Test Environment System Test Environment
TE.070.1 Perform System Test System-Tested Applications
TE.072.1 Test Pre-Upgrade Steps Packaged Software Upgrade Checklist
TE.073.1 Test Packaged Software Upgrade Pre-Upgrade Checklist
TE.074.1 Test Post-Upgrade Steps Post-Upgrade Checklist
TE.075.1 Perform Post-Upgrade Reconciliation Testing Reconciliation Test Report
TE.076.1 Review Upgrade Test Results Upgrade Test Analysis
TE.080 Develop Systems Integration Test Plan Systems Integration Test Plan
TE.082 Develop Acceptance Test Plan Acceptance Test Plan
PT.020 Define Performance Management Requirements and Strategy Performance Management Requirements and Strategy
PT.030 Define Performance Testing Strategy Performance Testing Strategy
PT.040 Identify Performance Testing Models and Scenarios Performance Testing Models and Scenarios
PT.050 Design Performance Test Scripts and Programs Performance Test Scripts and Programs Designs
PT.060 Design Performance Test Data and Load Programs Performance Test Data and Load Programs Designs
TA.006 Define Technical Prototype Subprojects Technical Prototype Approach
TA.020 Define Technical Architecture Requirements and Strategy Technical Architecture Requirements and Strategy
TA.030 Define Integration Requirements and Strategy Integration Architecture Strategy
TA.040 Define Reporting and Information Access Strategy Reporting and Information Access Strategy
TA.050 Define Disaster Recovery Strategy Disaster Recovery Strategy
TA.060 Define System Operations and Management Strategy System Operations and Management Strategy
TA.070 Define Initial Architecture and Application Mapping Initial Architecture and Application Mapping
TA.080 Define Backup and Recovery Strategy Backup and Recovery Strategy
TA.090 Develop Security and Control Strategy Security and Control Strategy
CV.020 Define Data Acquisition, Conversion and Data Quality Strategy Data Acquisition, Conversion and Data Quality Strategy
CV.025 Define Data Acquisition and Conversion Standards Data Acquisition and Conversion Standards
CV.027.1 Perform Data Mapping Data Mapping
CV.030.1 Prepare Conversion Environment (Initial Load) Conversion Environment (Initial Load)
CV.035.1 Define Manual Conversion Procedures (Initial Load) Manual Conversion Procedures (Initial Load)
CV.040.1 Design Conversion Components (Initial Load) Conversion Component Designs (Initial Load)
CV.050.1 Prepare Conversion Test Plans (Initial Load) Conversion Test Plans (Initial Load)
CV.055.1 Implement Conversion Components (Initial Load) Conversion Components (Initial Load)
CV.060.1 Perform Conversion Component Unit Test (Initial Load) Unit-Tested Conversion Components (Initial Load)
CV.062.1 Perform Conversion Component Business Object Test (Initial Load) Business Object-Tested Conversion Components (Initial Load)
CV.063.1 Perform Conversion Component Validation Test (Initial Load) Validation-Tested Conversion Components (Initial Load)
Documentation
DO.020 Define Documentation Standards and Procedures Documentation Standards and Procedures
DO.040 Prepare Documentation Environment Documentation Environment
OCM.155.1 Monitor Change Management Roadmap / Communication Campaign Effectiveness Change Management Roadmap / Communication Campaign Effectiveness Assessment
Training
Transition
TS.020.1 Define Cutover Strategy Cutover Strategy
Back to Top
Back to Top
MANAGING RISK
The risks described for the Inception phase also apply in this phase. In addition, you should be aware of the following areas of risk in the Inception phase:
Organization Structures and Business Processes Change Dramatically as a Result of the Introduction of the System: If this becomes apparent, then some user participants may feel
threatened by the imminent changes. Make sure that the ambassador users and advisor users are motivated and participate fully in the definition of processes. It is important that the user
participants develop a sense of ownership of the new system.
Original Project Approach is Inappropriate: As the requirements become better understood, it may be discovered that a OUM approach is not suitable. It may be that the client is not well suited
for the type of requirement flexibility implicit in a OUM project. This should not be regarded as a failure. In such a situation, the project sponsor should be informed immediately.
Back to Top
Availability of Ambassador Users: The project is dependent on ambassador user input. If the availability of the ambassador users is not sufficient, the convergence of the ambassador users
understanding and the developers understanding takes too long and hence the delivered prototype will be less useful both in terms of immediate business benefits and as a basis for further
development.
Suitability of Development Resources: The development resources are as critical as the user resources. OUM is for many developers a new type of development approach. They need to be able
to deliver quickly based on minimal requirements. Not all developers can successfully adapt to this kind of development. If the resources never have worked in a OUM or similar project
environment, but have been developing in more waterfall kind of projects, they should be checked for suitability. New developers that never have been involved in projects before will, in most
cases, adopt more easily to the OUM-way of working, as they have no prior experience that will interfere with this type of development.
Development Resource Skills: Because of the special skills required in a OUM approach, there is normally no time for training on the job. Skilled developers are essential. If there are any
inexperienced developers on the project, there should be at least one person coaching who is not on the critical path and estimates should be adjusted accordingly.
Facilitator Skills: During the Elaboration phase, most requirements are provided in workshops. Therefore the skills of the facilitator are vital in order to get the information in the right format, in the
right timeframe and with relevant and accurate content.
Communication: Communication is vital to make everyone understand what their tasks are and what they need to do in every situation, as well as to get clear requirements for the new system.
Every project participant (whether developer or user) needs good communication skills.
Understanding of the Approach: In a project using the OUM, it is important that all persons involved understand the approach and the benefits it delivers. For example, if the ambassador users do
not understand the need to prioritize functionality, they will tend to say that everything is equally important. They need to understand the impact of giving less important functionality a high priority.
Commitment from Client Organization: The commitment from the client organization is vital for a successful project. If this commitment is not present, then users (and user management) will not
prioritize project activities, and will not be sufficiently available, and even when available, they will not focus on making the right decisions.
Scribes: There should be at least one scribe in every session and it should be clear to everyone who is the scribe. The scribe should not be a person participating in the session. The scribe must
have the appropriate knowledge to perform this task.
Back to Top
B.ACT.DPS - DEFINE PROJECT STRATEGY
This activity allows for the defining of the various requirements, strategies, standards and procedures.
Back to Top
OBJECTIVES
The objective for this activity is to develop project strategies for the Application Extension, Testing, Data Acquisition and Conversion, Documentation, Training and
Transition of the solution.
Back to Top
TASKS
ID Task Name
DS.020 Define Application Extension Strategy
TE.005.2 Determine Testing Requirements
TE.010 Develop Testing Strategy
CV.020 Define Data Acquisition, Conversion and Data Quality Strategy
DO.020 Define Documentation Standards and Procedures
TR.010.2 Define Training Strategy
TS.020.1 Define Cutover Strategy
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to develop project strategies for the Application Extension, Testing, Data Acquisition and Conversion, Documentation, Training and
Transition of the solution. This includes strategies for Use Case, System, Systems Integration and Acceptance testing as well as Data Acquisition and Conversion. In
addition, the initial Cutover Strategy for the solution is formulated. The Education and Training Strategy is updated for user training and Documentation standards and
procedures that will be used during development of the solution are defined and communicated.
Back to Top
PREREQUISITES
A.ACT.LCOB Lifecycle Objective Milestone
Back to Top
B.ACT.DI - DEFINE INFRASTRUCTURE
This activity consists of producing the requirements for the Technical Architecture infrastructure.
Back to Top
OBJECTIVES
The objective for this activity is to Define the overall Technical Architecture infrastructure required to support the solution once it has moved to production.
Back to Top
TASKS
ID Task Name
TA.020 Define Technical Architecture Requirements and Strategy
TA.030 Define Integration Requirements and Strategy
TA.040 Define Reporting and Information Access Strategy
TA.050 Define Disaster Recovery Strategy
TA.060 Define System Operations and Management Strategy
TA.070 Develop Initial Architecture and Application Mapping
TA.080 Define Backup and Recovery Strategy
TA.090 Develop Security and Control Strategy
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is Define the Strategy and Requirements around the following:
system architecture
reporting
disaster recovery
backup and recovery
security and control
systems operations and management
This is required in order to develop an initial architecture mapping to support the solution once it has been moved to production.
Back to Top
PREREQUISITES
Back to Top
B.ACT.PEE - PREPARE ENVIRONMENTS - ELABORATION
This activity consists of setting up all the various environments.
Back to Top
OBJECTIVES
The objective for this activity is to prepare all environments needed to support development of the solution.
Back to Top
TASKS
ID Task Name
IM.007.1 Prepare Development Environment
TE.018.1 Prepare StaticTest Data
TE.038.1 Prepare Integration Test Environment
TE.060.1 Prepare System Test Environment
CV.030.1 Prepare Conversion Environment (Initial Load)
DO.040 Prepare Documentation Environment
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the development, test and documentation environments. This includes loading the environments with actual data to support the
activities that must go on to develop the solution.
Back to Top
PREREQUISITES
B.ACT.Di Define Infrastructure
Back to Top
B.ACT.GBRE - GATHER BUSINESS REQUIREMENTS -
ELABORATION
This activity involves the creation or refinement of detailed business process models reflecting the processes to be implemented in the new production system and the
documentation of role-based procedures based on the processes. The project team also reviews any proposed business process changes and other modifications
(setups, interfaces, custom extensions, etc.) to identify any gaps in the proposed solution.
Back to Top
OBJECTIVES
The objective for this activity is to add more detail to the Future Process Model reflecting the to-be business processes supported by the new application system and
prepare business procedures documentation aligned with the future processes.
Back to Top
TASKS
ID Task Name
RD.011.2 Develop Future Process Model
RA.055.1 Document Business Procedures
MC.030 Map Business Requirements
TA.006 Define Technical Prototype Subprojects
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to create or refine the business process models and document role-based procedures based on the processes.
Back to Top
PREREQUISITES
Back to Top
B.ACT.DTP - DEVELOP TEST PLANS
This activity allows for the developing of the various test plans.
Back to Top
OBJECTIVES
The objective for this activity is to develop the various test plans.
Back to Top
TASKS
ID Task Name
TE.015.1 Develop Integration Test Plan
TE.050.1 Develop System Test Plan
TE.080 Develop Systems Integration Test Plan
TE.082 Develop Acceptance Test Plan
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is prepare plans for Testing. This includes Integration, System, Systems Integration and Acceptance testing.
Back to Top
PREREQUISITES
B.ACT.DPS Define Project Strategy
Back to Top
B.ACT.SSC - SPECIFY SOFTWARE CONFIGURATION
This activity allows for the definition and documentation of all setup information, including business data structures, such as Inventory Item, Pricing, etc., not previously
addressed in the Specify Key Structure Definition activity (A.ACT.SKSD), as well as setup parameter values.
Back to Top
OBJECTIVES
The objective for this activity is to define and document all setup information to be used in configuring the Functional Prototype environment established for validation of
standard application functionality, as well the various other application environments established for development, testing and documentation. The setup information
initially specified in this activity is updated/maintained throughout the project, and ultimately, should reflect the setup parameters used to configure the Production
Environment.
Back to Top
TASKS
ID Task Name
MC.010.2 Define Business Data Structures
MC.040 Gather Setup Information
MC.050.1 Define Application Setups
MC.060 Document Functional Security
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to define and document all setup information, including remaining business data structures and values, and determine any additional
business data required to support functional prototyping and testing.
Back to Top
PREREQUISITES
Back to Top
B.ACT.PVC - PROTOTYPE AND VALIDATE CONFIGURATION
During this activity, you prepare the Configuration Prototype Environment and conduct a workshop with the organization with the goal of producing a Validated
Configuration.
Back to Top
OBJECTIVES
The objective for this activity is to validate the configuration with the organization.
Back to Top
TASKS
ID Task Name
TE.025.1 Create System Test Scenarios
MC.070
Prepare Configuration Prototype
Environment
MC.080
Conduct Configuration Prototyping
Workshop
MC.090.2 Conduct Reporting Fit Analysis
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Configuration Prototype Environment and conduct the workshop(s).
Back to Top
PREREQUISITES
B.ACT.SSC Specify Software Configuration
Back to Top
B.ACT.PGA - PERFORM GAP ANALYSIS
During this activity, alternative ways to address open requirements are determined and estimates for each alternative are prepared. As a final step the alternative
solutions are reviewed with the client and and the best alternative is determined based on the client's preference.
For projects that involve the upgrade of Oracle products, this activity is focused on identifying the gaps between functionality available within the clients current software
release and the target release.
Back to Top
OBJECTIVES
The objective for this activity is to identify any gaps in the proposed solution and determine the best alternative to resolving those gaps.
Back to Top
TASKS
ID Task Name
MC.100 Define and Estimate Application Extensions
MC.110 Define Gap Resolutions
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to review any proposed business process changes and other modifications (setups, interfaces, custom extensions, etc.). Prepare
alternative solutions and estimates and review them with the client to determine the best approach.
Back to Top
PREREQUISITES
B.ACT.GBRE Gather Business Requirements - Elaboration
B.ACT.PVC Prototype and Validate Configuration
Back to Top
B.ACT.DUCM - DEVELOP USE CASE MODEL
During this activity, you develop the Use Case Model.
Back to Top
OBJECTIVES
The objective for this activity is to develop the Use Case Model and identify the use cases that document the functionality required of the solution being developed.
Back to Top
TASKS
ID Task Name
RA.023.2 Develop Use Case Model
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the Use Case Model and identify the use cases.
Back to Top
PREREQUISITES
B.ACT.PGA Perform Gap Analysis
Back to Top
A.ACT.CCPI - CREATE CONCEPTUAL PROTOTYPE -
INCEPTION
B.ACT.CCPE - CREATE CONCEPTUAL PROTOTYPE -
ELABORATION
These activities consists of developing and validating the Conceptual Prototype.
Back to Top
OBJECTIVES
The objective for these activities is to develop a conceptual prototype in order to communicate requirements. Through these activities, you confirm early requirements and
show the users your understanding of an agreed set of requirements. The prototype is improved upon through the iterations where it finally shows a satisfactory result for
both parties. See the guidelines for IM.005 - Create Conceptual Prototype for more details about this.
Back to Top
TASKS
ID Task Name
IM.005 Develop Conceptual Prototype
RA.030 Validate Conceptual Prototype
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to these activities is to develop a Conceptual Prototype that assists in defining business requirements and user interface requirements early in the project.
Back to Top
PREREQUISITES
A.ACT.CCPI - Create Conceptual Prototype - Inception
#TOP #TOP
B.ACT.CCPE - Create Conceptual Prototype - Elaboration
B.ACT.DUCM Develope Use Case Model
Back to Top
B.ACT.CS - CONSOLIDATE SPECIFICATION
This activity provides another opportunity to refine the software requirements and review the Use Case Model and Use Case Specifications.
Back to Top
OBJECTIVES
The objective for this activity is to refine the software requirements and review the Use Case Model and Use Case Specifications and prepare for detail analysis and
design of the solution.
Back to Top
TASKS
ID Task Name
RD.140.2 Create Requirements Specification
RD.150.2 Review Requirements Specification
RA.180.1 Review Use Case Model
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is review the requirements as specified in the requirement specification and review the Use Case Model and Use Case Specifications in
preparation for the Analysis and Design activities.
Back to Top
PREREQUISITES
B.ACT.DUCM Develop Use Case Model
Back to Top
B.ACT.BSA - BASELINE SOFTWARE ARCHITECTURE
This activity produces the Architecture Description for the solution being developed.
Back to Top
OBJECTIVES
The objective for this activity is to provide a High level Architecture Specification for the solution being developed.
Back to Top
TASKS
ID Task Name
RA.035 Develop High-Level Software Architecture Description
AN.040.1 Develop Analysis Architecture Description
DS.040.1 Develop Design Architecture Description
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to define priorities for the use cases and update and consolidate any applicable documents in order to represent the prioritization decision
in a self-contained document. and The Architecture Design Description outlines the Design and Deployment models and their architecture
Back to Top
PREREQUISITES
B.ACT.CS Consolidate Specification
Back to Top
B.ACT.DUCD - DEVELOP USE CASE DETAILS
During this activity, you develops the use case details.
Back to Top
OBJECTIVES
The objective for this activity is to develop and provide details of the use cases that document the functionality required of the solution being developed.
Back to Top
TASKS
ID Task Name
RA.024.1 Develop Use Case Details
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is further detail the use cases in preparation for use case realization producing the solution design.
Back to Top
PREREQUISITES
B.ACT.BSA Baseline Software Architecture
Back to Top
B.ACT.AE - ANALYZE - ELABORATION
This activity allows for analyzing the captured requirements by refining and structuring them in the Analysis Model.
Back to Top
OBJECTIVES
The objective for this activity is to analyze the use cases and requirements.
Back to Top
TASKS
ID Task Name
AN.035.1 Update Existing Analysis Specification
AN.050.1 Analyze Data
AN.060.1 Analyze Behavior
AN.070.1 Analyze Business Rules
AN.080.1 Analyze Services
AN.085.1 Define Service
RA.026.1 Populate Services Repository
AN.090.1 Analyze User Interface
AN.100.1 Prepare Analysis Specification
AN.110.1 Review Analysis Model
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to perform analysis of the use cases and prepare and review the Analysis Model.
Back to Top
PREREQUISITES
B.ACT.DUCD Develop Use Case Details
Back to Top
B.ACT.DE - DESIGN - ELABORATION
This activity allows for designing the system to meet all functional and supplemental requirements.
Back to Top
OBJECTIVES
The objective for this activity is to realize the use cases into designed software components and database specifications.
Back to Top
TASKS
ID Task Name
DS.035.1 Update Existing Design Specification
DS.050 Determine Design and Build Standards
DS.060 Define Business Rules Implementation Strategy
DS.070 Define SOA Implementation Strategy
DS.080.1 Design Software Components
DS.090.1 Design Data
DS.100.1 Design Behavior
DS.110.1 Design Business Rules
DS.120.1 Design Services
DS.130.1 Design User Interface
DS.140.1 Prepare Design Specification
DS.150.1 Develop Database Design
DS.160.1 Review Design Model
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to realize the use cases into a software Design Model.
Back to Top
PREREQUISITES
B.ACT.AE Analyze - Elaboration
Back to Top
B.ACT.DCCTSE - DEVELOP CUSTOM COMPONENT TEST
SCRIPTS - ELABORATION
C.ACT.DCCTSC - DEVELOP CUSTOM COMPONENT TEST
SCRIPTS - CONSTRUCTION
This activity consists of developing the scripts and scenarios for the unit and integration tests.
*This activity has Elaboration Application Implementation supplemental activity guidance and Construction Application Implementation supplemental activity guidance.
Back to Top
OBJECTIVES
The objective for this activity is to develop the Unit Test Scripts and the Integration Test Scenarios.
Back to Top
TASKS
The tasks included in the Develop Custom Component Test Scripts - Elaboration activity are:
ID Task Name
TE.020.1 Develop Unit Test Scripts
TE.035.1 Create Integration Test Scenarios
The tasks included in the Develop Custom Component Test Scripts - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Unit Test Scripts and the Integration Test Scenarios.
Supplemental Guide to access all application implementation supplemental information. You can also go directly to the Elaboration activity-specific supplemental
guidance or the Construction activity-specific supplemental guidance.
Back to Top
PREREQUISITES
You will need the following for these activities:
B.ACT.DCCTSE - Develop Custom Component Test Scripts - Elaboration
B.ACT.DE Design - Elaboration
C.ACT.DCCTSC - Develop Custom Component Test Scripts - Construction
C.ACT.DC Design - Construction
Back to Top
B.ACT.DSTSE - DEVELOP SYSTEM TEST SCENARIOS -
ELABORATION
C.ACT.DSTSC - DEVELOP SYSTEM TEST SCENARIOS -
CONSTRUCTION
This activity consists of developing the System Test Scenarios.
Back to Top
OBJECTIVES
The objective for this activity is to develop the System Test Scenarios.
Back to Top
TASKS
The tasks included in the Develop System Test Scenarios - Elaboration activity are:
ID Task Name
The tasks included in the Develop System Test Scenarios - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the System Test Scenarios.
Back to Top
PREREQUISITES
B.ACT.DSTSE - Develop System Test Scenarios - Elaboration
C.ACT.DSTSC - Develop System Test Scenarios - Construction
B.ACT.LCAR Lifecycle Architecture Milestone (if no custom development)
Back to Top
B.ACT.DVCSP - DEVELOP AND VALIDATE CUSTOM
SOFTWARE PROTOTYPES
This activity allows for developing and validating the various prototypes, implementing the database and performing a component review.
Back to Top
OBJECTIVES
The objective for this activity is to develop prototypes to confirm, and communicate the requirements of the solution.
Back to Top
TASKS
ID Task Name
IM.010 Develop Functional Prototype
RA.085 Validate Functional Prototype
IM.020 Develop Architectural Foundation
IM.085 Develop User Interface Standards Prototype
RA.095 Validate User Interface Standards Prototype
IM.040.1 Implement Database
IM.053.1 Register Services
IM.055.1 Perform Business Rules Implementation (Rules Engine)
IM.060.1 Perform Component Review
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare prototypes and use them to validate the proposed functionality of the solution and their relationship back to business
requirements. The architecture required to support the solution and any user interface requirements are prototyped.
Back to Top
PREREQUISITES
Back to Top
B.ACT.PCCTE - PERFORM CUSTOM COMPONENT TESTING -
ELABORATION
C.ACT.PCCTC - PERFORM CUSTOM COMPONENT TESTING -
CONSTRUCTION
This activity consists of performing unit and integration tests as needed.
Back to Top
OBJECTIVES
The objective for this activity is to perform unit and integration tests as necessary.
Back to Top
TASKS
The tasks included in the Perform Custom Component Testing - Elaboration activity are:
ID Task Name
TE.030.1 Perform Unit Test
TE.040.1 Perform Integration Test
The tasks included in the Perform Custom Component Testing - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to performed unit and integration tests when and as needed.
Back to Top
PREREQUISITES
B.ACT.PCCTE Perform Custom Component Testing - Elaboration
B.ACT.DCCTSE Develop Custom Component Test Scripts - Elaboration
B.ACT.DVCSP Develop and Validate Custom Software Prototypes
C.ACT.PCCTC Perform Custom Component Testing - Construction
C.ACT.DCCTSC Develop Custom Component Test Scripts - Construction
C.ACT.ICC Install Custom Components
Back to Top
ACT.PSTE - PERFORM SYSTEM TEST - ELABORATION
This activity consists of performing the system test.
Back to Top
OBJECTIVES
The objective for this activity is to perform the system test.
Back to Top
TASKS
ID Task Name
TE.070.1 Perform System Test
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to perform a system test for each iteration as needed. The final system test at the end of all iterations should verify that the system works
as a whole, in a way that is consistent with what the users expect, and to detect inconsistencies and omissions between the partitions (including any from previous
increments).
Back to Top
PREREQUISITES
B.ACT.PEE Prepare Environments - Elaboration
B.ACT.DSTSE Develop System Test Scenarios - Elaboration
Back to Top
B.ACT.VUPE - VALIDATE UPGRADE PROCESS -
ELABORATION
C.ACT.VUPC - VALIDATE UPGRADE PROCESS -
CONSTRUCTION
These activities serve to validate the complete upgrade process.
Back to Top
OBJECTIVES
The objective for these activities is to perform an incremental rehearsal of the upgrade process.
Back to Top
TASKS
The tasks included in Validate Upgrade Process - Elaboration activity are:
ID Task Name
TE.072.1 Test Pre-Upgrade Steps
TE.073.1 Test Packaged Software Upgrade
TE.074.1 Test Post-Upgrade Steps
TE.075.1 Perform Post-Upgrade Reconciliation Testing
TE.076.1 Review Upgrade Test Results
The tasks included in Validate Upgrade Process - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to these activities involves formally testing all of the individual steps involved within the upgrade process according to the upgrade plan. The pre-upgrade
steps are performed, followed by the actual software upgrade, followed by post-upgrade steps. At each step, actual results are compared to predicted or expected results
followed by a reconciliation and subsequent updates into the next upgrade iteration.
The number of times the upgrade process is rehearsed prior to the final cutover depends on the number of iterations defined within the Project Management Plan. In any
event, each increment of the upgrade process can be expected to be progressively more comprehensive.
Back to Top
PREREQUISITES
B.ACT.VUPE Validate Upgrade Process - Elaboration
C.ACT.VUPC Validate Upgrade Process - Construction
C.ACT.ACDC Acquire and Convert Data - Construction
Back to Top
B.ACT.PPM - PLAN PERFORMANCE MANAGEMENT
This activity consists of producing the requirements, strategy, testing models, scenarios, test scripts, and program designs for Performance Management and Testing.
Back to Top
OBJECTIVES
The objective for this activity is to prepare a plan for managing performance of the solution being developed, both before, during and after implementation.
Back to Top
TASKS
ID Task Name
PT.020 Define Performance Management Requirements and Strategy
PT.030 Define Performance Testing Strategy
PT.040 Identify Performance Testing Models and Scenarios
PT.050 Design Performance Test Scripts and Programs
PT.060 Design Performance Test Data and Load Programs
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the requirements and strategy for measuring performance. This includes testing plans and program components that will
simulate the system under load, and measure the activity. This allows early detection of any performance issues, during development, well before the solution is
implemented.
Back to Top
PREREQUISITES
Back to Top
B.ACT.PACDE - PREPARE TO ACQUIRE AND CONVERT DATA -
ELABORATION
This activity consists of producing the standards, manual conversion procedures, designed components, and test plans as well as completing the conversion component
test for Data Acquisition and Conversion.
Back to Top
OBJECTIVES
The objective for this activity is to develop requirements and prepare the various components for the acquisition and conversion of data required to support the solution
being developed.
Back to Top
TASKS
ID Task Name
CV.025 Define Data Acquisition and Conversion Standards
RA.160 Conduct Business Data Source Gap Analysis
CV.027.1 Perform Data Mapping
RA.170.1 Conduct Data Quality Assessment
CV.035.1 Define Manual Conversion Procedures (Initial Load)
CV.040.1 Design Conversion Components (Initial Load)
CV.050.1 Prepare Conversion Test Plans (Initial Load)
CV.055.1 Implement Conversion Components (Initial Load)
CV.060.1 Perform Conversion Component Unit Test (Initial Load)
CV.062.1 Perform Conversion Component Business Object Test (Initial Load)
CV.063.1 Perform Conversion Component Validation Test (Initial Load)
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to define and prepare the necessary Data Acquisition and Conversion components required to move to the solution being developed. This
includes standards, conversion procedures, component designs, and test plans.
Back to Top
PREREQUISITES
Back to Top
B.ACT.PBPII - PREPARE BUSINESS PROCESS IMPACT
INVENTORY
This activity focuses on preparing the Business Process Impact Inventory.
Back to Top
OBJECTIVES
The objective for this activity is to capture the impact of the business process changes.
Back to Top
TASKS
ID Task Name
OCM.160 Prepare Business Process Impact Inventory
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to execute the task, Prepare Business Process Impact Inventory and capture the impact of the business process changes.
Back to Top
PREREQUISITES
Back to Top
B.ACT.DCMRCCIE - DEPLOY CHANGE MANAGEMENT
ROADMAP / COMMUNICATION CAMPAIGN - ELABORATION
C.ACT.DCMRCCIC - DEPLOY CHANGE MANAGEMENT
ROADMAP / COMMUNICATION CAMPAIGN - CONSTRUCTION
D.ACT.DCMRCCIT - DEPLOY CHANGE MANAGEMENT
ROADMAP / COMMUNICATION CAMPAIGN - TRANSITION
E.ACT.DCMRCCIP - DEPLOY CHANGE MANAGEMENT
ROADMAP / COMMUNICATION CAMPAIGN - PRODUCTION
These activities consist of rolling out the Change Management Roadmap / Communication Campaign by conducting the activities, events and communications
successfully as scheduled and then monitor the effectiveness of the Change Management Roadmap / Communication Campaign.ose activities, events and
communications.
Back to Top
OBJECTIVES
The objective for this activity is to successfully roll out the Change Management Roadmap / Communication Campaign in alignment with the overall project phases,
change. By utilizing techniques such as effective communication timing, various media sources, and participant feedback tools, the Change Management Roadmap /
Communication Campaign helps manage stakeholders concerns, fears, expectations, and information needs. The detailed Change Management Roadmap /
Communication Campaign includes activities and a two-way process organized by audience, expectations, issues, and preferred communication channels to ensure that
the right information is communicated to the right people using the right vehicle at the right time. The communication is tailored to the organizations culture and
communication style.
Back to Top
TASKS
ID Task Name
OCM.150 Conduct Change Management Roadmap / Communication Campaign
OCM.155 Monitor Change Management Roadmap / Communication Campaign Effectiveness
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is roll out the activities, events and communications in the Change Management Roadmap / Communication Campaign at the established
milestones. After each activity, event or communication, monitor the effectiveness by capturing feedback in order to align the organizational infrastructure with the change
and improve future rollouts.
Back to Top
PREREQUISITES
B.ACT.DCMRCCE Deploy Change Management Roadmap / Communication Campaign
- Elaboration
C.ACT.DCMRCCC Deploy Change Management Roadmap / Communication Campaign
- Construction
B.ACT.LCAR Lifecycle Architecture Milestone
D.ACT.DCMRCCT Deploy Change Management Roadmap / Communication Campaign
- Transition
C.ACT.IOCM Initial Operational Capability Milestone
E.ACT.DCMRCCP Deploy Change Management Roadmap / Communication Campaign
- Production
D.ACT.SIP System in Production Milestone
Back to Top
B.ACT.LCAR - LIFECYCLE ARCHITECTURE MILESTONE
SUMMARY
decisions should be made and goals evaluated. Each phase has a main milestone. The Lifecycle Architecture Milestone is the second key milestone of the project. It is
typically expected at the end of the Elaboration phase. At this point, most of the requirements should be analyzed and designed. At this time, the architecture should be
stabilized.
Back to Top
OBJECTIVES
Identify and validate architecture (i.e., the architecturally-significant requirements).
Identify key configuration decisions.
Prepare project environment.
Mitigate risks.
Back to Top
ACTIVITIES
B.ACT.DI Define Infrastructure
B.ACT.DTP Develop Test Plans
B.ACT.CCPE Create Conceptual Prototype - Elaboration
B.ACT.AE Analyze Elaboration
B.ACT.DE Design Elaboration
B.ACT.DSTSE Develop System Test Scenarios - Elaboration
B.ACT.PSTE Perform System Test - Elaboration
B.ACT.PPM Plan Performance Management
B.ACT.PACDE Prepare to Acquire and Convert Data - Elaboration
B.ACT.PBPII Prepare Business Process Impact Inventory
B.ACT.DCMRCCE Deploy Change Management Roadmap / Communication Campaign - Elaboration
Back to Top
ACTIVITY CHECKLISTS
Elaboration Phase / Lifecycle Architecture (LA) Milestone Checklist MS Word
Back to Top
[C] CONSTRUCTION
The goal of the Construction phase is to take the solution from detailed requirements models, through configuration of standard packaged software functionality, development and testing of custom
components, and integration to a system that is ready for a first release that goes into production, often a limited release and often called a beta release. In short, we complete the development of the
application system, validate that all components fit together, and prepare the system for the Acceptance Test and deployment.
For projects that involve the upgrading of an existing Production Environment, the Construction phase serves to update all components of the system and thoroughly test the migrated business
solution.
In more detail, the Construction phase clarifies the remaining requirements and completes the development of the system based upon the baseline architecture. In one sense, and particularly for the
custom developed components of the overall business solution, the Construction phase is a manufacturing process, where emphasis is placed on managing resources and controlling operations to
optimize costs, schedules, and quality. At this point, the management mind-set changes from the development of intellectual property during Inception and Elaboration, to the development of
deployable products during Construction and Transition. The application system is completed within a pre-defined number of iterations. Updates are made to each of the models (Use Case Model,
Design Model, Architectural Implementation, etc.), as the requirements are progressively refined. For each iteration, every developer works with a given set of prioritized use cases and based on this
develop and unit-test the components following the order of the priorities. When the development timebox has reached its end, the developer walks through the changes with the users. The users
validate and refine the requirements, and provide MoSCoW priorities for each changed or new requirement. The modified or new requirements are fed back to the requirement models in the business
layer. All changed or new requirements are evaluated to make certain there has not been a scope change, and the result provides the input for the next iteration of the partition. Once the team is
comfortable with the approach, the formal and sequential nature of development followed by walk through, followed by evaluation can be replaced with a more informal and continuous approach.
When all of the planned iterations have been completed for each partition, the complete application system is tested. The tested system is the end goal of the phase.
For Commercial Off-the-Shelf (COTS) software components of the overall business solution, the Construction phase involves the establishment of a System Test Environment based on the results of
business requirements mapping and configuration activities from the Elaboration phase, and the execution of one or more system tests, depending on the number of Construction phase iterations that
are planned. Where multiple iterations are planned, each system test will test the operation and integration of all business system flows within the (COTS) application system, as well as the application
extensions completed and integrated with the COTS application system during that iteration.
An iterative process is used to refine the data and detail the use cases, as well as develop the physical database and components, until they meet the business requirements, within the constraints of
the project timeboxes and priorities. The ambassador users provide refinements during each iteration, so that this can be used as input for the next iteration.
The outcome of the Elaboration phase is the architectural baseline and a version of all models. In particular, the Use Case Model and Analysis Model, as they are the most complete, provide the input
for the first iteration within the Construction phase. Every designer and developer works with a part of the Use Case Model and Design Model. Functionality is developed and unit-tested following the
order of the priorities of the use cases. When the iteration has reached its end, both technical participants and users review the results.
When all of the planned iterations have been completed, the complete system is tested. The tested system is the end work product of the phase.
The Construction phase finishes with the Initial Operational Capability Milestone. Review and be familiar with the objectives of this milestone before you begin this phase and make sure you have met
these objectives before you move to the Transition phase.
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-
Back to Top
OBJECTIVES
#TOP
Prepare system for acceptance test and deployment. Iteratively, produce a physical database, integrate developed or reused components, and configure product components, to produce an
integrated system that provides the high-priority business benefits. Ensure a stable and mature beta release. Adequately address non-functional requirements, such as security, reliability, etc.
Ascertain appropriate capacity and workload calculations in order to determine the Production Environment figures.
Develop supporting documentation. Prepare any required user and technical documentation and produce Online Help.
Prepare users for Transition. Properly involve users that can verify the implementation of the functional requirements. Begin to train end users in the functionality of the new system.
Estimate cost and plan. Recalculate the estimate in order to take into account information acquired during the first three phases. Prepare a well-defined plan for the Transition phase.
The Construction Phase / Initial Operational Capability (IOC) Milestone Checklist is available to assist with determination of completeness for this phase.
Back to Top
PROCESSES
Analysis (AN)
Design (DS)
Implementation (IM)
Testing (TE)
Documentation (DO)
Training (TR)
Transition (TS)
Back to Top
KEY WORK PRODUCTS
Back to Top
TIPS AND TECHNIQUES
This section discusses the primary techniques that may be helpful in conducting the Construction phase. It also includes advice and commentary on each process.
The priorities given in the requirements MoSCoW List (RD.045) and the detailed priorities given in the use cases should be continually monitored and maintained by the project manager as the
primary means of containing scope . See the task description of RD.045 for more details about prioritizing. In the Elaboration phase, we identified most of the use cases, but while going into more
detail we are likely to identify new and refined requirements that also should be captured in the models. Alternately, keep the scope in mind to prevent a creeping scope. Although we have tried to
identify the use cases that were architecturally significant in the Elaboration phase and to detail these to define a stable architectural baseline, we might discover new or changed factors that may
influence the architecture. If so, these should be included in the Global Analysis of the Application Architecture, as well as a strategy on how to deal with these factors.
As components are designed and developed, we still may identify some new use cases and actors. This normally would only be a fraction of the total set of use cases. The Use Case Model should be
refined to reflect the deepening understanding of the requirements and make the model more consistent. Both the technical staff and the ambassador users review the Use Case Model and the use
case details. The technical reviewers will probably use inspections of the model to ensure the quality of the model from a development and architectural viewpoint. Organize a walkthrough of the use
cases where the developer shows the actual developed use case and walks the user through the scenarios of that use case in order to let the ambassador users review the use cases. This hands-on
access allows the users to validate the requirements in detail. During the hands-on validation, the end user is able to discover shortcomings and possible factors that have not yet been included in the
requirements.
In Construction, you take one last opportunity to make any last minute updates to the Application Setup Documents.
Analysis
In the Analysis process, the work done in the Elaboration phase is further refined in the Construction phase.
Design
During the Design process, the system is shaped and formed to meet all functional and supplemental requirements. This is based on the architecture created and stabilized during the Analysis
process. Thus the artifacts produced during Analysis are an important input to this process. The Design Model can be used to visualize the implementation of the system, and collaboration diagrams
can be used to visualize how use cases are implemented. In the Elaboration phase, we designed and implemented only a few use cases, those that were relevant to develop the architectural baseline.
Therefore, elements will not be added (or only a few) that will impact the architectural baseline, such as design or service components, that already exist as skeletons. In this phase we will design the
rest of the use cases.
Implementation
During the Implementation process, the results of the Design process are used to implement the system in terms of source code for components, scripts, executables etc. We also implement and
perform development testing on software components. Throughout the lifecycle, hands-on access is provided for the end users to give them the opportunity to validate the requirements in detail
(RA.180). During the hands-on validation, the end user is able to discover shortcomings and possible factors that have not yet been included in the requirements. Within iterations, each developer or
team of developers must be provided the MoSCoW List of functionality to be developed during that timebox. The work must be accomplished according to the provided MoSCoW List. The developer
has a certain amount of time (a timebox) to develop and unit test the next version before the next hands-on validation. Therefore, it is vital that the priorities are properly managed because generally
there is not time enough to develop all functionality. End users tend to classify everything as a Must have, which results in an impossible job for the developers, in that functionality is not prioritized.
This may result in not all Must have functionality being developed, and some less important parts being developed. This principle must be completely understood by the end users as well as the
developers, and the developers must be able to trust the priorities as they have been provided. Provide, to each developer, a fixed set of components that should be implemented to a predefined level
determined by the priorities for those components, so that the developer can work as independently as possible during the set timebox. However, monitor that the effort between developers is similar,
so that one developer does not complete the Must Haves, while in the meantime another already is working on the Could have functionality. Also make sure that a developer does not invent
functionality just because it would be really nice for the users. In this way, the project fills each component with more and more code, timebox after timebox, iteration after iteration, until the end of the
Construction phase, where all components are completed to an acceptable level. Each developer should test each component prior to delivering it to the end user, preferable by creating unit tests.
When created properly, unit tests are repeatable, and thus can be reused, not only after each time the code changes, but also to discover unexpected side effects of changes of other components,
and during Testing. In the early iterations, it is not required that the component is bug-free, but it must be possible for the end user to validate and refine the requirements without too many irritating
bugs .
Testing
Test planning and test design begins early in this phase based on the Testing Requirements and Testing Strategy, the use cases and the architectural baseline. Checklists are prepared for each type
of component. Test scripts and scripted test data are developed for automated regression testing.
OUM emphasizes the need for early testing using real business data, which usually is converted from legacy systems. As well as supporting more effective and realistic testing, users find it easier to
test a system that contains recognizable business data. Analyze the data domains (or equivalence classes) in order to make sure that they are all covered in batch loading or during manual data entry,
as appropriate. Sufficient code data should be loaded into the code tables as early as possible. Other tables should be populated as soon as the Database Design has stabilized.
Reused components require at least functional testing. Any hand-coded programs should be white-box tested by a developer before user validation.
Make effective use of standard test tools (for example, unit testing framework) to increase your productivity and rapidly locate defects. Aim for a high level of functional coverage, and some
supplemental testing may be necessary. Performance testing is a separate process.
An adequate review of system architecture and system design prevents most defects at the system level. Therefore, involve ambassador users and IS staff members that have already been involved
in the high-level design reviews in order to reduce the time and effort needed in test and rework later. Regarding system testing, make effective use of standard test tools. Testing should, at a
minimum, cover all of the Must Have and Should Have requirements in the MoSCoW List. Testing of Could Have requirements should be given a lower priority but it must be understood that the
implementation of any such requirements may not compromise data integrity or application stability.
At the system level, supplemental testing is performed. Non-functional testing includes backup and recovery testing, which provides an additional benefit of DBA training.
Systems integration testing is performed where external systems interface to the new system. This is almost entirely supplemental testing. The procedures and tools involved in systems integration
testing depend on the nature of the interface, the operating environment and procedures of the external system and the kind of solution chosen (for example, using flat files and buffer tables,
transparent gateways, procedural gateways or ODBC). In some cases, replication may be an element of the solution and appropriate testing needs to be performed. Special attention should be given
to testing when interfacing to other databases (for example, for locking situations).
The objective of the Performance Management process is to proactively define, construct, and execute an effective approach to managing performance throughout the project implementation lifecycle
in order to ensure that the performance of the system or system components meet the user's requirements and expectations when the system is implemented. Performance Management is not
limited to conducting a performance test or an isolated tuning exercise, although both those activities may be part of the overall Performance Management strategy. In the Elaboration phase you have
identified which parts of the system are performance critical, and have defined the scenarios that should be performance tested. In the Construction phase you will develop those components that are
needed to be able to perform an adequate performance test. Realistic data volumes should be used in stress testing and performance testing. Use automated load- and stress-test tools, when
available. You also complete the Performance Test Environment and Database and conduct a dress rehearsal to validate the performance test and environment. It is important that the environment is
set up using realistic parameters and data, and with a realistic load. Performance Testing uses the concept of Test Scenarios to make this tieback to the real system. Test Scenarios are point-in-time
snapshots of the processing occurring (or projected to occur) in the real system. Once the scenarios have been identified, they can be characterized and used to fix the relative mix of different
transactions, inquiries, or reports that should execute during the Performance Test of that particular processing situation. You can scale the scenario mix to measure the performance of the system
under different total loads (transaction models).
During the Construction phase, you create the System Management Guide, conduct backup and recovery testing and define the final platform and network architecture. Optionally, you define and
conduct operational testing and conduct disaster recovery testing. Also, if your project encompasses a complex architecture change, you may also be creating the System Capacity Plan. The Capacity
Plan differs greatly from more traditional plans in that user load is not predictable. The user load that the site is required to support must be defined within the contract and the site should be designed
to support that capacity. The Capacity Plan rather reflects the agreement between the client and Oracle as to the capacity the system is required to support and the strategy for extending that capacity
as user demand increases. It is imperative that this agreement is carefully documented. These requirements are then fulfilled by the technical architecture consisting of components that are available
when required.
In the Elaboration phase, you agreed to convert data that will have an ongoing value to the business. Data fields in legacy systems often change meaning over time (without markers having indicated
a change in use). This makes it difficult to automatically convert data without manual intervention, or "data cleansing." It is difficult to estimate the extent of data cleansing needed until the Elaboration
phase is complete, and sometimes not even until one iteration has been completed in the Construction phase, so you may need to update your plan for data conversion as more becomes known. In
the Construction phase, review all the components that are required to convert and clean the data that should be converted. Then make an initial pass at converting and cleansing the data.
Documentation
During Construction, the actually Documentation is published and the Online Help is produced.
Ongoing throughout the project, change and communication events targeted to specific audiences with the goal of mitigating identified risks and challenges are conducted. In addition, during
Construction a Job Impact Analysis is conducted and the Managers' Unit/Department Impact Workshop is held.
Training
During Elaboration, you start preparing the organization for user training on the new system. This incorporates communicating, analyzing user needs, planning curriculums and conducting learning
events.
Transition
During Construction, refine your initial Cutover Strategy and develop your Installation Plan. A good Installation Plan eases the system rollout. This task is technical in nature and typically involves the
transfer of the operation of the new system from the project to the client operations and maintenance staff. Early in the project, start building the Installation Plan and test it for each iteration. In this
way, the Installation Plan evolves along with the system being built.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project Using Scrum technique. You can also go directly to the Construction phase Scrum guidance within this technique.
Back to Top
MC.050.2 Define Application Setups Application Setup Documents
Analysis
AN.085.2 Design Service Service Definition
Design
Implementation
IM.050 Implement Components Implemented Components
IM.070 Assemble Components Assembled Components
IM.080 Integrate Services Integrated Services
IM.090 Create Installation Routines Installation Routines
Testing
TE.019.2 Collect, Assess and Refine KPI Measurements Key Business Strategies and Objectives
TE.065 Perform Installation Test Tested Installation Routines
TE.085 Prepare Systems Integration Test Environment Systems Integration Test Environment
TE.090 Develop Systems Integration Test Scenarios Systems Integration Test Scenarios
TE.100 Perform Systems Integration Test Integration-Tested System
PT.070 Build Performance Test Scripts and Programs Performance Test Scripts and Programs
PT.080 Construct Performance Test Environment and Database Performance Test Environment and Database
PT.090 Conduct Performance Test Dress Rehearsal Validated Performance Test and Environment
TA.100 Define System Management Procedures System Management Guide
TA.110 Define Operational Testing Plan Operational Testing Plan
TA.120 Conduct Operational Testing Operational Test Results
TA.130 Conduct Backup and Recovery Test Backup and Recovery Test Results
TA.140 Conduct Disaster Recovery Test Disaster Recovery Test Results
TA.150 Define Final Platform and Network Architecture Final Platform and Network Architecture
TA.160 Define System Capacity Plan System Capacity Plan
CV.064.1 Install Conversion Components (Initial Load) Installed Conversion Components (Initial Load)
CV.065.1 Convert and Verify Data (Initial Load) Converted and Verified Data (Initial Load)
CV.068.1 Clean Data Clean Legacy Data
Documentation
DO.060 Publish User Reference Manual User Reference Manual
DO.070 Publish User Guide User Guide
DO.080 Publish Technical Reference Material Technical Reference Material
DO.100 Produce Online Help Online Help
OCM.155.2 Monitor Change Management Roadmap / Communication Campaign Effectiveness Change Management Roadmap / Communication Campaign Effectiveness Assessment
Training
TR.060 Conduct User Learning Needs Analysis User Learning Needs Analysis
TR.070 Develop User Learning Plan User Learning Plan
TR.080 Develop User Learningware User Learningware
TR.090 Prepare User Learning Environment Configured User Learning Environment
TR.100.1 Conduct User Learning Events Skilled Users
Transition
TS.030 Develop Installation Plan Installation Plan
TS.040 Design Production Support Infrastructure Production Support Infrastructure Design
Back to Top
Back to Top
MANAGING RISK
The risks described for the Inception and Elaboration phases also apply in this phase. In addition, you should be aware of the following areas of risk and suggested mitigation strategies in the
Construction phase:
Backtracking is Difficult: Configuration management must be established to allow development to return to an earlier version at any time. This may be necessary when, through a
misunderstanding between users and developers, development has started to go in the wrong direction. The risk of wasting effort in this way can be reduced by short, frequent cycles of
development and validation.
Testing is Not Integrated throughout the Lifecycle: An integrated, continuous approach to testing is important to minimize effort as a result of development going in the wrong direction or
critical errors. All team members need to understand this, which is mainly documented in the Business Testing process, but is also part of the Requirements Analysis process. One senior
developer should be allocated the role of lead tester and provided with training, if needed. This will assist the development team in testing components and interfaces, and following up on
testing activities.
Problems with the Tool Set: Development tasks such as component development, testing and version control, are most easily accomplished by using suitable tools. The choice of suitable
tools is important and while the direction of Oracle tools development is very positive, the Oracle tool set may not yet provide the complete suite of tools required for developing solutions in the
client environment.
Development Environment is Unfamiliar to the Developers: Make sure that the tools are made available and that any necessary training or guidance is provided. Where new skills are being
acquired or new tools are being introduced, specialist support should be available on demand.
Users Get Burned Out: If the users involved in the project are still doing their normal business activity, there is a risk that they will get burned out. Convince the sponsor, as well as the end
users, that this will only be destructive to the project, their normal activities and user well-being. Therefore, other employees, not involved in the project, should take over normal business
activities.
Developers Get Burned Out: These kind of projects require intensive work periods and high concentration. Project managers should discourage long working hours over an extended period of
time. If one or more team members are working late every night, it is advisable to try to discover the reason. Perhaps the workload has not been distributed evenly, or perhaps some developers
have set themselves an unnecessarily ambitious level for the solution. Try to avoid extended periods of working at high intensity.
Low Acceptance by the Rest of the User Organization -- The Project is Evolving on its Own: During this phase, there is a chance that the project is moving out of sight for the users not
involved in the project. Keep the rest of the organization constantly informed. If there is a large end-user base, create an information plan on how the end users best can be informed. This is
advisable both for internal and external end users. Also, motivate the involved users to talk about the project and to consult their colleagues on certain decisions.
Do Not Lose Focus of the Objectives: Implementing the use cases in the Construction phase is done with short timescales that may set a high pressure on both users and developers. Also,
while developers and users communicate about how to implement a use case, they may get highly motivated to go on and on, and thereby drop too far into details that are not relevant. Prevent
losing time on irrelevant details by constantly focusing on the objectives and priorities.
Back to Top
Development Resource Skills: In addition to the skill considerations described in the Elaboration phase, there must be developers on the team with a high level of knowledge in developing
using the OUM architecture and the development tools and frameworks chosen for the project.
Development Partition Planning: The system probably has been partitioned before this phase begins. It is important to consider any remaining dependencies between the partitions and plan
the iterations of the partitions to minimize the impact of dependencies. If there is a high coupling between the partitions, and the iteration is not carefully planned, then you might get a situation
in which certain activities of one partition are delayed.
Iterations and MoSCoW: The length and the number of required iterations for each partition depend upon a number of factors, such as complexity. Normally, each partition is developed
through a number of iterations and the MoSCoW List is used to determine priorities by the team developing that partition. If you plan the iterations of the partitions incorrectly, you might find that
one team has developed all of their Must have, Should have and even some Could have components within one partition, while another team experiences difficulty in completing all of its Must
haves. There must be a good balance between the Must have functionality and the other functionality within each team/partition.
Quality: While developing using timeboxes and prioritization, development activity can get quite hectic at times. This might result in the temptation to perform certain activities in a "quick and
dirty" way. If the team members allow themselves to cut corners, you will likely end up with an application that is difficult to maintain, and you will have to add additional effort to make
corrections. It is important that the team be made aware of the risk of developing in a quick and dirty way. It is recommended that the quality manager initiate frequent quality checks on the
repository content as well as on the delivered software during the iterations.
Configuration Management (CM): As with any system development, proactive configuration management is needed to prevent the "corner-cutting" that can cause chaos. It is important to
establish and implement adequate and realistic procedures for document management, version control, software release and status accounting. As far as possible these functions should be
automated and as little paperwork as possible should be required. The configuration management specialist should be empowered to make sure that these procedures are followed. This role
can be combined with that of DBA, or in small projects with the role of lead system developer. Time should be allocated for education of team members in configuration management. At the
start of this phase, appropriate tools should be implemented and procedures should be written to support version control to keep track of the status of each module.
Change Control: In OUM type of projects, change control is a dynamic activity, because the empowerment of ambassador users allow shorter decision cycles, as long as the changes remain
within scope. Change requests will be raised continuously during the validation periods. This ultimately grows into a very large amount of requests. It is important that decisions are made
quickly and that the requests are prioritized properly. It is vital to use an easy-to-use, well-constructed and easily understood change control mechanism. At the start of this phase, appropriate
tools should be implemented to support the change control procedures. It is also important that the project manager identifies and handles separately any change requests that could result in a
scope change.
Back to Top
C.ACT.FR - FINALIZE REQUIREMENTS
This activity consists of updating and finalizing the requirements.
Back to Top
OBJECTIVES
The objective for this activity is to confirm and document the fixed requirements for the solution in this increment.
Back to Top
TASKS
ID Task Name
RD.130.2 Develop Baseline Architecture Description
RA.023.3 Develop Use Case Model
RA.024.2 Develop Use Case Details
RA.180.2 Review Use Case Model
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to document any new requirements that come up as the system is going through the Construction phase. Some requirements may be
documented or postponed for the next increment of system development.
Back to Top
PREREQUISITES
Back to Top
C.ACT.AC - ANALYZE - CONSTRUCTION
This activity allows for analyzing the captured requirements by refining and structuring them in the Analysis Model .
Back to Top
OBJECTIVES
The objective for this activity is to analyze the use cases and requirements.
Back to Top
TASKS
ID Task Name
AN.035.2 Update Existing Analysis Specification
AN.040.2 Develop Analysis Architecture Description
AN.050.2 Analyze Data
AN.060.2 Analyze Behavior
AN.070.2 Analyze Business Rules
AN.080.2 Analyze Services
AN.085.2 Define Service
RA.026.2 Populate Services Repository
AN.090.2 Analyze User Interface
AN.100.2 Prepare Analysis Specification
AN.110.2 Review Analysis Model
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to perform analysis of the use cases and prepare and review the Analysis Model.
PREREQUISITES
C.ACT.FR Finalize Requirements
Back to Top
C.ACT.DC - DESIGN - CONSTRUCTION
This activity allows for designing the system to meet all functional and supplemental requirements.
Back to Top
OBJECTIVES
The objective for this activity is to realize the use cases into designed software components and database specifications.
Back to Top
TASKS
ID Task Name
DS.035.2 Update Existing Design Specification
DS.040.2 Develop Design Architecture Description
DS.080.2 Design Software Components
DS.090.2 Design Data
DS.100.2 Design Behavior
DS.110.2 Design Business Rules
DS.120.2 Design Services
DS.130.2 Design User Interface
DS.140.2 Prepare Design Specification
DS.150.2 Develop Database Design
DS.160.2 Review Design Model
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to realize the use cases into a software Design Model.
Back to Top
PREREQUISITES
C.ACT.AC Analyze - Construction
Back to Top
C.ACT.PTP - PERFORM TEST PLANNING
This activity allows for updating and refining the Integration and System Test Plans.
Back to Top
OBJECTIVES
The objective for this activity is to finish development of the Integration and System Test plans for the solution under development.
Back to Top
TASKS
ID Task Name
TE.015.2 Develop Integration Test Plan
TE.050.2 Develop System Test Plan
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to provide detail to the Integration Test Plan and System Test Plan that were initially prepared in the Elaboration phase during the Define
Project Strategy activity.
Back to Top
PREREQUISITES
Back to Top
C.ACT.PEC - PREPARE ENVIRONMENTS - CONSTRUCTION
This activity consists of preparing all the the Development and Integration Test Environments.
Back to Top
OBJECTIVES
The objective for this activity is to prepare the Static Test Data, and environments for the development and systems integration testing.
Back to Top
TASKS
ID Task Name
IM.007.2 Prepare Development Environment
TE.018.2 Prepare Static Test Data
TE.038.2 Prepare Integration Test Environment
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Development and Integration Test Environments required during the Construction phase. It also includes the preparation of
Static Test Data for all tests.
Back to Top
PREREQUISITES
Back to Top
B.ACT.DCCTSE - DEVELOP CUSTOM COMPONENT TEST
SCRIPTS - ELABORATION
C.ACT.DCCTSC - DEVELOP CUSTOM COMPONENT TEST
SCRIPTS - CONSTRUCTION
This activity consists of developing the scripts and scenarios for the unit and integration tests.
Back to Top
OBJECTIVES
The objective for this activity is to develop the Unit Test Scripts and the Integration Test Scenarios.
Back to Top
TASKS
The tasks included in the Develop Custom Component Test Scripts - Elaboration activity are:
ID Task Name
The tasks included in the Develop Custom Component Test Scripts - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Unit Test Scripts and the Integration Test Scenarios.
Back to Top
PREREQUISITES
#TOP #TOP
B.ACT.DCCTSE - Develop Custom Component Test Scripts - Elaboration
C.ACT.DCCTSC - Develop Custom Component Test Scripts - Construction
Back to Top
B.ACT.DSTSE - DEVELOP SYSTEM TEST SCENARIOS -
ELABORATION
C.ACT.DSTSC - DEVELOP SYSTEM TEST SCENARIOS -
CONSTRUCTION
This activity consists of developing the System Test Scenarios.
Back to Top
OBJECTIVES
The objective for this activity is to develop the System Test Scenarios.
Back to Top
TASKS
The tasks included in the Develop System Test Scenarios - Elaboration activity are:
ID Task Name
The tasks included in the Develop System Test Scenarios - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the System Test Scenarios.
Back to Top
PREREQUISITES
B.ACT.DSTSE - Develop System Test Scenarios - Elaboration
C.ACT.DSTSC - Develop System Test Scenarios - Construction
B.ACT.LCAR Lifecycle Architecture Milestone (if no custom development)
#TOP #TOP
Back to Top
C.ACT.DSITS - DEVELOP SYSTEMS INTEGRATION TEST
SCENARIOS
This activity consists of developing the Systems Integration Test Scenarios.
Back to Top
OBJECTIVES
The objective for this activity is to develop the Systems Integration Test Scenarios.
Back to Top
TASKS
ID Task Name
TE.090 Develop Systems Integration Test Scenarios
Back to Top
ITERATIONS
feedback.
This activity is instantiated at least once for each external system to be interfaced.
Back to Top
APPROACH
The approach to this activity is to develop the Systems Integration Test Scenarios.
Back to Top
PREREQUISITES
B.ACT.DC Design - Construction
Back to Top
C.ACT.IS - IMPLEMENT CUSTOM COMPONENTS
This activity allows for implementing the database, components, and services.
Back to Top
OBJECTIVES
The objective for this activity is to perform the installation test and implement the components of the system that have been developed in this increment of solution
development.
Back to Top
TASKS
ID Task Name
IM.040.2 Implement Database
IM.050 Implement Components
IM.053.2 Register Services
IM.055.2 Perform Business Rules Implementation (Rules Engine)
IM.060.2 Perform Component Review
IM.070 Assemble Components
IM.080 Integrate Services
IM.090 Create Installation Routines
TE.065 Perform Installation Test
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to perform the installation test and implement the components of the system as they become available during the Construction phase.
Back to Top
PREREQUISITES
Back to Top
B.ACT.PCCTE - PERFORM CUSTOM COMPONENT TESTING -
ELABORATION
C.ACT.PCCTC - PERFORM CUSTOM COMPONENT TESTING -
CONSTRUCTION
This activity consists of performing unit and integration tests as needed.
Back to Top
OBJECTIVES
The objective for this activity is to perform unit and integration tests as necessary.
Back to Top
TASKS
The tasks included in the Perform Custom Component Testing - Elaboration activity are:
ID Task Name
The tasks included in the Perform Custom Component Testing - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to performed unit and integration tests when and as needed.
Back to Top
PREREQUISITES
#TOP #TOP
C.ACT.DCCTSC Develop Custom Component Test Scripts - Construction
C.ACT.ICC Install Custom Components
Back to Top
C.ACT.PST - PREPARE FOR SYSTEM TEST
This activity consists of preparing for the system test by double checking the Application Setups and preparing the System Test Environment.
OBJECTIVES
The objective for this activity is to prepare for the system test.
Back to Top
TASKS
ID Task Name
MC.050.2 Define Application Setups
TE.060.2 Prepare System Test Environment
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to double check the Application Setups and prepare the System Test Environment.
Back to Top
PREREQUISITES
C.ACT.ICC Implement Custom Components
Back to Top
C.ACT.PSTC - PERFORM SYSTEM TEST - CONSTRUCTION
This activity consists of developing the System Test Scenarios, configuring the environment, performing the system test, and finalizing the Business Procedure
Documentation.
Back to Top
OBJECTIVES
The objective for this activity is to perform the system test and finalize the Business Procedure Documentation.
Back to Top
TASKS
ID Task Name
TE.070.2 Perform System Test
RA.055.2 Document Business Procedures
TE.019.1 Collect, Assess and Refine KPI Measurements
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to run through the preliminary test of the full system, which includes all components of the system available at the time of the test.
Ultimately, run through a final system test, which includes the entire system. In OUM the goal of system testing is to verify that the system works as a whole, in a way that
is consistent with what the users expect, and to detect inconsistencies and omissions between the partitions (including any from previous increments).
Back to Top
PREREQUISITES
C.ACT.CSTE Configure System Test Environment
Back to Top
C.ACT.PSIT - PERFORM SYSTEMS INTEGRATION TEST
This activity consists of preparing the Systems Integration Test Environment and performing the systems integration test.
Back to Top
OBJECTIVES
The objective for this activity is to perform the systems integration test.
Back to Top
TASKS
ID Task Name
TE.085 Prepare Systems Integration Test Environment
TE.100 Perform Systems Integration Test
Back to Top
ITERATIONS
feedback.
This activity is instantiated at least once for each external system to be interfaced.
Back to Top
APPROACH
The approach to this activity is to prepare the Systems Integration Test Environment and perform the systems integration test.
Back to Top
PREREQUISITES
B.ACT.PSTC Perform System Test - Construction
Back to Top
C.ACT.PPT - PREPARE FOR PERFORMANCE TESTING
This activity consists of building the test scripts and programs, constructing the environment and database and conducting a dress rehearsal.
Back to Top
OBJECTIVES
The objective for this activity is to prepare scripts and environments for performance test.
Back to Top
TASKS
ID Task Name
PT.070 Build Performance Test Scripts and Programs
PT.080 Construct Performance Test Environment and Database
PT.090 Conduct Performance Test Dress Rehearsal
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to check out everything needed to do the performance test, including test scripts and the environment. This includes preparation and a "dry
run" through the test procedure, prior to actually measuring the performance of the system.
Back to Top
PREREQUISITES
Back to Top
C.ACT.PT - PREPARE FOR TRANSITION
This activity consists of defining the System Management Procedures, Operational Test Plan, and the Final Platform and Network Architecture and the Capacity Plan.
Back to Top
OBJECTIVES
The objective for this activity is to prepare to turn over the developed technical architecture solution over to the production support environment.
Back to Top
TASKS
ID Task Name
TA.100 Define System Management Procedures
TA.110 Define Operational Testing Plan
TA.150 Define Final Platform and Network Architecture
TA.160 Define System Capacity Plan
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to define procedures for system management, operational support, and final platform and network architecture of the new solution as well
as planning for the system capacity.
Back to Top
PREREQUISITES
Back to Top
C.ACT.PCO - PREPARE FOR CUTOVER
This activity consists of defining the Cutover Strategy, developing the Installation Plan, and designing the Production Support Infrastructure.
Back to Top
OBJECTIVES
The objective for this activity is to define the strategy and plan for migrating the developed solution to production status.
Back to Top
TASKS
ID Task Name
TS.020.2 Define Cutover Strategy
TS.030 Develop Installation Plan
TS.040 Design Production Support Infrastructure
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to define procedures for cutover from test to production. The Installation Plan describes in detail the sequence of steps to perform a
successful first-time installation of the application system. It details what is required for a timely installation of the software, as well as what is to be installed and where.
This activity also includes designing the Production Support Infrastructure.
Back to Top
PREREQUISITES
Back to Top
C.ACT.TI - TEST INFRASTRUCTURE
This activity consists of conducting operational, backup and recovery and disaster recovery testing.
Back to Top
OBJECTIVES
The objective for this activity is to test the support of the new system in the production environment. This includes operational testing as well as Backup and recovery
test. A test of the Disaster Recovery procedure is also done.
Back to Top
TASKS
ID Task Name
TA.120 Conduct Operational Testing
TA.130 Conduct Backup and Recovery Test
TA.140 Conduct Disaster Recovery Test
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to test all support of the solution in a simulated production environment. This includes operational testing as well as Backup and recovery
test. A test of the Disaster Recovery procedure is also done.
Back to Top
PREREQUISITES
C.ACT.PT Prepare for Transition
Back to Top
C.ACT.PACDC - PREPARE TO ACQUIRE AND CONVERT DATA -
CONSTRUCTION
This activity consists of performing a detailed mapping of legacy data to be converted, manual conversion procedures, and conversion component designs, and test plans,
for Data Acquisition and Conversion.
Back to Top
OBJECTIVES
The objective for this activity is to develop detailed requirements, designs, test plans and other preparations for implementing and testing the conversion components.
Back to Top
TASKS
ID Task Name
CV.027.2 Perform Data Mapping
RA.170.2 Conduct Data Quality Assessment
CV.035.2 Define Manual Conversion Procedures (Initial Load)
CV.040.2 Design Conversion Components (Initial Load)
CV.050.2 Prepare Conversion Test Plans (Initial Load)
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to define and prepare the necessary Data Acquisition and Conversion components required to move to the solution being developed. This
includes standards, conversion procedures, component designs, and test plans.
Back to Top
PREREQUISITES
A.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
C.ACT.ACDC - ACQUIRE AND CONVERT DATA -
CONSTRUCTION
This activity consists of implementing and testing the conversion components and converting, verifying and cleaning the data.
Back to Top
OBJECTIVES
The objective of this activity is to implement the conversion components, test the conversion components, and run a trial conversion using the newly created conversion
components.
Back to Top
TASKS
ID Task Name
CV.030.2 Prepare Conversion Environment (Initial Load)
CV.055.2 Implement Conversion Components (Initial Load)
CV.060.2 Perform Conversion Component Unit Test (Initial Load)
CV.062.2 Perform Conversion Component Business Object Test (Initial Load)
CV.063.2 Perform Conversion Component Validation Test (Initial Load)
CV.064.1 Install Conversion Components (Initial Load)
CV.065.1 Convert and Verify Data (Initial Load)
CV.068.1 Clean Data
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to run through the conversion process prior to the move to production. Data is converted using the newly developed conversion
components, tested and verified. This is followed by data cleansing as needed.
Back to Top
PREREQUISITES
C.ACT.PACDC Prepare to Acqure and Convert Data - Construction
Back to Top
#TOP #TOP
B.ACT.VUPE - VALIDATE UPGRADE PROCESS -
ELABORATION
C.ACT.VUPC - VALIDATE UPGRADE PROCESS -
CONSTRUCTION
These activities serve to validate the complete upgrade process.
Back to Top
OBJECTIVES
The objective for these activities is to perform an incremental rehearsal of the upgrade process.
Back to Top
TASKS
The tasks included in Validate Upgrade Process - Elaboration activity are:
ID Task Name
The tasks included in Validate Upgrade Process - Construction activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to these activities involves formally testing all of the individual steps involved within the upgrade process according to the upgrade plan. The pre-upgrade
steps are performed, followed by the actual software upgrade, followed by post-upgrade steps. At each step, actual results are compared to predicted or expected results
followed by a reconciliation and subsequent updates into the next upgrade iteration.
The number of times the upgrade process is rehearsed prior to the final cutover depends on the number of iterations defined within the Project Management Plan. In any
event, each increment of the upgrade process can be expected to be progressively more comprehensive.
#TOP #TOP
Back to Top
PREREQUISITES
Back to Top
C.ACT.PD - PRODUCE DOCUMENTATION
This activity consists of publishing the appropriate documentation and producing the Online Help. During the Transition phase, you will have an opportunity to review all
implemented system changes and system defects for any impact on the Documentation work products and finalize these work products.
Back to Top
OBJECTIVES
The objective for this activity is to produce documentation that may be needed to document the functionality and support of the system.
Back to Top
TASKS
ID Task Name
DO.060 Publish User Reference Manual
DO.070 Publish User Guide
DO.080 Publish Technical Reference Material
DO.100 Produce Online Help
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare documentation for the users and technical support of the system.
Back to Top
PREREQUISITES
Back to Top
communications.
Back to Top
OBJECTIVES
Back to Top
TASKS
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
#TOP #TOP
Back to Top
PREREQUISITES
- Elaboration
- Construction
- Transition
- Production
Back to Top
C.ACT.CJIA - CONDUCT JOB IMPACT ANALYSIS
This activity focuses on identifying the impact of the project on the organization structure, end user roles, responsibilities, knowledge and work requirements and
developing a plan to transition people.
Back to Top
OBJECTIVES
The objective for this activity is to identify the impact of the project on jobs, analyze the impact and define a plan to transition people.
Back to Top
TASKS
ID Task Name
OCM.170 Collect and Analyze Job Change Data
OCM.180 Determine the Impact of Job Changes
OCM.190 Prepare HR Transition Plan
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to collect and analyze job change data, determine the impact of job changes and define the actions and processes needed to transition
people and teams regarding new job assignments.
Back to Top
PREREQUISITES
Back to Top
C.ACT.CMAWC - CONDUCT MANAGERS' ALIGNMENT
WORKSHOP - CONSTRUCTION
This activity focuses on preparing and conducting the Managers' Unit/Department Impact Workshop.
Back to Top
OBJECTIVES
The objective for this activity is to enable managers to transition their people to the new processes, tasks and procedures.
Back to Top
TASKS
ID Task Name
OCM.200 Design Managers' Unit/Department Impact Workshop
OCM.210 Conduct Managers' Unit/Department Impact Workshop
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the materials for and conduct the Managers' Unit/Department Impact Workshop.
Back to Top
PREREQUISITES
C.ACT.CJIA Conduct Job Impact Analysis
Back to Top
C.ACT.DEUT - DESIGN END-USER TRAINING
This activity focuses on designing end-user training.
Back to Top
OBJECTIVES
The objective for this activity is to determine the user learning needs and develop a plan for meeting those training needs.
Back to Top
TASKS
ID Task Name
TR.060 Conduct User Learning Needs Analysis
TR.070 Develop User Learning Plan
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to conduct an analysis of the user learning needs and develop the User Learning Plan for meeting those needs.
Back to Top
PREREQUISITES
Back to Top
C.ACT.BEUT - BUILD END-USER TRAINING
This activity focuses on building the necessary components for end-user training, that is, the actual learning materials and the environment.
Back to Top
OBJECTIVES
The objective for this activity is to develop the actual learningware and environment.
Back to Top
TASKS
ID Task Name
TR.080 Develop User Learningware
TR.090 Develop User Learning Environment
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the User Learningware and the Configured User Learning Environment.
Back to Top
PREREQUISITES
C.ACT.DUET Design End-User Training
Back to Top
C.ACT.TEUC - TRAIN END USERS - CONSTRUCTION
D.ACT.TEUD - TRAIN END USERS - TRANSITION
These activities focus on preparing the users for the new system.
Back to Top
OBJECTIVES
The objective for these activities is to train the end users in the functionality of the new system.
Back to Top
TASKS
The tasks included in the Train End Users - Construction activity are:
ID Task Name
TR.100.1 Conduct User Learning Events
The tasks included in the Train End Users - Transition activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to these activities is to conduct the training events as planned.
Back to Top
PREREQUISITES
C.ACT.TEUC Train End Users - Construction
C.ACT.BEUT Build End-User Training
D.ACT.TEUT Train End Users - Transition
Back to Top
C.ACT.IOCM - INITIAL OPERATIONAL CAPABILITY MILESTONE
SUMMARY
decisions should be made and goals evaluated. Each phase has a main milestone. The Initial Operational Capability Milestone is the third key project milestone produced
at the end of the Construction phase. At this point, a decision is made on whether the application, infrastructure and users are ready to move to operation. The Initial
Operation Capability Milestone is also considered a "beta" release.
Back to Top
OBJECTIVES
The objectives for the Initial Operational Capability Milestone are:
Prepare system for acceptance test and deployment.
Develop supporting documentation.
Prepare users for Transition.
Back to Top
ACTIVITIES
C.ACT.PTP Perform Test Planning
C.ACT.PEC Prepare Environments - Construction
C.ACT.DCCTSC Develop Custom Components Test Scripts - Construction
C.ACT.DSTSC Develop System Test Scenarios - Construction
C.ACT.DSITS Develop Systems Integration Test Scenarios
C.ACT.CSTE Configure System Test Environment
C.ACT.PSTC Perform System Test - Construction
C.ACT.PSIT Perform Systems Integration Test
C.ACT.PPT Prepare for Performance Testing
C.ACT.PCO Prepare for Cutover
C.ACT.TI Test Infrastructure
C.ACT.PACDC Prepare to Acquire and Convert Data - Construction
C.ACT.VUPC Validate Upgrae Process - Construction
C.ACT.PD Produce Documentation
C.ACT.DCMRCCC Deploy Change Management Roadmap / Communication Campaign - Construction
C.ACT.CMAWC Conduct Managers' Alignment Workshop - Construction
C.ACT.DEUT Design End-User Training
Back to Top
ACTIVITY CHECKLISTS
Construction Phase / Initial Operational Capability (IOC) Milestone Checklist MS Word
Back to Top
[D] TRANSITION
The goal of the Transition phase is to take the completed solution from installation onto the production system through the Acceptance Test to launch of the live
application, open and ready for business. Validate that the system is tested systematically and is available for end users. During this phase, the new system is accepted
by the client organization, the organization is made ready for the new system, and the system is put into production and, if the new system replaces an old one, a smooth
cutover to the new application is provided. The system has been found acceptable to operate in the user environment, but it may not be perfect. Minor enhancements
may be developed and released after production starts. Also, planning is performed for the development of any remaining functionality, in a new increment.
The Transition phase can span several iterations, and includes testing the new system in preparation for release, and making minor adjustments based on user feedback.
At this point in the lifecycle, user feedback should focus mainly on fine-tuning the product, configuration, installation, and usability issues. All the major structural issues
should have been resolved earlier in the project lifecycle.
The Transition phase finishes with the System in Production Milestone. Review and be familiar with the objectives of this milestone before you begin this phase and make
sure you have met these objectives before you move to the Production phase.
Back to Top
OBJECTIVES
Prepare users for Production. Educate ambassador users in order to deliver the application properly to the rest of the organization for internal acceptance.
Implement Production support infrastructure. Establish the maintenance environment required for supporting and managing the site. Make adequate
arrangements for application support and properly-trained staff members.
Deploy system into Production. Ensure an application system which meets the performance requirements.
Obtain acceptance. Gain acceptance of the project from the project sponsor.
The Transition Phase / System in Production (SP) Milestone Checklist is available to assist with determination of completeness for this phase.
Back to Top
PROCESSES
Testing (TE)
Documentation (DO)
Training (TR)
Transition (TS)
Back to Top
KEY WORK PRODUCTS
Back to Top
TIPS AND TECHNIQUES
This section discusses the primary techniques that may be helpful in conducting the Transition phase. It also includes advice and commentary on each process.
Testing
During this phase, the development team supports the Acceptance Test as executed by the users. Typically, the version that goes into the Acceptance Test is called a
beta version of the system. It is often that different users are involved in this testing compared to those that were involved during the project. However, it is important that
the users that perform the Acceptance Test have been kept in the loop throughout the project, so that they are familiar with the system and know the decisions and
choices that were made. This prevents the users from questioning the actual solution that has been agreed upon during earlier reviews during the project. The
Acceptance Test Criteria should have been agreed upon at the start of the project, and will be part of the contract. You should motivate the client to create test cases and
scenarios to use in the Acceptance Test, including the expected outcomes. Preferably this should start in the earlier phases. Hopefully, this process will help uncover any
discrepancies in understanding between the developer and client organizations. It also helps picture what kind of expectations the users have for the various parts of the
system, and provides some unexpected clarifications. Therefore, the earlier they start making these scenarios, the better, as the earlier discrepancies are discovered, the
easier they can be corrected. Preferably, the Acceptance Test should be performed with actual converted data.
During the Transition phase, you perform the actual Performance Test. The Performance Test is an iterative task, and may become quite labor-intensive and time-
consuming when there are strict performance requirements. You need to tune the application, and may even need to rewrite code to fulfill the requirements. Therefore, it
is important to have a focus on performance during the development of the components (also, see the Construction phase). If there are complex scenarios, you should
consider using tools that are especially made for Performance Testing.
Acceptance and validation of converted data is every bit as important as validating software. Usually data that is converted at the start of a new system is done by
specialized software that ceases to be part of the ongoing system. Because this software mostly has no ongoing value, it often is not subject to the same quality
standards as other system software components. The earlier you discuss and resolve data conversion issues, the earlier you can introduce converted data into the
Testing process.
Review the Data Acquisition, Conversion and Data Quality Strategy (CV.020) created in the Elaboration phase. Agree to convert only data that will have an ongoing value
to the business. Data fields in legacy systems often change meaning over time (without markers to indicate a change in use). This makes it difficult to automatically
convert data without manual intervention, or data cleansing. It is difficult to estimate the extent of data cleansing needed until the Elaboration phase is complete, and
sometimes not even until one iteration has been completed in the Construction phase (also, see the Construction phase).
In this phase, continue to convert the data. Test the correctness of converted data first, before making it available for use. Providing converted data with errors can cause
problems that outweigh the benefits of providing early test data. If you have to convert data from legacy systems that include data where the data structure is very
different from the data structure in new system, or that the old legacy data is difficult to understand, you probably will need to convert using an iterative process, where
users with a good knowledge the old system are involved in verifying the data and testing the conversion programs.
Documentation
During the Transition phase, minor revisions or changes to the software system may cause updates to any or all of the documentation work products.
Ongoing throughout the project, change and communication events targeted to specific audiences with the goal of mitigating identified risks and challenges are
conducted. In addition, during Transition an IT Alignment is conducted and the HR Transition Plan prepared during Construction is implemented.
Training
During Transition, you continue conducting user learning events.
Transition
A good maintenance and production environment planning task eases the system rollout. This task is technical in nature and typically involves the transfer of the
operation of the new system from the project to the client operations and maintenance staff. As the system is developed through a number of iterations, the project team
already has experience in making components ready and installing them in some environment.
To take the new system into production is the single biggest decision that is made on a project. It can either be made with confidence or a "hope for the best" attitude.
See the Construction phase for discussions on various approaches for going into production. A main goal of OUM is to provide a proven process for making this decision
easily and confidently.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. You can also go directly to the Transition phase Scrum guidance within
this technique.
Back to Top
Testing
TE.105 Prepare Users for Testing Prepared Users for Testing
TE.110 Prepare Acceptance Test Environment Acceptance Test Environment
TE.120 Support Acceptance Test Acceptance Test Results
PT.100 Execute Performance Test Performance Test Results
PT.110 Create Performance Test Report Performance Test Report
CV.065.2 Convert and Verify Data (Initial Load) Converted and Verified Data (Initial Load)
Documentation
DO.110 Finalize Documentation Final Documentation Work Products
OCM.155.3
Effectiveness
Assessment
Training
Transition
TS.050 Prepare Production Environment Production Environment
TS.052 Implement Production Support Infrastructure Production Support Infrastructure
TS.054 Perform Pre-Upgrade Steps Pre-Upgrade Checklist
TS.055 Upgrade Production Environment Upgraded Production Environment
TS.056 Perform Post-Upgrade Steps Post-Upgrade Checklist
TS.057 Revise Application Setups Configured Applications
TS.058 Verify Production Readiness Production-Ready System
TS.060 Go Production System In Production
TS.070 Shut Down Legacy System Legacy System Shut Down
Back to Top
Back to Top
MANAGING RISK
The most likely areas of risk in the Transition phase are the following:
Disagreement on Problem Severity: During the Acceptance Test, it is possible that the ambassador users will uncover problems not identified during system
testing. Classification of the severity of these problems could impact the acceptance of the system. Is it essential that clear problem classifications and their impact
on production are included as part of the contract and that these classifications be used to decide when the system is ready for production.
Unavailable or Poor Quality Production Data: Often, the task of developing or providing production data is the responsibility of the client or a third party engaged
by the client. Sample data, consistent with the production data, must be provided early in the Construction Phase and is required during system and validation
testing. It is imperative that the client or their designee understand their obligations to provide timely and appropriately cleansed production data on the schedule
agreed to in the contract.
Back to Top
Delivery and Installation of Production Hardware: The delivery and installation of the production hardware must be successful and on time.
Technical Infrastructure: The technical infrastructure, including all of the technical architecture, must be on target to support the actual data volumes and number
of users. The success of internet-deployed businesses is critically dependent upon a reliable, high performance infrastructure.
User Commitment and Ownership: The ambassador users commitment and sense of ownership is vital in this phase. If the ambassador users and advisor users
are highly committed and have a strong sense of ownership, they will more easily accept the application.
Back to Top
D.ACT.SUAT - SUPPORT USER ACCEPTANCE TEST
This activity consists of preparing users for testing, preparing the Acceptance Test Environment and supporting the users in conducting the acceptance test.
Back to Top
OBJECTIVES
The objective for this activity is to prepare and support the users and the system for the transition to production, to verify that the system functions as specified by the
business requirements.
Back to Top
TASKS
ID Task Name
TE.105 Prepare Users for Testing
TE.110 Prepare Acceptance Test Environment
TE.120 Support Acceptance Test
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is prepare the users to test and accept the system, set up the Acceptance Test Environment and support the users in performing the
acceptance test. This test simulates the true operation of the system once it is moved to the Production Environment. The acceptance test may include any aspect of the
system from business scenarios to individual screens to recovery and fallback procedures. A summary of the test results is prepared.
Back to Top
PREREQUISITES
Back to Top
D.ACT.CPTST - CONDUCT PERFORMANCE TEST
This activity consists of executing the performance test and creating the Performance Test Results.
Back to Top
OBJECTIVES
The objective for this activity is to run the actual performance test of the solution, and document the results.
Back to Top
TASKS
ID Task Name
PT.100 Execute Performance Test
PT.110 Create Performance Test Report
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to conduct the performance test and prepare the test results in a report format. Results of this activity will influence the completion Go
Production Activity.
Back to Top
PREREQUISITES
Back to Top
D.ACT.PPE - PREPARE PRODUCTION ENVIRONMENT
This activity consists of preparing the Production Environment.
Back to Top
OBJECTIVES
The objective for this activity is to prepare the Production Environment.
Back to Top
TASKS
ID Task Name
TS.050 Prepare Production Environment
TS.054 Perform Pre-Upgrade Steps
TS.055 Upgrade Production Environment
TS.056 Perform Post-Upgrade Steps
TS.057 Revise Application Setups
Back to Top
ITERATIONS
This activity is not iterated.
Back to Top
APPROACH
The approach to this activity is to prepare and configure the Production Environment.
Back to Top
PREREQUISITES
Back to Top
D.ACT.CDT - CONVERT DATA - TRANSITION
This activity consists of converting, verifying and cleaning the data.
Back to Top
OBJECTIVES
The objective for this activity is to convert and cleanse data in preparation for the transition of the solution into the Production Environment.
Back to Top
TASKS
ID Task Name
CV.064.2 Install Conversion Components (Initial Load)
CV.065.2 Convert and Verify Data (Initial Load)
CV.068.2 Clean Data
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to run conversion process against data coming from legacy system(s), and provide any cleansing that is required to allow the solution to
use the data in the production environment after cut-over.
Back to Top
PREREQUISITES
D.ACT.PPE Prepare Production Environment
Back to Top
communications.
Back to Top
OBJECTIVES
Back to Top
TASKS
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
#TOP #TOP
Back to Top
PREREQUISITES
- Elaboration
- Construction
- Transition
- Production
Back to Top
D.ACT.CITA - CONDUCT IT ALIGNMENT
This activity focuses on assessing the impact of the project on IT groups and developing a plan to transition the IT groups.
Back to Top
OBJECTIVES
The objective for this activity is to assess the impact of the project on IT groups and propose changes to the organizational structures and role definitions and transition
the organizational with minimal negative impact.
Back to Top
TASKS
ID Task Name
OCM.220 Prepare Assessment of Impact on IT Groups
OCM.230 Prepare IT Transition Plan
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to review the current and future proposed IT structure and assess the impact of the technology changes and compare the findings with
leading practices and benchmarking data. Then you develop a plan to transition the organizational with minimal negative impact.
Back to Top
PREREQUISITES
Back to Top
C.ACT.TEUC - TRAIN END USERS - CONSTRUCTION
D.ACT.TEUD - TRAIN END USERS - TRANSITION
These activities focus on preparing the users for the new system.
Back to Top
OBJECTIVES
The objective for these activities is to train the end users in the functionality of the new system.
Back to Top
TASKS
The tasks included in the Train End Users - Construction activity are:
ID Task Name
The tasks included in the Train End Users - Transition activity are:
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to these activities is to conduct the training events as planned.
Back to Top
PREREQUISITES
Back to Top
#TOP #TOP
D.ACT.FD - FINALIZE DOCUMENTATION
This activity provides a last opportunity to make any revisions to appropriate documentation and Online Help.
Back to Top
OBJECTIVES
The objective for this activity is to prepare the final documentation for the solution.
Back to Top
TASKS
ID Task Name
DO.110 Finalize Documentation
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to make any final changes to the documentation of the solution. During the Transition phase, minor revisions or changes to the software
system may cause updates to any or all of the documentation work products. This task covers the incorporation of any of those changes into the Documentation work
products.
Back to Top
PREREQUISITES
D.ACT.IOCM Initial Operational Capability Milestone
Back to Top
D.ACT.GP - GO PRODUCTION
This activity consists of preparing the Production Environment, going production, and shutting down the legacy system.
Back to Top
OBJECTIVES
The objective for this activity is to move the solution into the Production Environment and close down the Legacy Systems being replaced by the Solution.
Back to Top
TASKS
ID Task Name
TS.052 Implement Production Support Infrastructure
TS.058 Verify Production Readiness
TS.060 Go Production
TS.070 Shut Down Legacy System
Back to Top
ITERATIONS
This activity is not iterated.
Back to Top
APPROACH
The approach to this activity is to prepare the Production Environment, prepare contingencies, go production and shut down legacy systems. In some situations, the
legacy systems may continue to operate in parallel for some period of time.
Back to Top
PREREQUISITES
D.ACT.SUAT Support User Acceptance Test
D.ACT.CPTST Conduct Performance Test
D.ACT.CDT Convert Data - Transition
Back to Top
D.ACT.SIP - SYSTEM IN PRODUCTION MILESTONE SUMMARY
decisions should be made and goals evaluated. Each phase has a main milestone. The System in Production Milestone is produced at the end of the Transition phase.
At this point, the stakeholders decide if the goals and objectives set for the project have been met and if a new increment should begin.
Back to Top
OBJECTIVES
Prepare users for Production.
Implement Production support infrastructure.
Deploy system into Production.
Obtain acceptance.
Back to Top
ACTIVITIES
D .ACT.CDT Convert Data - Transition
D.ACT.DCMRCCT Deploy Change Management Roadmap / Communication Campaign - Transition
D.ACT.CITA Conduct IT Alignment
D.ACT.FD Finalize Documentation
D.ACT.GP Go Production
Back to Top
ACTIVITY CHECKLISTS
Transition Phase / System in Production (SP) Milestone Checklist MS Word
Back to Top
[E] PRODUCTION
The goal of the Production phase is to operate the newly developed system and monitor and address system issues. This includes monitoring the system and acting
appropriately to maintian continued operation, measuring system performance, operating and maintaining supporting systems, and responding to help requests, error
reports and feature requests by users. It is also important to manage the applicable change control process so that defects and new features may be prioritized and
assigned to future releases and put into a plan for future enhancements to the application system. These corrections to defects and new features will also need to be
considered when determining, developing and implementing required upgrades.
The Production phase finishes with the Sign-Off Milestone. Review and be familiar with the objectives of this milestone before you begin this phase and make sure you
have met these objectives before you complete this phase.
Back to Top
OBJECTIVES
Obtain sign off. Obtain management sign-off for delivery.
Address critical operational issues. Monitor the system performance in production and solve any problems detected, if necessary. Log problems and make
corrections, if necessary. Provide agreed on level of user support. Fulfill obligations during the warranty period. Deliver a plan that describes the approach for
continuing management and support of the system.
Plan for future enhancements. Work with the user to develop an Enhancement Plan that helps enable continuing success.
The Production Phase / Sign Off (SO) Milestone Checklist is available to assist with determination of completeness for this phase.
Back to Top
PROCESSES
Transition (TS)
Operations and Support (PS)
Back to Top
KEY WORK PRODUCTS
Back to Top
TIPS AND TECHNIQUES
This section discusses the primary techniques that may be helpful in conducting the Production phase. It also includes advice and commentary on each process.
Production Performance Management is the extension of Performance Management techniques and approaches identified and implemented prior to production
implementation. Performance metrics should be regularly collected and reviewed for all components. Although the basic strategy may be in place, variations in both
requirements and performance are likely to be encountered. Particular scrutiny of performance metrics should occur any time a change is introduced to the system such
#TOP #TOP
as a patch, new interface or module, a change in hardware, etc.) Proactive evaluation of variations to the baseline will help to identify potential performance issues before
the user community notices the impact.
Ongoing throughout the project, change and communication events targeted to specific audiences with the goal of mitigating identified risks and challenges are
conducted. In addition, during Production, you conduct an effectiveness assessment to capture the efficiency of the work done during the project and highlights the
change management work to continue after the Go Live to enable a shorter transition, as well as the IT Transition Plan prepared during Transition is implemented.
Operations and Support
The contracts for most software development and implementation projects specify a required warranty period. This is the length of time following system acceptance that
the project team is obligated to address problems and fix any faults that are found. A typical warranty period is ninety days. The specified warranty period usually
determines the character of the Operations and Support process. A short or absent warranty period means a very short time to hand over the crucial jobs of application
support and maintenance. A longer warranty period allows a more gradual hand-off.
Strict change-control procedures are critical to the success of the Operations and Support process. Procedures for logging faults and performance exceptions must be
explicit and well understood. The project manager and client project manager must have a very good operational understanding of the definitions of a system defect, a
performance exception, and an application enhancement. Any misunderstanding can easily contribute to scope expansion.
Some customers require a configuration audit of the system. This audit usually includes validation of the system against supplemental requirements. Increasingly, such
audits focus on security issues, such as the prevention of unauthorized access to data. Therefore, it is important to address such issues and to involve the internal
auditors in the Technical Architecture process. Audits should be repeated as the system is updated.
Many of the tasks in the Operations and Support process involve evaluating the system's performance in relation to the performance requirements documented in the
Technical Architecture process. If the project team has not built hooks into the application to capture exact response times and transaction frequencies, these tasks
require gathering subjective feedback from the users.
Also during this process, the Future MoSCoW List is developed. This list defines enhancements to be made during and after the Production phase. Unlike typical IS
systems, OUM custom developed applications may require frequent releases to keep pace with competitors, refine the business model, and add capability. The
uncompleted Should have, Could have, and even Won't have requirements may be reprioritized and included in the Future MoSCoW List.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. You can also go directly to the Production phase Scrum guidance within
this technique.
Back to Top
RD.160 Convert Project Views to Reusable Viewpoints New Reusable Viewpoints
PT.120 Conduct Production Performance Management Managed Production Environment
OCM.155.4
Effectiveness
Assessment
Operations and Support
PS.010 Audit System System Evaluation
PS.050 Analyze Problems Fault Corrections
PS.060 Monitor and Respond To System Problems Problem Log
PS.135 Determine Future Functional Enhancements Future Functional Enhancements
PS.140 Plan Enhancements Future MoSCoW List
Back to Top
Back to Top
MANAGING RISK
The most likely areas of risk in the Production phase are the following:
System Performance Cannot Adequately Support Transaction Volumes: Refine the production system setup and configuration based on user feedback
regarding system performance, reporting, and system functionality. By considering performance throughout the development cycle and requiring the conduct of
performance testing, system performance problems can be uncovered before the system goes live.
Additional Business Requirements are Discovered Following Launch: Establish an ongoing solution support business function with policies, procedures,
organization, and staff to address new and changed requirements.
Ongoing Production Staff Does Not Possess Adequate System Knowledge: Retain contractors to provide support during the critical period. Verify that
ongoing client staff is adequately prepared and supporting documentation is effective.
Back to Top
effective use of change control tools and procedures
accurate compilation of volumes, transaction histories, and other performance drivers
effective participation by business management and users
effective technical and application architecture
high level of service commitment by the support team
Back to Top
E.ACT.MPSP - MANAGE PRODUCTION SYSTEM
PERFORMANCE
This activity provides for managing the Production Environment.
Back to Top
OBJECTIVES
The objective for this activity is to monitor and adjust the system based on production performance.
Back to Top
TASKS
ID Task Name
PT.120 Conduct Production Performance Management
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to monitor and tune system performance after initial system Go Production.
Back to Top
PREREQUISITES
Back to Top
E.ACT.EPS - EVALUATE PRODUCTION SYSTEM
This activity consists of audting the production system and collecting, assessing and refining KPI measures.
Back to Top
OBJECTIVES
The objective for this activity is to audit the system after the move to production.
Back to Top
TASKS
ID Task Name
TE.019.2
Collect, Assess and Refine KPI
Measurements
PS.010 Audit System
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to audit the system functionality.
Back to Top
PREREQUISITES
Back to Top
E.ACT.RPP- RESOLVE PRODUCTION PROBLEMS
This activity consists of analyzing and resolving production problems.
Back to Top
OBJECTIVES
The objective for this activity is to work to discover, anlayze and resolve production issues with the new system.
Back to Top
TASKS
ID Task Name
PS.050 Analyze Problems
PS.060 Monitor and Respond to System Problems
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is monitor the production system and detect any production issues. Problems that are found are analyzed and resolved during this activity.
Back to Top
PREREQUISITES
Back to Top
communications.
Back to Top
OBJECTIVES
Back to Top
TASKS
ID Task Name
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
#TOP #TOP
Back to Top
PREREQUISITES
- Elaboration
- Construction
- Transition
- Production
Back to Top
E.ACT.PF - PLAN FOR FUTURE
This activity consists of determining the Future Functional Enhancements and prioritizing them in the Future MoSCoW List. In addition, you measure the effectiveness of
the Organizational Change Management effort.
Back to Top
OBJECTIVES
The objective for this activity is to review new Functional enhancements and create the list of considerations for potential solution development as well as capture the key
benchmarked findings and recommendations for continuous improvement in all organizational, business, and technical systems (for example, system, business, and
organizational performance, and so on).
Back to Top
TASKS
ID Task Name
RD.160 Convert Project Views to Reusable Viewpoints
PS.135 Determine Future Functional Enhancements
PS.140 Plan Enhancements
OCM.250 Measure Organizational Change Effectiveness
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the list of future enhancements. In addition, capture the key benchmarked findings and recommendations for continuous
improvement in all organizational, business, and technical systems (for example, system, business, and organizational performance, and so on). This activity is used in
planning the work for any subsequent Increments for further development of the system.
Back to Top
PREREQUISITES
Back to Top
E.ACT.DITTP - DEPLOY IT TRANSITION PLAN
This activity consists of implementing the IT Transition Plan.
Back to Top
OBJECTIVES
The objective for this activity is to facilitate the transition within the IT organization, securing the right level of sponsorship in order to deploy the plan recommendations.
Back to Top
TASKS
ID Task Name
OCM.260 Implement IT Transition Plan
Back to Top
ITERATIONS
feedback.
Back to Top
APPROACH
The approach to this activity is to implement the IT Transition Plan by establishing a task force to facilitate the transition within the IT organization and secure the right
level of sponsorship in order to deploy the plan recommendations.
Back to Top
PREREQUISITES
Back to Top
E.ACT.SO - SIGN-OFF MILESTONE SUMMARY
decisions should be made and goals evaluated. Each phase has a main milestone. The Sign-Off Milestone is produced at the end of the Production phase (as far as the
engagement goes). This is the last key project milestone.
Back to Top
OBJECTIVES
Obtain sign off.
Address critical operational issues.
Plan for future enhancements.
Back to Top
ACTIVITIES
E.ACT.MPSP Manage Production System Performance
E.ACT.EPS Evaluate Production System
E.ACT.RPP Resolve Production Problems
E.ACT.DCMRCCP Deploy Change Management Roadmap / Communication Campaign - Production
E.ACT.PF Plan for Future
E.ACT.DITTP Deploy IT Transition Plan
Back to Top
ACTIVITY CHECKLISTS
Production Phase / Sign Off (SO) Milestone Checklist MS Word
Back to Top
[RD] BUSINESS REQUIREMENTS
In the Business Requirements process, you define the business needs that will be fulfilled by the application system. The business requirements for the proposed system
or new enhancements are identified, refined and prioritized by a tightly integrated team of empowered ambassador users and experienced analysts. The process often
begins from an existing high-level requirements document and a scope document, such as the Project Management Plan, Validated Scope (PJM SM.010). However, it is
possible to begin from an agreed on scope and objectives before requirements have been defined. The Business Requirements process delivers a set of requirements
models and a prioritized list of requirements as a basis for system development. Both the models and requirements list are dynamic and may change as the
understanding of the team develops with the system.
The main work products or outputs of this process are the business objectives and goals, the list of functional requirements and the supplemental requirements.
Back to Top
PROCESS FLOW
Back to Top
APPROACH
Depending on your project (e.g., large, complex, etc.), the project manager may designate a Business Requirements team leader and/or team leaders for various other
reasons that the project manager deems necessary. If the project manager designates team leaders, they are responsible for leading their team and reviewing the work
products produced by their team. The team leader plans, directs, and monitors the day-to-day work of the team. The team leader assigns work packages to the team
members and makes sure they understand the requirements. The team leader is responsible for building team cohesion, motivating the teams, and providing assistance
and encouragement to the team members. Each team leader performs the final quality control and quality assurance for the team by reviewing all work products. The
team leader also signs off on team work completion and quality. Work that is not up to quality standards is returned. Team leaders review work products from other teams
when these work products may impact aspects of the system. The team leader reports the team's progress to the project manager. Refer to Project Management in OUM
for additional information on team leaders.
The Business Requirements process begins with defining the Business and System Objectives (RD.001). These objectives form the actual business benefits the customer
wants to achieve by the new system. This is an important input to use during the rest of the project, from the beginning to the end. It will help in defining the right
priorities, and to make decisions in line with the objectives.
Another early task is the creation of a System Context Diagram (RD.005) for the proposed system. The model identifies the business areas covered, all external data
flows into and out of the proposed system and the related external systems.
The team then proceeds to high-level modeling, beginning with the identification and definition of the primary business processes. The requirements are transformed into
the requirement models, the Future Process Model (RD.011.1), High-Level Business Descriptions (RD.020) and the Domain Model (RD.065). Often all these tasks are
often performed as part of the same (or following) Business Requirements Workshops. Workshop techniques are used to determine the business process model, more
detail is provided in the business descriptions, and may trigger changes to the process model. At the end of the Business Requirements Workshop, these work products
should be consistent with each other.
During this process we also, together with the ambassador users, develop and prioritize a list of requirements, and produce the MoSCoW List (RD.045). The prioritization
of this list confirms the current requirements. This is sometimes done partly of fully as part of the Business Requirements Workshop(s), but often you need to gather
everything at the end of the workshop, and perform a separate workshop to produce the final MoSCoW List.
The Domain Model as a business domain model is often created in parallel with the Business Use Case Model (from the Requirements Analysis process) to model all the
relevant business objects that relate to the Business Use Case Model.
In parallel, the supplemental requirements are defined. Some of these might have come up in the Business Requirements Workshops, but using a separate workshop is
recommended to identify supplemental requirements that go into the Supplemental Requirements (RD.055). As for the functional requirements, these are prioritized using
the MoSCoW principle.
In addition, a baseline Architecture Description (RD.130) is developed. The goal of this task is to highlight the factors that influence the application architecture and to
enumerate strategies for dealing with these factors in the architectural design. Development of the Architecture Description starts with the identification of organizational,
technological and product factors that may affect the architectural design. These may have come up as part of both the functional and supplemental requirements, some
are constraints that are given for the project. Finally, from the prioritized list of requirements (MoSCoW List), the initial requirements models, and the Supplemental
Requirements, the requirements are consolidated into a Requirements Specification (RD.140) that undergoes a peer-review (RD.150). This may be done in a number of
iterations. Such an iteration may either consist of a subset of the Requirements Specification, or cover the complete set of requirements. This will depend on the size of
the application to develop, the complexity, and the vagueness of the requirements. Typically, the smaller application, the lesser complex and the clearer requirements,
the more requirements you include in a single iteration, as you do not expect too much to be changed as a result of the review. After a peer-review, any new and changed
requirements are incorporated into the Reviewed Requirements Specification that may undergo a new review.
After the final peer-review, the project manager reviews and if necessary, (re)defines the project plan and partition(s), and again any new and changed requirements are
incorporated into the appropriate requirements models, and (re)prioritized.
*This process has Application Implementation supplemental process guidance.
Back to Top
Application Implementations
This process has supplemental guidance that should be considered if you are doing an application implementation. Use the OUM Application Implementation
Supplemental Guide to access all application implementation supplemental information. You can also go directly to the Business Requirements process supplemental
guidance.
Back to Top
Inception Phase
RD.001 Detail Business And System Objectives Business and System Objectives
RD.003 Identify Viewpoints Viewpoints List
RD.005 Create System Context Diagram System Context Diagram
RD.012 Document Present And Future Organization Structures Present And Future Organization Structures
RD.015 Determine KPI Collection and Reporting Strategy Key Business Strategies and Objectives
RD.020 Obtain High-Level Business Descriptions High-Level Business Descriptions
RD.030 Develop Current Business Process Model Current Process Model
RD.034 Document Current Business Baseline Metrics Current Business Baseline Metrics
RD.055 Detail Supplemental Requirements Supplemental Requirements
RD.065 Develop Domain Model (Business Entities) Domain Model
RD.070 Determine Audit and Control Requirements Audit and Control Requirements
RD.134 Identify New Software Release Changes Software Release Changes Summary
RD.136 Perform Custom Extension Impact Analysis Custom Extension Impact Analysis
RD.138 Perform Data Impact Analysis Data Impact Analysis
Elaboration Phase
Construction Phase
Construction Phase
RD.160 Convert Project Views to Reusable Viewpoints New Reusable Viewpoints
Back to Top
OBJECTIVES
The objectives of the Business Requirements process are:
Define clear, concise, consistent and measurable business and system objectives that should be achieved by the proposed system.
Define clear, concise, consistent, testable and unambiguous business requirements in order to show our understanding of the client's requirements and thereby
provide a basis for a common understanding of the proposed system.
Prioritize the business and supplemental requirements, based on the MoSCoW principle (Must have, Should have, Could have and Won't have).
Construct process and domain models as a basis for system design and subsequent testing.
Create a model that visually depicts information flows in the business in order to specify data use within and across your organization.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
APS Application/Product
Specialist
In a commercial off-the-shelf (COTS) application implementation, this person provides functional knowledge about the COTS application.
BA Business Analyst Facilitate workshops, interviews or meetings. Prepare for the workshop and lead the modeling activities. Record/document models and
work products. Develop the Glossary. Focus on a clear definition of project scope. Verify that the business and system objectives are
achievable and testable. Communicate the need for commitment from the organization. Facilitate the development of the Current Process
Model. Consolidate requirements into a single Supplemental Requirements document. Develop the Domain Model. Determine and
document the Audit and Control Requirements. Help formulate and prioritize the organization and product architectural risk factors.
Consolidate requirements into a single Requirements Specification document. Review Requirements Specification.
DES Designer Resolve any conflicts that arise between teams concerning the definition of shared domains for the Domain Model (RD.065). Review
Requirements Specification.
SAN System Analyst Review Requirements Specification.
SA System Architect Help consolidate requirements into a single Supplemental Requirements document and single Requirements Specification document.
Facilitate workshops, interviews or meetings. Formulate technological risk factors. Facilitate and review the Requirements Specification.
Client (User)
KEY Ambassador User Provide information about the business, business processes, organization units and external interfaces. Participate in modeling. Provide
information about business terms. Help consolidate requirements into a single Supplemental Requirements document and single
Requirements Specification document. Provide information about domain objects related to the business. Participate in the determining
the Audit and Control Requirements. Formulate and prioritize the organization and product architectural risk factors. Review Requirements
Specification.
BLM Business Line
Manager
Provide information about the business Select the business processes that should be baselined. Assist in determining the Audit and
Control Requirements.
CPM Client Project
Manager
Focus on staffing and other organizational issues that must be addressed in order to achieve the objectives.
CSM Client Staff Member Collaborate with the business analyst and the application product specialist to confirm the KPI benefits and their measurement.
OS IS Operations Staff Provide information about existing systems and their operation.
SS IS Support Staff Provide information about system terms.
CPS Project Sponsor Responsible for all budget issues. Provide information about the business. Provide business context information about the process(es)
being modeled.
USR User Provide information about a particular business process.
VS Visionary Communicate the vision.
Back to Top
Availability and Motivation of Qualified and Empowered Ambassador Users: The project is dependent on ambassador user participation. If the ambassador
users are not sufficiently available, then it will take too long for the ambassador users understanding and the developers understanding to converge, and thereby
to form a common understanding of the requirements. Is that the case, the reviewed Conceptual Prototype and Requirements Specification will be less useful as a
basis for further development. The ambassador users need to be strongly motivated to participate. They must also be able to compromise in order to reach
agreement. The project sponsor needs to understand that the right users must be released to the project, not just the users who can most easily be released from
other duties. If we do not have the right users, the developed system will neither be right.
Availability, Skills and Continuity of Qualified Analysts, Designers, Architects and Developers: The development organizations resources are as critical as
the ambassador user resources. OUM focuses on keeping the same resources throughout the lifecycle of the project. Therefore, these resources need a
combined set of skills so that they can take on different roles, as they become appropriate for each phase and process. OUM will be new to many developers, who
may feel uncomfortable without the structures and procedures of a traditional (waterfall) development approach. Developers need to deliver quickly, meeting fixed
deadlines, often from minimal requirements. Because a OUM project is focused on quick delivery, there is normally no time for training on the job. If there are
inexperienced OUM participants on the project, there should be at least one experienced practitioner (who is not on the critical path) coaching.
Project Scope: An agreement must be reached with the sponsor about the project scope and the project scope must be prioritized. It is necessary to start
prioritizing at this level in order to introduce the possibility that not everything will be included.
Commitment from User Organization: The user organization must be committed to a successful project. If this commitment is not present, then users (and user
management) will not prioritize project activities, will not be sufficiently available, and when they are available, will not focus on making the right decisions.
Communication Skills of the Participants: Good communications is vital in order to help everyone understand what their tasks are and what they need to do, as
well as to get the requirements of the new system clear. Every participant needs good communication skills. The Project Manager should be able to clearly explain
the project plan, the impact on the organization, the benefits of the approach, and the necessity of getting sufficient time from the right users. The project sponsor
should be able to describe the business problems to the developer organization and to make clearly explain the business benefits of the solution.
Facilitator and Scribe Skills: During the Inception and Elaboration phases, most requirements are produced during workshops. Therefore, the skills of the
facilitator and scribe are important to get the information in the right format, in the right timeframe and with the right content.
Good knowledge and understanding OUM by the Project Manager: Normally the project manager drives the Inception phase and at the end plans the rest of
the project. Therefore the project manager must know and be able to communicate the OUM approach, together with the demands that a project using OUM
makes on the client organization, as well as the implications of using techniques like MoSCoW.
Understanding OUM by other project participants: It is important that all persons involved understand the OUM and its benefits. For example, if the
ambassador users do not understand why we need to prioritize functionality, they may tend to view everything as equally important. They need to understand the
impact of giving non-important functionality a high priority. The project manager and any team lead should know the OUM approach thoroughly in order to motivate
and guide the team, as well as understand the inherent risks in order to mitigate risks and issues as they develop. The developers (architects, analysts and
designers) need to understand the differences between OUM and traditional waterfall development, and to make the necessary adjustments in order to deliver on
time with an acceptable level of quality.
Back to Top
RD.001 - DETAIL BUSINESS AND SYSTEM OBJECTIVES
In this task, you document the key business benefits to be gained by the proposed system. Project stakeholders agree on the business and system objectives, and
whether these objectives should be accomplished in one or several projects. It is important that the objectives are tangible and measurable. Objectives should be
prioritized. Any milestones previously defined should be reviewed and adjusted where necessary to produce an outline plan.
In a commercial off-the-shelf (COTS) application implementation, employing a solution-driven approach, you generally review the documented business case and
business benefits associated with the selected solution with the client to confirm that they are the desired business benefits and determine how these objectives will be
measured.
ACTIVITY
Back to Top
WORK PRODUCT
Business and System Objectives - The Business and System Objectives is a description of the key business benefits of the system, including priorities indicating which
objectives are the most important. This work product is further used as a reference throughout the project to ensure that the requirements are properly prioritized, and
that project participants keep focused on the tasks that relate to achieving these objectives.
Back to Top
TASK STEPS
1 Arrange meeting(s) with project sponsor and stakeholders to agree on
plan and schedule for the objectives workshop/meeting.
Input to Vision and
top-level
objectives.
None
2 Prepare for workshop/meeting. Workshop/Meeting
Plan
The Vision
(presentation)
The Workshop/Meeting Plan details what techniques you will use, the
schedule, participants and required facilities.
The Vision presentation includes an overview of the business benefits
to be achieved.
3 As part of workshop, present the Vision. None None
4 Identify stakeholders that are impacted by the scope of the project.
Potential sources for this information are Enterprise Stakeholder
Inventory (ENV.BA.015), Identified Project Stakeholders
(PJM.BT.030) and anyone/anything that is affected by the system
under discussion.
Stakeholder List The Stakeholder List is a list of all relevant stakeholders.
5 As part of workshop, agree on detailed business objectives. Business
Objectives
The Business Objectives is a list of the critical few objectives that must
be met by the application system. Identify any new or changed business
processes.
6 As part of workshop, agree on detailed system objectives. System Objectives The System Objectives lists any system objectives that can be
identified at this stage. Examples of these may include the requirements
of external partners, regulatory bodies or other stakeholders, and
corporate standards for security or auditability. There may be
requirements to exchange data with existing systems.
7 As part of workshop, prioritize objectives. Prioritized
Objectives
For each objective listed in the Business Objectives and System
Objectives, indicate a MoSCoW priority.
Back to Top
APPROACH
This task is mandatory and should be performed once for each project. In subsequent projects, the earlier work product should be used as input to a similar meeting. The
Future MoSCoW List (PS.140) should also be used as input if the project follows an earlier related project.
Using the Project Management Plan, including the Quality Plan (PJM), develop the detailed objectives for the business and system.
Detailing the Business and System Objectives can be accomplished in several different ways. Depending on the size of the solution being developed, you can use
interviews, meetings, workshops, as well as a combination of these methods or a series of meetings and workshops. This task may be one of many tasks being
addressed in a meeting or workshop that is being held to gather business requirements.
Agree on Business and System Objectives
Business objectives are business conditions that, if met, solve the business problem. Well-defined objectives are measurable and often relate directly to business
processes and work products. Examples of business objectives are:
to reduce stock by 75% without increasing inventory carrying costs
to complete QA review of 95% of all proposals within 48 hours
to respond to 95% of all customer service calls within 24 hours
to reduce billing errors by 90%.
It is important to note that for most business objectives, it is not expected that the project in itself should ensure that the objectives are reached, but that the result of the
project should be a means in helping to achieve these benefits. Most objectives can only partly be achieved through a new system and are also dependent on other
project external factors, such as, organizational and human factors. However, it still is important to have these objectives defined, so that during the project, the
requirements are defined and prioritized to best support these objectives.
In an OUM project, there should be a constant focus on business benefits. Therefore, system objectives should be defined only where they deliver such benefits (for
example, by supporting one or more business objectives). Examples of system objectives include the following:
The system should be available to users between 07.00 and 19.00 every day of the year.
System response times should not delay users during customer interactions.
All data that has been entered should be retrievable at any later date.
In order to detail the Business and System Objectives, determine the participants that should have a say, and to invite them to an objectives workshop. In most projects,
high-level objectives have already been defined, but these are often not measurable and they are difficult to relate to business processes. Use the high-level objectives
as a starting point and ask the participants what kind of detailed objectives can be defined that make the high-level objectives obtainable. In this way, you should get a
tree with objectives, from a high-level to a measurable level. It is a good idea to use the SMART (Specific, Measurable, Achievable, Realistic and Timely) approach for
defining these objectives. Some examples follow:
High-Level Objective: Increase Customer Satisfaction
More-Specific Objective: Make ordering procedure more effective.
Specific Objective: Respond to ordering calls within 15 seconds.
High-Level Objective: Deliver as Promised
More-Specific Objective: Up to date inventory information to ensure correct information about availability.
High-Level Objective: Quick Response to Customer Service Calls
Specific Objective: Respond to 95% of all customer service calls within 24 hours.
Be as specific as possible detailing what the objective is about. Ensure you understand the reason for the objective (why). Often, you find the why is more visible on a
higher-level objective. For example, why do you want to respond to ordering calls within 15 seconds. Because you want to do what -- make the ordering procedure more
effective. This often relates to an even higher-level objective. For example, why do we want to make the ordering procedure more effective --to decrease customer
complaints.
In most situations, the question of how to realize this objective is only partly found in the system being developed. Thinking about the how in relation to the system, leads
to the requirements for the new system. For example, what system requirements help support the objective, Respond to ordering calls within 15 seconds -- a call router
system that immediately transfers the call to the available operator, allows the customer to enter their customer ID, thus ensuring that when the operator takes the call,
the customer information is already available, and so on. Keep in mind, you still need to determine what is within scope. In addition, some how solutions result in non-
system requirements, such as, having enough operators to answer calls.
Make the objective measurable. (Respond to ordering calls within 15 seconds). This makes it easy for the customer to see whether the objective has been reached, or
not. Again, it is important to state that for many objectives you cannot use the system as the only factor to reach the objective. On the other hand, you might be able to
make specific measurable requirements for the system as a part of the objective. For example, the Register Call page must be able to retrieve customer information
based on the customer ID, within x seconds with y concurrent users.
Make certain that the objectives are achievable within the given constraints. For example, is it achievable that the customer have enough operators available to answer
calls within 15 seconds, all the time (even with a perfect supporting system)? If not, you should rephrase the objective.
The objectives must be realistic or relevant for the project. If the objective does not deliver any requirements for the System under Discussion (SuD) it will not be
relevant for the project, and should not be included as part of this work product.
What is the timeframe (timely) for the goal to be achieved? The timeframe should be related to the project timeframe. Objectives that lay further into the future should be
divided into sub-objectives that can be related to the project. The project is only one step on the way to achieve a larger objective.
Using this technique, we can ultimately make the objectives more clear and understandable.
Prioritizing the Objectives
After the objectives have been defined, they should be prioritized. Having the objectives prioritized makes it easier to prioritize the requirements correctly, and thereby
keeps the team focused on actually delivering a system where you achieve these objectives. Use the MoSCoW priorities, as they are described in RD.045.
Start on prioritizing the objectives at the highest level. At this level, most of them are often Must have objectives. However, try to make them think specifically and use a
"What if" technique:
What if, you did not have the possibility (budget, time) to reach all these objectives?
Which would you prefer the most to be reached?
Which would you need the least?
In most situations, there are differences in the importance of objectives.
When the top level has been prioritized, move on to the next level. What detailed objective would be the most effective to achieve the top-level objective? Continue In this
way all the way down to the lowest level.
The Business and System Objectives Impact on the Project
Once the Business and System Objectives have been defined in detail, this might have an impact on the project. You might come to the conclusion that it may not be
possible to achieve all of the high-level objectives in a single project. It might be better to consider a phased approach, in which the Vision is achieved in a series of
increments, each delivering tangible business benefits. You may find that some of the work to be done to achieve the Vision can be more effectively performed by other
routes. Some projects are better achieved by a different approach (for example, where there is computational complexity, you may decide to use a more waterfall kind of
approach), or by the implementation of standard applications, or by performed business process reengineering. Where two or more projects run in parallel, you should try
to identify well-defined interfaces between them and to reduce interdependencies as much as possible. The scope of the project(s) should be defined in terms of
functional areas.
If you already have a signed contract prior to performing this task, you must ensure that the objectives identified fall within scope of the contract. If they do, and you come
to the conclusion that the project would be better run in a number of sub-projects, discuss this with the client to determine what the best approach would be (either
remaining within the same contract, or changing it).
You should also review the milestones that were defined in CR.010, to see whether they are realistic in relation to the objectives.
Commercial Issues
This meeting is not a forum for the discussion of commercial issues. Consulting managers and salesmen should not attend.
Back to Top
WebCenter (formerly E20)
This task has supplemental guidance that should be considered if you are doing a Webcenter implementation. Use the following to access the task-specific supplemental
guidance. To access all WebCenter supplemental information, use the OUM WebCenter Supplemental Guide.
Back to Top
Business Analyst Facilitate the workshop, interviews or meetings. Focus on a clear definition of project scope. Verify that the business and
system objectives are achievable and testable. Communicate the need for commitment from the organization.
If a Business Requirements (or other) team leader has been designated, 20% of this time would be allocated to this individual,
leaving 80% allocated to the business analyst. The team leader would then facilitate the w orkshop, interviews or meetings.
100
Ambassador User Provide information about business processes, organization units and external interfaces. Participate in modeling. *
Visionary Communicate the vision. *
Client Project Manager Focus on staffing and other organizational issues that must be addressed in order to achieve the objectives. *
Project Sponsor Responsible for all budget issues. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Strategy
(ENV.BA.010)
Use this Envision work product or a similar enterprise-level document, if available. You need this information before you can begin this
task. Therefore, if it is not available, you should obtain this information prior to beginning this task.
Project Management Plan
(PMP)
The Project Management Plan is used by the team to define and agree on the detailed Business and System Objectives and milestones.
The Project Management Plan may not be complete at this stage, in which case this task will provide additional input into its development.
Future MoSCoW List
(PS.140)
If this is not the first project (of related projects), you should review the Future MoSCoW List from the preceding project.
Skilled Project Team
(TR.050)

Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-
001_BUSINESS_AND_SYSTEM_OBJECTIVES.DOC
MS WORD
Tool Comments
This task has supplemental guidance for
using Oracle User Production Kit
Professional (UPK Pro) and Oracle Tutor. Use
the following to access the task-specific
supplemental guidance. To access all Oracle
UPK Pro and Oracle Tutor supplemental
information, use the OUM Oracle User
Productivity Kit Professional (UPK Pro) and
Oracle Tutor Supplemental Guide.
Oracle User Productivity Kit Professional (UPK Pro) and Oracle Tutor are complementary Oracle tools that are used
to develop, deploy and maintain content that can be used throughout each phase of the enterprise application
implementation lifecycle from blueprinting/design/testing to go-live and maintenance/support. UPK Pro and Tutor can
be used with all of Oracles business application brands as well as non-Oracle business applications. UPK Pro and
Tutor allow project teams to streamline the creation of business process documentation, test scripts, interactive
simulations, job aids, presentations, courseware, and in-application performance support, reflecting the specific
business practices and applications environment. For creating the above content types, use Tutor for business
process documentation and UPK for everything else. Oracle Corporation uses Tutor to document its business
processes.
Back to Top
The Business and System Objectives is used in the following ways:
as the starting point for identifying requirements
as a reference against which analysis and design will be validated at all stages
as a continuous reference
each new requirement must be traceable to an objective
Distribute the Business and System Objectives as follows:
to stakeholders that have an interest in the Business and System Objectives, such as the clients management
Back to Top
QUALITY CRITERIA
Are the scope and objectives of the project clearly defined?
Are the objectives achievable within the agreed time frame and resource level?
Are the objectives defined from high-level to low-level, and are the levels related to each other?
Are the low level objectives testable?
Are the objectives prioritized?
Back to Top
RD.003 - IDENTIFY VIEWPOINTS
During this task, you review the Viewpoint Library for relevant viewpoints to reuse for your project, and define all the views you will need for various tasks during your
project. This is based on the type of stakeholders that will be involved in these tasks, their concerns and the objectives of the tasks. You typically define views for the
tasks where there are high risk project stakeholder concerns.
Note: Review the definitions of the terms: viewpoint, architectural view, model and concern in the OUM Terms before executing this task.
DETAILED DESCRIPTION
Viewpoint modeling is commonly used in other more mature engineering disciplines outside of IT. For example:
different models for a building (floor plans, electricity, water, heating system, etc.)
different models for a city (physical, metro, buses, etc.)
Although an IT project is, to a large part, defined by its requirements and technology used, the main determining factor of what makes a project different from another is
people. The entire process of software development, service engineering, and operations management is strongly stakeholder influenced. By carrying out this
stakeholder analysis before implementing a project, stakeholders such as architects and project managers can detect and act to prevent potential misunderstandings.
Within a single project, it is not expected that every possible viewpoint available will be needed. So a solution architect will need to make critical decisions such as:
Which existing viewpoints are needed for this project?
Is there a need to develop a new viewpoint to address any specific project needs?
What level of detail should the models be developed to? (Also referred to as the abstraction level of the model)
What level of model validation is required? (Also referred to as the formality of the model)
The type and scale of the project and the complexity of the concerns, dictates how much time at any stage of the project lifecycle, should be devoted to this task. For this
reason the identified stakeholders are prioritized against pre-selected criteria to assist in narrowing down which stakeholders and viewpoints to select and develop.
Although viewpoint modeling is required at an early stage in the project lifecycle to allow the stakeholder analysis process to proceed, it is emphasized that verification
and possible revision of the list of viewpoints included should be kept in mind throughout the project lifecycle, otherwise the viewpoints may become obsolete.
Situations may arise that could affect the viability of the viewpoints. Examples of these situations are:
New information acquired may reveal previously unrecognized stakeholders
New information acquired may show that a particular stakeholder is less significant than originally assumed.
Stakeholders concerns may evolve.
Project concerns may shift over time.
Business Unit or Enterprise may reorganize.
Back to Top
ACTIVITY
Back to Top
WORK PRODUCT
Viewpoint List - The Viewpoint List contains all the viewpoints, selected from the Viewpoint Library that should be used for the various modeling activities in your project.
It also contains a definition of ad hoc project views to address concerns that are not addressed in any of the existing viewpoints.
Back to Top
TASK STEPS
1 Review Viewpoint
Library for
relevant
None
viewpoints.
2 Evaluate
stakeholder
concerns against
Viewpoint Library.
None
3 Select viewpoints
for reuse.
Reuse
Viewpoint List
The Reuse Viewpoint List contains all the viewpoints that will be reused in the project with or without any project modifications.
For each viewpoint it is indicated which stakeholder concerns should be covered by the viewpoint. There may be multiple
viewpoints addressing the concerns of a single stakeholder, and one viewpoint may address concerns of multiple
stakeholders.
4 Determine ad hoc
views.
Ad Hoc View
Definitions
The Ad Hoc View Definitions contain a definition of every view that is needed for the project where there were no viewpoints to
reuse from. The view definition contains a name of the view, for which purpose they should be used, and the stakeholders
concerns that it should address.
5 Define Additional
Views to Address
Project Concerns
Reuse
Viewpoint List
and Ad Hoc
View
Definitions
These components are an addition to the reused viewpoints or ad hoc views but addressing any additional project-specific
concerns not covered by stakeholder concerns.
Back to Top
APPROACH
A Viewpoint Library that is kept at enterprise level contains reusable viewpoints that can be used for any project that should be executed within the enterprise. Each
viewpoint should be classified in a way that makes it easier to determine whether there are any reuse candidates at a project startup. This is typically classified against a
domain or project type.
A viewpoint is a set of standards that is used to create one or more views that addresses one or more stakeholders concerns. A view is specific for a project, and consists
of a number of models.
For example, if the viewpoint determines the standards (i.e., the notations) to be used for the process models, then a view based on this viewpoint is a set of process
models produced using this notation, and addressing the concerns of one or more stakeholders (if they have the same collection of concerns). For example, if the
stakeholders are Human Resources stakeholders, the view is the Human Resources processes, and the models belonging to that are all the process models that cover
the Human Resources processes.
Review Viewpoint Library for Relevant Viewpoints
Review the Viewpoint Library to determine whether the project is similar to any past projects. If so, review the associated viewpoints for possible reuse in the current
project.
Evaluate Stakeholder Concerns Against Viewpoint Library
Review the Project Stakeholder Analysis (PJM.CMM.010) to understand the stakeholder concerns and how they are prioritized. Use the viewpoint classification scheme to
assist with searching the domain Viewpoint Library for appropriate viewpoints for each stakeholder.
When doing this, you may have the following situations for one stakeholder:
Exact Match - If there is an existing viewpoint for a stakeholder that completely addresses the stakeholder concerns, then there is an exact match, and you should
reuse that viewpoint.
Partial Match - If there are one or more existing viewpoints that partially address the stakeholder concerns, then there is a partial match.
No Match - If there are no existing viewpoints that address the stakeholder concerns, either partially or fully, there is no match
Select Viewpoints for Reuse
If there is an exact match to one or more existing viewpoints that address the concerns of one ore more stakeholders, include them in the Reuse Viewpoint List so that
they can be used to create views for the project.
If there is a partial match between the stakeholder concerns and a viewpoint found in the Viewpoint Library, then do one of the following:
Define an ad hoc view by combining existing viewpoints.
Define an ad hoc view by expanding the viewpoint.
Include these in the Reuse Viewpoint List and stipulate what should be used from each viewpoint. If the view is expanded, indicate what areas should be expanded.
Define Ad Hoc Views
If there is no match between the stakeholder concerns and a viewpoint found in the domain Viewpoint Library, then define an ad hoc view for the project.
Define Additional Views to Address Project Concerns
If there are any unique/specific project concerns that can be addressed by a view, then do one of the following:
Use an existing viewpoint from the domain Viewpoint Library.
Define an ad hoc view to address the specific project need.
Back to Top
Enterprise Architect Identify high risk project concerns that can be addressed with the selected viewpoints. 100
Project Manager Assist the enterprise architect by Identifing the viewpoints that address those concerns. minimal
Back to Top
PREREQUISITES
Prerequisite Usage
Project Stakeholder Analysis
(PJM.CMM.010)
Use the Project Stakeholder Analysis to determine what kind of viewpoints would be the most effective for the different types
of stakeholders.
Enterprise Modeling Strategy
(ENV.ER.070)
If available, use the Viewpoint Library that is created has part of this task. The Viewpoint Library contains all the viewpoints
that should be considered.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Viewpoint List is used in the following ways:
by every project team member that is going to produce a model
Distribute the Viewpoint List as follows:
Back to Top
QUALITY CRITERIA
Have all the concerns of high-priority stakeholders be covered either be a viewpoint or an ad-hoc view?
Have the number of ad-hoc views be minimized to maximize viewpoint reuse?
Is the number of views (ad hoc or from a viewpoint) to be created not too large given the projects resources?
Back to Top
RD.005 - CREATE SYSTEM CONTEXT DIAGRAM
In this task, you produce the System Context Diagram. This model is used to illustrate the Vision and explain concepts to the wider world. It also provides a baseline view
of scope.
In a commercial off-the-shelf (COTS) application implementation, any variance between the business requirements identified in the execution of this task and the
capability or features of the proposed application system that are necessary to meet that requirement (that is, gaps) should be captured in the System Context Diagram
by annotation and additional textual reference, if necessary. Gaps identified in this manner should also be entered into the MoSCoW List (RD.045) and used as input into
subsequent tasks [for example, Develop Future Process Model (RD.011.1 and RD.011.2), etc.] for further refinements.
The System Context Diagram is used to show a high-level view of the system and its external interfaces (human and non-human). It is generally drawn after the Level 1
(business area) Business Process Model is created and is refined to provide more detail regarding how the system within the business area will satisfy the business
users need for information. It is a graphical representation depicting the boundary of the system and its association with external entities called actors. An actor can be
one of 4 types (i.e., human, another system, a clock representing a time-based event, or a hardware device). These actors have the ability of sending or receiving
information and/or events into or out of the system. The key information represented on the association line between the actor and the system is at a summary-level and
shows an arrow indicating the direction of the information flow.
Back to Top
ACTIVITY
Back to Top
WORK PRODUCT
System Context Diagram - The System Context Diagram is a high-level view of the system and its external interfaces (human and non-human).
Back to Top
TASK STEPS
1 Determine the boundary of the system that you would like to
represent and draw a box with the name of that system
inside.
Bounding
Box
This box represents the boundaries of the system you are interested in modeling.
#TOP #TOP
2 Identify the actors (people, organizations, or other systems)
which have a direct relationship (or interaction) with the
system from step #1 and label each actor with an appropriate
role name (that is, customer, night manager, etc.).
Actors The actor symbol is drawn as a stick figure for humans or organizations, a box for
other systems or hardware devices, and a clock for time-based events. If available,
reference the Enterprise Business Context Diagram ENV.BA.045) to bring in the
business actors from that diagram who will be actors in the new system.
3 Identify key inputs and outputs from each actors point-of-
view. Place this key information on the line between the actor
and the bounding box and label it with an arrow indicating the
direction of the information flow.
Key
Information
with
Directional
Arrows
The lines with arrows indicate the direction that the key information flows. The words
on the line should be nouns, indicating data (not process).
4 Review available documentation and talk with subject matter
experts (SMEs) to ensure all Actors have been identified.
Update the diagram for completeness.
5 Write a brief description describing the role and responsibility
of each actor.
Stakeholder
Description
This description helps to define the daily activities being performed by that actor as
they are related to the business or organization.
6 Identify the expectations of each actor regarding their future
needs from the business and/or organization.
Stakeholder
Expectations
This should be a bulleted list of high level goals or objectives that each actor would
expect to achieve from the business/organization in the future (that is, Reduce
Procure to Pay cycle from 14 to 7 days).
Back to Top
APPROACH
System Context Diagram Preparation
The System Context Diagram represents a strategic view of the system. The diagram should not depict how technology will be used by the business, but instead it shows
the people, organizations, and key information that allow the system to operate (from an internal point of view). One technique that is used for accurately depicting the
system is to hold a facilitated session with senior-level members of the team or a subject matter expert who knows about the business. Here are the steps you should use
for this brainstorming session:
1. Hold a 30 minute to 1 hour meeting with key stakeholders and/or subject matter experts to define the boundaries of the system.
2. Have one person draw the diagram while another person facilitates the brainstorming discussion.
3. Begin with a review of the Enterprise Business Context Diagram, if available. This will assist in identifying business actors who may become system actors.
4. Try to identify as many actors as possible, and postpone judgment on whether they are inside or out of the bounding box."
5. Once the actors have been identify, choose 1 actor at a time, and identify their information needs (both input and output).
6. Update the diagram with this information, making sure that the information placed on the model is at a summary level."
7. After each actors key information has been defined, briefly describe the role and responsibility from each actors point of view.
8. Identify a list of 3-5 expectations from each actors point of view.
The UML optionally allows you to indicate system actors with a rectangle and the <<actor>> stereotype. It is just another way of saying it is an actor, but some people
prefer to differentiate between human actors and actors that represent computer systems.
Creating the System Context Diagram can be accomplished in several different ways. Depending on the size of the solution being developed, you can use interviews,
meetings, workshops, as well as a combination of these methods or a series of meetings and workshops. This task may be one of many tasks being addressed in a
meeting or workshop that is being held to gather business requirements.
For custom-developed systems, OUM recommends performing this task by gathering all the required participants in a working session. Preferably, use a facilitated
workshop, but in smaller projects, it may be sufficient to do this in a meeting. Either way, it is essential that all of the relevant stakeholders and ambassador users
participate. Do not include anyone who has little or nothing to contribute to the workshop. The results of this workshop define the scope of the project. Subsequently, the
project manager will only accept requirements if they can be traced to objectives defined in this workshop. Use techniques that encourage user participation.
System and Its Actors
When the need for a new system is determined, the first task is to define the business area that the new system will automate. In order to do this, we need to understand
the client's business objectives and primary business processes. We also need some way of understanding the size and complexity of the business area. We can
accomplish this by answering the following questions:
How do the objectives of the project relate to the business areas and actors?
How many different actors are involved in executing primary processes?
What information is needed for the processing?
Are the processes geographically dispersed?
The System Context Diagram considers these issues by looking at how the system supports a business area and its relationship to the environment.The term business
area is used to refer to the set of business organizations involved in the scope of a project. This high-level or contextual perspective provides a unique view of the
system. It defines the scope by specifying what is inside the system and what is outside the system. Although the project sponsor drives the definition of scope, we use
the System Context Diagram to expose and clarify what is in scope.
Back to Top
Back to Top
Business Analyst Facilitate the workshop, interviews or meetings. Lead the modeling activity. Record/document the model.
leaving 80% allocated to the business analyst. The team leader would then facilitate the w orkshop, interviews or meetings.
100
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Process
Model (ENV.BA.040)
Use this Envision work product or a similar enterprise-level document, if available. You need this information before you can begin this task.
Therefore, if it is not available, you should obtain this information prior to beginning this task.
Enterprise Business
Context Diagram
(ENV.BA.045)
Use this Envision work product as a starting point, if available. If this task was not done, you need to draw the Enterprise Business Context
Diagram in context of your implementation project (not the full Enterprise, just those business areas impacted by the system implementation),
as a first step of this task.
Business and System
Objectives (RD.001)
The Business and System Objectives are used as to help determine the context of the system.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-
005_SYSTEM_CONTEXT_DIAGRAM.PPTX
MS POWERPOINT - Use this template if you choose to create the System Context Diagram in MS PowerPoint.
RD005_SYSTEM_CONTEXT_DIAGRAM.ZIP This zipped file contains an MS VISIO template and stencil to assist you in creating a System Context Diagram in MS
VISIO.
Tool Comments
Getting Started with Use Case Modeling JDeveloper
Getting Started with Activity Modeling (regarding the Context Process Diagram) JDeveloper
Use Case Diagram Viewlet JDeveloper
Activity Diagram Viewlet (regarding the Context Process Diagram) JDeveloper
Example Comments
System Context Diagram MS Visio
Back to Top
The System Context Diagram is used in the following ways:
to communicate and develop the Vision
to depict the scope of the project
to identify the external actors to which the system will respond
to identify external systems for which interfaces will be defined
Distribute the System Context Diagram as follows:
to all team members
to the project manager to help them determine the scope of the project
to the technical architect to help determine the external interfaces to other systems
to Quality Assurance to ensure test cases are written to include key actors
to the database designer to ensure key information is included in the database schema
Back to Top
QUALITY CRITERIA
Does the System Context Diagram conform to the project Standards and Guidelines?
Have all the external Actors been drawn on the diagram?
Has the key information (input/output) for each actor been determined at the summary level?
Has the diagram been drawn using UML notation?
Is the proposed boundary of the system realistic given the timescales?
Are all affected business areas adequately covered by the diagram?
Are all external systems and external interfaces within scope included in the diagram?
Back to Top
RD.011 - DEVELOP FUTURE PROCESS MODEL
In this task, you define the future business model in the form of integrated process flows based on the business processes supported by the new applications. The
Future Process Model is created through iterations, starting with a higher level view in the Inception phase, and progressing into a more detailed view in later iterations.
If pre-defined process models/business flows exist for the functionality being implemented, they should be used as a starting point for preparation of this task's work
product. Wherever possible, adapt existing standard models to the future business processes rather than redesign the business processes.
If you have created a Current Process Model (RD.030), or have it available, this is often a good starting point. It is often easier for the users to visualize how the current
situation can be improved, rather than figure out the best approach for the process from scratch. If you have both (pre-defined and current process models/business
flows), this enables you to point out differences and weaknesses in the current models as a preparation for the modeling exercise.
In the System Context Diagram (RD.005), you have identified the external actors that interact with the business in some fashion. Each of these actors causes one or
more events to which the business should respond. When developing the Future Process Model, you should identify all these events. In addition, you should identify
temporal events and internal events. Then diagram and describe the business flows with which the business area responds to these events. Some of these business
flows might be entirely internal to the business area.
For projects that involve the upgrade of Oracle products, it is important to consider the potential business process improvement features offered by the new release.
However, the primary purpose of this task (within an Upgrade Project) is to review and confirm the post-upgrade business process flows, and not to complete a full To-Be
process definition.
ACTIVITY
RD.011.1
RD.011.2
Back to Top
WORK PRODUCT
Future Process Model - The Future Process Model documents the triggering events that drive the business areas that are to be automated and describes the future
business process that the business executes in response to each of those events as a set of one or more activities. The model includes the following:
a catalog describing all the triggering events
diagrams of the business processes by which the business responds to those events
Back to Top
TASK STEPS
1
(Optional)
Using one or more workshops may be the most appropriate
technique to execute this task, depending on the size and
complexity of the project, and/or the number of client
personnel involved. Please see the Conduct Requirements
Workshops section in the Approach for more details. In
addition to normal workshop preparation (goals, agenda,
invitations, logistics, etc.), you should have as an input to the
workshop.
Review any documented future business requirements.
If available, review any current process models, and try
to identify weak areas related to documented future
requirements.
If available, review any pre-defined process
Workshop
Preparation
Notes
Workshop
Agenda
Workshop
Logistics
The Workshop Preparation Notes is all the information you send to the
participants ahead of the workshop. The notes state the goal of the workshop,
so that everyone is well aware of the purpose of the workshop, and what is
expected to be achieved.
It is also all the information you have gathered for input to the workshop. This
would often be some kind of presentation material. This would typically be the
result of the detailed preparation described in the task step.
The Workshop Agenda describes in detail what should be done in the
workshop, and timeboxes all the activities. Preferably, this should be sent to
the attendants ahead of the workshop.
The Workshop Logistics describe all the required logistics for the workshop.
#TOP #TOP
models/business flows exist for the functionality being
implemented, and identify gaps between these and the
current process models. The Enterprise Repository
may be helpful for this if one is in use in the enterprise.
2 Confirm and identify new high-level business triggering events
to which the business and system must respond.
Triggering events may already have been identified in a
number of other work products, such as the Business Context
Diagram (ENV.BA.045), System Context Diagram (RD.005)
and the Use Case Models (RA.015/RA.023).
For each iteration, you should review and refine the Event
Catalog from the previous iteration.
Event
Catalog
The Event Catalog should provide a table to list the events that trigger
responses by the business area. For each event, provide a name, define the
event type (internal, external, temporal), the conditions under which it occurs
and the frequency of the event. These may be external events (a customer
order), internal events (the completion of production), or temporal events (end
of month). The table should also identify the business processes that respond
to those events. If there is a Current Process Model (RD.030), then the Event
Catalog from that model can be used as the starting point. The introduction of
new packaged applications may also introduce new events.
3 Identify business actors.
Business Actors may already have been identified in a number
of other work products, such as Business Use Case Model
(RA.015), and the Use Case Model (RA.023).
For each iteration, you should review the already identified
actors, and whenever required add new actors to the list.
Business
Actors
The Business Actors are those that respond directly to a business triggering
event, or that have to perform an activity as part of the business process that
is triggered by the event. Examples are customers, departments, employees,
and vendors.
4 List each process and write a summary description of each,
specify the event to which it responds and its main inputs and
outputs.
If you have a Business Use Case Model (RA.015) or a Use
Case Model (RA.023) available, you may identify processes
and descriptions from these work products.
For each process, describe the flow of activities for the
business process that is performed in response to each event.
Identify the steps, and their sequence. First focus on the main
path. Later, identify the conditions that determine alternative
paths. If you have Use Case Specifications (RA.024)
available, you can identify steps using these work products.
Construct process flow diagrams for processes with more than
two activities or with conditional activities showing the
sequence of process steps and the flows between them. Show
conditional activities, where appropriate.
For each iteration, use the previous process model and add
more detail and make changes wherever required. In the
Inception phase, you typically model level 1 and 2, but in the
Elaboration phase you should model down to level 3. In the
Elaboration phase, you should model all alternative flows, in
addition to the main flow, the agent responsible for each step.
At level 3 (in the Elaboration phase), each step should
represent a sea level use case, an activity that can be
completed in one sitting.
Process
Listing and
Process
Descriptions
Process
Flow
Diagrams
Process
Step
Catalogs
Alternate
Process
Scenario
The Process Listing and Process Descriptions provide a textual description
of the process that is executed in response to each event, along with an
identification of the main inputs and outputs of the process. Also describe the
business issues that are associated with the business process, and that may
be solved through the future processes.
The Process Flow Diagrams visually describe the flow for each of the
business process within the business area. If pre-defined process
models/business flows exist for the functionality being implemented, consider
using them as a starting point. Also, if you have any current process flows,
these could be used as a starting point.
The Process Step Catalogs lists the process steps or activities that make up
the primary, or most commonly executed, scenario for the process. Each step
should have a brief, and descriptive title. You also record the agent
responsible for the execution of each activity. At level 3, you should classify
each activity by desired degree of automation: manual, computer assisted, or
fully automated.
The Alternate Process Step Scenario lists the process steps or activities
that make up an alternate scenario for the process. List and describe the
steps associated with scenarios, other than the primary scenario, which result
in the same output as the primary scenario.
5 Provide an analysis of the business process change. Process
Analysis
Summary
The Process Analysis Summary provides a review of the process changes by:
Performance and Efficiency
Change and Impact
Security and Risk
6 Review the Future Process Model with users and
management.
None None
7 Secure approval of project and business line management. None None
Back to Top
APPROACH
The Future Process Model identifies the complete set of events to which the business function should respond in order to meet the objectives, describes the future
processes that the business should perform to respond to each of the events and identifies each of the activities executed in those processes.
Before you start creating business process diagrams, you need to decide upon the technique that you will use for each level of diagrams. See the Functional or Process
Modeling Technique for guidance.
The process models should be presented back to the business' management and users and to new members of the project team. The models must be easy to read and
understand for the intended audience. This feedback could be done in such a manner that it tells a story describing the functionality of the business areas that have been
the subject of the analysis and leads the reader through a high-level overview and then into the detail for each business use case.
Definition of Process Modeling of Future Business Processes
Process modeling of the future business processes results in a common and comprehensive picture of the projects scope of relevant processes and, if desired, expected
metrics and costs.
Processes are Driven by Business Objectives
Process modeling needs to capture those processes that are the essence of the mission statement for the business. Often the design and execution of the business
processes are the mechanism by which a competitive advantage or parity is achieved. In fact, it is possible that the mission statement embodies the reason for
developing or selecting this application system in the first place.
Advantage of Process Modeling
The advantage of process modeling is that business processes are real and understandable to users in a way that, for example, a class model is not. Users are the ones
who actually perform business processes. Such processes represent the work of the organization and show how information is used. The outputs they produce are
tangible and essential to the organizations mission. In fact, one of the primary means for measuring the success of a process model is that it is intelligible to the users
who perform the process. By linking business requirements to modeled processes, the quality of defined requirements will be better than informal wish lists or non-
integrated requirements listed by functional area.
Conduct Requirements Workshops
Creating the Future Process Model can be accomplished in several different ways. Depending on the size of the solution being developed, you can use interviews,
meetings and workshops, as well as a combination of these methods or a series of meetings and workshops. This task may be one of many tasks being addressed in a
OUM recommends performing this task by conducting one or more requirements workshops, in which you naturally start by using business process modeling and
identifying parts of the Domain Model. Often, it is easier for the users to first model the Current Process Model (RD.030) as this is well known and familiar, and from there
identify the weaknesses and places to improve. If you have pre-defined process models, then these may also be a good starting point for discussion.
It is recommended that you use facilitated workshops, as you will have the key stakeholders together and thereby be able to make decisions during the workshop and
build a broader ownership for those decisions. However, for various reasons, you may decide to use other approaches.
Process Analysis with Business Process Teams
Process analysis is a logical technique used to drive the task of defining the Future Process Model. The recommended approach is to hold a series of working sessions in
which the teams of analysts and business staff work together to develop a business process model for the processes that represent the scope of the implementation.
During this time, these teams perform the following functions:
Participate in a series of workshops to construct the future processes.
Identify business triggering events, and the process steps for each process that responds to each event.
Identify responsible actors for each process step, and represent using swimlanes.
Capture the process flow using flowcharting software.
Hold feedback and review sessions with appropriate business area management.
Iteratively, refine the model throughout process design activities.
Identify Business Triggering Events
External events should have been identified in the System Context Diagram (RD.005). If there is a Current Process Model available, then business and system events can
be obtained from that model. Also, if you have pre-defined process models/business flows for the functionality being implemented, you may identify candidate events
from these.
Preferably, in a high-level requirements workshop, during the Inception phase, ask the participants to identify business events, and use the prepared list of candidate
events as an input. Ask them to define all those events to which their business unit or functional area must respond. They should uniquely identify and name each event,
and describe each event in business (not system) terms.
Identify each triggering event as one of the following:
external event (initiated outside the business area)
temporal event (initiated at a point in time, often related to the business calendar)
internal event (initiated inside the business area)
The users may not understand the concept of an event, so be prepared to explain this including some examples. The triggering events will become the initial node in an
activity diagram explaining a certain business process.
Ask questions regarding the fulfillment of customer (internal or external) requests to build a complete list of events.
Ask about the business calendar. Walk through each business event, as these may cause one or more events that initiates a business process. Very often these events
will be temporal events.
Capture high-level descriptive information about the event, such as its frequency and immediacy (how soon must a response occur). Finally, work with the business staff
to produce a summary description of the business use case that responds to the triggering event and to identify its main inputs and outputs. Some examples of events
from a customer information system for an electric utility are as follows:
EA005 - customer requests termination of service
ER092.2 - customer requests removal of third party billing notification
EC017 - customer requests collections information
OE-10 - Customer requests change of billing address
OE-23 - Customer orders inventory item
OE-17 - Customer orders warranty contracts
OE-30 - Customer requests credit approval
Assign ownership of each event to a functional area. You can base ownership on who performs the majority of process steps in the process or on the functional area that
initiates the business process responding to the event. Recognize that events create responses by processes that may be self-contained within one functional area or
which may cross-functional boundaries.
It may be difficult to identify events or to distinguish an event from an event mechanism. For example, receiving internal information is not necessarily an event, but is
simply the natural flow of information between process steps in a process. If you are unsure whether something is an event, determine if it would still be an event if the
roles of sender and receiver were performed by the same person.
Identify Business Actors
For each triggering event, you should identify the responsible actors. There might be more actors involved to resolve the event from beginning to end. You should identify
all these actors.
Specify Business Processes
The goal of this step is to specify, at a high level, the business response to each event. Identify each of the high-level steps in the business use case, their sequence and
conditional flow. Keep in mind, that there might be more responses to a single event, but with different actors. In that case, there will be a business use case for each
actor.
For each event, ask the business personnel to describe the activities performed by the business, in a logical sequence, that occur to completely satisfy or respond to the
event. First, concentrate on modeling the main flow that represents most of the possible situations. At a later point in time, you can model the alternate flows.
If there are more possible responses to the event, ask them to describe the decision process necessary to determine each response. If a decision is the very first part of
the event response, this is often an indication that there are more actors involved. Then break it down to different business processes. Dependent on the situation, you
may model this in separate process diagrams, one for each responsible actor. Alternatively, you can show the difference in a single diagram where the different
responsible actors are shown in different swimlanes. Using the same diagram makes it possible to visualize the decision flow to show in what situation the response is for
each actor. Also, if the processes for both actors flow into a common process at a later point (for example, handing it over to third actor, shown in a third swimlane), it is
beneficial to show the processes in a single diagram. On the other hand, if the processes are mainly distinct and large, keeping it in the same diagram will make the
processes less readable.
By working on a suitable medium such as a whiteboard you and the staff who perform the process should create a business process diagram to represent the response.
Some find a white board too restrictive, and prefer to use large sheets of brown paper and yellow sticky labels. This approach allows for more team participation, and
makes it very easy to change the steps/activities and flow during the discussions. You should also use sticky labels for the flows (or some other means where you can
change it easily), as these also will change during the discussion. Do not draw on the brown paper itself.
You may also decide to model directly on-line using some modeling tool, showing it to the users via a large screen. The benefit is that you do not have to record it
electronically after the session. However, for larger processes it is often too restrictive as you may only see a small part of the process at the same time, or the
letters/drawings will be too small. Also making changes to the process during the discussions may be too slow. Keep in mind that whatever tool/mechanism you use, it
should not slow the discussion process, or make it more difficult to understand or to get an overview of the whole. If you want to model on-line directly, this could also be
done in the background by one of the team members, documenting the process on the wall. In any case, you should at least have a printer easily accessible so that you
can print the whole quickly whenever required.
Many of these activities might need to be decomposed later, but will be as part of the Use Case analysis. You should also get the members of the business staff to specify
who is responsible for each activity within the process and to identify the inputs and outputs for each step. You should use these to provide input to the identification of
business objects (domains) and attributes. You might also be able to determine the degree of automation that is required for each activity and specify whether it is to be
performed manually, with computer assistance or entirely automatically by the system.
In a commercial off-the-shelf (COTS) application implementation, you may have access to pre-existing, multi-level business process models, which depict how the
application system supports the business functions being addressed by the project. If such process models are available, leverage them to help identify the triggering
events to which the business area responds. Such business process models should be revised as necessary to reflect the implementing organizations requirements, and
may provide a suitable alternative for the Process Flow Diagrams component of the Future Process Model.
Business Process Levels
It is important to understand the concept of levels, and the differentiation between high-level and low-level processes, when modeling business processes, for more
information refer to the Functional or Business Process Modeling Technique.
Degree of Automation
It is not always obvious in the beginning which steps should be automated, semi-automated or completely manual. For the level 2 models it is important to include the
manual steps, otherwise you will have an incomplete model.
During the Elaboration phase, you should be able to determine the degree of automation that is required for each activity, and specify whether it is to be performed
manually, or with system-assistance. The manual-only step will not be detailed any further. The future processes will be a combination of system-assisted process steps
and manual steps. The diagram may further divide the system-assisted steps into user-executed process steps and those done entirely automatically by the applications.
An example of a user-driven step is the creation of a work order; an example of a system step is the execution of a concurrent job.
At level 3, you would not normally add manual-only steps as part of the process. These are rather modeled as out-going messages to a person or other system, or an
incoming message from the outside world to the system. Only occasionally, when it is interesting to understand what happens to the out-going message, or how an
incoming message is originated, you may decide to model this. However, this is outside the implementation scope, and will only be there for a better understanding of the
whole picture. Occasionally, it may be interesting to model this to detect inefficient message flow.
In a commercial off-the-shelf (COTS) application implementation, as you construct processes, application consultants and analysts identify process steps that can be
supported by the target applications. The application process steps for a given process usually reside within the same applications (intra-application process steps), but
process steps can also reside within other application.
Client staff members add manual steps to the system-assisted process steps as necessary.
Relationship to Current Process Model (RD.030)
It is important to recognize that there may be significant differences between the depth, robustness, and content of current process modeling across different projects,
depending on each situation. One organization may choose not to create current process models, another may choose to do only a very high-level version, while a third
may implement the rigorous process modeling method described, both for its current and its future process model. For some it is just easier to model the current situation
ahead of the future processes.
The most important point to recognize is that future processes must cover the minimum business requirements that current processes cover, to supply the information
required to achieve the business objectives and, possibly, to yield business improvements in cost, time, and quality. Construct the future processes to respond to the
events that become approved business drivers. They will consist of process steps, which may be manual or automated. In the Future Process Model, evaluate each
process step conducted by the current business system to confirm that it has been addressed, either by a manual or an application step, or that it is no longer required.
Differences Between the Current and Future Models
Some project teams may want to see the differences between the current and future models quantified. If this is the case, it will be helpful to capture these changes by
annotating the Future Process Model (RD.011) accordingly.
Process Change
When major process change is applicable, create the Future Process Model in two stages. Initially, create the Future Process Model at a high level. This corresponds to a
generic process model, applicable to the whole organization. After that model is accepted, additional detail is added to the model. This corresponds to variations to the
generic process model needed to cater to the needs of individual business units.
Process Model versus Use Case Model
The process model and the use case model are tightly related, and where you start will often depend on your level of expertise in the various modeling techniques. Many
choose to start off with process modeling at a high level, while others choose first to identify the use case model.
If you start off with process modeling, you would start to identify business events, and then to model the responses to each business event as a business flow. When you
have identified the business process steps, many of these will be business use cases. When you derive the Business Use Case Model from the Future Process Model,
the most effective way of doing so is by starting to detail business process models to the level where the steps in there are comparable to user-goal level business use
cases, and from there create user goal level business use cases to complete the requirements models. A user goal level business use case is a use case that can be
completed within one sitting, i.e., the use case must either be completed (success or failure), or the operation must be aborted completely. It can be compared to what we
called an elementary function in functional decomposition analysis.
From there, each business use case can be further analyzed to identify the business actors. When the primary and secondary actors have been identified, it is good
practice to walk through each actor to verify whether there are any missing use cases, and through that, you may even identify missing business processes. Therefore,
creating the business use cases can be a perfect way of validating the business process models bottom-up and provide the starting point to create the Use Case Model
that captures the requirements of the SuD.
If you on the other hand start off with business use case modeling, you would typically start to identify business actors, and for each actor, identify candidate use cases
that reflect a certain goal that the actor has with the business. The Use Case Model and Use Case Specification would then provide input into the Future Process Model,
and flows can be drawn to visualize the business flow between the use cases. Also process models can be drawn to show the process flow for the activities within the
use case.
Either way, the Future Process Model and Use Case Model provide input to each other, over several iterations. For example, in the latter case, the Use Case Model and
Use Case Specification are used to create a first version of the Future Process Model, or update an existing process model if one exists. Next, the initial Future Process
Model provides input for refinement of the Use Case Model and associated Use Case Specification. The refined Use Case Model, and Use Case Specification, may then
lead to further refinement of the Future Process Model. This iterative development process is repeated until the future business processes are adequately understood
and documented.
Full Event and Process Coverage
Evaluate the entire catalog of events to confirm that associated processes fully capture the entire systems response, that all processes are comprehensively portrayed,
and that there are no disconnects when one process stops and another continues. One way to address the last point is through an integration team that has this
evaluation as one of its responsibilities.
Rapid Implementation Techniques
Implementations projects can derive the future process model faster by following these guideline:
Use an application references model such as Oracle Business Models as a target.
Confirm that process is suitable.
Create future process designs on an exemption basis.
Focus on high-impact areas.
Minimize the time spent on optimizing business processes.
Changes in Process Recognition
Since the solution has yet to be defined, it is too early to get complete commitment from the users. Therefore, you should obtain an agreement from users on overall
direction. Users should agree with the overall concept and framework of expected solutions. The flows should also represent some obvious benefits to users, such as a
reduction in material or information handling. Such a reduction implies reduced cycle times and less potential for communication errors. In the Future Process Model,
highlight the flows that provide more direct approaches than those in the current process.
Business Process Documentation
As you are starting to produce the various catalogs of events, process steps and so on, start capturing the information in your Business Procedure Documentation
(RA.055).
If requirements are managed at the enterprise level for reuse across projects (for example, in the context of a SOA strategy), you should make sure that the Future
Process Model is in line with the Enterprise Repository. This includes checking the repository for parts of the model that may already exist as reusable components and
updating the repository with any new component so that other projects may reuse it.
If a repository is used to manage the models:
Check the Enterprise Repository for existing reusable components of the model. Take all the newly identified components and check that they are not
already available. If they are in the repository, check if they fit the requirements of the current project or, if required, initiate a change process.
Update the repository with the new models. As the modeling work for your project is completed you should update the repository with new process
models so that they can be reused and tracked by other projects that may have the same need.
The requirements identified should be linked to the enterprise functional, process and/or domain models. Please refer to the Enterprise Requirements Management
Technique for more details.
Staffing
Depending on the number and complexity of the business processes, it may be necessary to divide the task workload among multiple teams. However, make every effort
to minimize the number of teams and business analysts involved in order to reduce communication overhead and improve efficiency. Ideally, these teams should have
one or more business analysts to work with the appropriate business representatives. Assign each team to a set of closely related processes, from which to develop a
model. When deploying multiple teams, require that they coordinate their models. Under no circumstances should teams work in isolation, or they may produce
inconsistent models, subsequently requiring considerable effort to integrate.
When managing the construction of future business models, move as rapidly as possible through this task. Because there will be many resources engaged in this task,
watch for and avoid the decision paralysis that can lead to scope and time creep. To meet the scheduled completion dates, the project manager and team members must
see that decisions are made, issues resolved, and consistent progress achieved. Do not hesitate to elevate delays, increase the urgency, and demand date accountability
from the process modeling teams.
Back to Top
Back to Top
Business Analyst Facilitate the workshop, interviews or meetings. Prepare for the workshop, and lead the modeling activity and
document the result.
If a Business Requirements (or other) team leader has been designated, 30% of this time would be allocated to this
individual, leaving 60% allocated to the business analyst. The team leader would then facilitate the workshop,
interviews or meetings.
90
Application/Product Specialist Provide knowledge and guidance regarding the functionality and capabilities of the product(s) being implemented. 10
Business Line Manager Provide information about the business. *
Project Sponsor Provide information about the business. *
Ambassador User Provide information about the business. *
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how
to govern process models. Check for existing process models and ensure that the the process model are added/updated in the
repository.
(ENV.BA.015)
Enterprise Process Models
(ENV.BA.040)
Service Portfolio - Candidate
Services (ENV.BA.070)
Process Improvement Options
(ENV.BA.090)
Use these Envision work products or similar enterprise-level documents, if available. You may need this information before you
can begin this task. Therefore, if they are not available, you should obtain this information prior to beginning this task.
Business and System Objectives
(RD.001)
The objectives are used to determine what should be the content of the new application.
System Context Diagram (RD.005) The System Context Model provides the boarders for the Business Process Model.
Current Process Model (RD.030) The team can use material from the Current Process Model to gain an understanding of the processes and systems that support
the current business. It may identify processes that offer opportunities for process improvement in cycle time, cost, and quality. It
may also show major processes that are candidates for process redesign.
Current Business Baseline Metrics
(RD.034)
For projects where there is a focus on business performance improvement, this is used to identify the critical performance areas
that need to be focused on while developing the future process model. Without this baseline, any business performance
improvement (or degradation) becomes very subjective.
Business Use Case Model (RA.015) The Business Use Case Model is used to illustrate how the high-level vision of business process will be put into practice.
Use Case Model (RA.023) The Use Case Model provides the high-level business requirements for the business processes.
Use Case Specifications (RA.024) The Use Case Specifications provides the detailed business requirements for the business processes.
Skilled Project Team (TR.050) The project team members must understand application concepts and capabilities in order to develop process models based on
leading practices. This prerequisite helps them understand what process steps are supplied by application-specific functions.
Business Process Reengineering
(BPR) Studies
Business Process Reengineering Studies are only appropriate if process change is relevant, and earlier business process
change tasks were not carried out most significantly, Detail System and Business Objectives (RD.001) and Obtain High-Level
Business Descriptions (RD.020). Process reengineering studies may recommend the complete overhaul of current processes to
be supported by the new applications. The output of a BPR study may, in fact, provide most of the content of the Future Process
Model.
Future Business Strategy This prerequisite includes other internal business documents that describe the future business processes. For example, the
original request for quote and management business strategy documents on the manufacturing, distribution, financial, and
administrative processes may be useful during this task.
Back to Top
TECHNIQUES
Technique Comments
This technique provides assistance in utilizing business process models as a requirements gathering technique and describes the
different levels of business process models.
Management
Use this technique to understand how to manage requirements at the enterprise level.
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-011_FUTURE_PROCESS_MODEL.DOC MS WORD - Use this template if you choose to create the Future Process Model in MS Word.
RD-011_FUTURE_PROCESS_MODEL.PPTX MS POWERPOINT - Use this template if you choose to create the Future Process Model in MS PowerPoint.
Example Comments
Future Process Model-Level 0

Tool Comments
Activity Diagram Viewlet JDeveloper
processes.
Getting Started with Activity Modeling JDeveloper
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
The Future Process Model is used in the following ways:
to document the core future business processes
as an input to use case modeling
as an input to domain modeling
as an input to definition of test scenarios
as in input to service identification
as a basis for partitioning of the project
Distribute the Future Process Model as follows:
to all team members
Back to Top
QUALITY CRITERIA
Does the Future Process Model notation and documentation conform to the projects Standards and Guidelines?
Have the responses to all external business events been described?
In the Elaboration phase, does the Future Process Model address business events (external, internal and temporal) to which the organization responds?
Does it reflect what processes make up the response?
Does it reflect the activities that make up each process?
Does it list how business decisions will be supported by the new system?
Does it provide how processes will be streamlined?
Does it provide how desired process changes can be accommodated?
Does it show how resources will interact in the new system?
Does it describe what necessary control elements (approval steps) should be established?
Does it explain how process and performance will be communicated to management for improvement?
Are the process descriptions clear, concise and consistent?
Are there any core business processes that do not support any business objective?
Back to Top
RD.012 - DOCUMENT PRESENT AND FUTURE ORGANIZATION
STRUCTURES
In this task, you identify the key internal and external organizations in scope, their geographic or physical locations, and their headcounts and skill sets.
ACTIVITY
Back to Top
WORK PRODUCT
Present and Future Organization Structures - The Present and Future Organization Structure Definition defines key internal and external organizations affected by the
business objectives and that interact with the application.
Back to Top
TASK STEPS
1 Document the existing organization
hierarchy and sites.
Organization Hierarchy,
Company Sites List
The Organization Hierarchy should show two or three levels of hierarchy. The Company Site
List contains the major organizational units, such as divisions.
2 Document the existing organization units. Existing Business Unit
Descriptions
The Existing Business Unit Descriptions contains a description of each organization unit.
3 Identify external organizations that
interact with the business.
External Organization List The External Organization List contains the external organizations.
4 Document any anticipated changes and
their impact on the business.
Business Unit Change
Descriptions
The Business Unit Change Descriptions describes all planned changes to organization units.
Assess their impact on the system to be developed
Back to Top
APPROACH
Documenting the Present and Future Organization Structures can be accomplished in several different ways. Depending on the size of the solution being developed, you
can use interviews, meetings, workshops, as well as a combination of these methods or a series of meetings and workshops. This task may be one of many tasks being
OUM recommends performing this task by conducting one or more high-level requirements workshops, but for various reasons, you may decide to use other approaches.
Identify and document the internal and external organization structures. Most of the organization units should have been identified in the High-Level Business Process
Model (RD.011), or in the Business Use Case Model (RA.015) as actors. For each organization unit, you should describe the following:
the unit's position in the organization's structure (where appropriate)
geographical location
headcount details, preferably by job function or skill
set anticipated changes
Existing Client Organization
The internal organizations are often divided into groups or departments but they may be divided by physical location. Internal organizations are also known as business
units. The internal organizations captured are those that are potentially affected by the business objectives or the resulting application system.
*Use the following to access task-specific Application Implementation supplemental guidance.
External Organizations
#TOP #TOP
External organizations are also known as external entities. External organizations captured are those that need to interact with the resulting application system. The
following list includes some examples of external organizations:
banks
outside collection agencies
print vendors
Back to Top
This task has supplemental guidance that should be considered if you are doing an application implementation. Use the following to access the task-specific supplemental
guidance. To access all application implementation supplemental information, use the OUM Application Implementation Supplemental Guide.
SOA Governance Implementation
This task has supplemental guidance that should be considered if you are doing a SOA Governance Implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Governance Implementation supplemental information, use the OUM SOA Governance Implementation Supplemental Guide.
Back to Top
Business Analyst Facilitate the workshop, interviews or meetings. Lead the modeling activity. Record/document the work product.
leaving 80% allocated to the business analyst. The team leader would then facilitate the workshop, interviews or meetings.
100
Ambassador User Provide information about the business organization. *
IS Operations Staff Provide information about existing systems and their operation. *
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.BA.020)
Impact Study and List of Proposed
Organizational Changes
(ENV.GV.040)
Use these Envision work products or similar enterprise-level documents, if available. You may need this information before you
can begin this task. Therefore, if they are not available, you should obtain this information prior to beginning this task.
Project Management Plan (PJM) The client organization charts can be used as a starting point for defining the present organization structures.
(RD.001)
The business objectives might include the need to adapt to organizational changes.
System Context Diagram (RD.005)
Future Process Model (RD.011.1) At a high level, the Future Process Model identifies the business processes and is a useful aid to identify organization units
and other participants.
High-Level Business Descriptions
(RD.020)

Business Use Case Model (RA.015)
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-012_PRESENT_AND_FUTURE_ORG_STRUCTURES.DOC MS WORD
Back to Top
The Present and Future Organization Structures is used in the following ways:
as input to use case modeling
as input to capacity planning
as input to network design
to verify that impacted parts of the organization are participating in the project
Distribute the Present and Future Organization Structures as follows:
Back to Top
QUALITY CRITERIA
Have all of the identified organization units been described?
Has information on locations, headcount and skill sets been recorded?
Has the impact of organizational changes been evaluated?
Do the organization units correspond to organization units defined in the System Context Diagram (RD.005)?
Back to Top
RD.015 - DETERMINE KPI COLLECTION AND REPORTING
STRATEGY
In this task, you review and confirm the project-related business case and business benefits with the client in order to confirm that these are the desired business benefits,
and determine how the projected benefits will be measured. The business case and business benefits, along with appropriate key performance indicators for measuring
progress, should be provided with the solution. In cases where these have not yet been developed for a particular solution or for some reason are not available, it will be
up to the project team to work with the client to define the expected benefits and develop a strategy for measuring the attainment of these objectives and reporting
progress.
ACTIVITY
Back to Top
WORK PRODUCT
Key Business Strategies and Objectives - The Key Business Strategies and Objectives details the business benefits to be derived from the project and the KPIs that
will be used for measuring progress against these strategies and objectives. Use the Key Business Strategies and Objectives to align the project with the key objectives
for which it was undertaken by establishing Key Performance Indicators (KPIs) that will be tracked and monitored throughout the duration of the project.
Back to Top
TASK STEPS
1 Review Business and System Objectives (RD.001). Key
Business
Strategies
This component describes managements key
strategic vision and project direction.
2 Conduct interviews with client executives to pinpoint existing pain points. Key
Business
Objectives
This component highlights the implementation
engagement objectives, projects the estimated
benefits on a year-by-year basis, and
documents associated assumptions.
3 Review existing Documentation for any predefined Key Performance Indicators (KPIs) supported by
the Software being implemented. If available, review the Policy Metrics (ENV.GV.070) and the
Metrics Collection and Reporting Strategy (ENV.BA.017) to verify whether there is a specific
requirement for metrics collection related to your project.
Key
Performance
Indicators
This component describes the Key
Performance Indicators to be tracked,
baseline metrics, targets and associated
calculations.
4 Determine KPI collection and reporting strategy. KPI
Collection
and
Reporting
Strategy
This component describes the method and
means for tracking progress toward the KPI
targets, data sources required, and reporting
format.
Back to Top
APPROACH
This task initiates a series of tasks aimed at aligning the project to the business objectives and key benefits the implementing organization is hoping to achieve through
the implementation.
In this task, you work with the client to identify the target benefits and Return On Investment (ROI) goals expected. Baseline values for the Key Performance Indicators
(KPIs) associated with the Business objectives being implemented are established, as well as target values at the completion of the project. A KPI monitoring strategy
and means of measuring improvement are determined.
Back to Top
Back to Top
Business Analyst The business Analyst will work with the Client Staff Member to confirm the project-related business case and business benefits.
As a result of this collaboration, they will confirm that these are the desired business benefits, and determine how the
projected benefits will be measured.
70
Application/Product
Specialist
The Application/Product Specialist will be able to correlate the functionality of the software, back to the desired business
benefits.
30
Client Staff Member Collaborate with the Business Analyst and the Application Product Specialist to confirm the KPI benefits and their
measurement.
*
User *
Back to Top
PREREQUISITES
Prerequisite Usage
Metrics Collection
and Reporting
Strategy
(ENV.BA.017)
Use this Envision work product, if available. The Metrics Collection and Reporting Strategy should be used as an input to determine whether there
are any requirements relevant for the project for KPI collection. Preferably, the KPI Collection and Reporting Strategy component for the project
should follow the same principles used for the enterprise-level Metrics Collection and Reporting Strategy.
Policy Metrics
(ENV.GV.070)
Use this Envision work product, if available to identify key performance indicators.
Business and
System Objectives
(RD.001)
The Business and System Objectives defines the overriding business objectives and strategic intent of the project.
Present and Future
Organization
Structures (RD.012)
The Present and Future Organization Structures provides a clear understanding of the current and proposed organization structure.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-015_KEY_BUS_STRATEGIES_AND_OBJECTIVES.DOC None
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
Back to Top
RD.020 - OBTAIN HIGH-LEVEL BUSINESS DESCRIPTIONS
In this task, you collect high-level information about how the users conduct their business for those areas under investigation.
ACTIVITY
Back to Top
WORK PRODUCT
High-Level Business Descriptions - The High-Level Business Descriptions is the structured notes of the business information collected in the high-level requirements
definition workshops.
Back to Top
TASK STEPS
1 Prepare the high-level
requirements workshop(s).
None None
2 Conduct and record high-
level requirements
workshop(s).
Workshop
Records
Make sure that all workshops are recorded and archived. The Workshop Records contain a summary of each
workshop.
3 Perform analysis. Business
Descriptions
The information obtained in the workshops is analyzed and organized into the Business Descriptions so that it can be
used as input to use case and domain modeling.
4 Archive drawings and text. Business
Descriptions
The information obtained in the workshops is analyzed and organized into the Business Descriptions so that it can be
used as input to use case and domain modeling or managed at the enterprise level if it is the customer's strategy.
Back to Top
APPROACH
Creating the High-Level Business Descriptions can be accomplished in several different ways. Depending on the size of the solution being developed, you can use
interviews, meetings, workshops, as well as a combination of these methods or a series of meetings and workshops. This task may be one of many tasks being
OUM recommends performing this task by conducting workshops with the users to identify the processes and functions they perform and the data they use in order to
meet their defined business objectives. Developers collect information about the users' concerns, requirements and expectations for the proposed system. Document this
information in a form that can be immediately reviewed and verified by the users. OUM employs a workshop approach to information gathering. This replaces the
traditional techniques of interviewing and presentation. In the workshops, you can use scenario modeling techniques such as story boarding in order to reach a common
understanding of the business processes and how the system supports them. As far as possible, capture data in drawing files and text files that can be stored
electronically.
In a project with a very low project complexity (e.g., 1), this task is optional. This assumes that sufficient information for high-level modeling can be gathered in the
workshops associated with the Future Process Model (RD.011). In a project with a higher project complexity (e.g., 2 or above), this task is mandatory. It is performed
once and is singly instantiated.
When the customer or program has a strategy for reuse, for example, whenever the project is part of a SOA strategy, it is a best practice to manage requirements at the
enterprise (or program) level. In this case, the individual project requirements are pooled together and managed in an Enterprise Repository so that duplication can be
avoided. Requirements that are common to at least two projects are implemented in a reusable fashion, typically as SOA services. For this to work two additional sub-
task steps are required:
1. If requirements are managed at the enterprise level, check for duplicates in the enterprise repository. During requirement analysis (step 3 above), the requirements
are checked against existing requirements in the repository for potential reuse of the components or services that were built to answer this requirement.
2. During requirement archiving (step 4 above), the requirements are checked in the Enterprise Repository for tracking and consumption by other projects. The
requirements should be linked to the enterprise functional, process and/or domain models.
More details about enterprise management of requirements can be found in the Enterprise Requirements Management Technique.
Back to Top
Back to Top
Business Analyst Facilitate the workshop, interviews or meetings. Lead the modeling activity.If a Business Requirements (or other) team leader
has been designated, 20% of this time would be allocated to this individual, leaving 80% allocated to the business analyst. The
team leader would then facilitate the workshop, interviews or meetings.
100
Advisor User Provide information about a particular business process. *
Back to Top
PREREQUISITES
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
business descriptions. Check for existing business descriptions and ensure that the the business descriptions are added/updated in the
repository.
Business and
System Objectives
(RD.001)
The objectives are used to determine the content of the new application.
Future Process
Model (RD.011.1)
The model provides input into the areas where business descriptions are needed.
Back to Top
TECHNIQUES
Technique Comments
Management
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-020_HIGH_LEVEL_BUSINESS_DESCRIPTIONS.DOC
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The High-Level Business Descriptions is used in the following ways:
as input to modeling tasks
to provide definitions for the Glossary
Distribute the High-Level Business Descriptions as follows:
Back to Top
QUALITY CRITERIA
Have all of the issues raised in the workshops been addressed?
Has enough detailed been recorded?
Are all parts of the descriptions mutually consistent?
Can the minimum useable subset of functionality be identified from these descriptions (considering the business and system objectives)?
Back to Top
RD.030 - DEVELOP CURRENT BUSINESS PROCESS MODEL
In this task, you examine the current business processes and practices to identify how the existing business system meets current business requirements. If your project
requires an analysis of current business processes and functions, you should perform this task.
ACTIVITY
Back to Top
WORK PRODUCT
Current Process Model - The Current Process Model includes process flow diagrams of the current business processes and functions.
Back to Top
TASK STEPS
1 Define the scope of current
business analysis.

2 Review the High-Level
Business Descriptions
(RD.020).

3 Review any current business
materials that may enhance
team understanding of the
current business processes.

4 Develop, schedule, and
confirm the process
definition sessions.

5 Produce a high-level current
process view of the entire
organization.
Enterprise
Process
Model
This component prepares a high-level context diagram showing the major business process areas or core processes
and the information flows between them. A core process is a process essential to the running of the organization and
provides added value to the output produced (such as procurement or order fulfillment).
6 Identify and describe the
events to which the current
business processes
respond.
Event
Catalog
This component lists all of the events the business responds to; each event has a name, a brief description, frequency,
and conditions under which it occurs. These may be external events (a customer order), internal events (the
completion of production), or temporal events (end of month).
7 Conduct workshops to build
each existing core process
model one diagram per
core business process.
Core
Process
Models
This component constructs a process flow model showing the activities in the process for each core process, as
identified in the enterprise model. Each core process should be at a lower level of detail, generally corresponding to
levels 2 and 3 as described in the Functional or Process Modeling Technique.
8 List existing business
performance measures.
Performance
Measures
This component lists the performance measures used to measure current process performance for each core process.
9 Conduct business process
analysis meetings to further
define relevant existing
business processes.

10 Construct process flow
diagrams for each relevant
existing business process.
Process
Flow
Diagrams
Process
Step
Catalog
If process models/business flows exist for the current system, they should be used as a starting point for preparation of
the Process Flow Diagrams component of this work product. Whenever possible, use existing models of the current
business process rather than recreate them from scratch.
The Process Step Catalog lists the process steps that make up the process. Each step should have a brief, descriptive
title and represent an elementary business function. The process step catalog should also record the agent responsible
for the execution of each step, and classify each step by desired degree of automation: manual, computer assisted, or
fully automated. If desired, you can use procedure documentation software such as Oracle Tutor to assist with this
component.
11 Identify any issues from
current business analysis.

12 Review the Current Process
Model with users and
management.

13 Secure acceptance of the
Current Process Model.

Back to Top
APPROACH
Prepare the Current Process Model based on information collected during process definition sessions with the business area owner. Benefits of this exercise include the
opportunity to recognize potential process improvements by capitalizing on the new application functionality and the ability to establish a current business benchmark
against which to gauge the ultimate success of the new business model.
Process Flow Diagramming
Process flow diagramming supports the analysis of current business processes by:
clearly communicating the current business processes
allowing analysts to document the current business in a structured way
facilitating business requirements mapping to the applications
Develop process flows for the current business system, not the current set of applications (commonly called the system) used to run the business. The current business
System (big S) represents how a business runs, the formal and informal systems, processes, and procedures that are in place. The set of applications or system
(little s) are merely the tools/formal mechanism where data are transformed into useful bits used for making business decisions and providing information.
Current business process models may be created in several ways. If the organization has existing process models they developed internally, you may be able to use
them. Review them for suitability without modification, or possible further development. If no process models exist, consider starting with generic business flows and
tailoring them to your business, or build them from scratch. The important thing to remember is that they represent the way the business processes are running today.
Form is less important than substance.
Review and Signoff
As each process team completes its current business baseline, you should review it with the project team, area users, management, and any cross-process integration
teams.
Back to Top
Back to Top
Business Analyst Facilitate the development of the Current Process Model. 100
Business Line Manager *
Project Sponsor *
User *
Back to Top
PREREQUISITES
Prerequisite Usage
Business and System
Objectives (RD.001)
When process change is applicable, use the high-level enterprise model to determine the core processes to be modeled in this task.
High-Level Business
Descriptions (RD.020)

Current Business Baseline
Metrics (RD.034)
The project team uses structured process questionnaires as another process analysis technique to collect business and current system
information during a business baseline interview for a given process.
Skilled Project Team
(TR.050)
The Skilled Project Team has learned modeling and mapping techniques.
Existing Reference Material The project team uses existing reference material to gain an understanding of the existing practices, processes, and systems that
support the business objectives.
Back to Top
TECHNIQUES
Technique Comments
This technique provides assistance in utilizing business process models as a requirements gathering technique and describes the
different levels of business process models.
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-030_CURRENT_PROCESS_MODEL.DOC MS WORD
Tool Comments
processes.
Example Comments
Current Process Model
Back to Top
The Current Process Model is used in the following ways:
to reflect a common understanding of your existing business processes
to gain understanding of the integrated current business requirements
Distribute the Current Process Model as follows:
to all team members
Back to Top
QUALITY CRITERIA
Does the Current Process Model address business events to which the organization responds?
Does it provide a high-level model of enterprise processes?
Does it provide detailed process flow diagrams of current business processes?
Does it provide a detailed listing of process steps performance measures?
Back to Top
RD.034 - DEVELOP CURRENT BUSINESS BASELINE METRICS
The purpose of this task is to capture specific business performance baseline metrics against the current business processes. This allows the business to measure
subsequent business performance changes against the baseline. For example, the Marketing Campaign Approval process may be a key area that the new system
should improve upon. Therefore during this task, the current elapsed time to approve a new Marketing Campaign is captured. As the project progresses through its
lifecycle, additional measurements can be taken, ultimately culminating in post go-live metrics and an evaluation of overall specific business performance improvement. If
your project includes an emphasis on measuring and tracking progress towards improvement of key performance indicators (KPIs) or requires an analysis of current
business processes and functions, you should perform this task.
ACTIVITY
Back to Top
WORK PRODUCT
Current Business Baseline Metrics - The Current Business Baseline Metrics provides specific performance metrics of selected business processes.
Back to Top
TASK STEPS
1 Review the Key Business Strategies and Objectives (RD.015).
2 Review the Current Process Model (RD.030).
3 Identify specific process steps that can be used to capture a performance
baseline. Identify process steps that are strategic in nature, and are suitable
for measurement.

4 Determine the frequency of metric capture. Metric Capture
Milestones
The Metric Capture Milestones define the milestones at which
point the metrics will be re-captured (i.e., at the end of each
project phase).
5 Capture baseline metrics. Current Business
Performance
Baseline
This component either physically, or systematically, captures
the metrics.
Back to Top
APPROACH
For projects where there is a focus on business performance improvement, it is critical to capture a baseline. Without a baseline, any business performance improvement
(or degradation) becomes very subjective.
When considering which process steps to capture a baseline against, it is important to consider the overall objectives of the project. For example, if an automated
inventory picking system is being implemented, there may be little value in baselining the time it takes to enter a Purchase Order. On the other hand, if an electronic
Purchase Order Approval process is being implemented, it would be appropriate to baseline the current manual approval process time.
It is also important to agree with the client the frequency of subsequent metric capture points. For example, it may be appropriate to capture a Purchase Order approval
baseline, plus another measurement just prior to go-live, and once more after go-live.
You should agree with the client the methodology for recording the current business performance baseline, i.e.,
the client may already well established KPIs which you can use
you may need to physically record the time it takes to perform a process
you may need to count the number of Sales Orders, Purchase Orders, New Hires, Customer Calls etc per hour
Back to Top
#TOP
Back to Top
Business Analyst Facilitate the Business Requirements Workshop, interviews or meetings. 100
Business Line Manager Select the business processes that should be baselined. *
Project Sponsor Provide business context information about the process being modeled. *
User *
Back to Top
PREREQUISITES
Prerequisite Usage
(PJM)
The team uses the Project Management Plan to further clarify the scope of the project.
Current Baseline Metrics
(ENV.BA.018)
Use this Envision work product, if available. The Current Baseline Metrics should be used as an input to to your baseline metrics
calculation. Preferably, the Current Business Baseline Metrics should follow the same principles used for the enterprise-level Current
Baseline Metrics.
Present and Future
(RD.012)
The Present and Future Organization Structures provides a clear understanding of the current and proposed organization structure.
Key Business Strategies
and Objectives (RD.015)
The Key Business Strategies and Objectives details the business benefits to be derived from the project and the KPIs that will be used for
measuring progress against these strategies and objectives.
(RD.030)
Use the Current Process Model to identify steps within a process that can be used to capture business a performance baseline.
Existing Reference
Material
The project team uses existing reference material to gain an understanding of the existing practices, processes, and systems that support
the business objectives.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-034_CURRENT_BUSINESS_BASELINE_METRICS.DOC MS WORD
Back to Top
The Current Business Baseline Metrics is used in the following ways:
to capture specific business performance metrics before the implementation of any system changes
to encourages the project to focus on generating real improvements to strategic business processes
Distribute the Current Business Baseline Metrics as follows:
to all team members
Back to Top
QUALITY CRITERIA
Is the current business process documented in a clear, concise and unambiguous manor?
Have any supplemental business requirements or improvement opportunities been captured?
Back to Top
RD.042 - DEVELOP GLOSSARY
In this task, you document the definitions of the terms that are used in the business or application, and other terms that appear in the work products. This is an ongoing
task that is performed as needed over the course of the project as you go from an initial Glossary to a final Glossary.
ACTIVITY
RD.042.1
RD.042.2
RD.042.3
Back to Top
WORK PRODUCT
Glossary - The Glossary is a list of definitions, with cross-references to other definitions. This list is used as a reference when developing models, components and
documentation, and helps to make sure that the terminology used throughout the system is both consistent and meaningful to end users.
Back to Top
TASK STEPS
1 Develop Glossary Definition List The Definition List contains all business terms used in the business area addressed by the project.
Back to Top
APPROACH
This task is mandatory and is ongoing throughout the Inception phase. Optionally, it might be instantiated in the Elaboration and Construction phase. Document system
and business terms as they appear, and make them available in a medium available for everyone involved in the project (for example, on a project site).
If your engagement is producing documentation, you may want to incorporate the Glossary, in part or total, in some or all of the Documentation work products.
Back to Top
Back to Top
Business Analyst Develop the Glossary. 100
Ambassador User Provide information about business terms. *
IS Support Staff Provide information about system terms. *
Back to Top
PREREQUISITES
RD.042.1
Prerequisite Usage
Enterprise Glossary (ENV.BA.030) Use this Envision work product or a similar enterprise-level document, if available.
Business and System Objectives (RD.001)
Future Process Model (RD.011)
High-Level Business Descriptions (RD.020)
Current Process Model (RD.030)
(RD.034)
Supplemental Requirements (RD.055)
Domain Model (RD.065)
While defining these work products, there may be terms that need a definition. These should be included in the
Glossary.
RD.042.2
Prerequisite Usage
Glossary (RD.042.1) Expand/update the initial glossary with new and redefined definitions.
Reviewed Use Case Model
(RA.180.2)
Reviewed Analysis Model
(AN.110.2)
Reviewed Design Model
(DS.160.2)
While retrieving, detailing, analyzing and designing requirements, new terms may come up that need a definition. These are included in
the glossary with an appropriate definition.
RD.042.3
Prerequisite Usage
Glossary (RD.042.2) Expand/update the revised glossary with new and redefined definitions.
Back to Top
TEMPLATES AND TOOLS
RD-042_GLOSSARY.DOC MS WORD
Back to Top
The Glossary is used in the following ways:
to maintain consistency of terminology
as an explanation of terms to all project members
as a reference for the development of components
as a reference for the documentation team
Distribute the Glossary as follows:
to all project team members (for example, as a dynamic, electronic document)
Back to Top
QUALITY CRITERIA
Have all of the identified terms been explained with a proper definition, preferably with examples?
Back to Top
RD.045 - PRIORITIZE REQUIREMENTS (MOSCOW)
In this task, you produce a prioritized list of requirements by the business (both functional and supplemental). MoSCoW provides a method for focusing on the relative
importance of requirements. The acronym MoSCoW stands for:
Must Have - critical requirements without which the system cannot function. They are fundamental to the system. The requirements define the minimum
usable subset and are within the scope of the contract.
Should Have - requirements that are important but not critical to the system. In a less time-constrained development, these requirements would be
mandatory. The Should Have requirements can be sacrificed if development of Must Haves or Should Haves takes more effort than estimated. In most
contracts, this is the lowest category level of in-scope requirements.
Could Have - requirements that are desirable but which could be left out of the increment under development. More Could Have requirements can be
delivered if development of Must Haves and Should Haves takes less effort than estimated. In most contracts, this is the first category of out-of-scope
requirements.
Won't Have - requirements that are valuable but which will not be delivered by the increment under development. These requirements are out-of-scope.
In order for the task to be successful, there must be "buy-in" from the project sponsor on this method of categorization. Once completed, this list drives development and
sets expectations. In most projects, when you start the project, the Must Haves and Should Haves are within scope and the Could Haves and Won't Haves are out of
scope. This is an ongoing task that is performed as needed as requirements are refined over the course of the project.
In a commercial off-the-shelf (COTS) application implementation, ensure that all gaps identified in RD.005, RD.011, RA.085, MC.090 and RA.160 are entered into the
MoSCoW List for further analysis.
ACTIVITY
RD.045.1
RD.045.2
RD.045.3
Back to Top
WORK PRODUCT
MoSCoW List - The MoSCoW List is a combination of a prioritized Actor-Goal List and a prioritized list of the high-level requirements valid for the application system that
is being developed.
Back to Top
TASK STEPS
1 Prepare workshop. None None
2 Formulate top-level
requirements.
Actor-Goal List
List of
Supplemental
Requirements
The high-level requirements has two sections, one for functional requirements -- the Actor-Goal List, and a second for
the supplemental requirements -- List of Supplemental Requirements.
3 Convene workshop. None None
4 Categorize each top- Prioritized The Prioritized Requirements List contains the high-level requirements (Actor-Goal List and List of Non-Functional
level requirement. Requirements List Requirements), divided into the four categories (Must Have, Should Have, Could Have and Won't Have).
Back to Top
APPROACH
Requirements Baseline
In OUM, requirements are baselined at a high level. These requirements are both functional and supplemental. At this level, the functional requirements are defined
through an Actor-Goal List, preferably at the user-goal level (sea-goal-level).
Baselining of requirements means freezing and agreeing on the purpose and scope of the system at a level that allows for detailed investigation of what the requirements
imply. The MoSCoW method is a good tool to indicate what is inside or outside scope, and therefore, the MoSCoW List often becomes a part of the contract. In most
projects at this level, the scope is defined through the Must Have and Should Have requirements, while the Could Have and Won't Have requirements are outside scope.
The Could Haves are out-of-scope but are strong candidates of being included. The Should Haves are in-scope, but could possibly be excluded.
When the project moves into the Elaboration phase, you also use these priorities to determine on which use cases to start. The Should Haves are not as important as the
Must Haves and may not even be considered during the Elaboration phase.
This classification makes our understanding explicit as soon as project progress changes. New functionality can appear and be prioritized as necessary while other initial
requirements turn out to be less important. However, be aware that the process of taking Should Haves out of scope to leave room for new functionality or swapping
some Should Haves and Could Haves is not a straightforward process. The project manager should take care of these kind of changes (at this top-level) as in any other
change of scope. It is only possible to change scope if there is no additional costs. Impact analysis and an evaluation of effort already spent must be carefully considered.
For example, many tend to think, that you can always substitute one use case (UC1) classified as easy by another use case (UC2) that is also classified as easy. This is
possible at the beginning of a project where no effort has been performed on the UC1. However, assume that we are at the beginning of the Construction phase. We
have already spent effort in Business Requirements, Analysis and Design for UC1, therefore, this used effort must be considered when studying the substitution. Instead
of comparing the initial estimate, compare the remaining estimate of UC1 with the total estimate of UC2. Also, the inclusion of UC2 may bring additional risks or changes
to the project that were not initially considered. Therefore, when you consider swapping functionality:
Consider all the impact of this change (used and remaining effort, risks, impacts on what has already been done).
Use all the control of a Change Request. Every change has to be recorded, and considered. Using the MoSCoW List does not necessarily illuminate a change in
the project cost. Without formalizing it, you risk being asked to complete the original project scope.
Decide to make the change as early as possible in the project. As you advance in the project, more work is completed and seemingly equal changes are no longer
equal.
The ultimate MoSCoW List should be a mutually exclusive and completely exhaustive set of functional and supplemental requirements. Each requirements should relate
to at least one of the objectives stated in the Business and System Objectives (RD.001). When this list is completed and agreed upon, it should be used as a basis for
estimating. If your project was estimated at an earlier point of time, re-estimate at this point of time to limit risks related to discrepancies between the initial and current
estimate.
Supplemental Requirements List
In this task, make a list of the supplemental requirements where each requirement is about a one-line phrase. This makes it easier to see all the requirements as a whole
when prioritizing them. The supplemental requirements are defined in detail in the task, Detail Supplemental Requirements (RD.055) task.
For large projects, it is recommended that Supplemental Requirements be captured using an Enterprise Repository. The work product for this task (MoSCoW List)
includes a sheet that can be used to capture the non-functional requirement for small projects.
Actor-Goal List
Before starting to prioritize requirements, you need to identify the goals that should be prioritized. You do this by creating an Actor-Goal List. Use facilitated workshops for
the creation of the Actor-Goal List. However, there may be projects where this is difficult because you cannot gather all the ambassador users in the same room at the
same time. If this is the case, you may need more time to complete the list and get it reviewed and accepted. There may also be small projects where a facilitated
workshop is too formal because there are only a few stakeholders. In this situation, a smaller workshop/meeting (without a facilitator) would work.
Prepare the workshop by reviewing the current material available, in particular, the Future Process Model (RD.011) and the Business Use Case Model (RA.015). Use
these to identify candidate actors and goals that should be included in the Actor-Goal List. Many of these goals will be on kite or cloud level, but will be useful to help
identify sea-level goals. Ensure that the participants receive this information prior to the workshop, including the objectives for the workshop itself.
While you identify the goals, try to identify to which level they belong. Do not go into too much detail. All goals on sea-level and above should be documented, but any
goals on a lower level should not get any focus during this activity (naturally, if identified, the scribe should make a note of any goals identified, but there will be no further
focus on them during the workshop). The primary objective is to identify all the sea-level goals.
At the end of the exercise, turn your approach upside down, and have a look at each actor to see if there are any missing user goals. If so, add these goals to the list.
Prioritized Requirements
After having identified the complete Actor-Goal List, start prioritizing the goals. Dependent of the size of the system (and the number of participants), you can either take
the prioritization as a second part of the same workshop, or conduct another workshop for the prioritization. You may even decide to combine it with the use case
workshop, but it all depends on the size of the system to develop, the number of participants, and the available time for the workshop.
An effective approach for prioritizing is to write all the user goals on large pieces of paper (typical flip-over pages), and place them on the wall in the workshop room.
Ensure that you have a good understanding of each requirement. Write a short description for each (if possible a use case brief or a casual-dressed use case) and send
the information to the participants prior to the workshop so that they can be prepared. If you decide to use a single workshop for both identifying and prioritizing the goals,
walk through each goal with the participants to ensure that everyone understands each goal. If there are too many goals to work with at the same time, group them into
logical areas (possibly by kite or cloud level), and work through them group by group.
Decide on the prioritizing technique you want to use during the workshop. One effective technique is to give every participant a number of points (for example 80 points)
which they can distribute among the requirements as they like, with the idea that they give the requirement they think is the most important, the most points. Afterwards
summarize all the points and conclude which requirements they think are the most important. Afterwards, talk through the result, and based on the discussion, make any
necessary changes. Perform a similar exercise for all the supplemental requirements. You may decide to do that in a separate workshop, as you may need
different/additional participants.
You now have a list of top-level functional and supplemental requirements with the most important (highest sum of points) requirements at the top. Now determine where
the line goes between the Must Have requirements and the Should Have requirements. Make the participants understand that there is more damage in setting non-critical
requirements as Must Haves than making everything Must Have. The whole point of prioritizing is to make certain that the most important requirements are delivered first,
so that, if for some reason you are not able to deliver everything, you have at least delivered the requirements that are most important. Try to have them limit the number
of Must Haves so that they can think about their true business priorities.
In addition, sub-prioritize the Should Have requirements so that when all the Must Have requirements are delivered, we know which Should Have requirement are the
most important. This is just a numbered list, 1, 2, 3, etc. Also do this for the Could Have requirements.
Prioritizing After Inception
The MoSCoW List is initially created in the Inception phase, but this does not mean that you do not continue prioritizing further into the project. In fact, you use priorities
throughout the project. You indicate priorities for each use case defined. However, all the detailed requirements should be related to the requirements given in the
MoSCoW List.
You may decide to format the MoSCoW List into two levels; the highest level indicating the goals on cloud and kite level, and the next level below indicating the goals on
the sea-level. You must at least include the sea-level, the level above is optional. The sea-level is used for estimating, but in some projects, you do not have this kind of
detail at the start of the project. In those situations, you often have to estimate on cloud and kite-level goals. If that is the case, re-estimate when you get the sea-level
goals to minimize risk. If you have included goals at cloud/kite level, this level, in most situations, remains fairly stable.
As the project moves forward, the sea-level goals defined on the MoSCoW List are related to a use case, which again contains a number of more detailed goals (fish
level goals) that again gives us subfunction use cases At this point, priorities are specified on the use cases. This makes it easier for anyone picking up a use case to
see the actual priority. However, as a tool for the project manager, it is also useful to have a mechanism to see the picture as a whole. Provide an overview of all the
priorities given for the use cases on the different levels. This overview with detailed priorities (a detailed MoSCoW List) is a very useful tool to keep track of the overall
scope and business objectives.
When the customer or program has a strategy for reuse, for example, whenever the project is part of a SOA strategy, it is a best practice to manage requirements at the
enterprise (or program) level. In this case, the individual project requirements are pooled together and managed in an Enterprise Repository so that duplication can be
avoided. Requirements that are common to at least two projects will be implemented in a reusable fashion, typically as SOA services.
Because of this level of reuse across project, inter-dependencies across projects will arise and it is very important for the people carrying out this task to understand the
that the project lives in the context of the enterprise. For example it may be that a Could will become a Must because it is foreseen that other projects will require the
same functionality.
You normally use the Enterprise Repository for tracking project interdependencies and all requirements should be recorded there for this purpose. Any change in
requirements, such as estimated go-live date of the corresponding implementation should also be updated in the repository as it occurs. As such, the requirements
identified in other tasks (such as, RA.023, Develop Use Case Model) will normally already be in the repository and linked to enterprise functional, process or domain
models when you start this task. As such, the Enterprise Repository could be your main input to the requirements for this project.
More details about enterprise management of requirements can be found in the Enterprise Requirements Management technique.
MoSCoW Traceability
When there is no Enterprise Repository in use, the MoSCoW List MS EXCEL work product may be used for traceability of requirements. This is not advisable for projects
of any substantial size or complexity, as the effort to maintain this traceability is purely manual and prone to human error. Please refer to the instructions included within
the MoSCoW List MS Excel work product for details on how to maintain manual requirements traceability for small projects.
The MoSCoW List template contains additional sheets that can be used to link the MoSCoW high-level requirements to the use cases that satisfy the functional
requirements and the COTS (Commercial-Off-the-Shelf) software that satisfy the resulting functional requirement.
Subsequent spreadsheets in the MoSCoW List MS Excel work product can be used to provide traceability to other artifacts that help trace the requirement through to the
end of the project where it they are validated through testing. These other worksheets may also be used to assess the impact of change throughout the life of the project.
Scrum
When using a Scrum approach, first read Managing an OUM project using Scrum and Planning a Project using OUM - An Iterative and Incremental Approach white
papers.
There are two worksheets in the MoSCoW List MS Excel work product that can be used in your Scrum project to manage the requirements and priorities. They are the
Product Backlog and the Sprint Backlog. Refer to the detailed notes within the work product template for instructions on how to use each of these worksheets.
Back to Top
Back to Top
Business Analyst Facilitate the workshop, interviews or meetings. Lead the prioritizing activity.
100
Ambassador User Provide information about the business organization. *
Back to Top
PREREQUISITES
RD.045.1
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
requirements. Use the Governance Implementation to prioritize the requirements from in the repository.
MoSCoW
Improvement List
(ENV.ER.130)
Use this Envision work product or a similar enterprise-level document, if available. You may need this information before you can begin this task.
Business and
System Objectives
(RD.001)
The Business and System Objectives should themselves be prioritized to indicate which objectives are the most important for the company. Then
these prioritized Business and System objectives are used to determine how the priorities should be set for the identified functionality.
Functionality that supports the most important business/system objectives should most naturally get the highest priority.
System Context
Diagram (RD.005)
Future Process
Model (RD.011)
Domain Model
(RD.065)
These models identify areas that need to be prioritized.
High-Level
Business
Descriptions
(RD.020)
The High-Level Business Descriptions identify the areas that should be prioritized.
Business Use Case
Model (RA.015)
The Business Use Case Model identifies the key use cases for the new system. This helps identify the Actor-Goal List that should be prioritized.
Supplemental
Requirements
(RD.055)
The Supplemental Requirements identify the supplemental requirements that must be prioritized.
Data Acquisition
and Conversion
Requirements
(CV.010)

RD.045.2
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
MoSCoW List (RD.045.1) Update the initial MoSCoW List, as appropriate.
RD.045.3
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
MoSCoW List (RD.045.2) Update the initial MoSCoW List, as appropriate.
Back to Top
TECHNIQUES
Technique Comments
2 x 2 Urgency Importance Matrix Use this technique to prioritize items on the MoSCoW List.
Pair-Choice Priority
This technique provides guidance in prioritization. It includes an MS Word template that can be used to
assist in prioritization.
Risk Portfolio Assessment Use this technique to prioritize items on the MoSCoW List.
Enterprise Requirements Management Use this technique to understand how to manage requirements at the enterprise level.
Managing an OUM project using Scrum Use this technique to understand how to manage an OUM project using the Scrum approach.
Planning a Project using OUM - An Iterative and
Incremental Approach
Use this white paper to understand how to plan a project using OUM.
Back to Top
TEMPLATES AND TOOLS
RD-045_MOSCOW_LIST.XLS MS EXCEL - When there is no Enterprise Repository in use, the MoSCoW
List MS EXCEL work product may be used for traceability of requirements.
You may choose to use just the MoSCoW sheet of the workbook as a
MoSCoW List in MS EXCEL format.
Scrum: When using a Scrum approach, use the Product Backlog and
Sprint Backlog sheets. Refer to the detailed notes within the work product
template for instructions on how to use each of these worksheets.
RD-045_MOSCOW_LIST.DOC MS WORD - You may choose to use just the MoSCoW List in MS WORD
format.
GENERIC_WORKSHOP_NOTES.DOC MS WORD
GENERIC_WORKSHOP_SCHEDULE_AND_WORKSHOP_PREPARATION_NOTES.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.
Example Comments
RD-045_MOSCOW_LIST_EXAMPLE.XLSX MS EXCEL - Ski-NOW Case Study Example
Back to Top
The MoSCoW List is used in the following ways:
as detailed requirements are introduced during development, they must be related to at least one of the requirements in the high-level baseline (If they cannot be
related to the baseline, they are out-of-scope, but may be placed in the Won't Have category.)
Distribute the MoSCoW List as follows:
to the visionary, project sponsor and other steering committee members
Back to Top
QUALITY CRITERIA
Have all of the currently identified requirements been prioritized?
Have all the priorities been assigned in collaboration with the ambassador users?
Does the sponsor and senior management agree that that no solutions will be delivered to Won't Have requirements (in this increment)?
Does the sponsor and senior management agree that solutions to some requirements might not be delivered (in this increment)?
Can all requirements be related to at least one business or system objective?
Are the priorities given for requirements consistent with the business and system objectives?
Are all the Must Have requirements truly part of the minimal usable subset for the new system? (That is, if you remove just a single one of the Must Have
requirements, the system cannot be delivered.)
Back to Top
RD.055 - DETAIL SUPPLEMENTAL REQUIREMENTS
In this task, you detail the list of supplemental requirements related to the system. Supplemental requirements (aka supplementary, non-functional and Quality of Service
requirements) are not commonly captured by use cases and generally revolve around usability, reliability, performance and supportability.
While a supplemental requirement may be related to a specific use case and can be documented with that use case, a supplemental requirement, by itself, does not
require detailing in a use case. Examples are legal and regulatory requirements, application standards, performance requirements, interface requirements, and physical
design requirements, monitoring and reporting the system health, etc. However, a supplemental requirement can also contain business rules and other relevant business
information about what the application should provide. Business rules are declarations of policy or conditions that must be satisfied by the system. If you discover any
business rules, you should collect them as an input to the Identify Candidate Business Rules (RA.027) task.
ACTIVITY
Back to Top
WORK PRODUCT
Supplemental Requirements - This work product contains the list of supplemental requirements for the new system under development. The main goal of this work
product is to capture supplemental requirements. Each requirement is detailed as exactly as possible, including constraints and conditions. These requirements can later
be applied to the use cases developed in Develop Use Case Details (RA.024).
Back to Top
TASK STEPS
1 Prepare supplemental
requirements workshop.
None None
2 Conduct supplemental
requirements workshop.
None None
3 Summarize supplemental
requirements workshop
Supplemental
Requirements
The Supplemental Requirements is a list with all the supplemental requirements for the new system to be developed.
Each requirement is detailed as exactly as possible, including constraints and conditions.
Back to Top
APPROACH
Supplemental Requirements Workshop
In preparation for the supplemental requirement workshop, review all contract documents to verify whether there are any supplemental requirements, and if so, note them
in the preparation material. The supplemental requirements workshop should be conducted to identify all generic supplemental requirements, including constraints and
conditions under which they apply.
As a starting point, you should look at the Project Charter or Statement of Work to identify supplemental requirements that were stated in writing at the time of project
initiation.
Supplemental requirements related to specific use cases are documented with the use cases, and in some situations, these requirements are identified during the
workshop. Although it is not the objective to identify these specific supplemental requirements at this point of time, these specific requirements may relate to higher level
generic requirements (for example, a generic performance requirement "no page should take longer than x seconds to open). However, some supplemental requirements
can not be detailed with specific use cases (for example, maintenance requirements for the final system).
During the workshop preparation, identify areas that may yield supplemental requirements. For example, think about factors that may be a result of the kind of
organization, current technology and chosen products.
The Supplemental Requirements should be reviewed after the Use Case Details (RA.024) have been developed for the use cases in each iteration group during the
project. During use case development, the examination of the Context of Use in the Use Case Details (RA.024) may identify some supplemental requirements related to
the frequency of use and volume of data accessed by an individual use case. This information should be captured in the Supplemental Requirements, and then
monitored as part of overall Performance Management.
Back to Top
Back to Top
Business Analyst Consolidate requirements into a single Supplemental Requirements document.
leaving 60% allocated to the business analyst. The team leader would then assist in the consolidation of the requirements into
a single Supplemental Requirements document.
80
System Architect Help consolidate requirements into a single Supplemental Requirements document. 20
Ambassador User Help consolidate requirements into a single Supplemental Requirements document. *
Back to Top
PREREQUISITES
Prerequisite Usage
Requirements (ENV.ER.100)
Architecture (ENV.EA.110)
Future State Transition Plan
(ENV.ER.170)
Use these Envision work products or similar enterprise-level documents, if available. You may need this information before you can
begin this task. Therefore, if they are not available, you should obtain this information prior to beginning this task.
(PJM)
The Project Management Plan may contain supplemental requirements that can be used as an input to the Supplemental
Requirements.
Business and System
Objectives (RD.001)

(RD.030)

Future Process Model
(RD.011)

Domain Model (RD.065) The Domain Model can be a useful aid to determine business rules.
Back to Top
TECHNIQUES
Technique Comments
Enterprise Requirements Management Use this technique to understand how to manage requirements at the enterprise level.
Back to Top
TEMPLATES AND TOOLS
RD-045_MOSCOW_LIST.XLS MS EXCEL - Use the RD.055 Supplemental Requirements worksheet in the MoSCoW List MS Excel work product (RD.045) to
document these supplemental requirements on projects where there is no Enterprise Repository being used.
Tool Comments
Repository.
Back to Top
The Supplemental Requirements is used in the following ways:
to capture supplemental requirements and business rules.
Distribute the Supplemental Requirements as follows:
Back to Top
QUALITY CRITERIA
Back to Top
RD.065 - DEVELOP DOMAIN MODEL (BUSINESS ENTITIES)
In this task, you construct a high-level model of the objects/components needed to satisfy the solution objectives. The Domain Model is a conceptual model. It is not a
model of software, but a model of the information that exists in the problem domain. The main purpose of the Domain Model diagram is to capture concepts and identify
relationships. In OUM, the Domain Model may also be used to capture and communicate overall data requirements.
The standard and recommended approach and notation for completing this task is to use a UML class diagram. This task may also be accomplished using a non-UML
approach that uses other notational or textual techniques including entity-relationship diagrams (ERDs) or data tables. If object-oriented analysis and design techniques
are going to be used to complete the design for custom software components, a class model is strongly recommended.
In a commercial off-the-shelf (COTS) application implementation, this task is generally performed only when there is a need to gain further clarification of the business
requirements represented in the use cases. This typically applies to those requirements that can only be satisfied through custom-built components, which extend the
functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems.
ACTIVITY
Back to Top
WORK PRODUCT
Domain Model - The Domain Model typically captures conceptual classes and their associations. Association rules (e.g., one-to-one, one-to-many) may or may not have
their multiplicity's specified. The model may contain attributes, if they are significant, but they do not need to be typed. Operations would not be used since the emphasis
of the model is to capture domain knowledge, not to synthesize it or normalize it.
Back to Top
TASK STEPS
1 Prepare
domain
modeling
workshop.
Workshop
Preparation
Materials
Before you begin this step, you should determine if there is an enterprise-level Domain Model available. Also, if use cases are available,
they can be examined to contribute to the initial Domain Model. If the projects involves consolidating data from a number of sources,
then the data model for those source systems should be examined as an input to this task. These materials can be used as input to a
workshop or meeting to confirm the data requirements for your project.
2 Conduct
domain
modeling
workshop.
Workshop
Presentation
Materials
None
3 Summarize
domain
modeling
workshop.
Domain
Model
The Domain Model consists of the Class Diagram containing the most important classes within the context of the domain, including a
definition for each class.
Back to Top
APPROACH
This task is singly instantiated (in each increment). The work product is not revised. Further domain modeling continues in the Analysis process where the class model is
further detailed. If you run your projects in more parallel partitions, it is recommended that each domain is owned by one and only one partition. This can be recorded in
the class notes. Before you begin this task, you should determine if a Domain Model exists for the enterprise. You may need to call upon an object designer to resolve
any conflicts that arise between teams concerning the definition of shared domains.
In most cases, the detailed Domain Model is produced using a class diagram. UML class diagrams support all of the constructs of an entity-relationship diagram, but also
are able to be augmented to add behavior to the objects during Analysis and Design. For very small business domains, it may be sufficient to produce only a list of the
domains and their definitions.
You should use a UML class diagram to represent the Domain Model, but it is important to note that it is a software-independent model. You can use a concept
stereotype for every class in this model, but from a packaging point of view, it is kept under the Business Requirements models.
Domain modeling is most effectively done through one or more workshops (depending on the project size).
Preparing for the Workshop
Creating the Domain Model can be accomplished in several different ways. Analyzing the use cases to determine all the various objects/components and their
relationships and constructing a Domain model is one way to accomplish this task. Another technique is to elicit these data requirements during a meeting or workshop.
Depending on the size of the solution being developed, you can use interviews, meetings, workshops, as well as a combination of these methods or a series of meetings
and workshops. This task may be one of many tasks being addressed in a meeting or workshop that is being held to gather business requirements.
Take the material you have collected from previous workshops to identify an initial set of domain objects. In particular, use the Business and System Objectives (RD.001)
and the High-Level Business Descriptions (RD.020) as a starting point for planning the workshop, but be certain you include a section in the agenda to verify whether you
have missed any areas. The workshop participants should be a combination of domain experts from the client, as well as people who are skilled in object modeling.
Conducting the Workshop
Start the workshop by prioritizing the domains so that the most important domains are modeled first. Walk through each domain to identify the main objects for the
domain. Identify the main relationships between the objects as well as the key attributes. The main objective for this activity is to get enough detail to understand the
context of the domain and to understand the problem that the system is supposed to solve. Therefore, make certain you do not start modeling the internals of the system,
but remain at a context level.
Summarize the Workshop
After the workshop, make sure that all the notes are captured, and that you update the Domain Model to reflect the decisions made during the workshop. Ensure that all
the objects, and identified attributes get a proper description. This is important as it helps everyone use a common terminology. This serves as an input to the Glossary
(RD.042).
For a strategic SOA project or whenever requirements are managed at the enterprise level for the purpose of reuse, you should also check whether there is some
potential duplication with existing entities and thus potential reuse of data services or components. In addition, you may have to update the enterprise data model with
any new or modified entity that you may have identified.
If requirements have been identified during this task, they should also be recorded in the Enterprise Repository and each of them linked to an element at one of the levels
in the model, i.e., either an entity or a data source, etc. More details about enterprise management of requirements can be found in the Enterprise Requirements
Management technique.
The Enterprise Repository, if one is used, is also a good source of information for preparing the workshop. It may contain the Enterprise Domain Model (ENV.BA.050)
that may contain most of the entities required for this project.
Back to Top
Back to Top
Resolve any conflicts that arise between teams concerning the definition of shared domains.
Business Analyst Develop the Domain Model. 100
Designer Advisory
Ambassador User Provide information about domain objects related to the business. *
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Domain
Model
(ENV.BA.050)
Use this Envision work product or a similar enterprise-level document, if available. You may need this information before you can begin this task.
Governance
Implementation
(ENV.GV.100)
Domain Model and business entities. Check for existing business entities and ensure that the the Domain Model and business entities are
Business and
System Objectives
(RD.001)
The objectives are used to identify the domains that should be covered by the project.
High-Level
Business
Descriptions
(RD.020)
The business descriptions identify the required business objects and their relationships.
Back to Top
TECHNIQUES
Technique Comments
Management
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RD-065_DOMAIN_MODEL.DOC MS WORD
Example Comments
Domain Model
Tool Comments
Class Diagram Viewlet JDeveloper
Getting Started with UML Class
Modeling
JDeveloper
Back to Top
The Domain Model is used in the following ways:
to communicate the developers' understanding of the business domains
as an input to a technical review of the architecture for the system
as an input for describing the use cases and during class analysis
as an input for designing the user interface
as an input to the estimation of subsequent phases of the project
Distribute the Domain Model as follows:
to all developers
to the ambassador users
to the project manager
Back to Top
QUALITY CRITERIA
Does the model conform to the Standards and Guidelines?
Have all of the identified concepts been described?
Are the concepts descriptions clear, concise and consistent?
Back to Top
RD.070 - DETERMINE AUDIT AND CONTROL REQUIREMENTS
In this task, you identify the high level requirements and policies that affect business and system security, control, and procedures.
ACTIVITY
Back to Top
WORK PRODUCT
Audit and Control Requirements - The Audit and Control Requirements help the organization plan the future procedures for maintaining and controlling the new system.
Back to Top
TASK STEPS
1 Review current security,
manual operations
procedures, and the Use
Case Model (RA.023)
and the Use Case
Specification (RA.024).
None None
2 Evaluate audit
specifications for division
of responsibility in
finance and operations.
None None
3 Create a list of security
requirements for the
organization, operating
system, application, and
database to support
future business
processes.
Audit and
Control
Requirements
Questionnaires
This component provides a set of self-assessment questions to:
facilitate compliance with generally accepted application audit and control objectives
serve as a checklist of issues for consideration during application setup
assist the functional leads or application owners in defining audit and control requirements
The seeded questions should be tailored to your enterprise by adding additional ones or deleting those that do not
apply. The specific questionnaire categories follow:
Application Owner and User Security Requirements - The application owner is generally responsible for
accomplishing the following for each application:
identifying sensitive programs and establishing controls
classifying data
making sure controls are in force
establishing adequacy of security testing
Separation of Duties - The duties of the developers, computer operations personnel, and user groups are
reviewed to verify that problems do not exist with the separation of duties. In other words, no one individual
should control activities within a process in a way that permits errors of omission, fraud, or theft.
Sensitive Programs - Sensitive programs are application programs whose improper use could cause serious
financial loss that normal application controls cannot prevent. When considering application security, the names
of sensitive programs, identification and protection of application data files, and the arrangements for archiving
and recovering vital records should be examined. The proper identification of sensitive programs is critical to an
effective control procedure. The sensitive program control concept is valuable only when a relatively small
number of programs are identified. Once identified, controls must be in place to prevent unauthorized
modification or use.
Logical Access Controls - While a site procedure generally controls sensitive programs, application data has a
formal access control mechanism. Through this mechanism, the application owner can authorize and control
who has access to data (by user ID) and how the data can be accessed (read,
update, and alter).
Vital Records - Vital records are essential to the continuing operation of the application system. You must identify
and safeguard all such records.
Change Control - A change control system should be in place to evaluate, justify, and control changes to
programs or procedures, including those for backlog management, library management, and system testing.
Transaction Origination Controls - Accuracy and completeness of information should be confirmed before it
enters the application system. Owner and user responsibilities include activities up to the point of converting data
to machine readable format.
Communication Controls - The integrity of data should be confirmed as it passes through the communication lines
from the input device to the reception devices. This covers hardware controls, message transmission, message
accountability, and reception controls.
Processing Controls - Controls for entry of data into the computer application system should be applied to help
maintain accuracy and completeness of data during processing.
Output Controls - Output controls help maintain the integrity of the output data from conclusion of computer
processing to delivery to the user.
Documentation - The quality and completeness of existing program documentation determines the degree to
which programs could be efficiently reconstructed if they were destroyed.
4 Create a list of user
security requirements.
User Security
Requirements
The process flow, transaction, and department that relate to a given audit or control should be identified. In addition, the
level of control (field, form, and process) should be identified as well.
5 Review the audit and
controls with business
area management.
None None
Audit and Control
Requirements.
None None
Back to Top
APPROACH
Audit Control and Objectives
The overall objective of Audit and Control Requirements is to consider audits and controls that will reduce or minimize the risk of those transactions being executed that
place organization assets or information in jeopardy. Such transactions, if executed, should be detectable and their recurrence prevented.
Remember to include functional and manual audits and controls, as well as automated background controls. By categorizing these types, you can further describe the
needs of each area. Be sure to address the following:
Who or what is dictating control?
Why do certain data, functions, or other elements require control?
Why do certain data, functions, or other elements require audit?
Who or what will perform these audits or controls?
Is timing or sequencing critical to the requirement?
What is the level and type of control (field, form, process, host, and so on)?
What impact does audit and controls create for normal business operations?
It is helpful to think about both application and general controls and risks. The following tables may help frame the thinking process:
Application Risks Application Controls
Unauthorized application access Logical access controls
Incorrect data entry Input controls
Rejected items resolution Processing controls
Incorrect processing/reporting Output controls

General Risks General Controls
Unauthorized system access System access controls
Unauthorized program changes Program change controls
Inadequate information systems operations Organization controls
Business interruption Disaster recovery controls
From an auditing standpoint, these are the questions you are attempting to answer:
What was changed?
Who changed it?
When did they change it?
Why did they change it?
Who logged in?
Why did they log in?
What kind of monitoring takes place of transaction processing?
From the standpoint of financial controls, consider the following questions:
What steps need to be taken to facilitate external auditors review of procedures and controls?
What controls are in place to prevent insider trading, fraud, nonmalicious errors, and so on?
What approval hierarchies need to be in place?
What are the electronic commerce and web-based systems security requirements?
What business transactions are permissible in a web-based system?
What policies will prevent unauthorized intranet access?
What kind of special security is required for financial and confidential information systems (such as General Ledger, Accounts Receivable, Human Resources,
Electronic Funds Transfer, Electronic Data Integration, and Data Warehouse)?
Key User Interviews
Interview the financial auditors, database administrators, and system administrators for specific security and period-close acceptance criteria. Interview managers for
direct report security requirements.
FINANCIAL PERSPECTIVE
Schedule and interview financial auditors for security and any period close needs. Financial auditors often have minimum information that they require when examining
operations and financial data. Financial and legal policies may influence the amount of history that the organization maintains.
In many large organizations, the business requires built-in process audit checks. For example, the process should not permit an accounts payable clerk to issue checks to
himself. Purchasing requesters should not be authorized to execute purchase order approval on their own requisitions. Collect these types of audit and control
requirements to confirm that the design can support it.
SYSTEM ADMINISTRATOR PERSPECTIVE
As part of daily operations, database and system administrators schedule and maintain backup and recovery procedures. In case of system failure, these administrators
will retrieve and restore specific data for a minimum period to continue running the business. Verify that the data retention period can adequately support the business
operations.
Additionally, interview managers for control needs based on individual areas of responsibility. When defining control requirements, keep in mind that job functions may
change based on the final design of business solutions. Gather information that will provide insight on data that should be segregated based on business function,
controlled because of sensitive information, or prohibited due to required authorization.
Other system administration topics that fall under audit and control are:
new accounts and passwords
transaction monitoring
log and output file purge tracking
Back to Top
Back to Top
Business Analyst Determine and document the Audit and Control Requirements. 100
Business Line Manager Assist in determining the Audit and Control Requirements. *
Ambassador User Participate in the determining the Audit and Control Requirements. *
Back to Top
PREREQUISITES
Prerequisite Usage
Present and Future
(RD.012)
Consider Audit and Control Requirements for each organization.
Current Business Baseline
Metrics (RD.034)
System security specifications and existing operations procedures for current processes may yield future Audit and Control
Requirements information.
Supplemental Requirements
(RD.055)

Use Case Model (RA.023.1) Use cases may have Audit and Control Requirements.
Existing Reference Material Policies and procedures may exist that contain Audit and Control Requirements that need to be perpetuated.
Future Process Model (RD.011) Business policies provide a good source of Audit and Control Requirements. Use of the Function Hierarchy component, developed
during this task, will point you toward relevant functions where policies may reside.
Workshop Results (TA.010)

Back to Top
TEMPLATES AND TOOLS
RD-070_AUDIT_AND_CONTROL_REQUIREMENTS.DOC MS WORD
Tool Comments
processes.
Back to Top
The Audit and Control Requirements is used in the following ways:
to plan the future procedures for maintaining and controlling the new system
to capture audit and control requirements
to define the types of fundamental audits and control needed to run the business
Distribute the Audit and Control Requirements as follows:
to the project team
Back to Top
QUALITY CRITERIA
Back to Top
RD.130 - DEVELOP BASELINE ARCHITECTURE DESCRIPTION
The purpose of this task is to perform a global analysis of the factors that will influence the architecture of your system and to develop strategies that address those
factors. This will help you to design an architecture that can both meet the systems requirements and tolerate any anticipated change in these external factors.
The task begins the development of the Architecture Description that eventually will fully describe the system architecture through a set of architectural views and related
information.
In OUMs architecture-centric approach, the systems architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system that
is being implemented. The Architecture Description (RD.130) work product is the collection point for all of the architectural views of the system. This artifact documents
the systems architecture through these architectural views and highlights the architecturally-significant aspects of the system by documenting the design and
development priorities or guidelines, as determined by an iterative examination of the implementation risks. A well-formulated Architecture Description is one of the key
elements of the Lifecycle Architecture Milestone that concludes the Elaboration phase.
The Architecture Description is iteratively developed and refined across four OUM tasks. Each of the four tasks contributes one or more architectural views to the
Architecture Description. For more information regarding global analysis and architectural views and development approach, see Applied Software Architecture. The table
below defines the architectural materials and views that are developed during each of the architecture tasks and provides a cross reference to the architectural views
defined by the Unified Software Development Process.
Task OUM Architectural View Corresponding UP Architectural View
RD.130 - Develop Baseline Architecture Description Global Analysis
RA.035 - Develop High-Level Software Architecture Description High-Level Software Architecture Architectural View of the Use Case Model
AN.040 - Develop Analysis Architecture Description Conceptual View Architectural View of the Analysis Model
DS.040 - Develop Design Architecture Description
Module View
Execution View
Architectural View of the Design Model
Architectural Viewof the Deployment
Model
The focus of the architectural work shifts as the project progresses through the early iterations. During Inception, you are concerned with identifying the architectural risks
and defining strategies to mitigate them. During the iterations of Elaboration, you are concerned with prioritizing the use cases in the Use Case View, and defining and
refining the Conceptual, Module, and Execution views of the architecture.
Some attention should be paid to developing a baseline Architecture Description by performing a Global Analysis on nearly every OUM project. The extent of additional
architecture work that is required will vary greatly based on the existence of architectural risk factors and extent of product customization that is involved.
In a commercial off-the-shelf (COTS) application implementation employing a requirements-driven approach, the depth to which this task is performed typically depends
on the extent to which the inclusion of a significant custom component (for example, Data Warehouse), large numbers of custom extensions, or integration with multiple
COTS or third-party systems leveraging Fusion Middleware requires a reassessment or extension of the application architecture of a single software product. Also, where
there are unusual supplemental requirements or stringent quality of service requirements, additional attention must be paid to this task to be sure that the architecture is
able to support these requirements.
This task is not normally performed in a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach that seeks to minimize custom
extensions by promoting leading practice use of standard functionality. This task is therefore not included in the pre-defined Solution-Driven Application Implementation
View Work Breakdown Structure (WBS). However, if your solution-driven application implementation includes architecturally-significant custom extensions, you should
include this task in your project.
ACTIVITY
RD.130.1
RD.130.2
Back to Top
WORK PRODUCT
Architecture Description - The Architecture Description provides a complete description of the system's architecture. It is a composite work product that is refined across
these four tasks:
RD.130 - Develop Baseline Architecture Description
RA.045 - Develop High Level Software Architecture Description
AN.040 - Develop Analysis Architecture Description
In this task, you add the Global Analysis results to the Architecture Description work product. These materials consist of a set of architectural goals and constraints that
documents the factors that influence the application architecture and strategies for accommodating these factors in the architecture design. The factors and strategies
can be categorized into Organization, Technological, and Product factors.
Back to Top
TASK STEPS
1 Identify Architectural Goals and
Constraints. Develop strategies
to deal with the identified
constraints.
Architectural
Goals and
Constraints
The Architectural Goals and Constraints describe the requirements and objectives that have some significant
impact on the business architecture (for example, the use of a particular technology, character of geographic
distribution). It also captures the special constraints that may apply, such as standards, development tools, team
structure, culture, and so on.
2 Identify Organizational Factors
and develop strategies to
address those factors.
Organizational
Factors
The Organizational Factors are those factors that will impose constraints in design choices (for example, team
cohesion and process maturity).
3 Identify Technological Factors
and develop strategies to
address those factors.
Technological
Factors
The Technological Factors are those related to the hardware and software technology and infrastructure
available to support the application. Since technology changes over time, the architectural design should be
designed with flexibility in mind and technological factors must be carefully addressed and their risks mitigated.
4 Identify Product Factors and
develop strategies to address
those factors.
Product
Factors
The Product Factors are those related to the required qualities that the application requires (for example,
dependability, performance, reliability, etc.).
Back to Top
APPROACH
A global analysis is initially performed before any of the specific architectural views are defined. It should be revisited during each of the iterations and refined throughout
the architectural design.
This analysis starts with the identification of a set of architectural goals and constraints and the development of strategies to deal with the identified constraints (for
example, a certain geographical distribution, or the use of a certain framework). It then goes on to the identification of organizational, technological, and product factors
that may affect the architectural design. It is important to identify these factors, to identify the associated risks, and to determine mitigation strategies.
Organizational factors are those factors that impose constraints in the design choices (for example, team cohesion and process maturity).
Technological factors are those factors that are related to the hardware and software technology and infrastructure available to support the system.
Consideration must also be given to factors related to any commercial-off-the-shelf software packages that will be included as part of the system. Since technology
will change over time, the architecture should be created with flexibility in mind. Technological factors must be carefully addressed and their risks mitigated.
Product factors are those factors related to the required qualities that the application will have to have (for example, dependability, performance, reliability, etc.).
The first step of this task is to make all organization, technological, and product factors explicit. Then, the strategies to deal with these factors should be carefully
developed. To analyze the three types of factors, the following steps can be followed:
Identify and describe the factors
Characterize the flexibility or the changeability of the factor
Analyze the impact of the factors
To derive strategies, the following steps can be followed:
Identify issues and influencing factors,
Develop solutions and specific strategies
Identify related strategies
Below are typical examples of organization, technological and product factors that you may need to make explicit and derive strategies to mitigate them:

Typical Organization Factors Typical Technological Factors Typical Product Factors
O1. Management T1. General Purpose Hardware P1. Functional Features
O2. Staff Skills, Interest T2. Domain-Specific Hardware P2. User Interface Strengths, Weaknesses
O3. Process and Development Environment T3. Software Technology P3. Performance
O4. Development Schedule T4. Architecture Technology P4. Dependability
O5. Development Budget T5. Standards P5. Failure Detection, Reporting, Recovery
Back to Top
Back to Top
System Architect Facilitate the workshop, interviews or meetings. Formulate technological risk factors.
80
Business Analyst Help formulate and prioritize the organization and product architectural risk factors. 20
Ambassador User Formulate and prioritize the organization and product architectural risk factors. *
Back to Top
PREREQUISITES
RD.130.1
Prerequisite Usage
Applications
Architecture
(ENV.EA.140)
Use this Envision work product or a similar enterprise-level document, if available. You may need this information before you can begin this
(RD.011.1)
The high-level Future Process Model may give an indication of specific functional features that need to be taken into consideration in the
Supplemental
Requirements
(RD.055)
The Supplemental Requirements contains additional requirements that may impact the application architecture.
Requirements
Specification
(RD.140.1)
The Requirements Specification may have an impact on the application architecture and should be reviewed as part of the global analysis.
Business Use Case
Model (RA.015)
The Business Use Case Model may give an indication of specific functional features that need to be taken into consideration in the application
architecture.
MoSCoW List
(RD.045.1)

RD.130.2
Prerequisite Usage
Architecture Description The initial version of the Architecture Description document that includes updates from the High-Level Software Architecture Description
(RA.035), Analysis Architecture Description (AN.040.1), and Design Architecture Description (DS.040.1) is updated in this iteration of this
task.
Hardware and Software
Foundation Definition
(TA.060)
Initial Architecture and
Application Mapping
(TA.070)
Recovery and Fallback
Strategy (TA.080)
Security and Control
Strategy (TA.090)
Capacity Plan (TA.120)
During the development of these Technical Architecture work products, new factors may have been identified that should be reflected in
the baseline analysis.
Back to Top
TEMPLATES AND TOOLS
ARCHITECTURE_DESCRIPTION.DOC MS WORD - Use the template to create the initial version or the Baseline Architecture Description (RD.130.1).
In the second iteration of this task (RD.130.2), update the Architecture Description work product originally created in the first
iteration of this task (RD.130.1) that may also have been updated with the Architectural View or High-Level Software
Architecture (RA.035), the Conceptual View (AN.040.1) and the Design Priorities, the Module View, and the Execution View
(DS.040.1).
Back to Top
The Architecture Description is used in the following ways:
to highlight the factors that influence the application architecture
to enumerate strategies for dealing with these factors in the architectural design
Distribute the Architecture Description as follows:
Back to Top
QUALITY CRITERIA
Although it might seem desirable to strive to achieve the highest levels of precision and consistency for a standard such as an Architecture Description, it is not
necessarily the case. To assist rapid development and provide a practical standard that can be readily adopted by a wide range of people in development projects, a
high-level view is all that is needed.
One objective is to define an Architecture Description just to the point to enable consistent definition and use by practitioners and to underpin the architectural aspects of
the project. Another, related objective is to provide a consistent base of concepts, terms, and notations for the architects to use as input into their design.
Such a specification does not have to be comprehensive to be effective. It only needs to cover the core areas of the architecture that must be defined and understood in a
standard way to enable effective design.
Although underlying precision and consistency are important (and will be achieved through additional tasks), practicality and usability are paramount. The critical factor
for success is whether the resulting set of concepts, terms, and notations is small, simple, and accessible enough to be understood.
Back to Top
RD.134 - IDENTIFY NEW SOFTWARE RELEASE CHANGES
The single most important factor in a software upgrade project is the accurate identification and understanding of the new release changes. These new release changes
can relate to multiple areas of technical, functional or applications processes and architecture including integration points. In this task, you identify the new software
release changes, assess the impact and propose feasible gap resolutions and additional configuration.
ACTIVITY
Back to Top
WORK PRODUCT
Software Release Changes Summary - The Software Release Changes Summary identifies all the new release changes along with new release features and
enhancements. The assessment of the impact of changed business processes on existing processes is also enumerated.
Back to Top
TASK STEPS
1 Review new release changes. New Release
Changes
This component provides a list of the new release features both from the technical and functional process and
integration aspects.
2 Review impact of new release
changes on existing business
processes and identify gaps.
Impact For each new release change, the impact on current business processes is documented and assessed from both
the technical and functional aspects.
3 Propose feasible gap
resolutions and additional
configuration for new release.
Gap
Resolutions
and Additional
Configuration
This component enumerates solutions that may affect the current processes in any of the areas of enhancements
or changes including the technical, functional and integration areas. In addition to the gap resolutions, any new
additional configurations needed to support the new applications changes are documented.
Back to Top
APPROACH
This task assesses the changes between the current and new software release. It maps the changes to the current business process. You will identify gaps between new
release features and business requirements and make recommendations on how to deal with these gaps. During this process you can also assess system-enabled
business process improvement opportunities where new release capabilities exist. Requirements mapping begins early in the life cycle of an upgrade project. Reviewing
the business requirements mapping documentation prepared during the initial implementation may help you identify the gaps that required custom extensions or changes
in business processes. Some examples of software release changes that can create gaps are:
new functionality and corresponding database changes can affect custom extensions and application interfaces
new functionality that enables business process improvement
additional technological capabilities such as web-deployed user interfaces
database enhancements such as advanced replication facilities and new data warehouse capabilities
The primary sources for release change information are the release manuals, training on the new release, and personnel with new release expertise. Consider the various
categories of new release changes since they relate to different areas of technical, functional, and software architecture. The organization may be upgrading from
character or GUI to web deployed access. A database upgrade may also be involved. The new release might require more or less disk storage and network bandwidth.
New integration features may be available allowing elimination or simplification of existing interfaces. During this task, the project team assesses the changes between
the current and new release. It is essential that a thorough understanding of these changes is achieved since this task drives the remainder of the upgrade project.
Review New Release Changes
Review the new release features both from the technical and functional process and integration aspects. Any existing product documentation associated with the new
release features needs to be reviewed.
Review Impact of New Release Changes
Review impact of new release changes on existing business processes and identify gaps. Any new mandatory or optional product feature or enhancement or retiring of
any processes as part of the new release changes needs to be analyzed in terms of its impact on current business processes. These gaps need to be identified and
assessed from both the technical and functional aspects.
Propose Feasible Gap Resolutions
Propose feasible gap resolutions and additional configuration for new release. All gap processes identified as part of the changes in new release are to be analyzed and
solutions enumerated. These solutions may affect the current processes in any of the areas of enhancements or changes including the technical, functional and
integration areas. In addition to the gap resolutions, any new additional configurations needed to support the new applications changes are to be enumerated.
Back to Top
Business Analyst Conduct interviews and working sessions. Identify detailed business requirements impacted by the upgrade and create revised
business requirement scenarios as appropriate.
80
System Architect Propose solutions and technical assumptions. Remap business data to new release applications. 20
System Administrator Provide new release version as delivered for project team to study the new release features and business processes. minimal
Back to Top
PREREQUISITES
Prerequisite Usage
Back to Top
TEMPLATES AND TOOLS
Tool Comments
PeopleSoft
Upgrade
Guidance
In terms of PeopleSoft new release feature identification, both the Target PeopleSoft Applications and PeopleTools Release Notes form the basis
of this task. Refer to the Upgrade Resources section on Oracle My Oracle Support.30
Back to Top
The Software Release Changes Summary is used in the following ways:
to identify changes between the current and new software releases
to identify gaps between new release features and business requirements and propose gap resolutions
to define the application configuration that needs to support the new application release solution
Distribute the Software Release Changes Summary as follows:
Back to Top
QUALITY CRITERIA
Back to Top
RD.136 - PERFORM CUSTOM EXTENSION IMPACT ANALYSIS
This task identifies the impact of the upgrade on existing custom extensions. During the initial application implementation and system maintenance, custom extensions
may have been developed for the current release of Oracle Applications. Custom extensions can include new or updated:
screens or forms
batch objects
custom database tables, triggers, stored procedures
integration points to third-party products
ACTIVITY
Back to Top
WORK PRODUCT
Custom Extension Impact Analysis - The Custom Extension Impact Analysis documents key information about the impact of the migration project on existing custom
extensions. This work product is intended to be the central reference for information regarding the impact of custom extensions throughout the project.
Back to Top
TASK STEPS
1 Identify application-related custom extensions. Custom Extension Identification
2 Perform analysis on identified custom extensions. Custom Extension Analysis
3 Evaluate steps necessary to perform on each custom extension. Custom Extension Evaluation
Back to Top
APPROACH
Identify and determine the disposition for each existing custom extension. Some may need to be migrated unchanged because new release changes do not provide the
needed functionality. It may be possible to eliminate others owing to new release functionality (refer to the Software Release Changes Summary, RD.134). Some may
require changes prior to migration.
Do not underestimate the effort and resources needed for this task. A thorough knowledge of new release functionality is necessary as well as a complete understanding
of the nature of existing custom extensions. There may be little or no documentation for these custom extensions and few, if any, people with this knowledge available to
the project team.
Be cautious about custom functionality developed by user organizations without the knowledge of the corporate information systems department. End user use of report
writing and query tools based on extracts directly from database platform tables is not uncommon. The structure of these tables, which are the source for such extracts,
may have changed in the new release. The extract process may need to be treated as a custom extension whose disposition must be determined.
Back to Top
Application/Product
Specialist
Identify, analyze and review custom extensions. 50
System Architect Identify, analyze and review custom extensions. 50
Client Project Manager Identify, analyze and review custom extensions. *
#TOP #TOP
Back to Top
PREREQUISITES
Prerequisite Usage
Software Release Changes Summary (RD.134)
Back to Top
TEMPLATES AND TOOLS
Tool Comments
PeopleSoft Upgrade
Guidance
PeopleSoft Enterprise specific upgrade guidance can be accessed through Oracle My Oracle Support.30 Upgrade guidance is Pillar dependent
and is therefore located on multiple Home Pages.
Back to Top
The Custom Extension Impact Analysis is used in the following ways:
to evaluate and determine custom extensions to be brought forward into the new release application
Distribute the Custom Extension Impact Analysis as follows:
to the project team members
to the client project manager
Back to Top
QUALITY CRITERIA
Back to Top
RD.138 - PERFORM DATA IMPACT ANALYSIS
The goal of any data migration is to migrate and test all the required data from the current application instance for operation of the new system. Applications are typically
delivered with standard migration tools or methodology to migrate the data stored in the existing standard application tables, but these may not be sufficient to migrate the
data stored in custom tables or data requiring clean up. This task includes the evaluation of existing and new data structures and analyzes the impact in terms of the
overall upgrade.
ACTIVITY
Back to Top
WORK PRODUCT
Data Impact Analysis - The Data Impact Analysis captures the impact of the existing data that will not be migrated by the delivered upgrade tools and methodology on
the overall upgrade. The Data Impact Analysis also enumerates and highlights the requirement of manual or additional data migrations if required.
Back to Top
TASK STEPS
1 Review the Delivered Upgrade
Data Migration Tools.
Delivered Upgrade
Data Migration Tools
These are the data migration tools and process steps provided with the upgrade identifying the areas of the
data upgrade that should be accomplished using the delivered tools.
2 Identify the gaps in Delivered
Upgrade Data Migration Tools
and their impact.
Impact This component Identifies and enumerates the cases where the delivered upgrade tools and processes will
not cater to the data migration in the upgrade project. The impact of such gaps has to be assessed in terms
of their complexity and overall effect on the upgrade.
3 Propose feasible gap
resolutions for custom data
migration.
Gap Resolutions and
Custom Data
Migration Strategy
This component suggests high-level gap resolutions in terms of an overall Custom Data Migration Strategy.
Back to Top
APPROACH
The data migration process should move all the required data from the current application instance for the operation of the new upgraded system. The delivered upgrade
tools and processes will migrate the application data to the new release. But there are certain cases where additional tasks must be performed such as:
populating new tables or new columns with data to support new or changed application features
providing new values for setup data
migrating data in custom tables to new tables in the standard applications
correcting errors in current production data before the new production database is upgraded
The project team determines an overall strategy to meet the data migration requirements, defining both automated and manual methods.
The standard migration tools and process provided with the application release automatically migrates data stored in existing standard application tables. It will not
migrate data stored in custom tables or data in standard tables requiring clean up.
Custom tables and custom columns added to current tables may exist in the new release to support enhanced functionality. Current table columns may have been split
into multiple columns to provide more detail or flexibility.
In these cases additional work will be required to populate these tables if related new functionality is to be used.
All such cases of data migration that are not catered for by standard and delivered functionality should be assessed and the impact factor assigned based on the
complexity of the required custom data migration. This information should be used to determine a strategy for the overall data migration approach.
Back to Top
System Architect Perform data migration mapping and assist in design of data migration modules. 70
Application/Product
Specialist
Identify any business data that supports the current application release, but which resides outside of the standard tables 30
Back to Top
PREREQUISITES
Prerequisite Usage
Software Release Changes Summary
(RD.134)
Use the Software Release Changes Summary to understand the scope of the changes that the new software release
introduces.
Custom Extension Impact Analysis
(RD.136)

Back to Top
TEMPLATES AND TOOLS
Back to Top
The Data Impact Analysis is used in the following ways:
to determine date migration requirements not addressed by the standard data migration tool
Distribute the Data Impact Analysis as follows:
Back to Top
QUALITY CRITERIA
Back to Top
RD.140 - CREATE REQUIREMENTS SPECIFICATION
The goal of this task is to consolidate all the requirements into a unique document, the Requirements Specification. This task is only required when it is necessary to have
a formal review. The Requirements Specification can contain both functional and supplemental requirements.
In a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach, the Requirements Specification (when required), captures only
requirements representing changes the client has requested to the pre-defined business processes comprising the business system functionality (solution) the client
organization will be implementing.
ACTIVITY
RD.140.1
RD.140.2
Back to Top
WORK PRODUCT
Requirements Specification - The Requirements Specification captures the complete software requirements for the system, or a portion of the system. Basically, it
contains all requirement documents consolidated and organized into a single document.
Back to Top
TASK STEPS
1 Collect the requirements. Introduction The Introduction contains the objectives and scope definition. You should include a glossary (RD.042) for any
terms or acronyms.
2 Produce the Overall Description. Overall
Description
The Overall Description describes the general factors, assumptions and dependencies that affect the product
and its requirements. This section does not state specific requirements. Instead, it provides a background for
those requirements that are defined in detail in the Specific Functional Requirements section, and makes them
easier to understand.
3 Determine which specific
functional requirements you
want to include in the
Requirements Specification.
Specific
Functional
Requirements
The Specific Functional Requirements contains all the requirements identified in a structured format, for
example, the Use Case Model or the Business Use Case Model, or both. It also contains all the non-functional
(supplemental) requirements as associated to each use case included in the work product.
4 Provide references to other
requirement work products that
have been prepared for the
project.
Supporting
Requirements
Work
Products
The Supporting Requirements Work Products includes references to other requirements captured in additional
OUM work products. You should reference these tasks to determine the level of detail required for your project.
Services Catalog (RA.025)
Business Rules Catalog (RA.027)
Functional Prototype (RA.085)
Reporting Fit Analysis (MC.090)
Validated User Interface Standards Prototype (RA.095)
Determine Audit and Control Requirements (RD.070)
Define Documentation Requirements and Strategy (DO.010)
Performance Management Requirements and Strategy (PT.020)
Define Data Acquisition and Conversion Requirements (CV.010)
Define Architecture Requirements and Strategy (TA.020)
Testing Requirements (TE.005)
5 Determine which models or Models and The Models and Repository Artifacts component refers to additional specific requirements-related models or
artifacts you want to include in
the Requirements
Specifications.
Repository
Artifacts
artifacts that you may want to include in the Requirements Specification. For example, you may choose to include
Business Process Models, Domain Model, or Business Rules.
Back to Top
APPROACH
This task is optional and is usually performed whenever a formal review of the requirements is required. It allows project teams to develop the appropriate level of
"deliverable" to satisfy the project needs. It does not provide guidance about how to detail the requirements, rather it simply provides a template, and guidance for
creating a single Requirements Specification for your project, or to create an index that links to other requirements artifacts. Therefore, the Requirements Specification is
used as a collection point or index to other requirements work products.
The following illustrates the various tasks where work products might be incorporated into the Requirements Specification.
The objective is to collect the requirements into a form that is accessible and understandable for the reviewers. By completing this task, you will produce a single
requirements specification that captures a picture of the functional and non-functional requirements for the system. There are many industry examples for how this work
product should look (IEEE template, etc.)
It is important to remember that use cases are requirements. The intent of the use case it to accurately detail what the system should do. It should not be necessary to
convert use case to another format. However, use cases do not represent ALL of the requirements. Use cases do not document quality of service requirements, external
interfaces, user interfaces, data formats, calculations, or business rules. Every organization collects requirements to suit its needs and may document this collection in a
unique way.
You should also collect the requirements you have documented in business process models, domain models, and, if available, the business use case model. Organize
the material into logical sections and use the collected material to produce the Overall Description. You should also include Business and System Objectives, a System
Context Diagram, and any assumptions and constraints under which the requirements have been produced. In addition, if you know that there are still outstanding areas
or subjects, include a note in order to prevent unnecessary review comments about missing requirements.
You should include a section on how the requirements can best be reviewed (i.e., a How to Read section), so that the reader understands how the different sections are
related.
Reference the MoSCoW List (RD.045) to make sure all agreed upon requirements have been addressed in the Requirements specification. If your project is using a
Requirements repository you may be able to use the tool to generate stakeholder appropriate views of the requirements.
The requirements specification includes both specific functional requirements as specified through Use Cases and process models as well as supplemental requirements
that have been document in other OUM work products.
Consider the following requirements for inclusion in the Requirements Specification:
Functional Requirements
Use case diagrams and use case descriptions - Use Case Model (RA.023)
References or links to Use Case Specifications (RA.024)
Process models that have been developed to capture detailed functional requirements
User Interface Requirements
Storyboards - demonstrate the flow between screens and forms
Wireframes - identify the data to be input, viewed or changed by a user
Functional Prototypes
Reporting Requirements
Reporting Fit Analysis (for existing COTS reports that are to be included
Report layouts
Behind-the-scenes logic to produce the report
Calculations, sorting, summarization and transformation information
Supplemental requirements related to the reports
Volume, frequency, time to generate and amount of data for reports
Other types of requirements you may wish to include are:
Quality of Service Requirements (Non-Functional)
Performance
Security
Usability, Reliability, Supportability, Maintainability, Scalability
Safety
Environmental (audit, globalization and localization, legal)
Privacy
Architecture, Interface (hardware, software)
Operational
Failure and disaster recovery
Training
Testing Requirements Reference the testing requirements that have been agreed to for the project.
Business Rules Reference the Business Rules catalog for a list of the business Rules that support the functional requirements.
Services Catalog If your project involves Service Oriented Architecture (SOA), reference the list of Services or the SOA Catalog for the project.
Data Requirements Reference Class Diagrams, or Entity Relationship diagrams that have recorded the Data requirements
Back to Top
Back to Top
Business Analyst Consolidate requirements into a single Requirements Specification document.
leaving 60% allocated to the business analyst. The team leader would then assist in the consolidation of the requirements into
a single Requirements Specification document.
80
System Architect Help consolidate requirements into a single Requirements Specification document. 20
Ambassador User Help consolidate requirements into a single Requirements Specification document. *
Back to Top
PREREQUISITES
Prerequisite Usage
Project Management The scope must be included in the Requirements Specification to ensure that the reader understands the scope of the requirements.
Plan (PJM)
Applications
Architecture
(ENV.EA.140)
Use this Envision work product or a similar enterprise-level document, if available. You may need this information before you can begin this
Business and System
Objectives (RD.001)
The Business and System Objectives should be included in the Requirements Specification to ensure the reader understands under which
objectives the requirements have been determined.
(RD.011)
The high-level Future Process Model should be included, if available.
Supplemental
Requirements (RD.055)
The Supplemental Requirements should be included, if available.
Business Use Case
Model (RA.015)
The Business Use Case Model should be included, if available.
Use Case Model
(RA.023)
Use Case Specification
(RA.024)
The Use Case Model and Use Case Specifications should be included, if available.
Domain Model (RD.065) The Domain Model should be included, if available.
MoSCoW List (RD.045.1)
Back to Top
TEMPLATES AND TOOLS
RD-140_REQUIREMENTS_SPECIFICATION.DOC MS WORD
Tool Comments
Back to Top
The Requirements Specification is used in the following ways:
to consolidate all the requirements into a unique document
Distribute the Requirements Specification as follows:
Back to Top
QUALITY CRITERIA
Are all the functional requirements stated in a testable format?
Are references included to all Other requirements documents agreed to for the project?
Have all requirements been consolidated into this document?
Back to Top
RD.150 - REVIEW REQUIREMENTS SPECIFICATION
The goal of this task is to remove defects on the requirements via peer-review.
OUM promotes the use of inspections in peer-reviews, the most efficient peer-review method. In particular, in an offshore project, peer-reviews play a very important role.
Peer-review can reduce the amount of errors and improve the quality and productivity of the project. OUM recommends that the offshore project manager and architects
should also participate in the early peer-review meeting. Once the software requirements documents (RD.140) are ready for review, a team of system analysts, business
analysts, ambassadors users, and testers review the requirements. As a result of such a review, defects can be found and change requests can be triggered. There are
many different types of changes. Some changes can affect scope these require change requests. Other changes do not affect scope; these should be handled through
the MoSCoW List.
Different types of review can be used. Inspections can be used to review the requirements by a team composed of system analysts, testers, users, and developers.
Formal review can be used to review the requirements by a separate team of people who did not, necessarily, participate in the Business Requirements activities.
However, in order to foster productivity and quality it is recommended that the requirements be produced by the information technology people in close collaboration with
the ambassador users. Thus, peer-review is recommended to be used as a tool to improve the quality of the requirement.
ACTIVITY
RD.150.1
RD.150.2
Back to Top
WORK PRODUCT
Reviewed Requirements Specification - This contains the list of defects, including priorities, that were found in the requirements documents.
Back to Top
TASK STEPS
1 Prepare review. None None
2 Perform review. Defects Produce a list of Defects that are found in the requirements during the review.
3 Prioritize changes. Prioritized Defects The Prioritized Defects is same list of defects, including priorities indicating the importance of the changes.
Back to Top
APPROACH
This task is particularly important if the project is an offshore project. This may also be an important task if you have larger user groups where you need to get an
acceptance for the current state of the requirements, or where there are users that should have a say in the requirements, but for whatever reason cannot be involved in
the project on a day-to-day basis. On the other hand, if the project has a small team that is continuously involved in the Business Requirements process, this task would
often be unnecessary. However, even if everyone has been involved in the Business Requirements process, you may in some situations, decide to include the task as a
mechanism to get an overview of the status, and the requirements as a whole.
Preparing and Performing the Review
You have collected the requirements to review in the Requirements Specification (RD.140). If it has not already been decided, determine what kind of review would be
the most effective, who should be involved in the different parts of the review, how defects should be reported back, the schedule of the review, and so on. The peer-
review is most effective where you have a team of system analysts, business analysts, ambassador users, and testers that, as a team, review the requirements. As a
result of such a review, defects can be found and change requests can be triggered.
Another review mechanism is that each reviewer inspects the material on their own, and sends their feedback to the team. The disadvantage in doing that is that it is
difficult to make clarifications underway, and that the feedback may be interpreted wrongly. However, if that is the only way to do it, it is often better than no review.
It is recommended that the review starts off with a presentation where the background is explained, important decisions are explained, and a short walkthrough of the
requirements is presented. In this way each reviewer will be better prepared for the task.
Prioritizing Defects
At the end of the review, there will be a number of reported defects. It is recommended that the person/team that submits a defect, make a suggested priority for the
change. However, it must be very clear that this may not be the final priority. When the review is completed, collect all the defects, and determine the final priorities for
each defect. It is the client that determines the priorities, but we must ensure that the priorities are set according to the projects scope and objectives.
Back to Top
Back to Top
System Architect Facilitate the review meetings. Review Requirements Specification.
leaving 60% allocated to the system architect. The team leader would then facilitate the review meetings.
40
Designer Review Requirements Specification. 20
Business Analyst Review Requirements Specification. 20
System Analyst Review Requirements Specification. 20
Ambassador User Review Requirements Specification. *
Back to Top
PREREQUISITES
RD.150.1
Prerequisite Usage
Business and System
Objectives (RD.001)
The Business and System Objectives should be kept in mind while reviewing so that comments are to the point and the focus is kept
on the actual objectives.
MoSCoW List (RD.045.1) The MoSCoW List is used to determine the order in which the content is reviewed. The comments that come out of the review
process should also e fed back into the MoSCoW List.
Requirements Specification
(RD.140.1)
The Requirements Specification provides the consolidated specifications included in the review process.
RD.150.2
Prerequisite Usage
(RD.001)
The Business and System Objectives should be kept in mind while reviewing so that comments are to the point and the focus is
kept on the actual objectives.
MoSCoW List (RD.045.2) The MoSCoW List is used to determine the order in which the content is reviewed. The comments that come out of the review
process should also e fed back into the MoSCoW List.
Future Process Model (RD.011.2)
(RD.020)
Business Use Case Model
These are included in the review process.
(RA.015)
Requirements Specification
(RD.140.2)
The Requirements Specification provides the consolidated specifications included in the review process.
Reviewed Requirements
Specification (RD.150.1)
The results from any previous reviews can be used during the preparation for subsequent reviews to verify whether or not
previously agreed to actions have been taken into account.
Back to Top
TEMPLATES AND TOOLS
REVIEW_RESULTS.DOC MS WORD
Back to Top
The Reviewed Requirements Specification is used in the following ways:
to reduce the amount of errors and improve the quality and productivity of the project
Distribute the Reviewed Requirements Specification as follows:
Back to Top
QUALITY CRITERIA
Has every reviewer/team provided feedback as a proof of review?
Have all requirements defects been collected and prioritized?
Have the review comments been verified and agreed by the ambassador users?
Have any unresolved issues, for example conflicting user requirements or priorities, been escalated?
Have expectations been met, or documented where not met?
Do the review records provide sufficient information to show where the requirements falls short of expectations?
Back to Top
RD.160 - CONVERT PROJECT VIEWS TO REUSABLE
VIEWPOINTS
During this task, you review all the views you have created specifically for the project to determine whether it may be useful for other projects, and if so, convert these
views to reusable viewpoints. Finally you add these viewpoints to the Viewpoint Library.
ACTIVITY
Back to Top
WORK PRODUCT
New Reusable Viewpoints - The New Reusable Viewpoints are viewpoints that have been created based on project views and submitted into the Viewpoint Library.
Back to Top
TASK STEPS
1 Review project views for
reusability.
Candidate
Viewpoints
The Candidate Viewpoints contain all the project views that are suggested for future reuse.
2 Propose viewpoints for
reuse.
Proposed
Viewpoints
The Proposed Viewpoints contains a description of each viewpoint, including the type of stakeholders the viewpoint is
intended for and the concerns that should be addressed by the viewpoint.
3 Accept or reject proposed
viewpoints.
None
4 Convert project views into
reusable viewpoints.
New Reusable
Viewpoints
The New Reusable Viewpoints contains the converted project views that were accepted.
5 Submit the viewpoints to the
Viewpoint Library.
updated
Viewpoint
Library
The Viewpoint Library is updated to include the New Reusable Viewpoints.
Back to Top
APPROACH
Review Project Views for Reusability
Review the Viewpoint List (RD.003) to see if any of the ad hoc views defined for the current project should become Viewpoint Candidates. Review the models that have
been produced in the project outside of the view to see whether any of these should also become Viewpoint Candidates. Finally, if available, review the Enterprise
Modeling Strategy (ENV.ER.070) to determine whether the candidates fit into the strategy before suggesting them.
Propose Viewpoint for Reuse
For each viewpoint that should be proposed for reuse you need to provide a proper description, and describe which stakeholders concerns it addresses. Send the
proposed viewpoint with its description to the appropriate authority that should determine whether or not the proposed viewpoint will be accepted. This is often an
enterprise architecture board.
Accept or Reject Proposed Viewpoints
The appropriate authority should accept or reject the proposed viewpoint based on the benefit they expect the viewpoint will have for future projects.
Convert Project Views into Reusable Viewpoints
For every propose viewpoint that has been accepted, convert the project views into reusable viewpoints following the enterprise standards. The project views and models
can also be used as examples in the Viewpoint Library.
Submit the Viewpoints to the Viewpoint Library
When the viewpoints are complete, insert them into the Viewpoint Library for reuse by other projects.
Back to Top
Enterprise Architect Convert project views to reusable viewpoints. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Enterprise Modeling
Strategy (ENV.ER.070)
If available, the Enterprise Modeling Strategy should be reviewed to determine whether a project view fits within the enterprise strategy.
Architecture Principles,
(ENV.EA.010)
If available, use the Architecture Principles, Guidelines and Standards to see how the viewpoints should be defined.
Viewpoint List (RD.003) The Viewpoint List contains all the project views that have been used by the project.
All OUM Tasks Almost any OUM task can be executed through the creation of one or more models. Collect the models that have been created during the
project and use them as a basis to create Candidate Viewpoints. If the Candidate Viewpoint has been accepted, then use the applicable
models as an input to define the viewpoint.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The New Reusable Viewpoints are used in the following ways:
by any new project to reuse for their modeling activities
The New Reusable Viewpoints should be inserted into the Viewpoint Library and made available for every future project.
Back to Top
QUALITY CRITERIA
Have all ad hoc views and models created for this project been considered as potential Viewpoint Candidates?
Do the viewpoint definitions follow enterprise standards?
Has every Viewpoint Candidate been reviewed by the proper authority?
Has every viewpoint included in the Viewpoint Library been accepted by the proper authority?
Back to Top
[RA] REQUIREMENTS ANALYSIS
In the Requirements Analysis process, the functional and supplemental requirements identified and prioritized during the Business Requirements process are analyzed
further into a Use Case Model that is further refined by adding use case details in order to establish a more precise understanding of the requirements. The process of
creating use cases helps ensure that the models and the associated system processes satisfy the business requirements. The Use Case Model is used as the basis for
the solution development. This process helps provide structure and shape to the entire solution. The Use Case Model is used to document in detail the requirements of
the system in a format that both the client and the developers of the system can easily understand.
The Use Case Model is dynamic and is changed as the teams' understanding develops with the system. The resulting business requirement models are maintained
throughout the project lifecycle as understanding of the requirements deepens.
The main work products or outputs of this process are the Use Case Model, a prototype of the user interface, and a high-level description of the software architecture.
The work products from this process are used in data modeling and as a basis for system design.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Depending on your project (for example, large, complex, etc.), the project manager may designate a Requirements Analysis team leader and/or team leaders for various
other reasons that the project manager deems necessary. If the project manager designates team leaders, they are responsible for leading their team and reviewing the
work products produced by their team. The team leader plans, directs, and monitors the day-to-day work of the team. The team leader assigns work packages to the
team members and makes sure they understand the requirements. The team leader is responsible for building team cohesion, motivating the teams, and providing
assistance and encouragement to the team members. Each team leader performs the final quality control and quality assurance for the team by reviewing all work
products. The team leader also signs off on team work completion and quality. Work that is not up to quality standards is returned. Team leaders review work products
from other teams when these work products may impact aspects of the system. The team leader reports the team's progress to the project manager. Refer to Project
Management in OUM for additional information on team leaders.
In the Requirements Analysis process, the requirements captured during the Business Requirements process are analyzed. In short, the requirements are refined and
structured via a Use Case Model in order to establish a more precise understanding of the requirements. The Use Case Model is used as the basis for the solution
development. This process helps provide structure and shape to the entire solution. Detailed Use Case Models are used to document the requirements of the system in
order for the customer as well as the developers to more easily understand the system requirements.
The requirements are first formed into a Business Use Case Model (RA.015). In this model, the business processes are described in terms of business use cases and
actors that correspond to the business processes and business roles, such as a customer. It shows the business from the usage perspective and shows how it provides
value to the actors. The use cases that are relevant to the business are modeled, just enough to understand the context of the new system. The Domain Model (from the
Business Requirements process) is often created in parallel with the Business Use Case model to model all the relevant business entities that relate to the Business Use
Case Model. Most often this is done as part Business Requirements Workshop(s). This is an iterative process, and when reviewing the Business Use Case model, you
may discover incompleteness or inconsistencies in the other models (Future Process Model RD.011), and therefore you may need to update these as a result.
The Business Use Case Model is further detailed into the Use Case Model (RA.023) where new actors and use cases are identified. Also here the workshop is a good
technique to use. Go through each use case to identify the detailed use cases and actors, and thereafter provide the Use Case Specification (RA.024). Use the priorities
given in the MoSCoW List (RD.045) to determine which use cases to go through first. When identifying the detailed use cases, each use case gets their own priority that
will be used when defining the Use Case Specification (RA.024). While determining the Use Case Specification, new use cases may be identified that should be reflected
in the Use Case Model. Therefore, these tasks are often done in parallel, and iteratively.
Further the use cases and scenarios that capture the new system's critical functionality are identified, reviewed and prioritized. A goal matrix is produced based on the
Business and System Objectives (RD.001). This is all brought into the Architecture Description (RD.130) during Develop High-Level Software Architecture Description
(RA.035).
Other important work products are the Validated Conceptual Prototype (RA.030), the Validated Functional Prototype (RA.085) and the Validated User Interface
Standards Prototype (RA.095). These prototypes were produced in the Implementation process and are walked through with the users. Any feedback that results in either
added/changed/refined requirements or changed priorities is recorded in an appropriate tool. The changes are then, depending on priorities, updated into the various
requirement models.
Finally, a team with system analysts, ambassador users, designers, architects, and testers review the Use Case Model and Use Case Specifications (RA.180). As a result
of such a review, new defects and change requests can be triggered.
Although interim outputs and diagrams are required for review purposes, ultimately, there is only one set of final work products from the process. The main work product
of this process is the Use Case Model, a prototype of the user interface. Also during the process, the Architecture Description work product (RD.130) is updated by the
Develop High-Level Software Architecture Description (RA.035) task.
Back to Top
Supplemental Guide to access all application implementation supplemental information. You can also go directly to the Requirements Analysis process supplemental
guidance.
Back to Top
Inception Phase
RA.010 Simulate Business Process Business Process Simulation
RA.015 Develop Business Use Case Model Business Use Case Model
RA.019 Define Project Reference Architecture Project Reference Architecture
Elaboration Phase
RA.035 Develop High-Level Software Architecture Description Architecture Description
RA.085 Validate Functional Prototype Validated Functional Prototype
RA.095 Validate User Interface Standards Prototype Validated User Interface Standards Prototype
RA.160 Conduct Business Data Source Gap Analysis Business Data Source Gap Analysis
Construction Phase
Back to Top
OBJECTIVES
The objectives of the Requirements Analysis process are:
Shape and structure the system to be developed. This is achieved by analyzing and describing the system requirements in such a way as to be easily understood
by the system developers. The emphasis is now on the internals of the system. The structure of the new system determines the maintainability, adaptability, and
resilience to change aspects of the system.
Define clear, concise, consistent, testable and unambiguous use cases following the priorities that are given throughout the process.
Define a basis for the High-Level Software Architecture Description identifying the use cases that are most architecturally significant to the new system and
prioritize the use cases and project goals accordingly.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
BA Business Analyst Develop the business use cases. Facilitate the workshops where the business use cases are modeled. Define SOA Layering Architecture.
Identify and document candidate business services. Identify and document candidate business rules. Populate the Business Rules
Repository. Conduct working sessions. Gather and document the procedures supporting the business processes enabled by the system.
DV Developer Prepare for, and walkthrough the Conceptual Prototype, and gather new understanding of requirements. Prepare the Conceptual Prototype
Workshop, invite participants, and lead the workshop. Provide expertise on development tools and how they are to be used. Walk the user
through the Functional Prototype. Optionally, the developer records agreed changes and additions that can be reviewed after the
walkthrough. You may choose to use an additional lead application developer to lead the Validate Functional Prototype Walkthrough
Workshop. Assist in presenting the User Interface Standards Prototype. Optionally, develop a custom report to present the information
during or after the walkthrough. Lead the Validate User Interface Standards Prototype Walkthrough. Lead the Use Case Model
Walkthrough. Present the Use Case Model and Use Case Specifications.
QM Quality Manager Review the Use Case Model and Use Case Specifications from the point of view of the Testing process. Gain understanding of the internal
structure of the application.
SAN System Analyst Develop the Use Case Model and use cases. Facilitate the workshops where the use cases are modeled. Detail the use cases. Participate
in Conceptual Prototype Workshop to ensure that it fits within the overall architecture (as far as known). Assist in the prioritization based on
the documented business goals of the project. Assist in the validation of the Functional Prototype and advise on the impact of proposed
changes on the requirements. Assist in the validation of the User Interface Standards Prototype and advise on the impact of proposed
changes. Participate in the review meeting in order to verify if the Use Case Model and Use Case Specifications realize the requirements.
SA System Architect Define SOA Layering Architecture. Identify and document candidate business services. Decide on, define, format and populate the services
repository. Develop Architecture Description by prioritizing the use cases based on architecture risks and documented business goals of the
project. Provide input and advice on the architectural consequences of particular gaps and alternatives. Assist in validating that the standard
reports and forms, provided with the functionality being implemented, support the implementing organizations requirements. Participate in
the review meeting to verify if the Use Case Model and Use Case Specifications are compatible with the architecture.
SA
(IA)
System Architect
(Information
Architect)
Identify any gaps in the source systems for meeting the information requirements of the target system. Identify information (data) quality
issues early in the development cycle and establish appropriate escalation and resolution of those issues. Preferably, this should be done
by a system architect that specializes in Information Architecture.
Client (User)
KEY Ambassador User Provide information to create the business use cases and use cases and add detail to the use cases. Participate in the Conceptual
Prototype Workshop to ensure that the requirements have been properly prototyped. Provide assistance in prioritizing the uses cases, goals
and business units. Participate in working sessions and help identify setup parameters. Examine the Functional Prototype and give
feedback to the developers. Provide information on the organizations reporting requirements. Examine the User Interface Standards
Prototype and give feedback to the developers. Provide assistance in Identifying data quality issues early in the development cycle and
establish appropriate escalation and resolution of those issues.
CDA Client Data
Administrator
Provide assistance in Identifying any gaps in the source systems for meeting the information requirements of the target system. Provide
assistance in Identifying data quality issues early in the development cycle and establish appropriate escalation and resolution of those
issues.
Back to Top
The critical success factors of the Business Requirements process also apply to the Requirements Analysis process. Additional critical success factors are:
Access to Information Related to the Existing Business Processes and Systems: As part of the process to identify main business cases and internal and
external actors, it is important to have access to existing business processes and systems affected by the project objectives. Although a new system should be
built, and we should be careful not to be constrained by current business processes, it is useful to get an understanding of the current basis. This will make it
easier to understand the users business, and may also help the user to untie from old ideas and constraints in the old system. Existing systems may be of vital
importance as they may become important actors in the new system.
Back to Top
RA.010 - SIMULATE BUSINESS PROCESS
During this task a business process is simulated rather than executed. A Business Process Simulation is based upon pre-configured metrics that (among others) may
include the duration that an activity may take to execute, the amount of resources available (such as, the amount of people available to assign to a specific role), the
costs of execution, business calendar rules, as well as probability percentages of routing process instances through different outgoing sequence flows. Simulation can be
based on expected metrics and (in case of already realized processes) actual runtime data.
Business process simulation can be a valuable tool to predict the behavior of a business process under specific conditions, allowing verification of the process against
metric objectives, and to identify potential bottlenecks before (the change to) the business process actually has been implemented (pre-execution what-if modeling). It
can help domain experts (ambassador users) with verifying that the process has been modeled correctly or identifying changes to that model to optimize it. As a result of
this, simulation helps to improve the return on investment of realizing the process.
A Business Process Simulation consists of one or more Simulation Models, where each Simulation Model represents a different situation (that is, different resource
allocations or different activity behavior). For example, for some sales process different Simulation Models may be created for peak-volume, low-volume and normal
volume days.
ACTIVITY
Back to Top
WORK PRODUCT
Business Process Simulation - For each business process in question, the Business Process Simulation contains a list of measurable objectives to be accomplished by
the optimized business process, one or more simulation models that represent relevant scenarios for the business process, as well as a simulation analysis that
documents the findings as a result of running the simulations.
Back to Top
TASK STEPS
1 Capture metric
objectives.
Metric Objectives This component consists of (measurable) objectives that the business intends to achieve by realizing (the
changes to) the business process.
2 Determine simulation
models.
Determined Simulation
Models
This component consists in the definition of one or more Simulation Models where each simulation model
represents a different real world situation.
3 Configure simulation
models.
Configured Simulation
Models
This component consists of Simulation Models that are configured in the tool used to run them.
4 Run and analyze the
simulation.
Simulation Analysis The Simulation Analysis consists of the findings and suggestions for potential improvement based upon the
results of running the simulations.
Back to Top
APPROACH
Before executing this task, a consideration has to be made if the benefits of the Business Process Simulation outweigh the costs of creating it. Aspects that may make it
worthwhile are:
high costs for realizing the business process
low costs for capturing the metrics to be used in the Simulation Models
A high level of uncertainty about the requirements, for example, in case of a more complex, new business process
Advantages of the simulation process may include:
the discovery of activities that may be executed in parallel
activities that do not add value to the process
duplicate or overlapping activities
improvement by re-ordering activities
#TOP #TOP
identification of activities that will benefit the most from automation, and as a result of that, providing input to prioritization of implementation
Business Process Simulation typically follows the creation of the Current Process Model (RD.030), or Future Process Model (RD.011). The results from the analysis may
initiate changes of the business process model that on its turn may require a next simulation to verify its effect. Modeling and simulation therefore typically happen
iteratively.
Capture Metric Objectives
The results of the Business Process Simulation should be compared with metric objectives that the business defined up-front. The prime source for the objectives is the
Business and System Objectives (RD.001). These objectives should be reviewed to identify the objectives relevant for the business process that should be simulated.
Some objectives may need to be made more specific when progressive insight in the business process requires doing so. The Current Business Baseline Metrics
(RD.034) may provide metrics based on actual runtime data.
Determine Simulation Models
In principle, to simulate each different scenario (different path through the process) all scenarios should have their own Simulation Model. For more complex processes
there can be a large amount of scenarios, making choices have to be made for scenario a Simulation Model will be created. A good approach to this is to have one
Simulation Model for all of the most common scenarios, as well as those scenarios that may not be very common, but critical nevertheless. Another approach is to
determine all the sequence flows in the process, and make sure that every sequence flow is covered by at least one Simulation Model. Where useful and applicable,
when analyzing one scenario the outcome of a particular sequence flow may be substituted that of another. When necessary both approaches may be combined.
One or more For every Simulation Models need to be configured. Therefore metrics have to be defined for each activity, role, and (probability of) sequence flow. For
example, for an activity it has to be determined if it has a constant execution time or whether it varies, and if it varies, what the mean time for execution is and how great
the variations are. For the resources one may configure if an activity has a fixed amount of resources, or that this may vary because some resources also are used for
other roles and may be needed for other activities that happen in parallel (or in a different process that may execute at the same time). For most organizations these
metrics will not be consistent over the year, but will vary based on business calendar rules, seasons, and so on. For each Simulation Model, it should be clearly specified
which situation from the real world it represents, and the source of the metrics.
The business metrics should be gathered from and need to be verified with the ambassador users.
Configure Simulation Models
When the simulation models are determined and simulated using a tool, the Simulation Models will have to be configured in the tool. For example, with both the Oracle
BPA Suite as well as the Oracle BPM Suite simulations can be done automatically.
In principle, instead of using a tool Simulation Models can also be ran by people instead. Considering the investment in time and organization this will rarely pay off, and
therefore will not be further discussed.
Run and Analyze the Simulation
Once a Simulation Model has been configured, the simulation can be executed. Depending on the tools being used, the results may be shown graphically in the business
process itself (for example bottleneck activities become red, whereas other activities become green), as well as reports with bar charts. Most tools allow for saving these
reports, so that they can be compared with successive simulations. Once it has been verified that the simulations run properly they should be ran with the Ambassador
Users present. Ambassador Users may discover flaws in the metrics, as a result of progressive insight come up with suggestions for new Simulation Models, or may
propose optimizations for the process, which will feed into a revision of the Future Process Model (RD.011).
Very often it may be worth to realize the business process in a couple of iterations, where for example early iterations first address those activities that will benefit the
most from automation. In this way simulation may provide input for prioritizing the development of the business process, and as such provide input to the Project
(Iteration) Workplan (WM.010/WM.030).
Back to Top
Back to Top
Business Analyst Capture the metrics, configure the Simulation Models, run and analyze the simulations, and discuss the results with the
ambassador users.
100
Ambassador Users Provide input regarding the metric objectives and simulation metrics. Assist with running the simulations and propose
suggestions for business process improvements.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Future Process Model (RD.011) It is the Future Process Model that is being simulated.
Current Process Model (RD.030) (optional) Initial simulations may be based on the Current Process Model.
Business and System Objectives (RD.001) The Business and System Objectives provide the metric objectives for comparison.
Current Business Baseline Metrics (RD.034) (optional) The Current Business Baseline Metrics may be used for configuration of Simulation Models.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Business Process Simulation is used in the following ways:
as input for improvement options
as input for or to validate the Project Workplan (Iteration Plan)
Distribute the Business Process Simulation to:
ambassador users
the project manager
Back to Top
QUALITY CRITERIA
Are the business metric objectives sufficiently qualified and quantified for comparison with the results of the business process?
Are the Simulation Models sufficiently representative for real world situations?
Do the Simulation Models take events from the Business Calendar into consideration?
Is Simulation Model properly documented regarding which real world situation it represents and where the metrics are based on?
Back to Top
RA.015 - DEVELOP BUSINESS USE CASE MODEL
In this task, you develop the Business Use Case Model. The Business Use Case Model provides an enterprise-level framework from which the Use Case Model (RA.023)
can be built upon, if necessary.
For projects that involve the upgrade of Oracle products, this task can be used in combination with RD.011 (Review Future Process Model) to help the project team
understand interactions between the actors and the business.
The Business Use Case Model provides the business context in which the system under discussion (SuD) resides, and with that support a better understanding of the
purpose, as well as of the scope of the system. It describes what the business does (business processes) and who does it (customers, employees, vendors, all known as
actors). The Business Use Case Model provides an enterprise-level framework from which the system use cases can be elicited, and the Use Case Model (RA.023) can
be started. Heres an example of a Business Use Case Model:
The key difference between the Business Use Case Model (above) and the Use Case Model (below) is that the Business Use Case Model has the enterprise business
and/or organization as a scope (and may cover aspects that are outside of the scope of the current project, meaning that some business use cases may not be subject to
implementation), whereas the Use Case Model has the system as a scope (and is used to define the set of requirements that are within scope of the current project,
meaning that all system use cases are subject to implementation). Heres an example of a Use Case Model (RA.023):
In a commercial off-the-shelf (COTS) application implementation, you may have access to pre-existing, multi-level business process models, which depict how the future
application system supports the business functions being addressed by the project. If such process models are available, leverage the top-level models (i.e., Level 1 or
Level 2) to help identify the enterprise-level business functions in scope, and the actors who participate in those functions, for developing the Business Use Case Model.
#TOP #TOP

The Business Use Case Model represents the highest-level view of the operations or processes performed within a business area. This model should not describe
system and/or implementation details but should focus mainly on the business processes. This model generally relates to the Level 1 Business Process Modeling that is
performed during the Inception phase. Examples of business use cases (from the customers perspective regarding a retail store) are: Browse for Product, Purchase
Product, and Return Product.
Back to Top
ACTIVITY
Back to Top
WORK PRODUCT
Business Use Case Model - The Business Use Case Model is a model of the interior of the business. Goals are set at the level of workers groups, customer sets,
suppliers, etc. It models what this organization does and how it is organized to deliver value. The Business Use Case Model has the design scope of enterprise. You are
discussing the behavior of the organization, its departments and their relationship with customers, suppliers, worker groups, etc. The focus should be on the operation of
the business rather than its computer systems. This model can serve as a supporting input for the MoSCoW List (RD.045) and the Use Case Model (RA.023). Usually,
the Business Use Case Model consists of (business) use case descriptions. Optionally the Business Use Case Model includes a set of use case diagrams that serve as
an index to the use case descriptions.
Refer to the White Paper: Getting Started with Use Case Modeling as referenced in the Templates and Tools section below for guidelines on how to organize use cases
with use case diagrams.
Back to Top
TASK STEPS
One way to identify business use cases is by starting to identify the actors that have a goal with respect to the business and the events to which the business responds.
Examples of such triggering events, as they are called, are Hire new employee or Receive purchase order." The business use cases document the response of the
organization to these triggering events. To be able to document how external systems are involved, these systems can be included as actors.
1 Find business actors. In this step, identify the main business actors representing
groups of workers (or departments), clients, suppliers that may interact with the
organization. This step can be performed by facilitated workshops (JAD),
brainstorming, interviews, checklists, or examining existing documentation.
Business
Actor Model
The Business Actor Model contains the business actors
discovered during Business Use Case Modeling workshops. Each
business actor represents a role played in relation to the business
by someone or something in the business environment. Actors are
broadly of two types:
Internal Actors - Roles within the enterprise units of the
enterprise (e.g., Customer Service Representative, Sales
Manager)
External Actors - Roles that are external to the enterprise
(for example, Customer, Vendor, Partner). The actor
specification must include the names, role and responsibility
of the actor and for what they use the system.
Following are some of the attributes that can be maintained for
actors:
Name
Description
Kind (Person, System, Device, etc.)
Category (Internal, External)
Superior Actors (in the actor taxonomy)
Subordinate Actors (in the actor taxonomy)
Use Cases (through which the actor communicates with the
system)
2 Find candidate use cases. In this step, use top-down and bottom-up approaches
to discover candidate (business) use cases.
Top-down: From the main activities and workflows, detail the goals of each
actor;
Bottom-up: From each actor point of view, figure out if all goals of that actor are
described.
Actor-Goal
List
or
Business
Use Case
Diagram
At the business level, and using JDeveloper, sometimes it is easier
to draw an UML Business Use Case Diagram. If some important
description is necessary at this point, include it in your diagram or
list. You can use simple brief descriptions or the "casual-dressed"
format. The bottom-up approach is one of the most important uses
for the actors.
3 Add detail to each business case. In this step, each business case is detailed at
the adequate level. Use the casual or fully-dressed models accordingly with
project necessity. Remember that the business use case should be a document
written in user language and does not substitute the user-goal system-level use
cases that will be used in estimating and planning the project.
Business
Use Case
Details
To develop the Business Use Case Details, detail for each use
case should be put in writing in the use case form (available as a
separated template or inside a tool repository such as JDeveloper).
Back to Top
APPROACH
Developing the Business Use Case Model can be accomplished in several different ways. Depending on the size of the solution being developed, you can use interviews,
meetings, workshops, as well as a combination of these methods or a series of meetings and workshops. This task may be one of many tasks being addressed in a
The Business Use Case Model is developed to increase the understanding of the organization and environment in which the SuD will be embedded. This model utilizes
the use cases tool to represent the interactions of the business with the external environment typically done without referring to the SuD itself. This task is usually done
when the project team lacks specific knowledge about the company or industry. It is also appropriate for increasing understanding during organizational changes.
As in the use case approach, business use cases should be developed with the pattern BreadthBeforeDepth; develop first an overview of the use cases, then
progressively add details. Task steps 1-2-3 above should be iterated to reach a good model.
Since this model is a support for increasing understanding, the project team should focus primarily in providing necessary information or context for the SuD. Avoid the
risk of Analysis Paralysis.
In case no Future Process Model (RD.011.1) has been created, business use case modeling may be done as an alternative to or in combination with business process
modeling. But even when a Future Process Model (RD.011.1) is available, creating a Business Use Case Model could add value. The added value of business use cases
to process models is that use case descriptions can capture aspects that typically are not covered by a business process model, such as the following:
With a use case description you can capture the complete set of stakeholders involved with a use case, whereas with a business process you normally only model
the primary actor. As a result, requirements of stakeholders other than the primary actor might be discovered more easily.
A proper use case description contains a clear statement about its goal. The effort of describing that forces you to properly think about the scope of the use case.
As a result you might discover other use cases.
Depending on the required level of detail, use case descriptions offer the opportunity to capture aspects, such as, pre-conditions and post-conditions. Especially
capturing pre-conditions may help in discovering other use cases that are needed to set those pre-conditions.
When a Business Use Case Model is derived from the Future Process Model (RD.011.1) created in combination with business process modeling, the most effective way
of doing so is by starting to detail business process models to the level where the steps in there are comparable to user-goal level business use cases and from there
create use-goal level business use cases to complete the requirements models. Creating business use cases can be a perfect way of validating the business process
models bottom-up and provide the starting point to create the Use Case Model (RA.023) that captures the requirements of the SuD.
The following picture illustrates how the Future Process Model (business process models) map to the Business Use Case Model (for projects where both approaches are
combined) and how the Business Use Case Model maps to the Use Case Model.
Back to Top
Business Intelligence (BI)
This task has supplemental guidance that should be considered if you are doing a custom Business Intelligence (BI) implementation. Use the following to access the task-
specific custom BI supplemental guidance. To access all BI supplemental information, use the OUM BI Supplemental Guide.
Back to Top
Business Analyst Develop the business use cases. Facilitate the workshops where the business use cases are modeled. Record/document the
model.
If a Requirements Analysis (or other) team leader has been designated, 20% of this time would be allocated to this individual,
leaving 60% allocated to the business analyst. The team leader would then facilitate the workshops where the business use
cases are modeled.
100
Ambassador User Provide information for the business use cases. *
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.BA.015)
These work products provide information on stakeholders who may also be actors in the Business Use Case Model.
High-Level Use Cases (ENV.BA.060)
Candidate Business Rules
(ENV.BA.080)
(ENV.GV.030)
Use these Envision work products or similar enterprise-level documents, if available. You may need this information before
you can begin this task. Therefore, if they are not available, you should obtain this information prior to beginning this task.
Business and System Objectives This work product is used to ensure that the focus on developing the Business Use Case Model remains within the business
(RD.001) objectives.
Future Process Model (RD.011.1) This model is used to identify actors and to identify possible business use cases.
(RD.020)
The High-Level Business Descriptions is used to identify possible requirements for business use cases.
MoSCoW List (RD.045) The MoSCoW List is used to identify the key areas to include in the Business Use Case Model.
Back to Top
TECHNIQUES
Technique Comments
Management
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
RA-015_BUSINESS_USE_CASE_MODEL.DOC MS WORD
RA015_BUSINESS_USE_CASE_MODEL.ZIP This zipped file contains an MS VISIO template and stencil to assist you in creating a Business
Use Case Model in MS VISIO that can then be inserted into your Business Use Case Model
document.
Tool Comments
Getting Started with Use Case Modeling JDeveloper - JDeveloper Use Cases model with scope = organization can be used to model
Business Use Cases. A separate project can be used to differentiate from other scope levels.
To generate the project documentation, select the project and use the javadoc function.
Getting Started with Activity Modeling (regarding the use case
details)
JDeveloper
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE
UNIFIED METHOD (OUM)
Provides a scenario example that will be useful when performing this task
Example Comments
Business Use Case Model MS Visio
Back to Top
The Business Use Case Model is used in the following ways:
to check the understanding of the project team and the client about the business needs and work
to increase the understanding about the environment where the system under discussion (SuD) is inserted
to identify gaps between the current and future Business processes
to provide input into task RA.023, Develop System Use Case Model
Distribute the Business Use Case Model as follows:
to client and Oracle project managers - This document is written in non-technical language for managerial level and should be checked by the project managers.
to all the analysts and designers
to the client project team as well as for the whole project team to increase the understanding about the environment
Back to Top
QUALITY CRITERIA
Are the business use cases presented in a written format (an additional UML use case diagram may complement)?
Are Use cases written in user language being clear and easy for people outside the project team understand?
Is the focus on what the business does and how its interactions bring value?
Are only the areas and departments that influence the system under discussion (SuD) modeled?
Check task, Develop Use Case Model (RA.023) for additional quality criteria for use cases.
Back to Top
RA.019 - DEFINE PROJECT REFERENCE ARCHITECTURE
In this task, you identify the enterprise architectural strategy documented as part of the enterprise Technology Reference Architectures (EA.075) and Applications
Architecture (EA.140), and how they should be applied to the project. From there you determine the Project Reference Architecture. The Project Reference Architecture
also addresses those architectural aspects that are relevant for the project, but that were not addressed in the enterprise architectures.
The items to identify are:
Technology Reference Architectures (EA.075)
Architectural Roadmap, comprised of Future State Transition Plan (ER.170) and IT Portfolio Plan (IP.060)
Governance Strategy (GV.010)
The items to determine are:
Project Reference Architecture
Project Policies
For projects that involve the upgrade of Oracle products, this task would typically be required if the project involved the migration from one type of architecture to another.
ACTIVITY
Back to Top
WORK PRODUCT
Project Reference Architecture - The Project Reference Architecture includes the following components:
References to Relevant Technology Reference Architectures
Listing of Reference Architecture Deviations, including motivations
Project-Specific Architectural Principles, Standards and Guidelines
Project Policies, including relevant enterprise-level policies
Back to Top
TASK STEPS
1 Identify relevant Reference
Architectures.
Reference
Architectures
List
The Reference Architectures List is a listing of the Reference Architectures that are relevant for the project,
including enterprise Technology Reference Architectures (ENV.EA.075), technology or industry-specific
Reference Architectures, and Applications Architecture (ENV.EA.140).
2 Determine any deviations from
the relevant Reference
Architectures and document the
motivation for the deviation.
Reference
Architecture
Deviations
The Reference Architecture Deviations contains an overview of where the project deviates from the application
Reference Architectures. It also includes the reason why the project chooses to deviate. The reason is
particularly important when the project chooses to deviate from the relevant enterprise Reference
Architectures.
3 Determine Project Architectural
Principles, Standards and
Guidelines.
Project
Architectural
Principles,
Standards and
Guidelines
The Project Architectural Principles, Standards and Guidelines contains the architectural principles, the
standards applicable for each principle and guidelines to which the project should adhere, including references
to relevant enterprise-level architectural principles, standards and guidelines. Any deviations from the latter are
documented and motivated as part of this component.
4 Define Project Policies.
Summarize the findings of the
previous steps and create
associated Project Policies.
Project Policies The Project Policies describes policies that are relevant for the project. This includes any additional enterprise-
level governance prescribed to your project.
Back to Top
APPROACH
Identify Relevant Reference Architectures
Determine if there is an existing enterprise Reference Architecture that applies to the project. One may be existing in the enterprise or may have been created as an
earlier run of this task in another project or as part of an Envision engagement (ENV.EA.075, Technology Reference Architectures). If none of these exist, then you may
want to look for any relevant Reference Architectures available in the market.
Determine Deviations from the Chosen Reference Architectures
Review the chosen Reference Architecture to see if it provides everything you need as part of the Reference Architecture for your project. Also, see if all the elements of
the Reference Architecture are appropriate for your project. Document any deviations, including the motivation of why you deviate and choose to do it differently for your
project. If you deviate from the enterprise Reference Architecture, this should be made clear. If many projects deviate from the enterprise Reference Architecture, this
may be a reason to update the enterprise Reference Architecture, rather than deviating from it on every project.
Enterprise architects may have to provide an exemption for every deviation of enterprise-level Architectural Principles.
Determine Project-Specific Architectural Principles, Standards and Guidelines
If anything is missing from the chosen Reference Architecture that you need to have in place, it is recommended that you define a baseline to be used for the project by
conducting a workshop with the organization architects. While you concentrate on the needs of the project, you should try to stay agnostic enough so that this can be
reused for a later update/creation of the enterprise Technolgy Reference Architectures.
For example, with a SOA approach, you would review the chosen Reference Architecture to check if it provides a clear definition of a service and its components. Then
check which taxonomies the architecture defines to classify services and to manage Architectural Policies with design and implementation guidelines. If anything is
missing, you should use the Service Architecture technique as a source of leading practices and an input to define the blueprint for the project.
Refer to the enterprise Technology Reference Architecture for SOA (ENV.EA.075) for for guidance on developing the Project Reference Architecture for SOA at the
project level.
IDENTIFY THE ARCHITECTURE ROADMAP
Determine if there is an existing enterprise Roadmap that applies to the project. One may have been created as part of an Envision engagement (ENV.ER.170, Develop
Future State Transition Plan).
Review the Roadmap to understand if and how it may impact this project. For example, it may be that some aspects of the project may take a higher precedence than
they otherwise would because the have a high priority in the Roadmap.
IDENTIFY GOVERNANCE STRATEGY
As an example, if you are following a SOA approach, determine if the customer has an Enterprise Repository to support portfolio management and what service portfolio
governance the customer has in place. There may be one existing in the enterprise or it may have been created as part of an Envision engagement (ENV.GV.096,
Services Meta Data Description).
If the organization already has a Service Portfolio Management Strategy as part of the Governance Strategy (GV.010) and an Enterprise Repository, discover what the
impact is for your project. You will probably have to follow some rules as part of the delivery aiming at sharing information about the services you create and reusing
existing SOA services the enterprise already has. Learn how you can use the repository to manage the service lifecycle and support multiple versions of the same service
in parallel. Review the repository for repository assets that your project will use or create.
Refer to the SOA Service Lifecycle technique to understand the lifecycle used in OUM including the asset types suggested for collaboration and management during the
project. Map that level to the available setup of the customer. If there is a gap, try to clarify with the customer, how it should be covered.
If the organization does not have an Enterprise Repository in place for managing SOA services, discuss creating one with the customer. If an Enterprise Repository is not
an option, you may have to manage your own repository within your project. Do not try to manage SOA services without a repository, be it an Enterprise Repository
product (such as, Oracle Enterprise Repository), a simple database or a collection of spreadsheet files. This would otherwise jeopardize creating a catalog of SOA
services that effectively supports reuse and with that provides return on investment for creating such a catalog.
Refer to the Services Meta Data Description (ENV.GV.096) task for details of the enterprise version of the repository which you should attempt to approach at the project
level.
Note that in order to simplify service integration, it is recommended that the Service Portfolio uses at least the following 3 taxonomies:
Business Context Taxonomy: This taxonomy is used to classify the functionality of a service in business terms. This will improve discovery of already existing
assets the project can reuse.
Architectural Layer Taxonomy: This taxonomy is used to identify the technology to be used to deliver the service.
Scope Taxonomy: This taxonomy helps classify the planned usage of a service within the organization.
Define Project Policies
Summarize the findings of the previous steps and create the associated project policies. You also should review any additional governance requirements that apply to
your project and ensure that you comply with the relevant enterprise Governance Model, if any. This typically takes the form of steps that must be carried out (e.g., check
in asset in the repository), procedures that must be followed (for example, project architecture approval procedure) or documents that must be written (for example,
support strategy for your services) as defined by the enterprise.
For each policy you need to track, add a policy asset to either the enterprise or project repository, as identified in the previous step.
Finally, refer to the enterprise Technology Reference Architectures (ENV.EA.075) for details on the enterprise Technology Reference Architectures and for guidance on
developing the Reference Architecture at the project level.
Back to Top
Back to Top
System Architect Define SOA Reference Architecture. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Governance Strategy
(ENV.GV.010)
Governance Policies
Catalog
(ENV.GV.030.1)
Future State
Enterprise
Architecture
(ENV.EA.110)
If available, these documents may have already established how the architectural strategy supports the overall Business and IT strategy. The
Future State Enterprise Architecture is probably not yet available at the time this task is executed. See if the enterprise has an equivalent
type of document.
Architectures
(ENV.EA.075)
If available, use any relevant Technology Reference Architectures (for example, SOA Reference Architecture) to gather details on the
enterprise version of the relevant Technology Reference Architecture for guidance on developing the Project Reference Architecture.
Services Meta Data
Description
(ENV.GV.096)
If you are using a SOA approach, and if available, use the Services Meta Data Description to gather the details of the enterprise version of the
repository which you should attempt to approach at the project level.
Plan (ENV.ER.170)
IT Portfolio Plan
(ENV.IP.060)
If a relevant Architectural Roadmap does exist, use this as an input to see how the relevant architectural aspects may be applied into your
project.
Back to Top
TECHNIQUES
Technique Comments
SOA Service
Lifecycle
If you are using a SOA approach, use this technique to understand the lifecycle used in OUM including the asset types suggested for collaboration
and management during the project.
Service
Architecture
If you are using a SOA approach, use this technique to define requirements for the Project Reference Architecture.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
RA.021 - CAPTURE USER STORIES
In this task, User Stories are developed. This task is used to document requirements when using a Scrum approach for managing the project. User Stories are high-level
requirements. They are developed and discussed by the stakeholders, product owner, and Scrum team. They provide information about the high-level requirements
written in the language of the business user. This task can be used in conjunction with use cases when using a blended approach (Unified Process, in combination with
Scrum techniques).
Before reading this task you should read the Managing an OUM Project Using Scrum technique.
ACTIVITY
RA.021.1
RA.021.2
RA.021.3
Back to Top
WORK PRODUCT
User Story - The User Story provides requirements when using a Scrum approach to managing an OUM project. It should be noted that User Stories are meant to be
done in a short form, either on an index card or half sheet of paper.
Back to Top
TASK STEPS
1 Prepare User Story Heading. This is usually done during Inception or early in
Elaboration. The product owner working with the stakeholders and users prepares the
initial User Story.
User Story
Name and
Identifier
The recommended wording for the User Story Name is
a sentence as follows:
As a USER NAME I want to VERB ACTION, so that I
can USER GOAL.
The Identifier is a unique identifier assigned to the User
Story.
2 Describe the User Story. The product owner working with the stakeholders and users
assists in the preparation of a brief description.
User Story
Description
The User Story Description is a high-level description of
the requirements; usually no more than 2-3 summary
sentences. This is similar to the Brief Description of a
use case in a Use Case Model (RA.023).
3 Develop the test completeness criteria that will be used to confirm completeness of the
User Story during the Sprint and Sprint Review meeting.
Completeness
Criteria
This section includes a definition of the criteria for when
the User Story is Done. It is sometimes written in a
structured manner, using the following format:
"Given <starting conditions> when <event> then
<result>. "
4
(Opt)
Outline the steps expected to complete the User Story at a high level. This can be done
during sessions referred to informally as Backlog grooming sessions. The User Stories
are further refined before a Sprint Planning meeting.
The product owner working with the Scrum team develops these steps as a result of
Steps This section documents the steps of preparing the User
Story. Steps briefly describe what must be done using a
numbered order of priority. Steps use simple wording to
describe WHAT should be done Examples are:
discussions with the users and the Scrum team. It is documented by the product owner
and the Scrum team based on their discussions.
Develop test plan.
Prepare prototype.
Create user interface.
This component does not have to describe the details
of HOW the step is to be accomplished.
5
(Opt)
For each step, develop the high-level estimated effort to give the User Story a size.
During the Sprint Planning meeting, the Scrum team prepares an estimate of the effort
by step.
Steps are given initial resource assignments as organized by the Scrum team.
The Scrum team may finish User Stories for a particular Sprint and then go back to the
product owner to negotiate which User Stories can be brought into the Sprint.
Note: Scrum teams are self organizing and they determine how to track the estimate
and resource assignment. This can be done within the User Story at the step level.
Alternatively, step estimates and resource assignments can be recorded in a central
place on the Sprint Backlog sheet of the MoSCoW List (RD.045), making this task step
optional.
Effort
Estimate
An Effort Estimate is assigned for each Step. The Effort
Estimate includes initial resource assignments for each
step.
6 Assign an estimated effort for the User Story. This is done by the Scrum team, and
provides feedback to the product owner on the level of effort expected to complete the
work.
If Steps were outlined for the User Story, add the Step Effort Estimates together to
come up with a Total Effort Estimate for the User Story.
If no Steps were detailed, record the Total Effort Estimate for the User Story as
determined during discussions in the Sprint Planning meeting.
The ScrumMaster uses the Total Effort Estimate (together with the other User Stories
for a Sprint) to prepare the Burn Down Chart.
Total Effort
Estimate
The Total Effort Estimate is the sum of the Effort
Estimates for each Step.
7
(Opt)
Obtain product owner sign-off.
During the Sprint Review, the stakeholders confirm that the User Story has been
completed. This is an optional step and there may not be a formal sign-off. The entry of
the date the User Story was completed at the Sprint Review meeting would be an
alternative.
Product
Owner Sign-
Off
The Product Owner Sign-Off may be a formal sign-off
confirming the User Story has been completed.
Alternatively, the Product Owner Sign Off may just be
an entry of the date the User Story was reviewed and
completed in the Sprint Review meeting.
Back to Top
APPROACH
User Stories are used when taking a Scrum approach to custom development of components of the system that are not defined at a detail level. Instead, they are a very
high-level description of a requirement. They include just enough information so that the Scrum team can produce a reasonable estimate of the effort to implement the
requirement. User Stories are a key artifact when using a Scrum or Extreme Programming approach.
Initial high-level User Stories may be prepared during Inception. They usually include only the User Story name and an identifier.
In a Scrum approach, the User Stories are written by the project stakeholders, in business language. The Scrum product owner acts as a liaison among the stakeholders
and represents their requirements to the Scrum team with knowledge of the detailed functional requirements and the User Stories.
Periodically, there are Product Backlog grooming meetings. These are done ahead of the Spring Planning meetings. The Scrum product owner (may also be referred to
as an ambassador user or business analyst) and the stakeholders meet and have conversations that develop a mutual understanding of the requirements. The product
owner working among the stakeholders and users prioritizes the User Stories. In some cases, they may prepare the User Stories in more detail as described in Task
Steps 4 and 5. The focus is on discussing the requirements, not documenting them in great detail. This usually occurs in the Elaboration phase just before a User Story is
nearing development in an upcoming Sprint (often done two Sprints ahead of the Sprint it is targeted for). It is important not to go too deep into the Product Backlog in
detailing User Stories. This is because some User Stories may be less architecturally significant than others, perhaps even later determined as not needed. In addition, it
may be that the requirements are adapting further with each Sprint, so detailing the User Story too early might be work that never needs to be done.
Those User Stories identified for the next Sprint may need more detail added in Testing (Completeness Criteria) in order to facilitate the Testing process. This is most
often the result of the Sprint Planning meeting.
As each User Story is developed, it becomes part of the Product Backlog (which may also be managed using the Product Backlog sheet in MoSCoW List (RD.045).
During the Sprint Planning meeting, the Scrum team uses the User Stories to estimate the size of the work to be accomplished within the agreed upon timeframe. They
review the User Stories to determine how many user stories can be completed within a single Sprint (similar to an iteration in OUM). The agreed upon User Stories then
become the Sprint Backlog (which may also be managed using the Sprint Backlog sheet in the MoSCoW List (RD.045). The User Stories should be no more than 3
person weeks of effort. If the User Story is larger than 3 person weeks, it should be broken down into smaller User Stories. Once agreed upon during the Sprint Planning
meeting, the Sprint Backlog is set. The ScrumMaster facilitates the Scrum approach and maintains the leading practices. The Sprint Backlog remains static and should
not be changed in mid-Sprint.
This task includes a work product template. This is meant to provide an idea of the format of the User Story. Most often they are hand written on an index card, however
when using virtual teams, these cards may need to be put into an electronic format so that they may be shared among the Scrum team.
Some similarities between well-written User Stories and use cases:
1. They should be as complete as possible before going into an iteration/sprint. Verb Noun phrases are important in the User Story Name just as they are in the Use
Case Name.
2. There should not be any Design language included. Software component requirements should be described using the language of the business stakeholders.
3. They should be independent of each other.
4. They should be written using clear statements (avoid use of words and, or, technical words and other words that might introduce confusion). The details are
negotiated between the users and the developers. They should be written clearly enough for the Scrum team to estimate them.
5. The must be testable and they should be of value to the business.
6. It is important to have a good understanding of the definition of done, what is included and what is not included between the stakeholders and the Scrum Team.
Fully-dressed Use Cases are described using the Use Case Specifications (details). In User Stories, the details are often determined during a discussion that
details out the testable steps (see task step 5).
Scrum and User Stories are used when the requirements are more adaptable. When requirements are more predictable and less volatile to change, use cases may be
more appropriate.
Use cases are simple, they contain what is referred to by those in the Agile community as the three Cs; Card, Conversation, and Confirmation. User stories are typically
written on a card (or a half sheet of paper). They do not contain all the details, just enough information to identify the main requirement. The requirement is then
communicated from stakeholders to the Scrum team through discussions that further clarify the requirement. The conversation part of this is usually verbal, but
prototypes or examples of what is being asked for through the requirement may also be discussed. The third C, Confirmation is the completeness criteria in combination
with the acceptance test.
Prepare User Story Heading
Prepare the User Story Name and Identifier. In the Agile community, this type of wording is most often used in structured User Story Names:
As a <user also referred to as Actor>
I want <Verb - stating business functionality>
So that I can <business value or goal statement>
A User Story Name can be very informal, or more structured. Some examples of informal or unstructured User Story Names are:
Warehouse Managers can track the details of a recycling pick up.
Receiving Agents track the details of recyclable packaged goods used in a shipment.
Some examples of more structured User Story Names are:
As a Warehouse Manager, I need to capture recycling pickup information so that I know the expected refund for recycling the goods.
As a Receiving Agent, I verify the use of qualified recycling materials to capture the use of recycling materials in a shipment.
User Stories can be used for non-functional and technical requirements in addition to the functional requirements given in the examples above. For example:
As a Procurement Manager, I want to monitor supplier performance so that I can manage the suppliers with which I do business. [Functional]
As a Procurement Manager, I want the Supplier Performance provided in a graphical Dashboard format so that I can graphically review the information. [Technical]
As a Procurement Manager, I expect Supplier Performance Dashboard information to be provided in the Dashboard in less than a 45 second response time.
[Supplemental or Non-Functional]
The User Story Identifier can be a number or a number-letter combination. You may use this to organize the User Stories for a particular functional area, or simply to
provide a unique identifier that differentiates a User Story from others. The identifier format standard should be a project standard as set out by the project manager in the
Configuration Management Plan and Processes (CM.010).
Describe the User Story
The User Story Description is usually not detailed until early in the Elaboration phase of the project. This section can be as much detail as is needed to record the results
of the product owner, stakeholders and the Scrum team. This can reference recorded notes, prototypes or other source documents to be used as references during the
Scrum Sprint.
Develop the Test Completeness Criteria
This section includes the acceptance test criteria that the user prepares in order to confirm that the story is completed. This is developed as the User Stories are
discussed during Spring Planning meetings. This criteria is sometimes written in a structured manner using the following language:
Given <starting conditions> when <event> then <result>.
Outline the Steps
The Steps are usually not detailed until one or two sprints before the User Story is to be used as input to a Sprint. This section is optional depending on the level of detail
being used by the Scrum team. Samples or examples are also helpful to define the steps required in order to create the result described in the User Story Completeness
Criteria.
Develop the Estimated Effort
During the Sprint Planning meeting, the Scrum team prepares an estimate of the effort (optionally by step). The estimated effort is the estimated size or effort required by
the Scrum team to complete the User Story. It is used during the Sprint Planning meeting. The User Stories to be included in the Sprint are negotiated between the
product owner and the Scrum team. The Scrum team formulates the estimates and must be able to determine what can be done in the time provided in the Sprint.
Obtain Product Owner Sign-Off
During development of the User Story, it is reviewed by the stakeholders, the product owner and the Scrum team. The User Story is meant to record the requirements as
stated by the user, and to allow communication between all involved parties. During the Sprint Review, the stakeholders confirm that the User Story has been completed.
This is an optional step and there may not be a formal sign-off. The entry of the date the User Story was completed at the Sprint Review meeting would be an alternative
to a formal signature.
Back to Top
Business Analyst Acts as a Scrum product owner. Assist in preparation of the User Stories. This may also be performed by someone designated
as a team leader who does not have development responsibilities on the project.
60
System Analyst Assist in preparation of the User Stories. This role may be filled by any Scrum team member. Scrum team members include
technical writers, designers, developers and testers.
40
Project Manager Acts as a ScrumMaster. This person has been trained and certified as a ScrumMaster. The person designated to fill this role is
usually not part of the Scrum team or responsible for development of the User Story.
*
Ambassador User Prepares the User Stories with assistance from the the business analyst and system analyst. Explains the details of the
requirements to the Scrum team.
*
Back to Top
PREREQUISITES
In a blended approach (combination of Unified Process and Scrum), the prerequisites are in line with the prerequisites for the Use Case Model (RA.023) and the Use
Case Specifications (RA.024).
In a pure Scrum development effort, you need the following for this task:
Prerequisite Usage
Product Backlog sheet of the MoSCoW
List (RD.045)
The Product Backlog sheet is used to catalog the list of User Stories as they are developed prior to a Backlog Grooming
or Sprint Planning meeting.
Back to Top
TECHNIQUES
Technique Comments
Managing an OUM Project using Scrum Use this technique to understand how to manage an OUM project using the Scrum approach.
Back to Top
TEMPLATES AND TOOLS
RA-021_USER_STORY.DOC MS WORD - This template includes both a short form User Story template and a longer form that can be used if more detail is needed.
Tool Comments
Scrum Resources This link accesses helpful Scrum resources.
Back to Top
The User Story is used in the following ways:
to capture business requirements at a high level
to convey the requirements from the business stakeholders to the Scrum team
to size and prioritize the work that needs to be done
Distribute the User Story as follows:
to the Scrum team (Development team) for use in a Scrum Sprint
Back to Top
QUALITY CRITERIA
Is the User Story as complete as possible, without going into detail about how something will be designed or built?
Can the work be estimated based on what is written in the User Story?
Does the User Story produce something that is of value to the business?
Is the language of the User Story stated in present tense language and written using clear statements?
Is the User Story independent of other User Stories?
Are the statements in the User Story testable?
Is it possible to understand what the result of the User Story will be and is there a clear definition of what it means to be "done?"
Have you applied the INVEST mnemonic to the User Story?
Have you applied the SMART mnemonic to the User Story?
Back to Top
RA.023 - DEVELOP USE CASE MODEL
In this task, the use cases and actors are refined into a consistent model creating a first-cut view of system scope. Determine who (or what) interacts with the system
(actors) and the objectives of this interaction (goals). Actors and use cases are refined in order to create a consistent model. At this point the use case details for each
use case in the model have not been specified.
In a commercial off-the-shelf (COTS) application implementation, the Use Case Model complements business process models in helping the implementation team gain a
thorough understanding of business requirements. At a minimum, the Use Case Model should be developed for those requirements that can only be satisfied through
custom-built components that extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems. Development of a Use
Case Model for all other business requirements is considered helpful, as they contribute to a better understanding of requirements and can be leveraged to prepare a
number of other required work products downstream, such as test scenarios and business procedures documentation.
For projects that involve the upgrade of Oracle products, this task can be used in combination with RD.011 (Review Future Process Model) to help the project team
understand interactions between the actors and the system. The focus should be on reviewing the client's existing use case artifacts rather than creating new ones.
The Use Case Model focuses primarily on defining the high-level functionality of the system under discussion (SuD). This is done from the actors point of view (both
human and non-human actors) and uses both a diagram and a brief description to define the functionality of the system.
The following is an example of a Use Case Model. It represents the system functionality that will automate all or part of the business operations described by the
Business Use Case Model (RA.015), and together with a set of supplemental requirements, the Use Case Model defines the scope of requirements for the project.
Use Case
Name
Description
Return
Product
This use case begins when the customer returns a
previously purchased product. The PoS verifies the
receipt with its records and credits the customers
credit card. The use case ends when the system
generates a receipt indicating the purchase has been
credited.
Back to Top
ACTIVITY
RA.023.1
RA.023.2
#TOP #TOP
RA.023.3
Back to Top
WORK PRODUCT
Use Case Model - The initial Use Case Model (diagram and descriptions together) provide essential input for Analysis, Design and Testing and should be the basis for
determining project scope. The Use Case Model includes the following components, as the Use Case Model is iterated on, the components are evolved:
Use Case Diagram - During the Inception phase the Use Case Diagram is a graphical depiction developed at least up to the point that the user-goal level use cases have
been determined. In its simplest form this results in an Actor-Goal List, but it is best to draw the diagram to show which actor interacts with each use case.
Use Case Brief Description - .Additionally, a brief description can be written for each use case which describes the start, end, and high-level process performed by the
use case. Optionally, the names and a brief descriptions of each use case can serve as an index to the use cases depicted in the diagram.
In later phases, more detail is added to the model. In fact, the Use Case Specification (RA.024) actually makes the model more complete as a progressive refinement of
the use case takes place. Additionally, it can provide input into the Glossary (RD.042) and Supplemental Requirements (RD.055). The Use Case Model can be derived
from business models, such as, the Business Use Case Model (RA.015), process models, the project proposal and the MoSCoW List (RD.045). When the latter has been
produced, the MoSCoW List already might have the format of an Actor-Goal List.
The System Use Case Model represents the system that will automate all or part of the business operations described by the Business Use Case Model. The system
Use Case Model focuses primarily on the interaction between the actors (both human and non-human) and the system. This model generally relates to the Level 2
business process modeling that is performed during the Elaboration phase. Examples of system use cases (from the customers perspective regarding a Purchase
Product Business Use Case) are: Scan Product, Calculate Price, Pay Bill, and Generate Receipt.
Back to Top
TASK STEPS
Creating use cases by end user-group (actors in Unified Process terminology) to document requirements ensures a better understanding of the business requirements.
Use cases must be specific, and testable. If the requirement cannot be specified in a use case following the RA.024 guidance, then additional refinement and discussion
of the requirements are necessary.
1 Find actors. In this step, we identify the
main actors representing the users, and
any other systems that may interact with
the system being developed.
Actor List The Actor List contains a list of actors and their description. Actors are roles that users or other
systems take on in the system. Include one or two phrases describing each actor. There is a technique
that suggests not only eliciting actors but also personas - a person from the real world that can assume
this role. Instead of calling only an ATM user, people that would really interact with it are represented:
an office-boy called John, a grandma called Mary, an executive called Larry. If the business actor
model was already created, you can refine business actors via actor generalization/ specialization.
2 Find use cases. This step is usually
performed in workshops with
representative users with decision power
(key users, ambassador users). The
facilitator elicits answers about system
functionality by asking questions such as,
"What should the system do", and "Why is
this actor using the system?" For a
completeness verification, the facilitator
can use two approaches:
Top-down: From the main activities and
workflows, detail the goals of each actor.
Bottom-up: From each actor's point of
view, figure out if all goals of that actor are
described.
Actor-Goal
List (at user-
goal level)
or
Use Case
Descriptions
with
(optionally)
UML Use
Case
Diagrams
When a Business Use Case Model is available, the initial Use Case Model is derived from that by
analyzing the business use cases. As explained in the APPROACH section below, there can be a n:m
mapping from business use cases to system use cases.
In its simplest form an initial use case consists of a name, the stakeholders and a brief description of
the primary actor's goal. It is also practical to use some coding mechanism (like simple numbering
them from 1 to n) for reference purposes. The one stakeholder that "executes" the use case is
identified as the primary actor. Other stakeholders that are required to fulfill the goal of the use case
are called secondary actors
A Use Case Diagram shows a set of use cases and actors and their relationship. Thus providing a
functional view of the system, its major processes and a boundary on the system scope. It also
provides a graphical description of who will use the system and what kinds of interactions they can
expect to have with the system. By convention the primary actors are put at the left side of the
diagram, the secondary actors at the right and the use cases in the middle. Stakeholders that are not a
primary actor nor a secondary actor (but do have an interest in the goal of the use case) are left out of
the diagram. At this point of the development of the Use Case Model you can use simple brief
descriptions or the casual-dressed format. The use cases will be detailed in the subsequent task,
Develop Use Case Details (RA.024). The bottom-up approach is the one that provides the most
important usage for the actors.
3 Provide a brief Use Case Description Use Case
Description
A Use Case description is used to capture the intent of the use case and the expected post-
conditions. This is often referred to as the Use Case "Brief" Description. This description should not
represent detailed scenarios (which are captured in RA.024). Instead it should summarize the process
in three sentences or less:
This use case begins when <actor> <does something>
The system responds by..
This use case ends when .
4 Check use cases against the Enterprise
Repository (optional)
Checked
duplicate
requirements
If the customer is managing requirements at the enterprise level, check for duplicate or existing use
cases in the Enterprise Repository. If the requirement has already been implemented by a reusable
component (such as a SOA service) it may be possible to mark it as already implemented. Please
refer to the Enterprise Requirements Management technique for more details.
5 Define scenarios (optional) Use Case
Scenarios
Scenarios are different paths that the system will take when performing the Use Case. For example, the
Use Case Return Product can have these scenarios: a) Customer does not have a receipt, b)
Product was not purchase from this store, c) The Credit Card system is down.
This step should only list the possible scenarios, but should not explain how the system will handle
the situation.
6 If there are too many use cases to
comprehend in one level, group related
use cases into Use Case Packages.
Use Case
Packages
Use Case Packages:
Group related use cases.
Construct packages for each major actor.
Build lower-level packages for related uses.
This packaging approach re-emphasizes user-value organization.
7 Add supplemental material (optional). Glossary
Supplemental
Requirements
Sketches
and
Diagrams
The Glossary contains the terms used by the users that either are new to the project team or that are
dubious.
Supplemental Requirements contain requirements (aka non-functional) that do not fit in the use case
format.
Sketches and Diagrams can be created during the workshop to clarify what is being defined and
should be included as part of the specification.
Supplemental requirements found for a specific use case may lead to a more generic non-functional
requirement that should be included in the Supplemental Requirements (RD.055). Terms may also be
found that should be documented in the Glossary (RD.042).
8 Add use cases to Enterprise Repository
(optional)
Updated
Enterprise
Repository
If the customer is managing requirements at the enterprise level, the use cases need to be inserted in
the repository for tracking. The requirements should be linked to the enterprise functional, process
and/or domain models. Please refer to the Enterprise Requirements Management technique for more
details.
Back to Top
APPROACH
This task should first be performed during the Inception phase of every software development project after which the use cases are being worked out during the following
phases.
To determine the first versions of the model, it is recommended to gather appropriate ambassador users in a facilitated workshop. This will provide a broader acceptance
and sense of ownership by the client. Other techniques for eliciting use cases include:
Existing documentation examination;
Brainstorming (this can also be done as part of an facilitated workshop);
Interviews.
Often one or more of these techniques can also be used as a preparation for a facilitated workshop.
When a Business Use Case Model (RA.015) is available, the initial system use cases can be derived from there. Ideally the Business Use Case Model has been brought
down to the level of user-goal business use cases. First you identify all business use cases that will be supported by the SuD. All other business use cases are
considered to be out of scope. The remaining set of business use cases can either be transferred into system use cases (meaning that original business Business Use
Case Model will change into a Use Case Model), or you can copy the supported business use cases to system use cases, and keep the Business Use Case Model as is.
When transforming business use cases into or mapping them onto system use cases, you may find user-goal system use cases that support multiple business use cases.
Incidentally, you may find a business use case that is supported by multiple user-goal system use cases. This usually indicates that the business use case actually is not
a user-goal level use case, but a summary use case instead. When you decided to keep the Business Use Case Model, consider to bring down that business use case to
the level of user-goal use cases. This makes the mapping of the Business Use Case Model easier because then each user-goal business use case either is not
supported (out of scope / manual) or will have a 1:1 mapping on a system use case. Such a mapping is done, for example, when validating the completeness of the Use
Case Model. The following picture shows how business use cases can map to system use cases:
As illustrated above, in the business use case Archive Paper Order is a manual use case so there is no transformation to a system use case. For the business use cases
Place Customer Order and Place Self-Service Order it appears that they both can be supported by the same system use case Create Order (that is, for the sake of
argument as in real life this is not likely as working out the scenario probably will reveal). After working out the scenario of the Register Customer business use case, it
turns out that this actually consists of two actions, the first one being the customer registering himself resulting in the system sending a confirmation e-email, and the
second one where the customer confirms the registration by following a link in that e-mail. As there can be a time-span in between both actions the Register Customer is
not a true user-goal use case (as they will not always be completed in one single setting), so it is mapped on the two system use cases Register Self-Service and
Confirm Registration.
The process of identifying system use cases is critical for the scope understanding. In the process of detailing use cases, new risks are detected as well as
communication problems and lack of understanding. For example, in the example above at first one could have thought that self-service registration by a customer would
be supported sufficiently by a simple web form. After a proper analysis however, it is discovered that the functionality concerning the e-mail confirmations has an impact
on the solution architecture, which would likely have led to a significant scope creep would it have been discovered after scoping.
Iterate the task steps above and the techniques suggested to assure the completeness of the model. Note however, that the model will evolve throughout the project as
both client and developers become more familiar with the subject matter the system to develop should support. In practice some use cases might get worked out
including all extensions that can be thought of, while others will never be worked out beyond their briefs to which only a triggering event has been added. This depends
on how self-explanatory the use case brief will be to both end users on one side and developers on the other.
To save energy and make the process more effective, Cockburn recommends the approach Breadth Before Depth; first develop an overview of the use cases then
progressively add details. Some authors refer to this as having a "one mile wide, one inch deep view of the process." This also helps in determining the scope at an early
stage of the project.
Create an Actor-Goal List with all use cases at user-goal level (sea-level) and prioritize as we suggest in the MoSCoW List (RD.045). Add use case briefs (2-6 sentences)
to the use cases. The Actor-Goal List delimits the scope of the project and the scope of the use case modeling. Have a general idea of all use cases and a clear idea of
the scope of the system. Add detail in casual form if needed.
In the Elaboration and Construction phases the task is iterated together with a number of other tasks. See the process diagrams for these phases to see which tasks are
iterated as a task group. See the process flow diagrams in the Process Overview files to understand how these tasks are iterated as a group.
In each iteration, more detail is provided to the use cases in the order of their priorities. In most cases the priorities are set so that the most informative and important use
cases is given the highest priority. The more risky and architecturally-significant use cases should get a high priority to minimize risk.
For each use case, identify the triggering event and for the use cases that require this, write the main success scenario. In case of complex use cases or use cases that
have the most risks associated with them, for each step identify the exception conditions and after that the exception treatment. When an exception in its turn has many
steps, consider including it in its own extension use case.
You might want to organize use cases by splitting them into a number of sub-sets or partitions, and iteratively provide details for the use cases in one sub-set, before you
move on to the next sub-set with use cases. If you decide to split into subsets you would typically perform the whole iteration (i.e., all the tasks within the iterated group)
on this sub-set, before starting on another sub-set (unless you work on more sub-sets in parallel with different teams).
It is recommended to involve ambassador users throughout this process to make clarifications.
It is also highly recommended to support a peer-review process to assure quality and completeness of the use cases before making the model available to a broader
public.
Use Case Packages
If there are too many use cases to comprehend in one level, group related use cases into Use Case Packages. Use the following guidelines:
Look for high cohesion and low coupling.
Divide use cases initially based on functional aspects.
Organize by conceptualization-level use cases.
Refine using application-level use cases and scenarios.
Move use cases among packages to reduce the coupling.
The following is a simple process for packaging use cases:
1. Start with all use cases and no packages.
2. Package use cases by initiating actor.
3. Place include use cases in package with base use case.
4. Place extend use case in package with base use case.
5. Place reusable common use cases in their own package.
6. Place Utility use cases in their own package.
Back to Top
Back to Top
System Analyst Develop the Use Case Model and use cases. Facilitate the workshops where the use cases are modeled.
leaving 80% allocated to the system analyst. The team leader would then facilitate the workshops where the use cases are
modeled.
100
Ambassador User Provide information for the use cases. *
Back to Top
PREREQUISITES
The prerequisites listed in these tables are not necessarily "required" in order to complete the associated task. This is simply a comprehensive lists of prerequisites that
might be helpful when completing the associated task. Depending on the engagement, some prerequisites may be required, others may simply be helpful, but not
required and others may not be needed at all.
RA.023.1
Prerequisite Usage
Governance Implementation (ENV.GV.100) If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes)
describes how to govern the Use Case Model. Check for duplicate requirements and ensure that the the Use Case
Model is added/updated in the repository.
Business Use Case Model (RA.015) The Business Use Case model is refined into the consistent Use Case Model.
System Context Diagram (RD.005 )
These work products may be used as a basis to identify new actors and use cases, or to detail those identified in
the Business Use Case Model.
Current Business Baseline Metrics (RD.034)
MoSCoW List (RA.045.1)
RA.023.2
Prerequisite Usage
The Business Use Case Model and Future Process Model serve as input together with the initial Use Case Model
to determine refined versions of use cases and additional use cases.
Use Case Model (RA.023.1) The initial Use Case Model serves as input into the next version.
Validated Conceptual Prototype (RA.030) The review of the Conceptual Prototype may reveal new or changes to requirements that should be reflected in the
Use Case Model.
Gap Resolutions (MC.110) The Gap Resolutions are an input into the Use Case Model when use cases are being used to fulfill gap
requirements.
Reviewed Analysis Model (AN.110.1)
Reviewed Design Model (DS.160.1)
While analyzing and designing the use cases, refinements and corrections in the Use Case Model may be
necessary.
MoSCoW List (RD.045)
The MoSCoW List and Business and System Objectives provide input to help determine the priorities of the use
cases in the Use Case Model.
Architecture Description (RD.130.1) The Architecture Description describe factors that influence application architecture and describe strategies how to
deal with these factors. These factors and strategies should be taken into account while developing the Use Case
Model.
RA.023.3
Prerequisite Usage
Configured Enterprise Repository (ENV.GV.098) If available, use the Enterprise Repository to check for duplicate requirements and to add to or update the use
cases in the repository.
Use Case Model (RA.023.2) The refined Use Case Model serves as input into the final version.
Validated Functional Prototype (RA.085) The review of the Functional Prototype may reveal new or changes to requirements that should be reflected in the
Use Case Model.
While analyzing and designing the use cases, refinements and corrections in the Use Case Model may be
necessary.
Business and System Objectives (RD.001) The Business and System Objectives provide input to help determine the priorities of the use cases in the Use
Case Model.
Reviewed Requirements Specification
(RD.150.2)
The Reviewed Requirements Specification may influence the Use Case Model.
Back to Top
TECHNIQUES
Technique Comments
Enterprise Requirements Management Use this guidance to understand how to manage requirements at the enterprise level.
Back to Top
TEMPLATES AND TOOLS
RA-023_USE_CASE_MODEL.DOC MS WORD - Use this template if you choose to create the Use Case Model in MS Word.
RA-023_USE_CASE_MODEL.PPTX MS POWERPOINT - Use this template if you choose to create the Use Case Model in MS
PowerPoint.
RA023_USE_CASE_MODEL.ZIP This zipped file contains an MS VISIO template and stencil to assist you in creating a Use Case
Model in MS VISIO that can then be inserted into your Use Case Model document.
Example Comments
UNIFIED METHOD (OUM)
Use Case Model MS Visio
Tool Comments
Getting Started with Use Case Modeling JDeveloper - You can use JDeveloper use case diagram complemented with some casual-
dressed descriptions.
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
The Use Case Model is used in the following ways:
to represent an important part of the functional requirements
to verify client and Oracle Consulting understanding of the project scope
to drive project execution and assists in task prioritization
to assist in linking the models from the requirement to the tested code (traceability)
as an input for effort estimation
to assist in eliciting all functions, users of the system and exceptions the system should support
to identify and define terms for the Glossary
to categorize and manage functional requirements
to help create and validate the MoSCoW List (RD.045)
Distribute the Use Case Model as follows:
at the very beginning of the process, to user representatives, executives, project managers, analysts and system architects for examination
later, to the project team as a strategic tool
Back to Top
WORK PRODUCT QUALITY CRITERIA
Are the Use Cases presented in a written format (additional UML use case diagrams may complement)?
Are Use Cases written in language that can be understood by all people who may be involved, especially the users?
For each actor, can you think of a real-world user that is represented by this actor?
Conversely, is each real-world user represented by one or more actors?
Have the use cases been provided with a brief description?
Has each use case been provided with a triggering event?
Are the use cases goals true goals of the primary actor?
Is this the complete list of functionality required by the project?
Is this equal to the project scope and to the project WBS (if already defined)?
Are the use cases verifiable?
When finished, is there a clear way to verify that the use case has been implemented properly?
Are the use cases at the user-goal level? (that is: is it possible to perform the use case in a single-sitting?)
Back to Top
RA.024 - DEVELOP USE CASE DETAILS
In this task, you define the details for each use case within the Use Case Model (RA.023). The process begins during the Inception phase and iteratively continues
throughout the Elaboration phase for each use case under consideration. The template that is used for writing use case details is called the Use Case Specification. The
template for this task contains sections that define requirements and other elements of information that are important to understand the actors needs; thus enabling a
design and implementation of a solution to best meet those needs. The primary focus of this task is to identify and write requirements in the form of scenarios; step-by-
step descriptions of interactions between the Actor(s) and the system under discussion (SuD). There are three types of scenarios:
1. Main Success Scenario: Describes the most frequent path chosen by the actor while interacting with the use case. This scenario does not include conditional
branches, but instead focuses on describing the sequential steps from the start of the use case to the end. The Main Success Scenario is also known as the Basic
Flow.
2. Alternate Scenarios: Describes the conditional paths that branch from the Main Success Scenario (Basic Flow); perform some alternate steps, and then return
back to the main flow.
3. Exception Scenarios: Describes the conditional paths that branch from the Main or Alternate Scenarios; perform some alternate steps, but does not return back to
the flow from which it came.
Use case details are made up of the following:
Pre-Conditions and Post-Conditions
Trigger
Basic Flow (i.e., the Main Success Scenario)
Alternate Flows (An Alternate Flow includes only the unique steps of an Alternate Scenario plus any additional post-conditions.)
Exception Flows (An Exception Flow includes only the unique steps of an Exception Scenario plus the failed post-conditions.)
Extensions or Inclusions (use case interdependencies)
The first iteration of creating use case details is to simply list the scenarios for a given use case without describing the details. Subsequently, these scenarios will be
iteratively refined until all the details are described. This can be done initially via workshops or interviews with users and system analysts, and then iteratively refined
independently.
In a commercial off-the-shelf (COTS) application implementation employing a requirements-driven approach, the Use Case Model complements business process models
in helping the implementation team gain a thorough understanding of business requirements. At a minimum, you should perform this task for those requirements that can
only be satisfied by custom-built components, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems.
Completion of this task for all other business requirements is considered best practice, as it will contribute to a better understanding of requirements and can be
leveraged to prepare a number of other required work products downstream, such as test scenarios and business procedures documentation.
In a commercial off-the-shelf (COTS) application implementation employing a solution-driven approach, this task is generally performed only for those requirements that
must be satisfied by custom-built components, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems.
However, the development of the Use Case Model for other requirements should also be considered for the solution-driven approach whenever a more thorough
understanding of business requirements is deemed necessary.
For projects that involve the upgrade of Oracle products, this task involves a review of the client's existing Use Case Specifications as a means of understanding how
actors currently interact with the system.
ACTIVITY
RA.024.1
RA.024.2
Back to Top
WORK PRODUCT
Use Case Specification - The Use Case Specification is comprised of a set of use case details (specifications) for each individual use case, preferably at the end in fully-
dressed formats. The following supplementary documentation may also be included:
Data Formats
Business Rules
UI Requirements
Performance Requirements
Availability Requirements
Back to Top
TASK STEPS
1 Define the scope and purpose of the use case. Context of Use
Scope and
Level
Write a brief statement explaining the goal of the actor when
using the behavior that the use case describes. The
Context of Use also includes the frequency and under
what conditions the use case is executed.
Scope describes the level in which the system is inserted in
the use case.
- Am I checking up on organization or on system?
- Am I describing its internal structure or not?
In general, OUM prescribes writing Use Case
Specifications as system black-box scope level. In this
case, anything that the actor is aware the system is doing,
is shown in the Use Case Specification. See the work
product appendix for a list of all of the design scope
descriptions that can be used.
Level - In general, OUM prescribes writing Use Case
Specifications as user-goal level. See the work product
appendix for a list of the other levels that could be used.
2 Identify the Primary and Secondary Actors. Primary and
Secondary
Actors
List the primary actor(s) who triggers the use case and the
secondary actor(s) who supports the functionality
3 Identify Stakeholder and Interest for the use case. Stakeholder
and Interest
Name the stakeholders and a brief description of their
interest in the use case.
4 List Assumptions. Assumptions Identify any assumptions; an assumption is a fact that we
hope is true, but we will not test to ensure it is true. These
assumptions should be considered risks and should be
specific to this use case. You should list any Assumptions
about the use case that will assist the reader in
understanding the intended functionality.
5 Identify Pre-Conditions. Pre-Conditions The Pre-Conditions identify conditions that should be
satisfied in all scenarios before any scenario (main or
alternate) can begin. A pre-condition is a fact that we will
test to ensure it is true before allowing the use case to start.
Use the defined actor and goal information from the Use
Case Model (RA.023).
6 Identify Post-Condition. Post-Condition The Post-Condition component describes the state the
system will be in after the use case finishes successfully.
Often refers to the state of the data (i.e. A purchase order
has been entered into the system).
7 Identify the Trigger for the use case. Trigger The Trigger is the action that is performed by the actor who
is the initiator for the use case. Generally, it corresponds to
the first sentence of the brief use case description from the
Use Case Model (RA.023) and is the same as the first step
of the Main Success Scenario.
8 Write the Main Success Scenario. Main Success
Scenario
The Main Success Scenario contains usually 3 to 9 steps
with descriptions of how the interaction with the system
satisfies the primary actor goal. Use the left hand side of
the table to indicate what the actor does, and the right hand
side to indicate what the system does.
9 Write the Extension - Alternate flow scenarios.
For each step in the main success scenario, identify failure and extension
conditions. Before treating the exceptions, brainstorm all the possible alternatives
(failures or alternate success paths) for each step.
Extension -
Alternate
Flows
Alternate Flow
Post-
Conditions
The Extension - Alternate Flows are extension points
which start from one of the steps in the Main Success
Scenario and continues to describe the steps to correct the
condition and returns to the main flow.
Each alternate flow may produce Alternate Flow Post-
Conditions that augment those stated for the main success
scenario.
Technology and Data Variations List (optional)
Extensions serve to express that what the system does is
different from the main success scenario, occasionally you
want to express that there are several different ways it can
be done. What is happening is the same, but how it is done
may vary. Almost always this is because there are some
technology variations you need to capture, or some
differences in the data captured.
10 Write the Exception flow scenarios.
First identify the extension conditions and only after that start detailing the recovery
steps that handle them.
Exception
Flows
Exception
Flow Failed
Post-
Condition(s)
The Exception Flows are extension points which start from
one of the steps in the Main Success Scenario or an
Alternate Flow and continues to describe the steps that
cause the use case to fail. Describe any steps that would
cause the actor to leave the use case without achieving the
intended goal. These flows do not return to the Main
Success Scenario.
Exception Flow Failed Post-Conditions that describe
what needs to happen when the actor leaves the main flow
and cannot complete the main goal of the use case.
11 Consider relationship with other use cases and actors. Use with care the UML
relationships with other use cases (includes and extends). Also consider to
generalize use cases.
Includes and
Extends
Relationships
New
relationships
of Actors and
Use Cases
Use Case
Generalizations
The Includes and Extends Relationships and the New
Relationships of Actors and Use Cases identifies the
relationships with other use cases. This is an Advanced
Use Case Diagramming technique. If they exist, note the
Includes and Extends relationships (references to other use
cases) within the Main or Extension - Alternate scenarios.
Thinking about which actors use one use case can reveal
that some actors are redundant. However, do not spend too
much time on this. At this point, it is better to have more
actors than miss an important one. Do not forget that actors
are roles. If necessary, you can map one actor as a
specialization of another one. (that is, AP Actor can be
used to indicate anyone from the AP Department such as
the AP Clerk, AP Supervisor, etc.)
12 For each use case, consider what updates are needed to other supplemental
material. Use cases should not make direct reference to data formats or include user
interface details. It is important that use cases become as stable as possible and
these types of information make use cases less resilient to change and more difficult
to read. Nonetheless, this information can be stored in supplemental work product
components so that the information is not lost. However, avoid going into too much
details and getting analysis paralysis.
Glossary
Data
Dictionary
Business
Rules
References
Decisions
Store information on any terms in the Glossary.
The Data Dictionary includes a conceptual class diagram,
some user interface prototyping and other supplemental
documents.
Generally, business rules should be included in a
supplemental document. Business rule information should
be stored in the Business Rules. Occasionally, there are
business rules that only makes sense in the context of the
use case and these may be included with that use case as
a text note.
Include references to other artifacts that may provide
additional information in References
Store information on key decisions made to resolve issues
under Decisions
Back to Top
APPROACH
Remember that OUM is an iterative process. This task is performed as part of an iterated task group. See the approach section for RA.023, Develop Use Case Model for
guidelines on how the use cases can be grouped and iterated. Use cases help the functional and technical developers standardize requirements to ensure the data
model supports the required business functions. Detail is added during the development cycle to better define the data and functional models.
Normally you would first detail the more risky and architecturally-significant use cases as these use cases would have the highest priority. Sometimes this process results
in new actors, use cases or risks being considered. This is one of the practices that make OUM risk-driven.
Developing use case details is best done in the order of the task steps above. Specifically, prevent identifying extensions too soon, as one can easily loose valuable time
by getting lost in too much detail too early.
Involve the ambassador users in this process as much as possible to help identify the use case details. Dependant on the kind of use cases, you can
effectively use workshops in this process.
Use a peer-review process to assure quality and completeness of the use cases before making the model available to a broader public.
During this process, new actors and use cases may be discovered. This should be reflected in the Use Case Model (RA.023), and sometimes even in the Business Use
Case Model (RA.015). Ensure that your models are updated when necessary.
Back to Top
Back to Top
System Analyst Detail the use cases. 100
Ambassador User Provide information to detail the use cases. *
Back to Top
PREREQUISITES
RA.024.1 (Elaboration Phase)
Prerequisite Usage
Use Case Model (RA.023.2) The use cases in the Use Case Model are those that are detailed in this task, following the priorities given for each use
case.
Validated Conceptual Prototype (RA.030) The review of the Conceptual Prototype may reveal requirements that should be reflected in the use cases.
(AN.110)Reviewed Design Model (DS.160)
The Reviewed Analysis Model and Reviewed Design Model provide details that should be taken into account while
detailing the use cases.
Architecture Description (RD.130.1) The Architecture Description describe factors that influence application architecture and describe strategies how to
deal with these factors. These factors and strategies should be taken into account while detailing the use cases.
RA.024.2 (Construction Phase)
Prerequisite Usage
Use Case Model (RA.023.3) The use cases in the Use Case Model are those that are detailed in this task, following the priorities given for each use
case.
Validated Functional Prototype (RA.085) The review of the Functional Prototype may reveal new or changes to requirements that should be reflected in the Use
Case Model.
Reviewed Analysis Model (AN.110)
Reviewed Design Model (DS.160)
While analyzing and designing the use cases, refinements and corrections in the Use Case Model may be necessary.
Architectural Prototype (IM.020) The outcome of this prototype may result in new requirements that should be reflected in use case details.
(RD.150.2)
The Reviewed Requirements Specification may influence the use case details.
Back to Top
TECHNIQUES
Technique Comments
Use Case Levels
This technique provides guidance in utilizing Cockburn's symbols to indicate the design scope and goal level of use case
documentation. It is very useful for for projects where systems involve a large degree of custom development.
Back to Top
TEMPLATES AND TOOLS
RA-024_USE_CASE_SPECIFICATION.DOC MS WORD - Use this template if you choose to create the Use Case Specification in MS Word.
RA-024_USE_CASE_SPECIFICATION.PPTX MS POWERPOINT - Use this template if you choose to create the Use Case Specification in MS
PowerPoint.
Tool Comments
Use Case Details Viewlet JDeveloper - You can use JDeveloper use case templates in fully-dressed and casual formats.
FROM BUSINESS PROCESS TO USE CASE WITH
ORACLE UNIFIED METHOD (OUM)
Example Comments
RA-
024_SKI_NOW_UC001_USE_CASE_SPECIFICATION.DOC
UC001 Monitor Supplier Performance for Ski-NOW Case Study Example
RA-
UC002 Acknowledge Product Receipt for Ski-NOW Case Study Example
RA-
UC003 Create Online Sales Order for Ski-NOW Case Study Example
RA-
UC004 Request Online Bid for Ski-NOW Case Study Example
RA-
UC005 Apply Rebates for Ski-NOW Case Study Example
RA-
UC006 Process Supplier Financial Entries for Ski-NOW Case Study Example
RA-
UC007 Capture Recycling Pickup for Ski-NOW Case Study Example
Back to Top
The Use Case Specification is used in the following ways:
to represent an important part of the functional requirements
to verify client and Oracle Consulting understanding of the project scope
to drive project execution and assist in task prioritization
to assist in linking the models from the requirement to the tested code (traceability)
as the basis for effort estimation (in the beginning through the Actor-Goal List and at the end of Elaboration, not only the scope is better understood but also the
architecture has been tested and the team can create a more precise estimate)
to assist in eliciting all functions, users of the system and exceptions the system should support
Distribute the Use Case Specification as follows:
at the very beginning of the process, to user representatives, executives, project managers, analysts and system architects for examination
later, to the project team as a strategic tool
Back to Top
QUALITY CRITERIA
Is the main scenario too long (i.e., more than 10 steps)?
Is each step a phrase stating a goal that succeeds?
Does each step indicate who is responsible for the action (actor or system)?
Are the the use cases free of any references to user interface or data format details? A use case visual sketch/prototype can be created but the use case text itself
should not make direct references to it.
Are there any IF statements (preferably use validate)?
Is the system capable of identifying the conditions?
Is every use case provided with enough detail to be able to realize it?
Check task, Develop Use Case Model (RA.023) for additional quality criteria for use cases.
Back to Top
RA.025 - IDENTIFY CANDIDATE SERVICES
This task is about identifying new service candidates and discovering already existing services. This may be various types of services, depending on the type of
engagement, (for example, SOA services or cloud services) For the remainder of this task overview, both SOA services and cloud services are simply referred to as
services. The task is only applicable if service, in some form, is being used for your project.
The project at hand may have been identified to deliver services and/or update existing services which may have been identified during an earlier enterprise-level effort
(like Envision). In that case carefully review the identified candidates and change requests to the services and apply changes if needed. Add the candidates and services
to the list of your project for further analysis.
It may be that some potential service candidates have been identified up front of the project to satisfy some of the project requirements, for example reuse of a specific
existing SOA service or to consume a known cloud service. Again, these types of candidates should be added to the list for further analysis to ensure that they indeed
deliver the requirements.
During this task, only candidate services are identified, as further analysis is needed in the task, Analyze Services (AN.080) to verify risks and benefits of using or
creating the service. Splitting the identification of candidate services from analyzing them lowers the risk that the services do not add real benefit to the business. In
practice, it is not feasible to provide all functionality through services. On the other hand, when the same functionality is needed by more than one consumer (for
example, identified in more than one project), the encapsulation of that functionality in a service candidate can potentially allow for cost reduction. Therefore service
identification and discovery of (re)use go hand in hand.
Depending on the strategy, environment and the purpose of the project, there can be one or more approaches to service discovery.
Top-Down - The top-down approach starts by obtaining or defining the business Process Model, the Use Case Model and/or Domain Model. In either case,
dynamic behaviors needed are often the source for service discovery.
Bottom-Up This approach looks at existing systems as potential sources for service functionality that supports business processes and/or use cases (via APIs,
adaptors, transactions, modules, etc.). Often this is the place to start when the purpose is to modernize the architecture.
Hybrid - A hybrid approach will seek to do both.
Whenever feasible, the hybrid approach is the recommended one, as it focuses on results while at the same time the big picture is kept in scope.
For projects that involve the upgrade of Oracle products, this task would typically be required if the project involved the migration from traditional to service-oriented
architecture.
ACTIVITY
RA.025.1
RA.025.2
RA.025.3
Back to Top
WORK PRODUCT
Service Portfolio - Candidate Services - The Candidate Services are newly identified services that are being added to the Service Portfolio as Candidate Services.
Changes required for existing services will be added to the Service Portfolio as Service Change Requests. When a physical Enterprise Repository has been established,
this information is captured in the Enterprise Repository.
If the organization does not have a physical Enterprise Repository, use the appropriate Service Portfolio template (IP.014) instead to capture the Candidate Services in
the same format as the Service Portfolio. This will allow you to easily merge a candidate service into the Service Portfolio at a later point, as appropriate.
Back to Top
TASK STEPS
#TOP #TOP
1 Perform analysis to identify
candidates
Service Portfolio - Candidate
Services
The Service Portfolio - Candidate Services component includes all the identified service
candidates.
For SOA, refer to the Technique Steps section of the SOA Service Identification and Discovery technique for the steps to perform this task.
Back to Top
APPROACH
Perform Analysis to Identify Candidates
Create a document that describes the Service Portfolio needed for the project. This document will be use to further analyze the new service candidates as well as to
review the desired use of existing services as part of the task AN.080 - Analyze Services.
Determine how you best can organize the service candidates into logical groupings that will be beneficial for further use of the work product. For example, when you are
identifying or discovering SOA services, it is useful to classify them by type : New Service Candidates, Reused Services Changed, and Reused Services Unchanged.
For SOA , provide a high-level description of the scope with respect to the current project, what benefit the service could deliver to the Business Strategy. Refer to the
Technique Steps (steps 1 through 4) and the Approach sections of the SOA Service Identification and Discovery technique for how to perform this step in more detail.
Refer to the IT Asset Management technique for a definition of the properties to be captured for a Candidate Service. This technique is especially interesting if you are
considering changing the Service Portfolio template.
Back to Top
Back to Top
Business Analyst Identify and document candidate business services. If possible, you may want use a business analyst with extensive SOA
experience.
50
System Architect Identify and document candidate business services. 50
Back to Top
PREREQUISITES
RA.025.1
Prerequisite Usage
Glossary (RD.042.1)
Use Case Model (RA.023.1)
Use these work products to identify candidate services.
Project Reference Architecture (RA.019) Use the Project Reference Architecture to determine to which layer each service belongs.
RA.025.2
Prerequisite Usage
Glossary (RD.042.2)
Use these work products to update the Service Portfolio as the project evolves.
Service Portfolio - Candidate Services (RA.025.1) Update the Service Portfolio with new and refined business services.
RA.025.3
Prerequisite Usage
Glossary (RD.042.3)
Use these work products to update the Service Portfolio as the project evolves.
Service Portfolio - Candidate Services (RA.025.2) Update the Service Portfolio with new and refined business services.
Back to Top
TECHNIQUES
Technique Comments
SOA Service Boundary Analysis Use this technique to understand how to define services to the right level of granularity.
SOA Service Identification and Discovery Use this technique to identify candidate services with the help of models and requirements documents.
IT Asset Management Use this technique to understand what information can be stored in an Enterprise Repository regarding Services.

Back to Top
TEMPLATES AND TOOLS
IP-
Service Portfolio template (IP.014), use the Service Portfolio template (IP.014) to capture the Candidate Services in the same format
as the Service Portfolio. This will allow you to easily merge a candidate service into the Service Portfolio at a later point, as
appropriate.
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Service Portfolio - Candidate Services is used in the following ways:
to show which and what type of services may be required to support the projects requirements
as input for further service candidate analysis
Distribute the Service Portfolio - Candidate Services as follows:
to project stakeholders for initial review
to project individuals that should perform the service candidate analysis
Back to Top
QUALITY CRITERIA
Is the purpose of each service candidate clearly defined?
Is it clear how the service candidate potentially will support the requirements?
It the type of service clearly defined for each service candidate?
Is it clear whether the service candidate will be built, reused/consumed, reuse with required update, etc?
Back to Top
RA.026 - POPULATE SERVICES REPOSITORY
If a Populated Services Repository already exists because of an earlier enterprise-level effort (such as, Envision) or was created in another project, you should start with
that repository and the execution of this task is limited to the population of new services candidates.
During this task, a design-time services repository is used to store the candidate services. This serves as a database of information about the services including:
technical constraints,
usage fees
security issues
contact persons
In short, this should be a complete single source of truth about service policies, SLAs contracts, design and implementation artifacts and interdependencies that govern
service usage.
There is a recent trend towards service repositories merging with service registries. Even then, there is still distinction between each in terms of design time versus a
runtime focus.
ACTIVITY
RA.026.1
B.ACT.ADE Analyze - Elaboration
RA.026.2
C.ACT.ADC Analyze - Construction
Back to Top
WORK PRODUCT
Populated Services Repository - The Populated Services Repository is a design-time repository that stores all the candidate services, and contains useful information
about each service.
Back to Top
TASK STEPS
1 Decide on
Services
Repository.
Services
Repository
Decision
This Services Repository Decision documents the decision regarding which Services Repository should be used in the project. This
should preferably not only be used in the current project, but for the Enterprise as a whole. If no Services Repository currently is used in
the Enterprise, the component also includes the requirements for a Services Repository, and the Services Repository products that were
considered as candidates. It also provides a mapping between the requirements and the candidate products, leading up to the reasoning
behind the chosen Services Repository Product that was selected.
2 Define
Service
Templates
and
format.
Service
Templates
Service Templates are only relevant when there is no current use of a Services Repository, and therefore no Service Templates exist. A
Service Template describes the type of information and format with which to document services in the Services Repository. There should
be one Service Template for each type of service, e.g., one for SOA services, one for each type of cloud service relevant for the
enterprise (e.g., one for Iaas, one for Paas, and one for Saas), and so on. Therefore, there are multiple Service Templates.
Refer to the IT Asset Management technique for guidance on which properties to capture for services in order to include them on the
Service Templates.
3 Format
candidate
services.
Described
Services
The Described Services contains all current and candidate services described using the Service Template. If a Services Repository exists
with already described current and candidate services, this component is restricted to the description of new candidate services identified
as part of the current project.
4 Populate
the
Populated
Services
The Populated Services Repository is the actual design-time repository including all the current and candidate services described using
the Service Template.
#TOP #TOP
services
repository.
Repository
Back to Top
APPROACH
Decide on Services Repository
The first thing you should do is to investigate whether a Services Repository is already in use within the enterprise, and if so, determine the status of that Services
Repository. It is strongly recommended that a single Services Repository is used by the entire enterprise, including all the individual projects. This allows for easier
identification of services available for reuse.
If a Services Repository is in use, you should document that this is the repository to be used. If changes must be performed to make the use enterprise wide, then you
should document the required changes.
If no Services Repository is in use, then you should determine your requirements for a services repository. Verify what kind of products meet these requirements, and
make a decision on the most appropriate tool. Obviously Enterprise stakeholders must be included in this.
Define Service Templates and Format
This step is only relevant when there is no Services Repository in use within the enterprise, or when no proper Service Template has been defined or where there is one
(or more) but it is lacking. Keep in ming, there should be one Service Template for each type of service, for example, one for SOA services, one for each type of cloud
service relevant for the enterprise (for example, one for Iaas, one for Paas, and one for Saas), and so on. That is, there are multiple Service Templates. Determine what
kind of information, and in what format you want or need to store this kind of information for each candidate service. It is recommended that you include an example on
how the template is used, so that it is easier for anyone to understand what each section in the template means.
Refer to the IT Asset Management technique for guidance on which properties to capture for services in order to include them on the Service Templates.
Format Candidate Services
Transform each candidate service into the relevant Service Template determined in the previous step. This ensures a consistent description of each candidate service.
Populate Services Repository
Populate the services repository with all the candidate services described in the relevant template format.
Back to Top
Back to Top
System Architect Decide on, define, format and populate the services repository. If possible, you may want use a system architect with extensive
SOA experience.
100
Back to Top
PREREQUISITES
Prerequisite Usage
Services Meta Data Description
(ENV.GV.096)
If available, use the Services Meta Data Description to determine what information about the services should be captured and how
to classify the services.
(GV.100)
If an Enterprise Repository is in use, the Governance Implementation describes the tooling and related procedures and policies to
populate the Services Repository within the repository.
Service Portfolio - Proposed
Services (AN.080)
The analyzed candidate services are used to populate the Services Repository.
Back to Top
TECHNIQUES
Technique Comments
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Populated Services Repository is used in the following ways:
to document all type of services relevant for the enterprise (for example, SOA services and cloud services)
to facilitate reuse of services
Distribute the Populated Services Repository as follows:
to all project resources
to Enterprise stakeholders using the Services Repository
Back to Top
QUALITY CRITERIA
Have all the candidate services identified as part of the project been named and documented in such a way that they can be easily identified for reuse?
Have the services been designated with service owners, and service consumers in mind?
Have all the services been described following the defined Service Template?
Back to Top
RA.027 - IDENTIFY CANDIDATE BUSINESS RULES
The purpose of this task is to create a list of business rules that will be implemented for your project. If possible, these rules should be organized by using business rule
sets.
During this task, you perform an inventory of business rules. The business rules identified during this task are called candidate rules because, at this stage, they are not
expressed in any consistent semantic format, nor are they validated or approved.
The mechanisms for discovering candidate business rules include the execution (and/or output) of many other tasks including:
Develop Domain Model (RD.065)
Develop Future Process Model (RD.011)
Develop Use Case Model (RA.023)
Develop Use Case Details (RA.024)
Develop Glossary (RD.042)
Detail Supplemental Requirements (RD.055)
Review Governance Policies which may have been identified in the Discover or Define Policies (GV.030) task of Envision
Obtain trading partner business rules
In addition, the very act of assembling the inventory of candidate business rules may also cause the discovery of new business rules.
In a commercial off-the-shelf (COTS) application implementation, business rules may be realized through standard configuration options, through custom-built
components that extend the functionality of the COTS system, or through a business rules engine. Perform this task only when there is a need to gain further clarification
of the business rules represented in the use cases. Business rules, which can be realized through standard configuration options, such as the selection of a Match
Approval Level (i.e., 2, 3, or 4 way matching) for invoices, may not require the additional effort called for in this task. However, complex business rules, or those that can
only be realized through custom-built components, or business rules engine, may require the additional effort.
architecture.
ACTIVITY
RA.027.1
RA.027.2
RA.027.3
Back to Top
WORK PRODUCT
Candidate Business Rules - The Candidate Business Rules is a list of possible rules that govern the business, and that remain stable for a longer period of time.
Back to Top
TASK STEPS
1 Review the Business Process Model (future
state) to identify candidate business rules.
Business Process
Model
Revisit each process in the Business Process Model and identify candidate business rules.
2 Review Use Case Model and Use Case
descriptions to identify candidate business rules
Use Case
Descriptions
Review each Use Case scenario and extract the business rules while placing a reference
number into the step of the scenario for where the business rule applies.
3 Review the Supplemental Specification to identify
Supplemental
Specification
Review each supplemental requirement in the Supplemental Specification and extract the
business rules.
4 Review Trading Partners business rules Trading Partners
rules and
regulations
Review any trading partner rules and extract the rules.
5 Review IT Governance Policies to identify
IT Governance
Policy
Review any IT governance policies and extract the rules.
6 Review the Inventory of Candidate Rules. Business rule
repository
Ensure the business rules are complete and unambiguous.
7 Review the Glossary. Glossary Place each new term into the Glossary and write a description for each
8 Add Facts to the Domain Model Domain Model For each new entity, attribute, association, and/or multiplicity; add it to the Domain Model.
9 Record the source for each discovered rule. Business rule
repository
For each new rule, map or link it to the source requirement from which it came.
Back to Top
APPROACH
The approach to collect candidate business rules may be a combination of harvesting already existing business rules, to review a number of work products to identify new
business rules, as well as to organize a business rules workshop with the goal to identify as many business rules candidates as possible.
The Inventory of Candidate Business Rules contains a list of candidate rules that need to be considered. For each rule, include a description of what the rule is about,
when the rule should be enforced, and optionally in what way it should be enforced (possibly with alternatives). You may also decide to add the candidate rules to the
Rules repository (RA.028) directly rather than preparing a separate inventory of candidate rules.
Business Rules are statements that define or constrain some aspect of the business. Business rules describe the operations, definitions and constraints that apply to an
organization in achieving its goals. Some common sources for business rules include: strategic direction from executives, laws and regulations, and contractual
obligations.
For example a business rule might state that no credit check is to be performed on return customers.
Individual business rules that describe the same facet of an enterprise are usually arranged into business rulesets.
For example the ruleset Purchase Authorization Policy groups together related business rules like this:
Purchase Authorization Policy
A customer must present one form of identification prior to purchasing product
A credit check must be performed on first time customers
No credit check is to be performed on return customers
In general, there are four types of business rules:
1 - Definitions of business terms
The most basic element of a business rule is the language used to express it. The very definition of a term is itself a business rule that describes how
people think and talk about things. Thus, defining a term is establishing a category of business rule. Terms should be documented in the Glossary (RD.042)
or as entities in the Domain Model (RD.065).
For example: Drop Shipping = Drop shipping is the process in which a retailer markets a product, collects payment from the customer and then orders the
item from a supplier, to be shipped directly to that customer. The retailer's profit is the difference between the amount collected and the amount spent. No
inventory is held and the retailer is not involved in the shipping.
2 - Facts relating terms to each other
The operating structure of an organization can be described in terms of the facts that relate terms to each other. To say that a customer can place an order
is a business rule. Facts can be documented as natural language sentences or as relationships, multiplicity, attributes, and generalization structures in a
domain model.
For example, facts could be written textually like this: A Catalog contains many Catalog Items which describe each Product supplied by a Manufacturer. A
Product is stocked in many Warehouses which makeup the Inventory. A Customer can submit a Purchase Order containing many Items that refer to the
Products in Inventory that are shipped by a Warehouse.
Or facts can be described by a graphical domain model like this:
3 - Constraints
Every business constrains behavior in some way, and this is closely related to constraints on what data may or may not be updated. To prevent a record
from being made or changed is, in many cases, to prevent an action from taking place.
For example: A product will not be discounted more than 50% from its wholesale price
4 - Derivations
Business rules define how knowledge in one form may be transformed into other knowledge, possibly in a different form.
For example: Multiply discounted subtotal by sales tax rate giving Total
Harvest Business Rules
Business Rules may already have been identified earlier, during an earlier enterprise-level effort or in other projects. If so, you should harvest these as an input to this
task to determine which are candidates for your project.
Review the Domain Model (RD.065), the Future Process Model (RD.011), and the Use Case Model (RA.023) to identify candidate business rules. While reviewing these
models, you may discover rules you have already identified. You should list all the rules that you see as possible candidates to be a business rule. When the Integration
Architecture Strategy (TA.030) has been completed in the Elaboration phase, you should also review this work product as this may contain integration business rules that
should be included in the list of candidates.
Typically, when you review the Domain Model, look for rules that are related to data, such as rules for data validation, data transformation, dependencies between data,
calculations and so on.
While reviewing the Use Case Model, you may also identify data-related rules, but also more process-related rules. The latter, you also identify while reviewing the Future
Process Model. For example, there may be conditions that must be true to enter a certain path in the workflow, or conditions that must be true to complete a process.
Ensure that whenever you identify a new rule, you keep track of the source of the rule. Ideally, you should relate the rule to a particular use case or generic supplemental
requirement. If you identify a rule based on one of the other models, try to identify a use case that relates to the rule. This makes tracking and testing of the rule a lot
easier as you will know in what use case test you can test the business rule.
Review the IT Governance Policies
If there are IT Governance Policies available, you should review them to determine whether there are any business rules that need to be covered to ensure that a specific
policy is properly implemented. Specifically look for policies related to security or auditing.
Review the Glossary
During the creation of the Glossary (RD.042), business objects may be defined in terms of the categories to which they belong. For example, in an Auto Insurance
Company, the glossary may define a high-risk policy as a type of policy where the customer has had an auto accident within the past 12 months. This constitutes a
candidate rule.
Obtain Trading Partner Business Rules
In some sectors, trading partners have agreed upon standards for exchanging business rules. One trading partner will be asked to use the business rules from another
trading partner to complete a transaction on their behalf in a manner that is compliant with the underlying business policies. These form another source for relevant
enterprise business rules.
Review the Inventory of Candidate Rules
Group the initial list of candidate rules logically in terms of common business entities or processes. Once this has been done and similar rules are grouped together, new
rules are often discovered. It is also easier to discover any duplicates.
Think about whether the rule actually is larger than it seems in the current context. If the rule may be different in another context, document this in order that the rule can
be seen in a larger context. Consider whether the rule is similar for all employees or business units, and whether it applies during the whole lifecycle of the objects to
which the rule applies.
Business Rules Workshop
If you decide to perform a business rules workshop, you should use the result from the review steps above as an input to the workshop. A good way to organize the
workshop is to either use the grouping of candidate rules you did when you reviewed the inventory of candidate rules, or if you have not yet done such a grouping, to
identify the most important business domains for which business rules may apply. Let the participants first prioritize the domains or groupings, and then walk through
each to identify new business rules, and/or to review rules that have been discovered prior to the workshop. Walking through the already identified business rules will
often reveal new candidates.
Do not attempt to perform any classification of the rules at this point of time, but try to identify the nature of the business rules so that it will be easier at a later point of
time.
Record the Source
Once an inventory of candidate rules exists, ensure that the source of each rule has been recorded (e.g., specific use case, requirement or policy).
Back to Top
Back to Top
Business Analyst Identify and document candidate business rules. If possible, you may want use a business analyst with extensive business
rules experience.
100
Back to Top
PREREQUISITES
RA.027.1
Prerequisite Usage
Enterprise Glossary (ENV.BA.030)
Governance Policies Catalog (ENV.GV.030)
Maintained Business Rules (ENV.BA.110)
Use these Envision work products, if available, to identify or further develop Candidate Business Rules or your project.
Glossary (RD.042.1)
Use these work products to identify Candidate Business Rules.
RA.027.2
Prerequisite Usage
Glossary (RD.042.2) Use these work products to update the Candidate Business Rules as the project evolves.
Candidate Business Rules (RA.027.1) Update the Candidate Business Rules with new and refined business rules.
Integration Architecture Strategy
(TA.030)
This work product may contain some Integration Business Rules that may need to be included in the list of Candidate
Business Rules.
RA.027.3
Prerequisite Usage
Glossary (RD.042.3)
Use these work products to update the Candidate Business Rules as the project evolves.
Candidate Business Rules (RA.027.2) Update the Candidate Business Rules with new and refined business rules.
Back to Top
TEMPLATES AND TOOLS
RA-
027_CANDIDATE_BUSINESS_RULES.XLS
MS EXCEL - Use this template when there is no Enterprise Repository or rules engine to record the business rules.
In addition, you may insert this worksheet into the MoSCoW List MS Excel work product (RD.045) when the MoSCoW
List is being used for traceability on small projects.
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Candidate Business Rules is used by subject matter experts (SME) to validate and verify Candidate Business Rules. Candidate Business Rules should be reviewed
by SMEs and checked for completeness and accuracy. These SMEs are intimately familiar with the facts, constraints, and definitions which govern the business.
The Candidate Business Rule are associated (i.e., mapped or linked to) all other work products that reference these rules. Therefore the distribution of these rules will
coincide with the distribution of other work products they reference.
Back to Top
QUALITY CRITERIA
Attribute Description
Atomic Single capability, complete; one requirement should not contain multiple capabilities
Unique Self-contained and can stand alone; may be associated with a unique label
Non-ambiguous Stated exactly; not vague or open-ended or subject to different interpretations
Consistent Names and concepts have a single definition
Comprehensible Capable of being understood; logic is understandable
Abstract Implementation independent: What, when, and how well is defined - how is deferred to design
Feasible Technologically and economically possible
Allocable Can be clearly allocated to hardware, software, interface, or manual processing
Verifiable Statements can be verified directly from their implementations for compliance
Traceable Clearly traced to higher level requirement and requirement drivers
Correct The requirement statements solve the specified problem; approved by project team
Flexible Modification or addition of requirements should be easily accepted
Back to Top
RA.028 - POPULATE BUSINESS RULES REPOSITORY
During this task, you record all the candidate business rules in a predetermined format, in a predetermined tool. It may be that the decisions on how to record business
rules, and which tool should be used to record business rules has already been defined for the enterprise. If so, you should use the same mechanisms. If this has not
been defined, then there might have been other projects where this has been defined. Verify whether this is the situation, and if so, consider reusing.
Otherwise, you need to determine how to document and store the candidate business rules. Typically, a business rule authoring or rule repository tool is used to store the
human readable version of the candidate business rules. Business rule templates for expressing business rules in a natural language are finalized and the format for
documenting business rules is agreed upon. Business analysts work with business users and developers to define the vocabulary used in the business policy. This
vocabulary is based on a business object model that also should be consistent with the Enterprise Glossary (ENV.BA.030, if available) and the project Glossary
(RD.042). If new business terms are discovered, you should also update the Glossaries to ensure that the business terminology remains consistent throughout the
enterprise.
The candidate business rules are then formatted according to these definitions and standards. Then the business rules are entered into the business rules repository. A
business rules repository is sometimes referred to as a Business Rules Management System (BRMS).
components that extend the functionality of the COTS system, or through a business rules engine. Perform this task only when there is a need to record business rules in
a predetermined format, in a predetermined tool. Business rules, which can be realized through standard configuration options, such as the selection of a Match Approval
Level (that is, 2, 3, or 4 way matching) for invoices, may not require the additional effort called for in this task. However, complex business rules, or those realized only
through custom-built components, or business rules engine, may require the additional effort.
architecture.
ACTIVITY
RA.028.1
RA.028.2
RA.028.3
Back to Top
WORK PRODUCT
Populated Business Rules Repository - Business rules are first identified (RA.027) Identify Candidate Business Rules) in other work products such as business
process models, use cases, conceptual models, supplemental specifications, etc. These rules are then consolidated into a central repository where they can be uniformly
documented, updated, and kept track of. Having a central repository to store these rules will allow easy access to rules.
Back to Top
TASK STEPS
Component
Description
1 Investigate use of existing business rules repository or business rule authoring tools, templates and
standards.
Existing Business Rules
Repository

2 Decide on business rules repository or business rule authoring tool.
3 Define business rule templates and formats and determine standards.
4 Format candidate business rules.
5 Populate the business rules repository. Populated Business Rules
Repository

Back to Top
APPROACH
During this task, business rule classifications are determined and business rule standards are confirmed.
Deciding the manner in which to store the business rules is critical to the implementation of a successful system. A variety of options are available, such as using
Microsoft Word, a database, or Oracles business rule engine. The main functionality you want is to be able to quickly find a business rule and audit changes.
Preferably, the business rules authoring tool to be used has already been defined for the enterprise, as well as how candidate business rules should be recorded using
this tool, including the necessary templates and standards. Investigate what has been decided, and use this as your tool including any templates and standards. If there
is no previous strategy determined at enterprise level, verify whether there have been any projects from where you can reuse the approach.
The Business Rule Repository is created and maintained throughout the life of the product. Once a rule ID is created and assigned to a rule, it should not be changed
because requirements from other documents will reference this rule for traceability.
The business rule repository typically contains fields such as the following:
Rule ID
Rule name
Status (proposed, validated, approved, or archived
Effective date
Expiration date
Brief Description
Expression (a concise statement of the rule)
Triggering business event
Ruleset, department or workflow category
Source(s) of rule, such as
System source code
Existing process documentation
IT and business staff
Once a candidate business rule is created in the repository, it is then referenced (or linked) in the document from which it was derived.
Back to Top
Business Analyst Populate the Business Rules Repository. If possible, you may want use a business analyst with extensive business rules
experience.
100
Back to Top
PREREQUISITES
RA.028.1
Prerequisite Usage
Enterprise Glossary (ENV.BA.030)
Maintained Repository of Artifacts (ENV.IP.080)
Use these Envision work products, if available.
Glossary (RD.042.1) The vocabulary used in the business policy should be consistent consistent with the Glossary.
Candidate Business Rules (RA.027.1) The Candidate Business Rules are used to populate the Business Rules Repository.
RA.028.2
Prerequisite Usage
Candidate Business Rules (RA.027.2) Update the Populated Business Rules Repository with new and refined business rules.
Populated Business Rules Repository (RA.028.1) Update the Populated Business Rules Repository with new and refined business rules.
RA.028.3
Prerequisite Usage
Candidate Business Rules (RA.027.3) Update the Populated Business Rules Repository with new and refined business rules.
Populated Business Rules Repository (RA.028.2) Update the Populated Business Rules Repository with new and refined business rules.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
suite.html
Rules Designer for describing business rules and integrating them into business processes.
Back to Top
QUALITY CRITERIA
Back to Top
RA.030 - VALIDATE CONCEPTUAL PROTOTYPE
In this task, the Conceptual Prototype that was created with the task, Create Conceptual Prototype (IM.005), is validated. The purpose of this prototype is to show the
users your understanding of an agreed set of requirements. While going through the prototype with the users you are able to make corrections to that understanding, and
the users are able to make the requirements more complete and clear.
This task should be timeboxed -- nonetheless it is very important to provide ambassador users and the development team the same context to determine any further
requirements and verify the existing requirements for the development of the new application.
In a commercial off-the-shelf (COTS) application implementation employing a requirements-driven approach, this task is generally performed only when there is a need to
gain further clarification of the business requirements represented in the use cases. This typically applies to those requirements that can only be satisfied through
architecturally-significant, extensive and/or complex custom-built components identified during the pre-sales cycle and/or during the Inception phase, which extend the
View Work Breakdown Structure (WBS). However, if your solution-driven application implementation includes architecturally significant custom extensions, you should
consider including this task in your project.
ACTIVITY
RA.030.1
RA.030.2
Back to Top
WORK PRODUCT
Validated Conceptual Prototype - The Validated Conceptual Prototype is the Conceptual Prototype as agreed upon with the users. This prototype is comprised of
sketches of screens via which the user will interact with the system and the execution flow of such screens. This prototype may consist of wire frame diagrams,
presentation slides, flip chart sheets or whiteboards illustrating how the screens and programs to develop should work. This model also contains flow diagrams, such as
story boards, navigation diagrams for screens, highlighting the main navigational methods necessary for the system, and execution flow diagrams. This may be
represented through activity diagrams. The Conceptual Prototype serves as a direct input for the task, Develop Functional Prototype (IM.010) and Develop User Interface
Standards Prototype (IM.085). In addition, the work product often contains open suggestions that have been agreed upon, but that have not been included in the
prototype. Finally, it may contain a list of issues or actions that could not be resolved as part of the workshop.
Back to Top
TASK STEPS
1 Invite the appropriate users, the system architect, analysts and designer to the
validation workshop. Send the invitation as early as possible to ensure that all the
relevant persons will be able to attend. Send as much useful material to the attendants
prior to the workshop, so that they have an opportunity to prepare for the workshop.
None None
2 Prepare validation workshop. Ensure that you have a clearly defined goal for the
workshop (context, timebox, scope, and priorities), as well as a high-level and detailed
agenda including timings to ensure you can keep your timebox.
Ensure that all participants are aware of the goal and what their roles and
responsibilities will be in the workshop.
With the exception of the detailed agenda, send the preparation material to the
participants in advance.
Workshop
Preparation Material
The preparation material should consist of at least
the following:
goal description
logistics
participants including there roles and
responsibilities
scope
detailed agenda
priorities
3 Validate Conceptual Prototype in the workshop following the detailed agenda. Validated
Conceptual
Workshop
This work product contains:
Conceptual Prototype that has been validated
List with agreed upon and preferably
prioritized changes to the prototype
List with open issues that could not be
resolved in the workshop
List with actions assigned to at least one
person with a set deadline
Back to Top
APPROACH
This task duration should receive special attention. It is common that users and the project team can spend much time in detailing screens and worrying with aesthetical
factors. It is highly recommend that this task should be timeboxed.
Remember to focus discussions on verifying the requirements as shown in the prototype. If there are uncertainties between the users about the requirements, or how they
should be implemented, then do not spend a lot of time to discuss this. Rather put it on an action list for the users to investigate outside the workshop.
You should make a detailed agenda including timings for the workshop to be able to keep the timebox. Also, make priorities so that you make certain you walk through the
most important requirements first. Explain to the participants that there are time constraints to get through the prototype, and that there will not be time for lengthy
discussions. Make clear that such points will be set on a list that should be investigated at a later point of time, so that the participants do not feel that they are not heard.
On the other hand, there is no point of rushing forward if there are too many uncertainties/discussions in specific areas. This will only leave a feeling that you didn't
manage to agree upon anything, and that it was a waste of time. Should this happen, then it is recommended that you adjust your agenda, explain to the participants that
this sometimes happen, and plan more sessions to come. Probably, you will also need to make more preparations for the additional sessions.
Walk through the different prototype sections. Preferably, let the developer that has drawn the prototype present it, as (s)he has the best understanding what is meant by
the prototype and how each requirement has been prototyped. However, this requires that the developer has good communication skills. If you have separate analysts
and developers on the project, you may choose to let the analyst present the prototype, especially if the developer does not have appropriate communication skills. The
risk of doing that is that what you get presented is the analysts understanding of the requirements, rather than the developers understanding, while it is the developer that
actually should implement the requirements. Therefore, if you choose this approach, at a minimum the developer should be present during the validation session, and
there must be narrow communication between the analyst and the developer when the requirements should be implemented.
Ensure that the most important requirements are walked through first. Ask the users to participate and to ask questions. If they do not respond, they probably don't
understand what is shown, so ask questions, do not rush to the next item before you are certain what is shown is understood. The purpose of the prototype is to show
your understanding of the requirements to verify that this is correct. If the users don't understand it, it is probably not. Therefore it is important to find out what is wrong
with the prototype.
If you are using a whiteboard, post-its or similar that is not documented digitally, then use a digital camera for capturing it. There is software available that automatically
improves the images if necessary.
Gain approval for the Conceptual Prototype. In some situations, it may be necessary to gather a big group and have a discussion in order to gain approval. In other
situations, approval is as simple as showing the sketches to one ambassador user. Be sure to receive an approval that is accepted by the other users.
Back to Top
Back to Top
Developer Prepare for, and walkthrough the Conceptual Prototype, and gather new understanding of requirements. Prepare the
workshop, invite participants, and lead the workshop.
leaving 50% allocated to the developer. The team leader would then prepare the workshop, invite participants, and lead the
workshop.
90
System Analyst Participate in workshop to ensure that the Conceptual Prototype fits within the overall architecture (as far as known). 10
Ambassador User Participate in workshop to ensure that the requirements have been properly prototyped, and if not point out what is incorrect or
incomplete.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Conceptual Prototype (IM.005) This is the prototype that should be validated.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
The following supplies may prove useful:
Whiteboard
flip chart
digital camera
post-its of different colors
Power point presentations
Avoid high-tech tools at this time - see the Approach section of the "IM.005 - Develop Conceptual Prototype" task.
Back to Top
The Validated Conceptual Prototype is used in the following ways:
to provide context for requirements, development and test
to increase understanding of the requirements
Distribute the Validated Conceptual Prototype as follows:
to all team members, both Oracle and client
Back to Top
QUALITY CRITERIA
Have all the most important parts of the Conceptual Prototype been validated and accepted?
Have unresolved issues been documented, and have actions been planned/taken to resolve these?
For requirements that were planned to be validated in the prototype, but that were not validated, been pointed out with a determination of what should be done by
these (new workshop, agreed to leave to next iteration, or to the Elaboration phase, etc)?
Does the prototype represent the general ideas behind the UI, and not the exact details?
Does the prototype show not only screen wire frames but also navigational details?
Back to Top
RA.035 - DEVELOP HIGH-LEVEL SOFTWARE ARCHITECTURE
DESCRIPTION
The purpose of this task is to establish an initial set of groupings and priorities for the use cases that you have identified. The intent is to identify the use cases that
describe important or critical functionality or that involve requirements that must be developed early in the project. These use cases will be described as architecturally-
significant and will be identified in the High-Level Software Architecture portion of the Architecture Description.
The High-Level Software Architecture also establishes the relationship of the projects goals to the prioritized use cases. It also documents the business units within the
organization that are critical to implementing the use cases successfully and, therefore, to achieving the goals.
The Architecture Description (originally created with RD.130) work product is the collection point for all of the architectural views of the system. This artifact documents
the systems architecture through these architectural views and highlights the architecturally-significant aspects of the system by documenting the design and
development priorities, as determined by an iterative examination of the implementation risks. A well-formulated Architecture Description is one of the key elements of the
Lifecycle Architecture Milestone that concludes the Elaboration Phase.
The first step in this task is to define priorities for the use cases you have identified, based a number of factors. You then place the prioritized use cases into groups that
will be developed concurrently, called iteration groups. You record these prioritization and grouping decisions in the evolving Architecture Description, as well as including
priority information in the MoSCoW List (RD.045). Architecture takes into account the major functionality requirements of the system as well supplemental and quality of
service requirements such as performance, reliability, scalability, portability, and system availability. Prioritization decisions must also take these requirements into
account.
The Architecture Description also becomes an index for:
Analysis artifacts that are created for each of the Analysis Packages defined in the Conceptual View (Package View) of the Analysis Architecture Description
(AN.040).
Design artifacts that are created for each of the Design Components defined in the Module View of the Design Architecture Description (DS.040).
This task is typically utilized on larger projects, but also should be considered when:
Architecturally-significant updates are required to standard product platform(s) as driven by functional or supplemental requirements
Integration is required between application systems or to outside systems
During Inception, you were concerned with identifying the architectural risks and defining strategies to mitigate them. During Elaboration, you are concerned in prioritizing
the use cases and defining the architectural views.
In a commercial off-the-shelf (COTS) application implementation employing a requirements-driven approach, you define priorities for architecturally-significant use cases
impacting the standard application architecture. The depth to which this task is performed typically depends on the extent to which the inclusion of a significant custom
component (for example, Data Warehouse), large numbers of custom extensions, or integration with multiple COTS or third-party systems leveraging Fusion Middleware
requires a reassessment or extension of the application architecture of a single software product. Also, where there are unusual supplemental requirements or stringent
quality of service requirements, additional attention must be paid to this task to be sure that the architecture is able to support these requirements.
ACTIVITY
Back to Top
WORK PRODUCT
these four tasks:
In this task, you add the architectural view of the Use Case Model, or High-Level Software Architecture, to the Architecture Description work product. In this view you
will:
Highlight the architecturally-significant use cases
Define the priorities of all the identified use cases
Place all of the use cases into iteration groups
Add a list of prioritized goals based on the business goals and objectives of the system
Identify the significant business units that will be interacting with the use cases that you have identified as architecturally-significant
Back to Top
TASK STEPS
1 Prioritize use cases. Prioritized Use
Cases
Use cases and scenarios that capture the system's critical functionality are identified, reviewed and prioritized. The
Prioritized Use Cases component, is normally, produced in the following way. To begin, we select a few scenarios on
the basis of risk and criticality. A scenario may be synthesized by abstracting several user requirements. This is
required in order to plan the iterations, i.e., to identify the functionality that must be incorporated in earlier iterations
versus those that can be developed later.
2 Prioritize goals. Prioritized Goals Based on the business objectives and goal, list of requirements, and prioritized use cases, the Prioritized Goals is
developed. It consists of a goal matrix is developed and the goals and objectives are classified. The most critical goals
and objectives of the organization must be highlighted based on the time frame to achieve them. The use cases that
are tied to these goals should have been previously prioritized.
3 Identify significant
business units.
Significant
Business Units
The Significant Business Units recognizes the most significant business units of the organization that interact in the
identified Prioritized Use Cases.
Back to Top
APPROACH
Prioritize Use Cases
In this task step, use cases and scenarios that capture the system's critical functionality are identified, reviewed and prioritized. To begin, select a few scenarios on the
basis of risk and criticality. This is required in order to plan the iterations, i.e., to identify the functionality that must be incorporated in earlier iterations versus those that
can be developed later. Remember that use cases may not be partially implemented. You always implement all of a use case or none of it.
Prioritize Goals
During this task step, identify the most critical goals and objectives of the organization based on the time frame to achieve them. The use cases that are tied to these
goals should have been identified in the previous task.
Identify Significant Business Units
In this task step, you indicate the most significant business units of the organization that interact in the identified prioritized use cases.
Back to Top
guidance. To access all WebCenter supplemental information, use the OUM
Back to Top
System Architect Develop Architecture Description by prioritizing the use cases based on architecture risks and documented business goals of
the project.
If a Requirements Analysis (or other) team leader has been designated, 20% of this time would be allocated to this
80
individual, leaving 60% allocated to the system architect. The team leader would then assist in the prioritization based on the
documented business goals of the project.
System Analyst Assist in the prioritization based on the documented business goals of the project. 20
Ambassador User Provide assistance in prioritizing the uses cases, goals and business units. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business and System
Objectives (RD.001)
The Business and System Objectives are used as a starting point to create the goal matrix.
(Baseline) Architecture
Description
The Baseline Architecture Description (originally created with RD.130.1) provides Organizational, Technical and Product factors that
should be taken into account when determining use case priorities. In addition, you document the High-Level Software Architecture by
updating this previously created work product.
Use Case Model (RA.023.2) The Use Case Model is used to identify and prioritize architectural significant use cases.
MoSCoW List (RD.045.2) The MoSCoW List is used as an input to prioritize the use cases and goals.
Back to Top
TECHNIQUES
Technique Comments
2 x 2 Use this technique to prioritize use cases for each iteration group.
Risk Portfolio Use this technique to prioritize items on the MoSCoW List work product.
Back to Top
TEMPLATES AND TOOLS
Architecture Description MS WORD - Add the architectural view of the Use Case Model, or High-Level Software Architecture, to the Architecture Description
work product originally created in Develop Baseline Architecture Description (RD.130.1).
Back to Top
The Architecture Description that has been updated to include the High-Level Software Architecture Description is used in the following ways:
to develop plans for iterative analysis, design, and implementation of prioritized groups of use cases or iteration groups.
understand how the goals of the business are supported by the priorities that have been identified.
Distribute the Architecture Description to:
All project team members
Back to Top
QUALITY CRITERIA
Back to Top
RA.055 - DOCUMENT BUSINESS PROCEDURES
In this task, you document the procedures supporting the business processes enabled by the system.
In a commercial-off-the-shelf (COTS) application implementation, particularly those employing a solution-driven approach, use any pre-defined procedures available for
the functionality being implemented as a starting point for preparation of this task's work product.
ACTIVITY
RA.055.1
RA.055.2
Back to Top
WORK PRODUCT
Business Procedure Documentation - The Business Procedure Documentation documents the procedures supporting the business processes.
Back to Top
TASK STEPS
1 Describe and identify the business process. Procedure - Scope The Procedure component contains
the following:
Scope
System References
Policy
Responsibility
Distribution
Ownership
Activity Preface
Tasks
2 List the system forms and reports accessed during this procedure. Procedure - System
References

3 List the policies that limit or affect how the business process can or will function. Procedure - Policy
4 List the user roles that participate in the procedure. Procedure - Responsibility
5 List the user roles that should receive a copy of this procedure documentation. Procedure - Distribution
6 Indicate who maintains this procedure. Procedure - Ownership
7 Indicate the business events that trigger this procedure. Procedure - Activity Preface
8 Document the procedural steps for each process task/step. Procedure - Tasks
9 Repeat all previous task steps for each business process and organize into the Business
Procedure Documentation.

10 Secure acceptance of the Business Procedures Documentation. Acceptance Certificate
(PJM.SM.040)

Back to Top
APPROACH
The Business Procedure Documentation provides a restatement of the information contained in business process designs in a narrative form.
Business Procedure Documentation
Business Procedure Documentation is a job-level description of a business process design. Business Procedure Documentation defines how the work is done and
accomplishes the following:
confirms the process design and how systems/files/tools/forms are to be used within each process step
creates prerequisite material and lays the foundation for the User Guide (DO.070), role-based user learning (TR.100), and user certification or other types of
readiness testing (if required)
Write Business Procedure Documentation for each business process. In general, there should be a one-to-one correspondence between use cases [refer to the Use Case
Model (RA.023) and the Use Case Specification (RA.024)] and the documentation.
The Business Procedure Documentation is like a topical essay. It describes a business solution by explaining how the new process supports the use case. Users,
managers, and developers use these essays to establish the framework for designing new procedures, and developing custom components.
Attention: When writing the Business Procedure Documentation, clearly state who the principle audience is. Write topical essays for a general business audience.
Refrain from making this document technical. Discuss technical details in detailed design documents.
Topical essays describe the mechanics of the process flow, detailing how inputs are converted into outputs within the boundary of the process.
From Use Cases to Business Procedure Documentation
The Business Procedure Documentation represents a decomposition of a use case (RA.023 and RA.024). Each use case can be related to a series of procedures,
application screens, reports, and inquiries. The lowest level of detail for a business procedure (sometimes referred to as a business requirements scenario - BRS) is the
triggering event , which is at an elementary business function (EBF) level. However, each triggering event represents a work activityand for each activity, there is
usually a set of procedural steps that describe how to accomplish that step. Each activity is:
usually a set of tasks or operations (often including a system transaction) logically grouped together
composed of manual, clerical, or online (system-assisted) types of work
executed to achieve file/records update, notification, decision-support, and so on
performed by a person or piece of equipment (or combination)
Two examples of an activity are:
A receiving clerk inspects goods, updates a manual receiving log, and enters a receiving transaction into the system.
A quality control inspector moves discrepant material to a holding area, hangs a tag on the material, and records a transfer transaction into the system.
An important quality objective is to verify process designs at the operator job level. The Business Procedure Documentation is a step in that direction. All Business
Procedure Documentation development work is reusable downstream during creation of learning materials and the User Guide (DO.070).
Comparison with Other Work Products
Whereas a use case is an instrument for answering the question, What are the business requirements of the process and its steps?, Business Procedure Documentation
answers the question, How will the process job steps be performed?
The User Guide (DO.070) helps ensure that people can demonstrate mastery of the process steps and use of systems/files/tools/forms, and so on. The Business
Procedure Documentation provides key input into such activities.
How does the Business Procedure Documentation differ from use cases (RA.023 and RA.024)?
The Business Procedure Documentation is the basis for how to perform the role steps (of the process), whereas use cases are for identifying what the business
requirements are.
The Business Procedure Documentation typically identifies expected step duration where feasible.
The Business Procedure Documentation is a set of directions for performing a role, and therefore begins to build understanding at the user level for confirming that
the process design proposed is the correct and best one.
The Business Procedures uses work language, not codes, to communicate with the user.
How does the Business Procedure Documentation differ from the User Guide (DO.070)?
The User Guide (DO.070) has field-level references (and refers to sample forms, reports, and so on).
Business Procedure Documentation has zone-level reference (for example, Header/Line-Item) and does not refer to field level.
A User Guide (DO.070) generally includes a section on how to correct errors.
Writing Teams Organization
Creating Business Procedure Documentation requires two primary skills:
strong business writing abilities
understanding of the business and systems concepts
Business understanding is important, since creation of the Business Procedure Documentation includes a level of quality assuranceverifying that each procedure makes
sense and fits with the characteristics and roles of anticipated users.
When possible, writing teams should be organized around the same grouping as mapping teams. In this way people who write Business Procedure Documentation are
involved during detailed business process design in their respective areas.
Approaches to Process Design
In order to engineer a business process so that people and equipment can reliably perform the steps time after time, a great deal of effort must go into specifying the
characteristics of each step. Delineating each step also improves quality, because expectations are set regarding the policies and tools that drive execution.
Prepare the Business Procedure Documentation in the same way you would prepare specifications for a manufacturing process, providing very detailed instructions for
each step along the way.
The input-process-output technique is a generic modeling tool that was designed for framing complete process specifications by identifying inputs, rules, process step
descriptions, tools, and outputs. The Use Case Model (RA.023) and Use Case Specification (RA.024) provide much of the material necessary for employing such a
technique in developing procedures.
Many techniques can be used to develop sound Business Procedure Documentation. Possibly the most important technique is the use of a physical walkthrough to verify
each procedure. This is not prototyping, where the goal is to prove that a design satisfies business requirements, or solution testing, where the goal is to confirm that
various elements of the solution will work together to create the output. Instead, this walkthrough technique focuses more on the ability of the resources involved to
perform the work consistentlyand having access to the appropriate tools/support systems (such as reports, scanners, and so on) as well as knowledge of driving
policies.
A policy is defined as a principle, plan, or course of action. Policies are the rules that strengthen a business process and make it workable and acceptable.
Warning: If a use case must be revised as a result of creating the Business Procedure Documentation (for instance, a task turns out to be less feasible than planned),
then that use case must be tested againpossibly resulting in project delay.
Linkage to Process Modeling
System process models can be developed in conjunction with, or at least as a facilitator of, the Business Procedure Documentation.
The system process model has two objectives:
to define the requirements for the system technical architecture
to define the requirements for the user interface
System process models enable users to visualize how the process will be executed with the new system. This goal can be accomplished in several ways and with varying
levels of sophistication.
Typically, system process models are process flow diagrams that are derived from the business process model and annotated with details about how the processes will
be automated. Process steps are identified as manual or automated and as batch or online. The type of user interface, frequency of execution, sites where the process is
executed, inputs, interfaces to other systems, and current systems support, if any, are also identified.
Relationship to Other Activities
The Business Procedure Documentation forms a strong link with these types of activities:
fit/gap
documentation
adoption
testing
user certification and readiness testing
Fit/gap produces a technically feasible solution that is reasonable in terms of process flows and steps. However, certain assumptions regarding underlying procedural
steps are not made until they can be documented in detail. The Business Procedure Documentation is the bridge between use cases (RA.023 and RA.024) and the User
Guide (DO.070). User learning materials should draw heavily from content found in the Business Procedure Documentation.
Because the Business Procedure Documentation describes business processes in terms of how work will be performed, they provide valuable input toward proving that
business process steps are feasible and can be supported by the resources that must ultimately perform them. Business Procedure Documentation helps narrow the
scope of Testing (TE) activities.
Although business solutions are generally approved before Business Procedure Documentation writing begins, solutions drive the procedures and the procedure may
modify the way solutions are presented or described. Additionally, the Create System Test Scenarios (TE.025) and Develop Systems Integration Test Scenarios (TE.090)
tasks provide data profiles that describe business conditions required for the application system to function properly in support of the business.
User certification and readiness testing will draw heavily from content found in the Business Procedure Documentation. Such testing is important for quality. Each
business process must meet the following performance criteria:
perform consistently under the same trained resource, using the same tools and achieving the same measurable results
produce consistent response in terms of acceptable process elapsed (or cycle) time
meet cost target
meet customer expectations (usually as required by the next process)
Impact of Business Procedure Documentation
Typical Questions and Answers Regarding Business Procedure Documentation
Question:Can we implement without Business Procedure Documentation?
Answer: No. This document is necessary for proving the procedures that support business processes and for developing user training material.
Question:Can we put off creating these documents until late in the project?
Answer: While Business Procedure Documentation work could be combined with creation of the User Guide (DO.070) at a later stage of the project, this leaves little time
for getting the ergonomics of job design right, so it is advisable to create this material as early as possible.
Question:Can Business Procedure Documentation be developed before custom development is complete?
Answer: Yes. Procedures are living documents.
Question:What is the biggest benefit of writing Business Procedure Documentation?
Answer: While demonstrating user-level task understanding is very important, a more important reason is to begin creating process step job designs that are efficient,
user friendly, and reliable.
Review and Sign-Off
As each Business Procedure is completed, have it reviewed by:
the project sponsor
management
representatives from process design and mapping teams
formal integration teams
Back to Top
Business Analyst Gather and document the procedures supporting the business processes enabled by the system. 80
Developer Provide expertise on development tools and how they are to be used. If available, you may want to consult a tool specialist. 20
Back to Top
PREREQUISITES
Prerequisite Usage
Use Case Model (RA.023)
Use Case Specification (RA.024)
These work products contain the use case information that is used to develop the Business Procedure Documentation.
Future Process Model (RD.011.2) The Future Process Model includes process flow diagrams of the events and business processes that the future applications and
the associated functions of the business area will support.
Mapped Business Requirements
(MC.030)
For scenarios with workarounds or proposed custom extensions, business requirements mapping forms are necessary to specify
the job-level details for the business process.
Documentation Standards and
Procedures (DO.020)
The Documentation Standards and Procedures determine the look and feel of the project documentation and the procedures the
project team uses to develop documentation.
Documentation Environment
(DO.040)
The Documentation Environment details all hardware, software, and utilities needed to support documentation development.
Back to Top
TEMPLATES AND TOOLS
RA-055_BUSINESS_PROCEDURE_DOCUMENTATION.DOC MS WORD
Tool Comments
processes.
Back to Top
The Business Procedure Documentation is used in the following ways:
to describe the business process being documented
to list primary inputs into the business process
to describe rules, policies and other constraints
to identify support tools required during execution of the business process
to describe the detailed procedural steps for each use case
Back to Top
QUALITY CRITERIA
Does the Business Procedure Documentation contain process numbers and process descriptions?
Is each use case covered by one business procedure (although one business procedure may cover multiple, related use cases)?
When multiple use cases are covered by one business procedure, do they have the same general flow with the same basic responsibilities and differ only in minor
logic?
Does the Business Procedure Documentation mention how all logs/forms/tools are to be used within each triggering event?
Does the Business Procedure Documentation describe the sequence of job activities for a process from request/trigger to fulfillment/completion?
Are job activities defined to include all details pertinent to user training, except references to individual fields on manual/computerized forms?
Is the procedure component written as an instruction, each sentence beginning with an action verb (use the imperative mood as you would in giving directions)?
Does a user responsibility appear first in each numbered paragraph of the Business Procedure Documentation (either in bold or with a trailing colon)?
Does the Business Procedure Documentation use simple, clear language, that is, does it avoid acronyms?
Back to Top
RA.085 - VALIDATE FUNCTIONAL PROTOTYPE
In this task, ambassador users with relevant knowledge validate the Functional Prototype created in the task Develop Functional Prototype (IM.010). The purpose of the
Functional Prototype is to demonstrate to the users your understanding of the agreed on set of requirements.
In some cases the Functional Prototype may be a demonstration of the proposed functionality. For example, a portal demonstration may show how static reports can be
viewed and how graphical reports can link to more detailed reports without actually building a prototype with the customer's data.
This task should be timeboxed -- nonetheless it is very important to provide ambassador users and the development team the same context to determine any further
requirements and verify the existing requirements for the development of the new application.
It is recommended that you invite the ambassador users that have relevant functional knowledge related to what is shown in the prototype. It may be that not all
ambassador users have the relevant knowledge for all areas that should be prototyped. You may also choose to make the prototype available to other users with relevant
knowledge. This is beneficial as a larger user community will better learn about what is happening in the project and will therefore be better prepared when the application
should be used in the future. However, when doing this you must ensure that whenever they have comments, they communicate this to the ambassador user that is the
owner of the functional area. In this way the ambassador user can communicate relevant comments further into the project, while irrelevant comments will not be a
disturbing factor for the project. The comments may be a result of misunderstandings or lack of knowledge for example related to decisions that have been made in the
project. If this is the case, then the ambassador user has an opportunity to explain this to the other user, including the reasons why the prototype has been made as it is,
and thereby create a better acceptance for the solution to come.
The ambassador user may want to invite one or a few other users in addition to themselves. If this is the case, you must make certain that these users know about
decisions that have been made in the project, what is the purpose of the prototype and what constraints are given for the project. If not, there is a risk that already made
decisions will come up again, or that suggestions will be made that are irrelevant or impossible within the constraints of the project. Communicate to the ambassador user
that if (s)he wants to include others, it is their responsibility to inform these users, and that situations that may occur that will delay the validation process (or even the
project itself) will be parked.
During the workshop, the developer will conduct a walkthrough of the developed pages to validate the prototype.
In a commercial off-the-shelf (COTS) requirements-driven application implementation, this task is used to validate the prototype of custom extensions that were developed
due to the technical complexity of the extension, or other risks associated with them.
In a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach, this task is used to validate the functional prototypes of
architecturally-significant custom extensions at this stage of the project.
ACTIVITY
Back to Top
WORK PRODUCT
Validated Functional Prototype - The Validated Functional Prototype is the approved and validated Functional Prototype (IM.010) including any inputs obtained during
the walkthrough, such as, additional functional or usability requirements related to specific use cases. This information should be recorded using appropriate tools, to
provide structure and traceability.
Back to Top
TASK STEPS
1 Conduct walkthrough of Functional Prototype (IM.010) with users. Defects
New or
detailed
requirements
Defects are changes that must be made based on misunderstandings or
shortcomings related to the requirements. These should be recorded using a
tracking system or by using the appropriate PJM template.
The New or Detailed Requirements contain any additional requirements that
come up during the walkthrough. These may be completely new requirements
or detailing of existing requirements. Record these in a similar way as the
defects.
Both defects and requirements should be prioritized.
#TOP #TOP
2 Obtain formal approval.
If you perform an additional iteration, this is normally obtained as
part the final iteration, but you should agree upon the changes,
including their priorities, that should be implemented in the next
iteration.
None None
Back to Top
APPROACH
It is useful to complete this validation task during the use case detailing as it provides the users with a better view of the future system.
Keep in mind that the main purpose of the prototype still is to communicate your understanding of the requirements to the user. Therefore the objective of this task is not
to prototype the entire system, but the areas that need the most to be clarified further. These may be use cases where the requirements for example are unclear,
complex or vague. Also, see the guidelines for IM.010 for more details on which use cases should be prototyped. Also, consider if some use cases are similar, and that
you can use one prototyped use case as an example for other uses cases, and thereby validate more use cases using a single prototyped use case.
Although the task can be iterated, aim to execute it only once or at a maximum twice for the same use case. It should be repeated if there are major misunderstandings in
the requirements. If you allow multiple iterations (without having planned so in advance) this might present difficulties in completing the Elaboration phase on schedule.
Therefore if the project is of high complexity, or many requirements are unclear, you should consider planning for multiple iterations in advance.
Walk through the different prototype sections. Preferably, let the developers themselves walk the users through the parts of the Functional Prototype they have developed
themselves. This is beneficial because the developer will describe his or her understanding of the requirements, and it is easier for the user to discover
misunderstandings, and ask questions. However, this requires that the developer has good communication skills. If you have separate analysts and developers on the
project, you may choose to let the analyst present the prototype, especially if the developer does not have appropriate communication skills. The risk of doing that is that
what you get presented is the analysts understanding of the requirements, rather than the developers understanding, while it is the developer that actually should
implement the requirements. Therefore, if you choose this approach, at a minimum the developer should be present during the validation session, and there must be
narrow communication between the analyst and the developer when the requirements should be implemented. The users validate what they see against their
requirements baseline.
This activity will result in both detection of errors due to misunderstanding of requirements, as well as in changes and additions to the requirements. All errors, changes
and additions must be recorded and prioritized. Also, it is essential to determine what kind of changes and additions are within or outside the scope of the project. Be
aware of scope creep. Use the MoSCoW principle to determine what is within or outside scope. Requirements that do not fit within the boundaries documented in the
MoSCoW list are out of scope, however, if it is appropriate, the users may choose to move some requirements of equivalent effort out of scope and replace it with the
new requirement(s). As long as that is possible, no Change Request will be required.
Changes that are outside scope, and cannot be handled through MoSCoW, should be recorded as new requirements that may be included in a later increment, or of it is
absolutely required, they may be included as a result of an agreed scope change (change control). The latter should be discouraged as it will impact the project effort,
and possibly schedule.
Any changes to the requirements must be reflected in the requirements as these are documented in the Use Case Model.
Back to Top
Back to Top
This task involves the following project roles when the Functional Prototype being validated is built with custom software (e.g., custom application code and/or custom
extension of a COTS product):
Developer Walk the user through the Functional Prototype. Optionally, the developer records agreed changes and additions that can be
reviewed after the walkthrough. Lead the Validate Functional Prototype Walkthrough Workshop.
80
System Analyst Assist in the validation of the Functional Prototype and advise on the impact of proposed changes on the requirements. 20
Ambassador User Examine the Functional Prototype and give feedback to the developers. If possible, all ambassador users should participate in
all sessions of the walkthrough. After the walkthrough, verify the recorded comments.
*
This task involves the following project roles when the Functional Prototype being validated is built upon standard product functionality (e.g., a COTS application
environment that has been configured based on the results of the Specify Software Configuration activity):
Application/Product
Specialist
Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for the product(s) being
implemented. Lead the Validate Functional Prototype Walkthrough Workshop.
70
Developer Assist in the validation of the Functional Prototype and advise on potential custom extensions to address gaps in functionality. 10
System Analyst Assist in the validation of the Functional Prototype and advise on the impact of proposed changes on the requirements. 20
Ambassador User Examine the Functional Prototype and give feedback to the developers. If possible, all ambassador users should participate in
all sessions of the walkthrough. After the walkthrough, verify the recorded comments.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Functional Prototype (IM.010) The Functional Prototype is validated in this task
Back to Top
TEMPLATES AND TOOLS
QM040_REVIEW_COMMENTS_LIST.DOC MS WORD
RA-085_VALIDATED_FUNCTIONAL_PROTOTYPE.DOC MS WORD
Use a tracking tool to capture review comments and changes. Ideally the tracking tool should also provide traceability mechanisms to relate these to the requirements and
to the Business and System Objectives.
Back to Top
The Validate Functional Prototype is used in the following ways:
to record user feedback as input to the formulation of detailed requirements
to improve the developers understanding of business needs
to improve the users understanding of their own requirements
to improve the users understanding of technical possibilities
to provide direction to further prototyping and design
to assist in planning and executing design tasks
to assist any future increment in avoiding any pitfalls that may have arisen so far in this increment
Distribute the Validated Functional Prototype as follows:
to all team members
Back to Top
QUALITY CRITERIA
Are the review comments rooted in the business objectives?
Do the changes made to some requirements involve a change of scope, and if so has this been handled as such?
Have the review comments been verified and agreed by the ambassador users?
Have any unresolved issues, for example conflicting user requirements or priorities, been escalated?
Have user expectations been met, or documented where they are not met?
Do the review records provide sufficient information to show where the prototype falls short of expectations?
If there are any parts of the prototype that should be frozen as they are (for example, because the users like it as it is), do the review records highlight these?
Back to Top
RA.095 - VALIDATE USER INTERFACE STANDARDS
PROTOTYPE
In this task, the ambassador users, or other relevant client participants, validate the User Interface Standards Prototype created in the task Develop User Interface
Standards Prototype (IM.085).
It is recommended that you invite the ambassador users that have relevant knowledge to determine the generic look and feel for the application to a workshop where you
will conduct a walkthrough to validate the prototype. Make certain that the invited Ambassador Users have good knowledge about the organizations standards and the
corporate branding policy. It might be that none of the ambassador users possess this knowledge. If this is the case, insist on inviting outside users that do possess this
knowledge to ensure that the project will comply to corporate standards.
In a commercial off-the-shelf (COTS) application implementation, this task also involves the validation of any revisions made to the standard functionality of the application
system user interface in order to meet the implementing organizations requirements. This is generally applicable only to those COTS application systems that enable
tailoring/revision of the standard user interface via supported means, such as Oracles Siebel Tools.
ACTIVITY
Back to Top
WORK PRODUCT
Validated User Interface Standards Prototype - The Validated User Interface Standards Prototype is the approved and validated User Interface Standards Prototype
(IM.085) including any inputs obtained during the walkthrough, such as, additional user interface requirements. This information should be recorded using appropriate
tools, to provide structure and traceability.
Back to Top
TASK STEPS
1 Conduct walkthrough of the User Interface Standards Prototype
(IM.085) with users.
User Interface Standards
Requirements
Record the User Interface Standards Requirements in a tracking
system or use the PJM QM.040 template.
2 Apply modifications prototype (skin/templates, etc.) and
document the changes.
If you perform an additional iteration, the modifications of the
prototype is done in the IM.085 task.
Adjusted Prototype
Updated User-Interface
Guidelines
None
3 Obtain formal approval.
If you perform an additional iteration, this is normally obtained as
part of this task, in the final iteration.
None None
Back to Top
APPROACH
The Develop User Interface Standards Prototype (IM.085) task and this task are critical for assuring the usability of the system being developed. The focus must be in
establishing visual guidelines for usability not in system functionality.
In smaller projects, you might choose to combine this task with the task to validate the Functional Prototype (RA.085). If you choose to do this, you must still ensure that
you separately focus on and agree on a standard look and feel independent of the functionality, preferably before discussing the functionality. It is important that the users
know in advance that the purpose of the validation is dual. You might have separate prototypes to discuss, but there might also be a single prototype that is used for both
purposes, to validate the generic look and feel, and to validate the actual functionality.
Preferably use the first part of the workshop to go through the user interface standards. If the users start to discuss functionality, you must delay this till the part of the
workshop where functionality should be discussed. Put it on a parking list, so that the users are ensured it will not be forgotten. When the user interface standards have
been agreed upon, take a break, and start discussing the functionality (RA.085) afterwards.
In larger projects, you will probably choose to keep the validation of the prototypes separate. In large organizations you will often see that there are separate users that
decide on the generic look and feel of the application to ensure that it fits within a corporate branding policy. These may be different to the business users that know the
functional requirements of the application.
If you feel it necessary, you will perform a second iteration for the User Interface Standards Prototype, and perform an update of the prototype (IM.085) with the feedback
from the walkthrough. This is recommended when you agree on substantial changes, to verify that your understanding of the requirements are correct. The updated
prototype is then again presented as part of the second iteration of this task. If the changes are minimal, you will probably not perform a new walkthrough, but only update
the used frameworks, skins or templates, so that this is ready to use.
Back to Top
Developer Assist in presenting the User Interface Standards Prototype. Optionally, develop a custom report to present the information
during or after the walkthrough. Lead the Validate User Interface Standards Prototype Walkthrough.
80
System Analyst Assist in the validation of the User Interface Standards Prototype and advise on the impact of proposed changes. 20
Ambassador User Examine the User Interface Standards Prototype and give feedback to the developers. The ambassador users that participate
must be familiar with company standards and branding requirements. After the walkthrough, verify the recorded comments.
*
Back to Top
PREREQUISITES
Prerequisite Usage
User Interface Standards Prototype (IM.085) The User Interface Standards Prototype is validated in this task
Back to Top
TEMPLATES AND TOOLS
QM-040_REVIEW_COMMENTS_LIST.DOC MS WORD
A tracking tool can also be used to log defects.
Back to Top
The Validated User Interface Standards Prototype is used in the following ways:
to allow the end users to familiarize themselves with the look and feel of the new application
to show the defined look and feel standards for the of the new application
Distribute the Validated User Interface Standards Prototype as follows:
to all ambassador users
to all developers
Back to Top
QUALITY CRITERIA
Was a small running prototype shown to representative users that are familiar with the corporate standards and branding policy?
Was the prototype sufficient to visualize the generic look and feel of the application?
Do the user interface requirements consider standards for colors, font types and sizes, wording, capitalization, use of abbreviations, alignments, navigation,
recommendations for error messages, formats (e.g., mm-dd-yy or dd-mm-yyyy), standards for buttons (e.g., consistent places in all pages, wording for labels,
colors), different monitor resolutions, different browsers and which browsers are supported, special needs for accessibility (W3C Web Accessibility Initiative site:
www.w3.org/WAI/References/) and internationalization?
Does it seem that the agreed look and feel will result in a user-friendly application?
Back to Top
RA.160 - CONDUCT BUSINESS DATA SOURCE GAP ANALYSIS
In this task, you verify that the data required to support the requirements identified in the MoSCoW List (RD.045) and the Requirements Specification (RD.140) and the
data elements identified in the Domain Model (RD.065) are available from the identified source systems with the required characteristics (that is, availability, timeliness,
granularity, quality).
In a commercial off-the-shelf (COTS) application implementation, you map the data elements from the legacy system to the target application modules, business objects,
and attributes. The primary purpose of this task is to discover at an early point in the project lifecycle whether any business objects or attributes in the legacy system are
not being stored in the new application system. This task should also determine whether the new application system stores any required attributes that the legacy system
does not currently store. Any variance between the business requirements identified in the execution of this task and the capability or features of the application system
that are necessary to meet that requirement (i.e., gaps), should be captured in the RA.160 work product.by annotation and textual reference, if necessary. Gaps identified
should also be entered into the MoSCoW List (RD.045) and used as input into subsequent tasks (for example, MC.030, Map Business Requirements, etc.) for further
analysis.
ACTIVITY
Back to Top
WORK PRODUCT
Business Data Source Gap Analysis - The Business Data Source Gap Analysis defines specific data element gaps between the available data required to support the
solution and the data available in the source systems as defined by the ambassador users. It details the gaps, and their characteristics (that is, uniqueness, availability,
granularity, quality, etc.) and defines possible options or alternate solutions to support the business requirements (where feasible).
Back to Top
TASK STEPS
1 Provide an introduction for the Data Source Gap Matrix. Introduction This component provides the definition, purpose, practical application, scope and
related documents for the Data Source Gap Matrix.
2 Review the entities previously defined and list them.
Categorize the entities according to type.
Target System
Entities
This component provides a list of entities required for the target system.
3 Define the gap types. Data Gap
Analysis
This component defines the various types of gaps that may occur.
4 Analyze the entities. Complete the Data Source Gap Matrix. Data Source
Gap Matrix
This component is the actual Data Source Gap Matrix.
Back to Top
APPROACH
The objective of this task is to identify any gaps in the source systems for meeting the information requirements of the target system. Use the High-Level Business
Descriptions (RD.020), Domain Model (RD.065), the MoSCoW List (RD.045) and the Requirements Specification (RD.140) to identify the information requirements of the
target system. Review the Data Acquisition and Conversion Requirements (CV.010) and the Data Acquisition, Conversion and Data Quality Strategy (CV.020) for source
system information. This task includes an analysis of the source system, identification of source system gaps, and identification of possible solutions and workarounds to
all identified gaps that require careful analysis of all data sources.
The Data Source Gap Matrix contains information regarding the gaps between the data required by the solution and the data available in the source systems.
Target System Entities
List the entities identified in the Domain Model (RD.065). Note that the Domain Model may not be in a final state when this task is initiated, so this section must be kept
up-to-date with any major revisions in the model. Entity Type describes the nature of the data, i.e., Factual or Reference. This list provides a checklist for ensuring
completeness of the Gap Analysis exercise. Each entity is ticked off once all of the attributes have been investigated.
#TOP #TOP
Data Gap Analysis
From initial investigation into the data, define the gap types. Assign each gap type a number from 0 on. Display the gap types in a table with columns for, gap type
number, definition, and comments where appropriate to add clarity. Create a rating system for the different categories of gaps that will be used in the gap analysis matrix.
The types of gaps are defined based on the following types of discrepancies:
Data content, that is, if the required data of an entity/attribute can completely be obtained from the source system directly or if it is derived. Note that the business
definition and use of the same data between the source system and the warehouse may not be the same.
Accuracy, how correct the source data is, and how consistent it is when compared to the target business requirements.
Data format, how closely the format of the data in the source system matches the format of its corresponding target entity, e.g., LastName, FirstName
Data relationships, to what extent would the integrity of relationships between the target entities can be maintained by the data in the source systems.
Granularity if the level of detail required of a target entity is available or can be derived from the source system.
Availability, if the source systems have constraints that hamper the extraction of data. CV.010 and CV.020 contain details on this as well.
An example of types of gaps based on the above factors follows:
Gap
Type
Gap Type Definition
Type 0 No Gap. Data source of required granularity and quality for the target data element is available from a single source.
Type 1 Data source of required granularity and quality for the target data element is available in more than one source and relationships between sources cannot be
clearly defined.
Type 2 Data source for a target element is not directly available. But it can be derived by a formula or calculation.
Type 3 Data source for a target element is available. But it is not of required granularity, format, accuracy or not available due to some constraints.
Type 4 Data Source for a target element is not present in the source systems and hence cannot be obtained.
Add a Comments column against each gap type to further illustrate what this gap type means in the context of this target system solution.
If there are any gap types that are specific to this implementation, list them as well.
Data Source Gap Matrix
For every attribute of entity A, identify the data source system based on the data source system information available. Determine the Gap Type based on the definitions
of gap type. If data source element is identified, capture those details. Analyze the severity of the gap on the solution and determine a resolution and assign a complexity
value to the resolution, such as, simple/medium/high complex. For example, if the gap happens to be non-availability of data for extraction due to operational/security
constraints, this can be resolved by generating flat file extracts from the source systems. Complete the Data Source Gap Matrix summarizing the gap analysis of the
target entities and their attributes vis--vis their sources. Include the following details:
Target Entity
Target Attribute
Data Source System
Source System Attribute
Gap Type
Gap Description
Severity of Gap
Resolution
Complexity of Resolution
Back to Top
System Architect
Identify any gaps in the source systems for meeting the information requirements of the target system. Preferably, this should
be done by a system architect that specializes in Information Architecture.
80
Application/Product
Specialist
Provide knowledge and guidance regarding the functionality and capabilities of the product(s) being implemented. 20
Client Data Administrator Provide assistance in Identifying any gaps in the source systems for meeting the information requirements of the target system. *
Back to Top
PREREQUISITES
Prerequisite Usage
Data Acquisition and Conversion Requirements (CV.010) These work products contain information about the data sources.
Data Acquisition, Conversion and Data Quality Strategy (CV.020)
Data Acquisition and Conversion Standards (CV.025)
MoSCoW List (RD.045.2)
Requirements Specification (RD.140.2)
These work products contain more detailed information about the data elements.
Back to Top
TEMPLATES AND TOOLS
RA_160_DATA_SOURCE_GAP_MATRIX.DOC MS WORD
Back to Top
The Business Data Source Gap Analysis is used in the following ways:
by the project manager to understand the severity of the gaps and complexity of the resolution and the impact this may have on the project schedule
by the project team during the execution of the Data Acquisition and Conversion tasks
Back to Top
QUALITY CRITERIA
Are all the entities identified in the Domain Model (RD.065) listed in the document.
Are gap types clearly stated and understood and cover all possible data issues?
Have all sources of each entity and their gaps been identified in the final work product?
Have possible solutions to address the gaps been covered?
Back to Top
RA.170 - CONDUCT DATA QUALITY ASSESSMENT
In this task, you conduct a high-level evaluation of the integrity and reliability of the source data to identify any significant data quality issues in order to escalate and
resolve those issues early to avoid adversely impacting the project scope.
In a commercial off-the-shelf (COTS) application implementation, you evaluate the integrity and reliability of source data to be converted from the legacy system(s).
ACTIVITY
RA.170.1
RA.170.2
Back to Top
WORK PRODUCT
High-Level Data Quality Assessment - The High-Level Data Quality Assessment documents findings related to source data, its integrity, availability, ability to meet
business requirements, and overall quality. It includes issues and possible resolution approaches.
Back to Top
TASK STEPS
1 Provide an introduction for the High-Level Data Quality Assessment. Introduction This component provides the definition, purpose, practical
application, scope and related documents for the High-Level Data
Quality Assessment.
2 Document the methods that will be used during the data quality assessment.
Define whether a tool will be used (DQI Data Quality Inspector, OWB Data
Profiling facility etc.). Explain how manual assessment (i.e., using SQL or
PLSQL scripts) will be performed.
Data Quality
Measures
This component contains an overview of assessment methods and
list of data quality measures (KPIs) to be evaluated in the
assessment. Include the following sections.
Assessment Methods
Data Quality Measures
3 Document information, in a separate section for each source system, details
about the source system, such as, sample the assessment was performed on,
when and by whom was the assessment performed. In addition, capture the
results of the data quality assessment performed for the source system.
Source
System
Data
Quality
Assessment
This component the conditions under which the assessment has
been performed and the results of the data quality assessment.
Repeat the following sections for each source system that was
subject of the data quality assessment and listed in the Scope in the
Introduction:
Source System Details
Assessment Results
Back to Top
APPROACH
The objective of this task is to identify data quality issues early in the development cycle and establish appropriate escalation and resolution of those issues. Implement
the Data Quality Strategy defined in the Data Acquisition, Conversion and Data Quality Strategy (CV.020) to execute this task. Document the results of the surveys
conducted on the source systems, specifically looking at the source objects identified in the Data Mapping (CV.027). The High-Level Data Quality Assessment then
becomes the basis for any any action that is to be taken to address the issues identified.
Describe the data quality measures (KPIs) evaluated during the source system data quality assessment and the methods used for the assessment.
ASSESSMENT METHODS
Document the assessment methods in a table. Include the following information::
ID unique identification of the assessment method
Assessment Method short name of the assessment method
Description detail description
Tool tool to be utilized
Applicable To types of data quality measures the method is applicable to
Consider the following methods for performing the data quality assessment:
Data profiling capability of OWB 10g Release 2
Data Quality Inspector (DQI)
PLSQL scripts for profiling data
Other data profiling tools
DATA QUALITY MEASURES
Define the data quality measures to be evaluated. Review the Data Acquisition, Conversion and Data Quality Strategy (CV.020) for the list of KPIs to include. Include
additional KPIs not listed in CV.020, if necessary. Decide on and document the appropriate assessment method for each measure.
Describe the data quality measures in a table. Include the following information:
ID unique identification of the measure
Business Entity entity that is subject of the measure
Business Attribute attribute that is subject of the measure
KPI name of the measure
Description description of the measure, i.e., how the measure is calculated
Assessment Method method to be used for evaluating this measure
Acceptable value what is the acceptable value for business
Data quality measures are usually defined as how many records do not meet particular quality criteria." Some of the possible criteria that can be measured are:
Missing Data Values data that should have value are missing, including both mandatory fields and analytical fields.
Domain Value Errors data do not correspond to the domain definition (e.g., unexpected or unknown codes, formats, etc.)
Duplicate Occurrences multiple records that represent a single real world entity. Typically customers or addresses are duplicated several times.
Business Rules Violation data do not conform to business rules, for example, two fields have valid values but the combination of these values is not allowed.
Reconciliation Errors data in the data warehouse do not correspond with the same data from another surrogate data source (e.g., comparing sum of balances on
client accounts and sum of balances on GL accounts).
Source System Data Quality Assessment
Review the Data Mapping (CV.027) to identify source systems and objects. Ensure the data sample for each system is available and that it has the required scope and
size. Conduct the survey on each source system for the KPIs identified and relevant for the particular source system. List the issues identified by the survey. Identify
possible resolutions for the problem. Where necessary, discuss the issues and resolutions with the owner of the source system. Assign owners for the tasks to be
performed for resolving the identified issues. When the necessary actions have been taken, update the document with the status of the issues.
SOURCE SYSTEM DETAILS
Create a table containing the following information about the data sample and the assessment:
Source System Name name of the source system
Source System Owner - owner of the system, i.e., role, department or individual
Format of Source Data - format of the source data files, SQL tables, etc.
Size of the data sample size of the sample
Data Sample Environment - from which environment the sample was produced
Effective Data of the Data Sample - effective data of the sample data
Who has performed the assessment - name of the person who performed the assessment
When the assessment was performed - date the assessment was performed
Comments - any general comments regarding the assessment, data sample, constraints, data manipulations needed to analyze the sample, etc.
ASSESSMENT RESULTS
Create a table containing the results of the assessment for each source object (file, table, message type etc.) and KPI. Include the following:
Source Object name of the file or table
ID unique identification of the assessment
KPI reference to the KPI
Result result of the assessment
Issue Description description of found issue (if any)
Suggested Resolution suggested method how to solve the issue
Assigned To to whom (person, team) is the issue assigned
Action Taken action taken to ensure resolution of the issue, status of the issue
It is important to document not only the KPIs the particular source systems did not meet, but also the KPIs that the system passed.
Back to Top
System Architect
Identify information (data) quality issues early in the development cycle and establish appropriate escalation and resolution of
those issues. Preferably, this should be done by a system architect that specializes in Information Architecture.
100
Client Data Administrator Provide assistance in Identifying data quality issues early in the development cycle and establish appropriate escalation and
resolution of those issues.
*
Ambassador User Provide assistance in Identifying data quality issues early in the development cycle and establish appropriate escalation and
resolution of those issues.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Data Acquisition, Conversion and
Data Quality Strategy (CV.020)
The Data Acquisition, Conversion and Data Quality Strategy describes the data quality objectives, measures and other data
quality requirements
(RD.020)
These work products contain descriptions of the current processes, files, known data quality, integrity and availability issues.
Business Use Case Model (RA.015) The Business Use Case Model contains information about the business needs and expectations, what is the data structure and
quality required from the business .
Data Mapping (CV.027) Use the Data Mapping to identify source system files and attributes to be subject of the data quality assessment (i.e., if an
attribute is not mapped it does not make sense to measure its quality).
Data Samples The data sample has to be statistically meaningful and, if possible, it should be generated from the production data. The
sample should correspond to the files or other data structures that are loaded to the target system.
Back to Top
TEMPLATES AND TOOLS
RA_170_HIGH_LEVEL_DATA_QUALITY_ASSESSMENT.DOC MS WORD
Back to Top
The High-Level Data Quality Assessment is used in the following ways:
to assess the extent of effort required to resolve any data quality issues and the impact on the overall project
to identify and resolve data quality issues in the source systems
Distribute the High-Level Data Quality Assessment as follows:
to the project team
to the owners of the source systems for review and any action on their part, if necessary
Back to Top
QUALITY CRITERIA
Are all source systems and source objects in the Data Mapping (CV.027) been covered?
Are the KPIs identified in the Data Acquisition, Conversion and Data Quality Strategy (CV.020) listed in this document for all source systems?
After surveying the source system, are all identified issues listed with recommended resolutions and have they been assigned resources?
Are these actions in line with the resolution and escalation hierarchies identified in the Data Acquisition, Conversion and Data Quality Strategy (CV.020)?
Back to Top
RA.180 - REVIEW USE CASE MODEL
In this task, the the Use Case Model (RA.023) and Use Case Specification (RA.024) produced in the Requirements Analysis (RA) process are reviewed and revised as
necessary. This review may also include the Validated Functional Prototype (RA.085) in order to ensure that any defects found during the validation have subsequently
been corrected.
Once the use cases are ready for review, system analysts, ambassador users, designers, architects, and testers review them. As a result of such a review, defects may
be found and should be addressed for correction. Different types of reviews can be used. However, OUM recommends the use of inspections and peer-reviews to
improve quality.
This task is performed several times over the course of the project as use cases are ready to review or are updated and in need of further review. The second iteration of
this task in the Elaboration phase is considered optional and only done if there are further use cases that require review.
ACTIVITY
RA.180.1
RA.180.2
Back to Top
WORK PRODUCT
Reviewed Use Case Model - The Reviewed Use Case Model consists of the list of defects and the corresponding action for correction.
Back to Top
TASK STEPS
1 Conduct inspections or peer
reviews.
Defects Record Defects on a tracking system or on the PJM QM.020 template.
2 Determine and make
corrections.
None None
3 Obtain formal approval. None It is important to receive formal acceptance for the use cases before spending development effort or finishing
definition of UI and architecture.
Back to Top
APPROACH
This task should be performed for every software development project. It could be repeated for subgroups of use cases during Elaboration phase iterations.
OUM recommends peer reviews and inspections to improve quality. After final approval, it is important to make the use cases available to the whole project team.
Back to Top
Back to Top
System Architect Participate in the review meeting to verify if the Use Case Model and Use Case Specifications are compatible with the
architecture.
25
Developer Lead the Use Case Model Walkthrough. Present the Use Case Model and Use Case Specifications. 25
Quality Manager Review the Use Case Model and Use Case Specifications from the point of view of the Testing process. Gain understanding of
the internal structure of the application.
25
System Analyst Participate in the review meeting in order to verify if the Use Case Model and Use Case Specifications realize the
requirements.
25
Back to Top
PREREQUISITES
RA.180.1
Prerequisite Usage
Use Case Model
(RA.023.2)
Use Case
Specification
(RA.024.1)
The Use Case Model and Specification are under review in this task.
Validated Functional
Prototype (RA.085)
The Validated Functional Prototype is included in order to ensure that any defects found during the validation have subsequently been
corrected. If the use cases being reviewed have not yet been included in the prototype, then this prerequisite is not required.
RA.180.2
Prerequisite Usage
Use Case Specification (RA.024.2)
The Use Case Model and Specification are under review in this task.
(RA.180.1)
The results from previous reviews may be used as an input for both preparing the review, as well as for a reference during the
review.
Back to Top
TEMPLATES AND TOOLS
QM-040_REVIEW_COMMENTS_LIST.DOC MS WORD
A tracking tool can also be used to log defects.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
[MC] MAPPING AND CONFIGURATION
In the Mapping and Configuration process, the goal is to create an acceptable and feasible configuration by mapping business requirements to standard features and
functions. The configuration is refined through prototyping and validating with users in preparation for system testing.
To begin, the key business data structures and associated values are defined and established within a prototype environment. The business requirements are assessed
and mapped to the standard application and system features. A prototype environment is updated with detailed setup parameters, and an iterative series of workshops
are conducted in order to validate that the prototype meets the business requirements. Resolutions to any gaps between the business requirements and the standard
application features and functions are defined, along with the documentation of detailed setup parameters.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
The objective of Mapping and Configuration is to create an acceptable and feasible prototype solution, that can be validated, and then is well documented.
Depending on type of business that the client is involved in, there will a number of key business data structures that must be defined. These business data structures will
be foundational to how the business is run; examples include Multi-Organization Structure, Trading Community Architecture (TCA), Chart Of Accounts etc. Once defined,
a representative subset of the business data structures and associated values should be established within the prototype environment in order to act as a foundation for
further more detailed setup and configuration steps.
The Mapping and Configuration process is closely related to the Business Requirements (RD) and the Requirements Analysis (RA) processes. Key outputs from these
related processes include Future Process Models, Use Case Models and Supplemental Requirements. These key outputs are assessed and mapped to the standard
features and functions that are available, and in scope, within the new system. Requirements that cannot be satisfied with standard features and functions are classified
as gaps in data or functionality (i.e., Gaps), which will subsequently be assessed in terms of identifying a workaround, a business process change, or custom software
extension.
The Prototype Environment is configured to support the mapped business requirements, and is refined through an iterative series of workshops designed to allow the
client and project team to progressively validate that the system will meet the in scope needs of the business.
Once the Configuration Prototype has reached a level of refinement that is close to the production needs of the client and project team, the configuration and setup
parameters are finalized and documented.
Back to Top
Inception Phase
MC.020 Define Business Data Structure Setups Business Data Structure Setups
Elaboration Phase
MC.030 Map Business Requirements Mapped Business Requirements
MC.040 Gather Setup Information Setup Information
MC.050.1 Define Application Setups Application Setups
MC.060 Document Functional Security Functional Security Setup
MC.070 Prepare Configuration Prototype Environment Configuration Prototype Environment
MC.080 Conduct Configuration Prototyping Workshop Validated Configuration
MC.100 Define and Estimate Application Extensions Application Extension Definition and Estimates
MC.110 Define Gap Resolutions Gap Resolutions
Construction Phase
MC.050.1 Define Application Setups Application Setups
Back to Top
OBJECTIVES
The objectives of the Mapping and Configuration process are:
Identify key business data structures and associated values.
Map business requirements to standard features and functions.
Prepare and conduct prototype validation workshops.
Resolve gaps.
Document application setups.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
Specialist
Provide knowledge and guidance regarding the functionality and capabilities of the product(s) being implemented. Provide knowledge and
guidance regarding the functionality, capabilities and implementation strategies for the product(s) being implemented. Validate that the
standard reports and forms, provided with the functionality being implemented, support the implementing organizations requirements. Assist
in validating that the standard reports and forms, provided with the functionality being implemented, support the implementing organizations
requirements.
BA Business Analyst
Conduct working sessions. Map detailed business requirements to the applications. Provide knowledge and guidance regarding the client's
existing business procedures, activities and functions and system access requirements. Provide assistance defining and estimating
application extensions. Define gap resolutions.
DBA Database
Administrator
Determine and set up the database schema structure, create and set up database.
SAD System
Administrator
Set up the administration of security and associated privileges. Prepare parts of the application environment.
SA System Architect Provide input and advice on the architectural consequences of particular gaps and alternatives. Assist in validating that the standard reports
and forms, provided with the functionality being implemented, support the implementing organizations requirements. Define and estimate
application extensions. Define gap resolutions.
Client (User)
KEY Ambassador User Participate in working sessions and help identify setup parameters and setup values. Provide specific examples of business transaction
forms, reports, data, etc. Provide information on the organizations reporting requirements.
BLM Business Line
Manager
Provide specific examples of business rules and procedures. Provide assistance as needed during the Perform Gap Analysis activity.
CPM Client Project
Manager
Provide assistance as needed during Define and Estimate Application Extensions (MC.100).
CSM Client Staff
Member
Ensure that physical resources are in place in time, and that proper software licenses are obtained.
PS Project Sponsor Provide assistance as needed during Define and Estimate Application Extensions (MC.100).
Back to Top
effective and continuing sponsorship at a high level in the organization
involvement by representative samples of stakeholders during the prototype workshops
clear understanding of the difference between process and functions or business units
measurability of process performance and determination of key performance indications (KPIs) for business processes
availability of expertise in relevant application features and how the features are used to support business processes
Back to Top
MC.010 - DEFINE BUSINESS DATA STRUCTURES
In this task, you design the structure of key business data elements that are application-specific and broad ranging. This involves identifying those key structural elements
(for example, Multi-Org, Trading Community Architecture (TCA), Chart Of Accounts) in the applications that are relevant to your particular implementation and
establishing the structures for those elements. This task focuses on the future production environment and not interim environments to support the project activities.
In a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach that includes pre-defined setup parameters, this task is performed
only to the extent necessary to tailor the pre-defined configuration, to meet client requirements.
For projects that involve the upgrade of Oracle products, this task is focused on the review of existing structural elements in order to determine the impact of any changes
introduced by the new release. For example, the new release may have additional fields, or characteristics that will enable the client to restructure their business data in a
more effective way.
ACTIVITY
MC.010.1
MC.010.2
Back to Top
WORK PRODUCT
Business Data Structures - The Business Data Structures identify those key structural elements in the applications (for example, Multi-Org, Trading Community
Architecture (TCA), Chart Of Accounts (COA) structures) that are relevant to your particular implementation and establish the structures for those elements across all
applications.
Back to Top
TASK STEPS
1 Review business requirements and mapping information to
establish values or parameters already specified.
None
2 Prepare an introduction for the work product. Introduction This component describes the purpose of the work product and lists the key
application structural elements that affect the application deployment and the
partitioning of data in the application database.
3 Establish a list of the sets of books needed for the
implementation and map their interrelationship.
Business Data
Structures
This component details the relationship between the key application setup
parameters, and relates them to the financial and operating structure of the
business.
4 Establish a list of inventory organizations needed for the
implementation and map their interrelationship.
Business Data
Structures
See above.
5 Establish a list of human resources business groups and
organizations needed for the implementation and map their
interrelationship.
Business Data
Structures
See above.
6 Create the integrated business architecture for the finance,
manufacturing, distribution, and human resources functions
of the business.
Business Data
Structures
See above.
7 Map the integrated business architecture to the detailed
business functions of finance, manufacturing, distribution,
and human resources functions.
Integrated
Application
Functional
Description
This component describes the relationship between the key application setup
parameters, and relates them to the main business functions.
8 Review application functional architecture with business
analysts.
Back to Top
APPROACH
The goal of this task is to define the aspects of the system configuration that are application specific and are broad ranging. These include organizational and
organizational structural elements.
This task is related to, but distinct from, normal application setups, because it deals with setup parameters that have a profound effect on the way the application database
is laid out and the basic functioning of applications. You may identify the critical parameters as part of Business Requirements (RD), but this task is where you define the
relationships between the key business data structures and define the cross unit and organizational features.
This task requires the identification and mapping of the key application setup parameters and the major application system functions to make sure that the overall
mapping of the parameters and functions is appropriate for the business processing requirements, but is also compatible with the application architecture envisioned for
the new system. The system architect gathers information about the different mapping decisions made, establishes the key parameters and functional areas affecting
architecture, and maps out the high-level interrelationship.
Attention: The system architect carries primary responsibility for this task and needs to be experienced and knowledgeable about the application architecture and
functionality of the application release and application products being implemented in the project. The system architect must make decisions on how to implement the
application and architecture to support the application functional architecture and the data distribution strategy developed in the conceptual architecture. These decisions
require knowledge of the fundamental technical architecture of the applications, and may also require a high level understanding of the key business processes involved
in different operations and business functions.
Relationship to Other Mapping and Configuration Setup Tasks
The following table describes the relationship of the setup tasks in the Mapping and Configuration process:
Task ID Task Name Usage
MC.010 Define Business Data
Structures
Design the structure of the various product components (for example, Chart of Accounts, Trading Community
Architecture, etc.).
Structure Setups
Define the values for the various components (for example, Chart of Accounts, Trading Community Architecture, etc.).
MC.040 Gather Setup Information Gather information about how the client intends to operate using the new application system in production in order to determine
appropriate setup options, including advanced, complex or foundational setup parameters ( such as Advanced Procurement,
Global Order Promising, Strategic Network Optimization, etc.).
MC.050 Define Application Setups Define the detailed application setup values.
General Business Data Structure Considerations
The design of the business data structures is concerned with aggregating the individual mapping decisions about the critical organizational relationships and application
setup parameters into an integrated and self-consistent architecture that spans every separate application install, site, or data center in your architecture.
The implementation of a package application product is unlike that of an in-house custom designed and built application, because in the former case, the structure and
processes of the business must be mapped onto the data and functional structures within the package, and there is usually very little room for altering the behavior of a
package application. Even a flexible application product suite, such as Oracle E-Business Suite, has a number of critical setup parameters that profoundly affect the way
applications function and the way data is organized in the application database. These parameters may affect the internal applications architecture, security, interfaces,
application database configuration, and logical partitioning of the data in the database. There are usually tradeoffs to consider in determining how best to configure these
parameters. The functional architecture of the applications varies from release to release of the applications, so it is important that you be aware of the functional
behavior for the release that you are targeting for your implementation.
Importance of the Business Data Structures
The effort required for this task varies with the complexity of the implementation you are performing, as determined by the following factors:
number of data centers or sites with application installations
the business functions and products you are implementing
the number of organizational business units and their relationships to each other
whether you have complex interrelationships between your business units or mixed centralized/decentralized business functions
whether your business requirements are easily met by the basic applications architecture and functionality
Regardless of the scope of your implementation, go through the exercise of mapping out your key setup parameters and their interrelationships. There are two major
reasons to do so:
INDEPENDENT MAPPING TEAMS
The decisions about the critical setup parameters are often made by individual functional mapping teams or individual analysts as they proceed with the mapping of
business processes. The danger is that the critical setup parameters are not assessed as a group to determine whether the overall mapping is consistent. Furthermore,
the functional mapping may not have the input of a system architect, who can assess the impact of the mapping on the overall architecture and processing of the system.
CONSOLIDATION AND COMMUNICATION OF DESIGNS
The other key reason for performing this task is to consolidate and document the overall application architecture, as well as to communicate it to the entire project team.
The application architecture design is a key piece of information for most of the separate processes in an implementation project, and should be communicated to the
team so that everyone understands the framework that they should be designing for or working within.
Critical Setup Parameters in Oracle E-Business Suite
SET OF BOOKS
A set of books is an accounting ledger with a particular chart of accounts, functional currency, and accounting calendar. It is important in financial applications.
BALANCING ENTITY
A balancing entity is a division or other business unit for which you prepare a balance sheet. A fund may also have its own balance sheet. This is implemented using a
balancing segment in the chart of accounts key flexfield. In non-multi-organization application architectures, the balancing segment values are used to specify legal
entities within a corporation, but the balancing entity can be used more generally for any type of entity producing a balance sheet. In multi-organization architectures, an
additional designation of legal entities is possible.
INVENTORY ORGANIZATION
An inventory organization is a plant, warehouse, or other type of business unit through which you access and perform transactions within one or more applications, such
as:
Inventory
Purchasing
Cost Management
Bills of Material
Engineering
Work in Process
Master Scheduling/MRP
Capacity
Quality
Attention: Review the current applications documentation to determine what applications utilize the inventory organization concept.
HR BUSINESS GROUPS AND ORGANIZATIONS
A Human Resources (HR) business group is the largest HR organizational unit you can define to represent your company, enterprise or corporation. It contains all
employee and payroll records that you enter into an HR system. You can define organizational hierarchies within a business group to represent reporting lines and
security hierarchies.
Depending on the applications mix being implemented, HR business group information may be managed in different places.
Sets of Books
When architecting your sets of books, situations exist in which you must consider tradeoffs and where you could satisfy the business requirements with more than one
approach. For example, you could fulfill the business requirements with one set of books or more than one set of books. Consider all the possible repercussions of your
decision, rather than just the narrow business requirement that led to possible use of multiple sets of books.
You can create an initial architecture for the sets of books by considering just the basic parameters that define the set of books, the chart of accounts, functional currency,
and calendar, and then mapping these onto the business organizations and their operating environments. Identifying the most appropriate functional currency for a
business organization is not always a clear-cut decision, but generally it is the currency that is used for the financial budgeting and forecasting of the organization that
is, the currency generally used for what are regarded as local currency transactions.
In foreign business organizations it is often the currency of the country where the particular office geographically resides, but this can be complicated by the flexibility in
local tax laws. It is also important to separate revenue (legal) entities from the local financial office entity. For example, it is possible to have a revenue entity
geographically based in the Pacific Rim that holds inventory owned by another entity and records its financial state in the currency of the owning legal entity. Having
created the initial architecture, you then need to identify the ramifications of the architecture, and you may even wish to create more than one candidate architecture for
review and comparison. The complexity of the sets of books architecture will increase with the implementation of the following elements:
financial subledger products along with General Ledger
Oracle Manufacturing products
a corporation with multiple legal entities that consolidates within General Ledger
multiple legal entities with different functional currencies
application products within multiple separate data centers with separate applications databases
A key decision you need to make in the financial architecture of your implementation is whether to use multiple sets of books for multiple legal entities with the same
functional currency, or to manage them within a single set of books and use the balancing chart of accounts segment to denote the different legal entities. This decision
should reflect:
security requirements in General Ledger
handling of inter- and intra-company transactions in General Ledger and other modules
consolidation process in General Ledger
security requirements in associated subledger and manufacturing products
use of accrual and cash-based accounting
specific functionality requirements in financial subledger and manufacturing applications
These are examples of factors that influence the business data structures of implementations and are not necessarily a complete list.
Warning: The details of the sets of books architecture depend on the specific release of the applications you are implementing. Determine the specific functional
capabilities of the application products and releases you are implementing prior to attempting the application functional architecture.
Inventory Organizations
As with the sets of books, consider the tradeoffs when you architect your inventory organizations and be aware that you can satisfy the business requirements with more
than one approach. A common case is where you could fulfill the business requirements with one or multiple inventory organizations. Again, like the sets of books
architecture, it is important to consider all the repercussions of your decision rather than the narrow business requirement.
As with the sets of books, consider the tradeoffs when you architect your inventory organizations and be aware that you can satisfy the business requirements with more
than one approach. A common case is where you could fulfill the business requirements with one or multiple inventory organizations. Again, like the sets of books
architecture, it is important to consider all the repercussions of your decision rather than the narrow business requirement.
The complexity of the inventory organization architecture increases with the implementation of the following elements:
distribution or financial products along with Manufacturing products
a business with multiple manufacturing/distribution units that have different business practices or manufacture different finished goods
a business that has a tightly integrated supply chain with other external trading partners
a corporation with multiple legal entities, some of which own inventory and generate revenue
application products within multiple data centers with separate applications databases
A key decision in the manufacturing and distribution architecture of your implementation is whether to use multiple inventory organizations to represent the manufacturing
and distribution functions of your business, or to use a single inventory organization with multiple subinventories. This decision should reflect the following possible
features:
security requirements for transactions generated by your manufacturing business units
costing methods and rules for different business units
multiple manufacturing calendars
handling of in-transit inventory and drop shipments
forecasting details
planning methods
handling of common parts across different business units (for example, different units of measure, costs, lead times, cycle count tolerance, and so on)
consignment inventory or external supply-chain requirements
This is only a selection of the factors that influence the functional architecture of implementations and not necessarily a complete list.
Warning: The details of the inventory organization architecture are very dependent on the specific release of the applications you are implementing. You should
determine the specific functional capabilities of the application products and releases you are implementing prior to attempting the application functional architecture.
Implementation of Multi-Organization Structure
The multi-organization structure option is a way to implement a decentralized business operational model within applications, within a single application database, and
within a single installation of every product.
The multi-organization architecture adds two more key setup parameters to the set of books, balancing entity, and inventory organization mentioned above.
LEGAL ENTITY
A legal entity is a legal tax or fiscal reporting entity. It is implemented as a classification of an organization within applications.
OPERATING UNIT
An operating unit is an operational business unit that performs one or more of the following business functions:
accounts payable
accounts receivable
revenue accounting
order management
customer service
purchasing
receiving
Legal Entities
The concept of the legal entity is used widely in standard reports and transactions; legal and tax reporting may also be done through the mechanism of reporting based on
the balancing segment. Refer to the current release documentation for specifics.
Operating Units
The operating unit parameter provides a means to define secure business units within the Oracle Applications products mentioned above. It does not directly affect the
architecture of the manufacturing application products, but has an indirect impact because the manufacturing products communicate with, and transfer data to and from
the subledger and distribution products. If you are implementing Oracle financial or distribution products along with the manufacturing products, you need to make sure
that the application architecture of the manufacturing part of the business is properly aligned with the financial and distribution application architecture.
The operating units are also important because of cross-business unit buying, selling, and shipping functionality in the multi-organization architecture. Different business
units (that may be in different legal entities) can buy, sell, and ship product from, or on behalf of, each other. A inter-company accounting process generates the payables
and receivable invoices that result from the cross-legal entity transaction. You implement this functionality at the operating unit level, and the need for this capability within
the business will be an important factor in the definition of the operating units.
HR Business Groups and Organizations
If you are implementing Oracle HRMS without implementing other Oracle financial or manufacturing products, you can define your application architecture based on the
HR requirements alone. Determine the reporting lines and security groupings you need to implement for your business, and then determine the business groups and the
HR organizational hierarchies you will use as the framework application architecture for the rest of the data you will enter in the system.
If you are implementing human resources applications with financial applications, bear in mind that data is shared between the application product families and may have
an impact on the overall application architecture. For example, the legal entity that you create as part of your financial architecture may also be a government reporting
entity within HR. Make sure that the same organization is correctly defined for the integrated application architecture. If you are sharing other classifications of
organizations in the HR organization hierarchy with financials and manufacturing, it is again important to provide consistency of operation.
HR employee data is also referenced within the financial and manufacturing products, such as Oracle Purchasing and Engineering. If you plan to create an HR application
architecture with multiple business groups, this may have implications for the ability to view employee data within the financial products.
Financial Application Implementations
If you are only implementing financial applications, you do not need to concern yourself with the detailed definition of a manufacturing or distribution application
architecture. However, because you may still need to share some of the setup parameters across business functions (for example, the parts master), you may not be
able to totally disregard the manufacturing and distribution sections of the deliverable. You may also need to consider the human resources business groups that you
create to store the employee data, which is shared with other applications.
Manufacturing and Distribution Application Implementations
Although you may only be implementing particular manufacturing or distribution application products, you may still need to define the accounting structure that defines the
financial operating environment for a particular inventory center or warehouse.
Back to Top
Back to Top
System Architect Provide input and advice on the architectural consequences of particular gaps and alternatives. 50
Business Analyst Conduct working sessions. Map detailed business requirements to the applications. 30
Application/Product
Specialist
Ambassador User Participate in working sessions and help identify setup parameters. *
* Participation level not estimated
Back to Top
PREREQUISITES
MC.010.1
Prerequisite Usage
Present and Future Organization Structures
(RD.012)
The Present and Future Organization Structures provides information about the company financial hierarchy, the
business organizations, and the functions the organizations perform.
Current Process Model (RD.030) The Current Process Model includes process flow diagrams of the current business processes and functions.
Future Process Model (RD.011.1) The Future Process Model describes the future-state business processes.
Technical Architecture Workshop Results
(TA.010)
The Technical Architecture Workshop Results provides information on the scope, requirements, and strategy for
the architecture work.
Application Product Reference and
Implementation Guides
The application product reference or implementation guides should contain information about the key application
setup parameters and their effect on the functional architecture and behavior of the applications.
Back to Top
TEMPLATES AND TOOLS
MC-010_BUSINESS_DATA_STRUCTURES.DOC MS WORD
Back to Top
Back to Top
QUALITY CRITERIA
Do the Business Data Structures address multi-organization architecture including entities, sets of books, operating units and inventory and supply-chain
organizations?
Back to Top
MC.020 - DEFINE BUSINESS DATA STRUCTURE SETUPS
In this task, you establish the values for the key business data structures in the applications (for example, Multi-Org, Trading Community Architecture (TCA), Chart Of
Accounts (COA) structures) that are relevant to your implementation, and whose structures were defined in the Key Business Data Structures (MC.010). This task
focuses on the future production environment though the values defined in this task are also used in interim environments to support the project activities.
In a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach that includes predefined setup parameters, this task is performed
only to the extent necessary to tailor the predefined configuration to meet client requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Business Data Structure Setups - The Business Data Structure Setups define the values for key structural elements in the applications (for example, Multi-Org, Trading
Community Architecture (TCA), Chart Of Accounts (COA) structures) that are relevant to your implementation.
Back to Top
TASK STEPS
Component
Description
1 Review the Business Data Structures (MC.010).
2 Review existing materials to establish values of parameters already specified.
3 Conduct meetings or workshops with client staff members who have understanding of the business requirements and
responsibility for defining Business Data Structure Setups.

4 Describe the purpose of the work product and its contents. Business Data
Structure Values

5 Define the Business Data Structure setup parameters intended for production. Business Data
Structure Values

6 Review and confirm configuration decisions and impact of changes.
7 Secure acceptance of the Business Data Structure Setups.
Back to Top
APPROACH
The goal of this task is to define the values for the key structural elements in the applications (for example, Multi-Org, Trading Community Architecture (TCA), Chart Of
Accounts (COA) structures) that are relevant to your implementation.
This task is related to, but distinct from, normal application setups in that it deals with setup parameters that have a profound effect on the way the application database is
laid out and the basic functioning of applications.
Structures
Design the structure of the various product components (for example, Chart of Accounts, Trading Community Architecture,
etc.).
Structure Setups
Define the values for the various components (for example, Chart of Accounts, Trading Community Architecture,
etc.).
MC.040 Gather Setup Information Gather information about how the client intends to operate using the new application system in production in order to
determine appropriate setup options, including advanced, complex or foundational setup parameters ( such as Advanced
Procurement, Global Order Promising, Strategic Network Optimization, etc.).
Back to Top
System Architect Provide input and advice on the architectural consequences and alternatives. 60
Business Analyst Conduct working sessions. Map detailed business requirements to the applications. 40
Ambassador User Participate in working sessions and help identify setup values. *
Back to Top
PREREQUISITES
Prerequisite Usage
Present and Future Organization
Structures (RD.012)
The Present and Future Organization Structures provides information about the company financial hierarchy, the business
organizations, and the functions the organizations perform.
Business Data Structures (MC.010.1) The Business Data Structures identifies those key structural elements in the applications (for example, Multi-Org, Trading
Community Architecture (TCA), Chart Of Accounts (COA) structures) that are relevant to your implementation and
defining the structures for those elements across all applications.
Back to Top
TEMPLATES AND TOOLS
MC-020_BUSINESS_DATA_STRUCTURE_SETUPS.DOC MS WORD
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
MC.030 - MAP BUSINESS REQUIREMENTS
In this task, you assess the fit of standard application and system features to the detailed business requirements as reflected in the Future Process Model (RD.011), Use
Case Model (RA.023), and Use Case Specification (RA.024), as well as requirements detailed in the Supplemental Requirements (RD.055), Reporting Fit Analysis
(MC.090), Audit and Control Requirements (RD.070), and the MoSCoW List (RD.045). Outcomes from the execution of this task may include one or more of the
following:
A determination of how standard application and system features can be employed to satisfy the requirements,
A description of workarounds that might be used to get around an application gap to a business requirement, and
Identification of application extensions, custom software modules, or enhancements needed to satisfy requirements.
For projects that involve the upgrade of Oracle products, this task is used to assess the fit of the new release to the detailed business requirements. The Future Process
Model (RD.011) and the Use Case Model (RA.023) describe the business requirements that are then mapped to the functionality in the new applications release. For
upgrade projects, this task should also include an update to the clients existing requirements mapping artifacts
ACTIVITY
Back to Top
WORK PRODUCT
Mapped Business Requirements - The Mapped Business Requirements shows the results of mapping detailed business requirements to standard application and
system features. This task generates the Business Requirements Mapping (BRMs) Forms for complex requirements and gaps. The compilation of all of the BRM Forms
represents the Mapped Business Requirements.
Consider using the MS Excel version of the MoSCoW List (RD.045) template to map detailed business requirements to standard application and system features and
reserve preparation of Business Requirements Mapping Forms for complex requirements and gaps. Use the RD.045 MoSCoW List tab to list the detailed business
requirements and populate columns B, D, E, etc. to document the mapping results.
Back to Top
TASK STEPS
1 Train all assigned team members in the use of the methods and
tools for mapping.

2 Review high-level gaps, and the approach to resolve these gaps.
3 Review Future Process Model and Use Case Models for target
processes in need of mapping.

4 Conduct mapping sessions to assess detailed application fit and
create or revise alternatives to business requirements. Map future
business requirements to application features, programs, reports,
and other standard modules.
Process
Scenario
Solution
This component requires the following information:
Process Step Number a unique sequence number for each task
System/Module a reference to the application system module that
satisfies this task requirement
Application navigation path or transaction zone information
describing entry form used for system-assisted tasks
Ref Manual Page/Line a topical essay or other narrative in an
application, user or technical reference manual
Tools reports or other mechanisms used in completing the task
successfully
Solution Type used to designate workaround/extension; use W if
there is a non-system workaround that is acceptable, although not
necessarily optimal; use E if there is a need for extension (complete a
Mapped Business Requirement form for all tasks coded with E)
BRM Ref Number Business Requirement Mapping Form control
number; optional unless Solution Type is E
5 Document major requirements. Mapping This component facilitates the analysis and comparison between current
Source solution to a business requirement and to a proposed solution.
The mapping source requires the following information:
Process a brief description of the process
Business Area a code designating the mapping team responsible for
this process
Date date form is being initiated
Control Number a unique identifier for each business process (for
example, 6-character code in format AAA.999, where AAA represents
the subprocess, and 999 is a unique 3-digit code assigned sequentially
from a log maintained by each team)
Mapping Team either the process modeling, design, or mapping
team responsible for this business process
Process Owner the agent with overall responsibility for the process;
could be the customer of the process, or the supplier (one who fulfills
the request)
Librarian the person charged with maintaining this work product and
interfacing with other teams in order to maintain control and proper
alignment with integration goals
Priority determined at each teams discretion; this is a good place to
identify Core Processes
Core an identification of major, driver processes that affect or
influence business objectives
Source Type indicate whether the BRM Form will document a gap or
a design note
Author originators name
Ref Doc reference to some other formal requirement description
source document (usually such a document already exists and the
BRM initiator simply wishes to avoid rekeying its contents on the BRM
Form)
Use Case Reference Number Use case control number that is the
parent of this BRM Form (also enter process step number)
6 Prepare Requirements Essay. Requirements
Essay
The Requirements Essay is used to describe the requirements in terms of
business objectives rather than application features. It should clearly define
the reasons for the requirement along with any supporting information.
7 Perform process research; look for and document alternatives.
8 Identify current versus proposed process steps and assess the
feasibility of proposed alternatives.
Current
versus
Proposed
This component documents the current process steps planned for elimination
or modification, including the expected effect on cycle time, cost, and other
resources. The section can be duplicated to show both current and proposed
processes.
Practices narrative description of customary or usual actions
Policies principles, plans or courses of action, especially as dictated
by management
Procedures narrative description of sequence of steps to be followed
Seq process step number
Ref/Description a brief description, beginning with an action verb,
that captures the purpose and deliverable task; alternatively, could
include a reference to another document (or just use the use case step
description)
Activity optionally may be used for activity-based analysis purposes
Action ADD/DEL/CHG status for the sequence number
Cost/Time/Resource measurable resource usage by the sequence
number
9 Document alternatives. Record possible alternatives for application
gaps.
Mapping
Solution
This component details the type and nature of the solution in a descriptive
format.
Workaround description of the proposed method for getting around
an application gap to a business requirement
Application Enhancement description of the custom modification to
the application whose implementation will result in satisfaction of the
business requirement
Reengineering Opportunity description of simplification, elimination
or enhancement of the target process
Solution/Design Document Reference if available, a document
number for high-level or detailed design planned to satisfy the
requirement
Mechanism resources that influence the process; people, tools, or
machines affected by the BRM proposal
Interfaces description of system interface requirements necessary to
satisfy the requirement
Solution Technique description and type of application feature that
will satisfy the requirement (configuration, setup, flexfield, alert, report,
form, and so on)
10 Document major operating and policy decisions.
11 Secure acceptance of the Mapped Business Requirements.
Back to Top
APPROACH
The Map Business Requirements task generates Business Requirements Mapping (BRMs) Forms for complex requirements and gaps. The combination of these
documents represents the Mapped Business Requirements.
Definition of Mapping
Mapping is a set of activities that begins during the presales cycle, continues during the initial stages of the project (gathering of identified business requirements and
application gap materials), becomes more formalized during the Inception phase, and concludes during Elaboration with the creation of Mapped Business Requirements.
Mapping a business process means:
proving designs through demonstration
identifying gaps in the application
proposing feasible bridges to gaps
The following list includes some broader connotations of the term mapping:
the basis for establishing application fit to business requirements, identifying gaps, and proposing alternatives
the formal linkage of Future Process Model (RD.011) to application features
In this regard, mapping describes the evolution of process design for a business process. The business processes and associated use case models will continue to evolve
and be supplemented and improved throughout all mapping tasks. The formal mapping task, however, is very specific in that it documents key business requirements
and proposed alternatives in much more detail than generally described in a business process model or use case.
Mapping Teams Organized
Organize mapping teams around the same grouping as process design teams. This means that the same teams will work on Future Process Model development, as well
as Use Case completion and BRM Form creation.
The skills required for a mapping team are similar to those for a process design team, except that mapping typically includes a heavier concentration on detailed
recommend alternatives. Detailed application knowledge becomes more important during mapping.
Key users should participate in mapping sessions. It is best to perform mapping as near as possible to the actual location in which most of the process tasks take place, in
order to have access to key users, and to be able to witness process execution as questions arise. Capture decisions made and agreements reached so that the final
product reflects the proposed business process design.
It is very important that the configuration management role be properly executed, especially with regard to the following areas:
updating BRM Forms providing work product status
setting up configuration management (to help encourage proper use of tools and cataloging of work products)
tracking events, use cases, and BRM Forms in order to help maintain integrity (addressing all identified gaps)
Always organize mapping sessions for efficiency by publishing a thorough agenda that includes:
session location and duration
role assignments
the business process to be mapped
activities and sequence
the inputs required (like prerequisite deliverables) and assignments for bringing them
the expected outputs and criteria for successful closure of the mapping session
Mapping Process
It may be hard to separate mapping activities from those of business process design, especially in the following situations:
The project is small or its target business area contains few business processes.
The project team is pursuing rapid implementation and therefore wants to complete deliverables in parallel as much as possible.
The process design team is intact through the mapping stage, and therefore process design and mapping form more of a continuum.
Update the Future Process Model as a record of your mapping progress. In addition to updating Future Process Model, create BRM Forms as needed. This document is a
proposal for changes to some process design detail (at the process step level) that needs approval or specification. It is a description of the proposal. If a business
requirement maps 100 percent to the application, it may not be necessary to create any BRM Forms for that business process.
When mapping, keep the following step-savers in mind:
Address critical business processes identified by the organization before seeking resolution to minor issues that crop up in business process designs and maps.
Use standard system features, functions, and reports whenever possible.
Use extensibility features, such as descriptive flexfield.
New business requirements could emerge during a mapping session. Verify that these new requirements fit within the scope of the project before adding them to the
business requirements list. Set aside time to finalize these requirements.
Detailed Fit Assessment
During the development of the Future Process Model (RD.011), encourage teams to perform an initial assessment of application fit to business requirements.
Documenting this information will provide an important input into detailed mapping.
Complete a BRM Form for those steps on the Future Process Model (RD.011) with a gap (or whenever you need a detailed requirement more thoroughly investigated). A
BRM Form is like a placeholder and usually results in an Application Extension Definition and Estimates (MC.100) document. After process refinements and decisions are
made, Design activities may begin, resulting in Application Setup Documents (MC.050).
Solution to Application Gaps
There are many types of alternatives to application gaps, ranging from large subsystems to localized modifications (configuration, setup, flexfield, alert, report, and form),
to simple workarounds. You still may want to create a BRM Form just for emphasis when approving a workaround built into the Future Process Model. The revised
process reflects the approach dictated by the workaround and downstream users, and reviewers of the process are able to use the reasons and support information.
Examples of large-scale subsystems are:
custom security architecture
reporting systems
critical enterprise interfaces
It is best to avoid very detailed documentation in the BRM Form. Think of the BRM Form as a record of key decisions, or as a placeholder in anticipation of additional
detailed design documentation.
Adequately bridging gaps is the primary purpose of the BRM Form. Consider these tips when mapping and creating BRM Forms:
Design alternatives for the desired state of the business, rather than directly mapping to current needs.
Always implement workarounds before designing and building a custom extension.
When multiple alternatives are available, choose the alternative that supports organization goals or broad business areas, rather than satisfying the needs of a
single department or user.
In order to obtain rapid implementation, consider these mapping tips:
Get quick closure on gaps.
Push hard on perceived gaps up to 80 percent of the initial gaps identified may actually be found to be unnecessary.
Ask the question, What does the application do? in order to keep the mapping session moving.
Adjust business processes to fit standard application functionality.
Pay special attention to prioritizing gaps in order to manage scope and budgeted resources properly.
Back to Top
Back to Top
Business Analyst
Provide knowledge and guidance regarding the client's existing business procedures, activities and
functions.
50
Application/Product Specialist
Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for
the product(s) being implemented.
25
System Architect Provide input and advice on the architectural consequences of particular gaps and alternatives. 25
Business Line Manager Provide specific examples of business rules and procedures. *
Ambassador User Provide specific examples of business transaction forms, reports, data, etc. *
Back to Top
PREREQUISITES
Prerequisite Usage
Future Process Model (RD.011) The Future Process Model describes the future state business processes.
Use Case Model (RA.023) The Use Case Model is helpful for identifying functional requirements that are described via a use case.
Use Case Specification (RA.024) The Use Case Specifications detail functional requirements that are described via a use case.
Reporting Fit Analysis (MC.090) The Reporting Fit Analysis provides a disposition of every report requirement.
MoSCoW List (RD.045) The MoSCoW List provides the prioritized list of requirements.
Back to Top
TEMPLATES AND TOOLS
MC-
030_BUSINESS_REQUIREMENTS_MAPPING_FORM.DOC
MS Word
Back to Top
Back to Top
QUALITY CRITERIA
Does the Business Requirements Mapping Form include an organization of mapping alternatives?
Does it eliminate non-value-added steps?
Does it provide the best method to implement selected alternatives?
Are the reporting and messaging needs of custom extensions covered?
Are special or additional implementation steps needed?
Does it include perceived shortfalls and required system enhancement?
Back to Top
MC.040 - GATHER SETUP INFORMATION
In this task, you gather detailed information about how the client wants to operate in the new application system once it is in production use. You conduct workshops to
collect input on application setup decisions that are not evident from the Future Business Process Model (RD.011) alone.
ACTIVITY
Back to Top
WORK PRODUCT
Setup Information - The Setup Information provides detailed information about the future-state business processes, activities and functions.
Back to Top
TASK STEPS
1 Schedule, confirm and prepare for process
exploration sessions by business area.

2 Identify the structurally-complex business
processes and write a summary description of
each process.
Process Listing and
Process Descriptions

3 Conduct interviews using questionnaires and other
sources of information to clarify questions you
have Identified.
Key Setup
Considerations
This component describes key setup considerations that need to be taken into
account when preparing the Configuration Prototype Environment (and eventually the
Production Environment).
4 Gather any business materials that may enhance
the teams understanding of the business process
requirements.
Current and Future
Business Process
Documentation

5 Identify any issues regarding the business
analysis.

6 Review the future business process and
procedures with users and business area
management.

7 Secure acceptance of the future business
processes and procedures from business area
management.

Back to Top
APPROACH
Set-up information can be derived from a number of sources including:
Present and Future Organization Structures (RD.012)
Where available, these work products should be reviewed in order to understand the future system setup requirements. Additionally, review any available documentation
that describes the clients existing business procedures, activities and functions in order to ascertain any potential impact on system setup decisions.
Structures
Design the structure of the various product components (for example, Chart of Accounts, Trading Community Architecture, etc.).
Structure Setups
MC.040 Gather Setup Information Gather information about how the client intends to operate using the new application system in production in order to
determine appropriate setup options, including advanced, complex or foundational setup parameters ( such as
Advanced Procurement, Global Order Promising, Strategic Network Optimization, etc.).
Business Process Questionnaires
Use structured process questionnaires to collect business and current system information during a business interview for a given process. These questionnaires can be
modified to help make sure that the team interviews net the following factors:
business events triggers for action (for example, receive invoice)
location, nature, and sequence of transactions data added
magnitude and frequency of transactions
performance metrics core processes or critical transactions
key factors for success
key processes and process cost drivers
representative families or products and transactions
opportunities, constraints, risks, and issues
underlying structures of static data organization
bottlenecks to the flow of information and material
the particular value of current business processes
data gathering methods that drive technology requirements
current system configuration options
Always customize the questions for your audience and their particular needs and business conditions.
Suggestion: Get assistance from users when creating the questionnaires. This helps develop ownership in key people who represent interviewees.
Use local business terminology to facilitate development of content and to avoid misunderstanding words, phrases and concepts during the interview. It is sometimes
helpful to review the terms definitions and document them to assist cross-functional users in accepting a departments/process jargon. For example: COB can mean
Close of Business in one area and Cost of Benefit in another.
Before using a questionnaire, think about how to organize the information (into families and categories) and reuse the questions to cover representative products and
processes for each group. For instance, the process baseline for finished goods shipments may be completely different from that of the shipment of spare component
parts. In this case, if you ask questions about only one class of material, you may miss critical information about how the business works.
Review and Acceptance
As each process team completes its Setup Information, it should be reviewed with the project team, area users and management, and any cross-process integration
teams. Formal acceptance of the work product should be by the business area manager.
Multi-Phase, Multi-Site Implementation
If the implementation is multi-phase or multi-site, the task of developing the Setup Information may be more complex. It is helpful in a multi-phase implementation effort to
complete the entire Setup Information work product, especially at the higher levels during the first phase. A completed Setup Information work product, at a high level,
gives the project focus and improves decision making and assists in defining the limits of the scope of the project. Additional detail or levels can be documented when the
appropriate phase is started.
With multi-site implementations, the differences in the processes can be annotated as belonging to the specific site where the process differs. Occasionally, process
modeling team members learn a better way in these sessions and business process improvements are affected more quickly. When this happens, determine if the better
way maps adequately to the standard application functionality and any custom designs.
Back to Top
Business Analyst Provide knowledge and guidance regarding the clients existing business procedures, activities and functions. 50
Application/Product
Specialist
implemented.
50
Ambassador User Provide specific examples of business transaction forms, reports, data etc. *
Back to Top
PREREQUISITES
Prerequisite Usage
Future Process Model (RD.011) The Future Process Model describes the future-state business processes.
Structures (RD.012)
This work product describes the current and future organizational state of the client's business.
(RD.020)
The High-Level Business Descriptions provides contextual business information collected during the high-level
requirements definition workshops.
Back to Top
TECHNIQUES
Technique Comments
Nominal Group Use this technique to help drive group consensus and decision making.
Back to Top
TEMPLATES AND TOOLS
MC-040_SETUP_INFORMATION.DOC MS WORD
Back to Top
The Setup Information is used as follows:
as an input to the Application Setup Documents (MC.050)
Distribute the Setup Information as follows:
to all Mapping and Configuration project team members
Back to Top
QUALITY CRITERIA
Does the Setup Information describe the key business processes and functions?
Does the Setup Information describe critical requirements in terms of their impact on system setup?
Back to Top
MC.050 - DEFINE APPLICATION SETUPS
In this task, you define and document the detailed setup values needed to configure the applications in accordance with the client requirements.
In a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach that includes predefined setup parameters, this task is performed
only to the extent necessary to tailor the predefined configuration, to meet client requirements. This typically includes those updates necessary to "personalize" the
environment with client-specific data, such as, company name, locations, Chart of Accounts Structure, etc., but could involve more extensive updates to enable additional
functionality, etc.
For projects that involve the upgrade of Oracle products, this task is used to make manual updates to application settings that could not be completed by the automated
upgrade process.
ACTIVITY
MC.050.1
MC.050.2
C.ACT.PST Prepare for System Test
Back to Top
WORK PRODUCT
Application Setup Documents - The Application Setup Documents define the detailed setup parameters that have been proven to support the future business
processes.
Back to Top
TASK STEPS
1 Review the Future Process Model (RD.011.2).
2 Review the Use Case Specifications
(RA.024).

3 Review Business Data Structures (MC.010.2).
4 Review the Business Data Structure Setups
(MC.020)

5 Define the application setups intended for
production.
Application Setup
Documents
The components of the Application Setup Documents vary depending on the application
that is being addressed.
6 Review and confirm configuration and impact
of changes.

7 Secure acceptance of the Application Setup
Documents.

Back to Top
APPROACH
The Application Setup Documents record the parameters, user-defined codes, and other setups for each application. As requirements definition completes and
requirements analysis begins, the components required to complete the configuration fall into place. You can extract the setup requirements from existing documentation.
The main objective is to consolidate the configuration of all applications for centralized maintenance. With the number of separate application databases on the
organizations systems, it becomes a challenge to make sure that the configurations represent the latest mapping decisions.
Because Application Setup Documents undergo many revisions, confirm that there are procedures in place to update and carefully control the setups. You may want to
control Application Setup Documents with a configuration management tool.
Warning: Only key project team members, each with specific responsibilities, should initially define the system application setups. It is important to stabilize the
environment and control the changes made during the mapping process, so that any one team does not undo the settings made by another team.
It is particularly challenging to maintain setups by application module when design and testing activities have been organized by business process. If an integration team
is responsible for cross-process integrity, let them assist with maintaining application setups as well.
The Application Setup Documents include master tables to control ownership, QA responsibility, due dates, and approval signoff for each component setup, in addition to
the detail table specific to each component.
Structures
Design the structure of the various product components (for example, Chart of Accounts, Trading Community Architecture, etc.).
Structure Setups
MC.040 Gather Setup Information Gather information about how the client intends to operate using the new application system in production in order to determine
appropriate setup options, including advanced, complex or foundational setup parameters ( such as Advanced Procurement,
Global Order Promising, Strategic Network Optimization, etc.).
Critical Setup Parameters
Application parameters do not all carry the same importance to the business. Some are more critical in determining how the system will be operated. For instance, within
the standard applications the following parameters control significant processing features and functions:
Set of Books an accounting ledger with a particular chart of accounts, functional currency and accounting calendar
Balancing Entity a division or other business unit for which you prepare a balance sheet
Inventory Organization a plant, warehouse, or other type of business unit designed to provide control and transaction functionality within one or more
applications modules
Low-Volume Conversion Activities
You may use the application setup tables or spreadsheets as source documents for manual conversion activities. These spreadsheets help you record the entries needed
for production. Weigh the resource time needed to enter this data against the total development time for automating the conversion.
Standard Reports
Some standard applications provide standard setup reports that capture the input data automatically. Simply run these reports and use these as source documents for
later setup activities.
Screen Shots
Take online screen shots of the standard applications displaying the system and parameter selections. Be careful to capture the complete setup; many definition screens
are made up of multiple screen pages.
Back to Top
Back to Top
Business Analyst Provide knowledge and guidance regarding the client's existing business procedures, activities and functions. 50
Application/Product Specialist Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for the
product(s) being implemented.
40
System Administrator 10
Ambassador User Provide specific examples of business transaction forms, reports, data, etc. *
Back to Top
PREREQUISITES
Prerequisite Usage
Future Process Model (RD.011.2) Use the Future Process Model to to understand the future-state business processes.
Use Case Specification (RA.024) Refer to the Use Case Specifications to understand functional requirements for gaps or complex business functions.
MoSCoW List (RD.045) The MoSCoW List provides the prioritized list of requirements.
Business Data Structures (MC.010.2) The Business Data Structures defines the structure of the key business data elements.
Business Data Structure Setups (MC.020) The Business Data Structure Setups describe key business data structure setup values.
Gap Resolutions (MC.110) The Gap Resolutions describe how gaps will be addressed.
Back to Top
TECHNIQUES
Technique Comments
Nominal Group Use this technique to help drive group consensus and decision making.
Back to Top
TEMPLATES AND TOOLS
MC-050_APPLICATION_SETUP.XLS MS EXCEL
MC-
050_APPLICATION_SETUP_DOCUMENT.DOC
MS WORD
Back to Top
The Application Setup Documents are used:
to compose profile options, application options, key and descriptive flexfields, and user-defined codes
to consolidate the setup parameters and codes of all applications for centralized maintenance as decided during business mapping
to capture and communicate the final application setup decisions for implementation in the Production Environment
Distribute the Application Setup Documents as follows:
to all team members
Back to Top
QUALITY CRITERIA
Do the Application Setup Documents address mandatory or optional setups?
Do the Application Setup Documents address common setups across applications?
Do they address key flexfields, descriptive flexfields, navigation to the screen, justification for selected options, maintenance consolidation (if any) and date of last
update?
Do they include the impact of any setup changes in the course of the implementation?
Back to Top
MC.060 - DOCUMENT FUNCTIONAL SECURITY
In this task, you gather role and function information and relate them to application security and responsibilities. As business requirements are established and mapped to
application features, you also begin to define the user security necessary to support the selected alternative in a controlled environment.
ACTIVITY
Back to Top
WORK PRODUCT
Functional Security Setup Information - The Functional Security Setup Information provides a list of role-based security specifications necessary to maintain good
controls and transaction access.
Back to Top
TASK STEPS
1 Identify user roles across all business functions
and organizations.
User Roles This component documents user information, such as role, title and department.
2 Identify security requirements for each user roles User Roles The User Roles is updated with security requirements.
3 Map user roles onto application security
structures.
System User
Roles
The System User Roles maps user roles to system information, such as business function,
transaction, group and audit level.
4 Define application module access for each system
user role.
System User
Roles
The System User Roles is updated with application module access.
5 Secure acceptance of the Functional Security
Setup Information.

Back to Top
APPROACH
The Functional Security Setup Informations primary objective is to develop a security structure that naturally supports business processes. The primary technique is to
map business process steps and their agents (owners) with the application-provided user roles/responsibilities and make adjustments to the roles/responsibilities as
required. It is important to achieve a good security structure so that application access naturally supports the flow of information in the workplace. This will also make
learning the application easier.
Back to Top
Business Analyst Provide knowledge and guidance regarding the clients existing business procedures, and system access requirements. 60
Application/Product
Specialist
implemented.
30
System Administrator Set up the administration of security and associated privileges. 10
Back to Top
PREREQUISITES
Prerequisite Usage
Future Process Model (RD.011) Use the Future Process Model to to understand the future state business processes including which roles are
responsible for which business activities/tasks.
Use Case Specification (RA.024.1) Refer to the Use Case Specifications to understand functional requirements for gaps or complex business functions.
Mapped Business Requirements (MC.030) The Mapped Business Requirements provide a detailed explanation of key decisions regarding application setups,
including security and responsibility information.
Audit and Control Requirements (RD.070) This component documents audit and control requirements that impact Security Profiles.
Back to Top
TEMPLATES AND TOOLS
MC-060_FUNCTIONAL_SECURITY_SETUP_INFORMATION.XLS MS EXCEL
Back to Top
The Functional Security Setup Information is used:
to identify roles grouped together by responsibility so that typical business functions, along with inquiries and reports, are accessible
Distribute the Functional Security Setup Information as follows:
to all Mapping and Configuration project team members
Back to Top
QUALITY CRITERIA
Are users assigned to roles that map to their job responsibilities for the new system?
Back to Top
MC.070 - PREPARE CONFIGURATION PROTOTYPE
ENVIRONMENT
In this task, you install the commercial off the shelf (COTS) applications and configure the environment according to the results of the A.ACT.SKSD Specify Key Structure
Definition, and B.ACT.SSC Specify Software Configuration activities. This includes the installation of the application software image, creation of user accounts and
establishing of appropriate user access. This task is used to establish a platform and software environment that supports the prototyping of standard configuration options
to satisfy client business requirements. If you are utilizing a hosted environment, or provisioned cloud environment, installation of the software may not be necessary.
ACTIVITY
Back to Top
WORK PRODUCT
Configuration Prototype Environment - The Configuration Prototype Environment is a working environment that includes the application(s) being prototyped, as well as
any other required components. It contains the minimum configuration required to support business process mapping and configuration verification. It should address the
following:
all application parameters to enable transactions
enough business data to demonstrate application features effectively
access to definition and setup screens for appropriate users
any links to nonstandard application or custom systems (if applicable)
reporting and data query tools available in the mapping environment to verify correct mapping
Back to Top
TASK STEPS
Component
Description
1 Review Architecture and Requirements Strategy (TA.020) to understand the strategy for deployment of the project environments in
general and the Prototype Environment in particular.

2 Install application software.
3 Configure the Prototype Environment.
4 Enter any data required for baseline configuration prototyping purposes.
Back to Top
APPROACH
The Configuration Prototype Environment is used to support all configuration familiarization and mapping activities.
Configure the Configuration Prototype Environment
Setup the Configuration Prototype Environment based on the latest application setups from the Application Setup Documents (MC.050). Before you begin prototyping in
the environment, you should:
1. Set up the applications.
2. Decide on the data to use.
3. Plan the volume of data.
4. Verify that all application parameters have been set up to enable transactions supported by the business flows within the scope of the engagement.
5. Verify that sufficient business data has been entered to demonstrate application features.
6. Provide access to definition and setup screens for appropriate users.
7. Make reporting, data query, and testing tools available in the prototyping environment to verify correct results against the expected results of the test scripts.
8. Record all changes and updates to the test environment in the Environment Setup Log to help you maintain the integrity of the objects that have been installed or
updated.
Back to Top
Business Analyst Provide knowledge and guidance regarding the clients existing business procedures, activities and functions. 35
Application/Product
Specialist
implemented.
30
Database Administrator Determine and set up the database schema structure, create and set up database. 25
System Administrator Prepare parts of the application environment. 10
Client Staff Member Ensure that physical resources are in place in time, and that proper software licenses are obtained. *
Back to Top
PREREQUISITES
Prerequisite Usage
Architecture Requirements and Strategy
(TA.020)
The Architecture Requirements and Strategy provides information on the scope, requirements and strategy for the
architecture work.
Future Process Model (RD.011.2) Use the Future Process Model to to understand the desired business flow for the business processes.
Use Case Model (RA.023) Use the Use Case Model to understand the functional requirements that are described via a use case and are not
subject to custom development.
Use Case Specifications (RA.024) Use the Use Case Specifications to understand the functional requirements that are described via a use case and are
not subject to custom development.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Configuration Prototype Environment is used to prototype the configuration during the Configuration Prototyping Workshop.
Back to Top
QUALITY CRITERIA
Back to Top
MC.080 - CONDUCT CONFIGURATION PROTOTYPE
WORKSHOP
In this task, you prepare a strategy and plan for conducting the Configuration Prototyping Workshop as well as conduct the workshop. The Configuration Prototyping
Workshop actually may consist of several workshops (for example, one for each COTS application, one for each business process, etc.) as well as multiple sessions for
each of those workshops.
Conduct the workshop(s) with the client organization to familiarize them with the COTS application(s) being implemented. Additionally, work with the organization to map
their business to the application and document any potential changes in business processes, setups, etc. needed to support the organizations requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Validated Configuration - The Validated Configuration is the result of conducting a series of workshops intended to demonstrate the standard functionality that has been
configured according to client requirements as reflected in the Application Setup Documents (MC.050). It represents the set of setup decisions, vetted and validated with
client participation during the Configuration Prototyping Workshops that will be used as the baseline setup values for establishing various application environments for the
remainder of the project (for example, Development Environment, System Test Environment, etc.).
Back to Top
TASK STEPS
1 Review the Future Process Model (RD.011) and
any other available materials.

2 Obtain a list of the organization project team
members, their areas of responsibility and their
availability for workshop participation.

3 Prepare the Configuration Prototype
Workshop(s) Strategy and Plan Introduction.
Introduction
4 Organize the needed number of Configuration
Prototyping Workshops.
Organization The Organization component of the Configuration Workshop(s) Strategy and
Plan details the number of workshops planned, the area covered by each
workshop (for example, COTS application, business process, etc.), the number
of sessions planned for each workshop and lists the participating project
members and their areas of responsibility for each workshop.
5 Determine any workshop participant training
requirements.
Training Plan The Training Plan outlines any learning needs required by participants prior to
attending the workshop as well as the learning events planned to address those
needs.
6 Define the scope, objectives and schedule for
each workshop.
Workshop Definition The Workshop Definition defines the scope, objectives and schedule for each
Configuration Prototyping Workshop.
7 Review the Configuration Prototyping
Workshop(s) Strategy and Plan with the
organization.
The Reviewed Configuration Prototyping Workshop Strategy and Plan has been
reviewed and approved by the organization.
8 Conduct the various workshop sessions to
familiarize the organization with the COTS
application by executing the pre-defined System
Test Scenarios (TE.025.1) and recording the
results.
Updated System Test
Scenarios (TE.025.1)
The System Test Scenarios (TE.025.1) are updated with the results from the
workshop sessions.
9 Document any issues that are raised and/or
comments made by the organization indicating
that a change is needed to support the
MoSCoW List (RD.045) The MoSCoW List (RD.045) is updated with proposed changes identified during
the workshop sessions.
#TOP #TOP
organizations business requirements.
10 Conduct review of Updated System Test
Scenarios with the documented results to clarify
and elaborate on results.
Updated System Test
Scenarios (TE.025.1)
The System Test Scenarios (TE.025.1) are updated with any additional
information to clarify or elaborate on the results.
11 Make any necessary changes to Business
Process Models, and/or use cases.
Updated Future Process
Model (RD.011)
Updated Use Case Model
(RA.023)
Business Process Models and/or use cases are updated to reflect in-scope
changes that are agreed to during the workshop sessions.
12 Make any necessary changes to the Application
Setup Documents (MC.050).
Updated Application Setup
Documents (MC.050)
The Application Setup Documents define and document the detailed setup
values needed to configure the applications in accordance with the
organizations requirements. They are updated to reflect changes that are
agreed to during the workshop sessions.
Back to Top
APPROACH
Proper preparation and planning for the Configuration Prototyping Workshop is essential in order to achieve the following objectives:
Familiarize the organization with the application(s) being implemented.
Map the application to the organizations business and identify potential changes.
The overall goal should be to demonstrate how the business can be run using the standard configuration (or business flows) and conduct an initial mapping of the
standard configuration to the organizations business.
The Configuration Prototyping Workshop provides examples of what is possible within the application. Leading practices are reflected in pre-defined configurations
(business flows) that contain the following:
solution sets, representing leading practices
process models, representing best use of the COTS applications for a complete range of processes for the majority of organizations
Using the models of leading practice and experience as a guide, the organization determines the processes and practices most appropriate to the goals in implementing
new applications.
In almost all cases, a workshop format is appropriate for this task. This allows process and other experts from the business to work with the product/application specialist
and business analysts to determine which leading practices are relevant and appropriate to the business and its implementation of the application.
Organize the Configuration Prototyping Workshop
The Configuration Prototyping Workshop Strategy and Plan starts with the determining the actual number/type of workshops required. This required number of workshops
can be based on several factors (for example, the number of business processes, such as, Order to Cash, Procure to Pay, etc. being implemented or the number of
COTS applications being implemented). Once you determine how many workshop groups, you can estimate the number of sessions for each workshop as well as the
appropriate workshop participants. Consider the participants for each workshop as a team for the related workshop.
Each workshop team should consist of at least one product specialist (or process owner) from the implementing organization acting as a facilitator, who is empowered to
make decisions regarding the product or business process area being addressed by the team, and one or more key users from the organization with experience
in/knowledge of that business process area.
Division of responsibilities between the implementer and client members of a workshop team are as follows:
Implementer Provide COTS application knowledge/expertise, update documentation, plan and facilitate workshop sessions.
Organization Members Provide knowledge/expertise on client business processes and requirements, and timely decisions on questions related to the
implementation.
Determine Training Requirements
Determine if any training is required for the workshop team(s) prior to the commencement of the session(s) and schedule it accordingly.
Plan and Schedule Workshop(s)
Once the various workshop groupings have been identified and the workshop team(s) established, the next step is to determine the number of sessions to schedule for
each workshop group. If you have organized your workshop groups by Business Process areas that consist of one or more related business processes, these processes
may be grouped logically into batches, which can be defined, tested and refined together. Each of the Business Process batches normally requires a minimum of one
workshop session, or in some cases more than one workshop session, in order to accomplish the objectives of the overall Configuration Prototyping Workshop. The
number of Business Process batch sessions identified for each Business Process workshop depends to a great extent on the processes in question, as well as other
factors such as the integration with other business processes being implemented, and the number of implementer product specialists and organization resources
available.
If you have organized your workshop groups by COTS applications then you need to consider any dependencies between those applications. You also need to consider
if any of your resources will need to participate in multiple workshops across different COTS applications.
Once the number of sessions for each workshop grouping has been determined, the order in which the workshops are to be conducted must be established. Workshops
that are dependent upon input from other workshops must be scheduled in the appropriate sequence. Some workshops may be conducted in parallel, if the necessary
resources are available and they are not dependent on each other.
Define the scope and objectives of each workshop and its session in as much detail as possible, ensuring that all business process areas and requirements are
adequately covered. Prepare a schedule for each workshop session in the overall Configuration Prototyping Workshop task reflecting the appropriate sequence and
integration with other sessions, as appropriate. As a rough guideline, one workshop session typically requires three man days of effort:
one day for preparation
one day for the workshop
one day for post-workshop session activities
Schedule resources well in advance. Ideally, you should schedule resources several weeks in advance of the workshop session. Send an agenda, as well as any
materials the participants will need for preparations at least three days prior to the commencement of the workshop session.
Configuration Prototyping Workshop Preparation Tips
Allow sufficient time for preparations prior to starting any workshop session. In addition to developing the Strategy and Plan, you should confirm that the Configuration
Prototype Environment is properly installed and configured to support the workshop activities, and verify that all necessary delivery assets (for example, Business
Process Models, scripts, etc.) have been properly updated, if necessary. In some cases, you may need to translate business processes and other documentation into the
local language.
Encourage organization personnel to make their own preparations prior to commencement of the workshop session. They may find it advantageous to attend related
training, review workshop session agendas and other documentation, and even conduct internal workshops to look at anticipated issues/questions and consider what
decisions might be most appropriate for the business.
Conduct the Configuration Prototyping Workshop
Conduct the Configuration Prototyping Workshop in accordance with the Configuration Prototyping Workshop Strategy and Plan. Workshop sessions may be scheduled
for a full day, or half day, depending on the availability of the associated team members.
Teams may work in parallel, so it is essential that appropriate ground rules are established and communicated to all participants to help ensure the smooth conduct of the
workshop sessions.
Employ the scope descriptions and workshop objectives included in the Configuration Prototyping Workshop Strategy and Plan to keep the workshops on track. Where
necessary, utilize timeboxing techniques to avoid exceeding the time allotted.
Assign a participant, other than the facilitator, to serve as a scribe to keep workshop minutes and document potential changes and related discussion during each
workshop session.
Execute the System Test Scenarios (TE.025.1) during the hands-on portion of the workshop sessions.
Allow sufficient time during each session to review the minutes with participants after the conclusion of the demonstration.
Review Workshop Results and Make Necessary Updates
Review the test scenario results and documented changes to clarify and elaborate on results.
Make any necessary changes to Business Process Models and/or Use Case Model.
Make any necessary changes to the Application Setup Documents (MC.050). The Application Setup Documents define and document the detailed setup values needed
to configure the applications in accordance with the organizations requirements.
Back to Top
Business Analyst 50
Application/Product
Specialist
30
System Architect 10
Client Staff Member *
Ambassador User *
Back to Top
PREREQUISITES
Prerequisite Usage
Skilled Project Team (TR.050) The Skilled Project Team represents the current team members who have a thorough knowledge of the project vision,
direction, strategies and their individual mandates.
Future Process Model (RD.011) Use the Future Process Model to to understand the desired business flow for the business processes.
System Test Scenarios (TE.025.1) The predefined System Test Scenarios are executed during the workshop sessions to illustrate the operation and
integration of business system flows within the (COTS) application system.
Application Setup Documents (MC.050.1) The Application Setup Documents define and document the detailed setup values needed to configure the applications
in accordance with the organizations requirements. Use this document to set up the configuration used during the
workshop sessions.
Configuration Prototype Environment
(MC.070)
The Configuration Prototype is demonstrated during the workshop on the Configuration Prototype Environment.
Back to Top
TEMPLATES AND TOOLS
MC-080_CPW_STRATEGY_AND_PLAN.DOC MS WORD
Back to Top
The Configuration Prototyping Workshop Strategy and Plan is used to plan and prepare for the various workshops. It should address the following:
Organization Identify the individual workshop groups, how they were determined and the teams and sessions for each group.
Workshop Training Plan
Workshop Definition (Scope, Objectives and Sessions and Schedule)
The Configuration Prototype Workshop Results consist of the following:
System Test Scenarios for the configuration (TE.025.1) annotated with the results from the workshop sessions. At the completion of the workshop(s), the
organization should have a working knowledge of how the COTS application(s) support their business. Additionally, an initial mapping of the organizations
business to the COTS application(s) should be completed, and any proposed changes identified.
MoSCoW List (RD.045) that documents the proposed changes identified during the workshop sessions.
Updated business flows and Future Process Models with any new and approved changes. It is important to only include updates that you know will be implemented
during the project. Any exceptions that have a MoSCoW designation of Should have, Could have and Wont have should not be included in the updated flows or
process models unless it has been determined they fall within the scope of the current implementation project.
Updated Application Setup Documents (MC.050) with any new and approved configuration data.
The Validated Configuration is used:
to familiarize the organization with the application(s) being implemented
to map the application to the organizations business and identify potential changes
to verify the application setups
to validate the System Test Scenarios (TE.025.1)
Back to Top
QUALITY CRITERIA
Back to Top
MC.090 - CONDUCT REPORTING FIT ANALYSIS
In this task you validate that the standard reports provided with the application functionality being implemented support the implementing organizations reporting
requirements. Use the Reporting Fit Analysis in conjunction with the Configuration Prototype Environment (MC.070) to analyze and map every reporting requirement to
both a future business process and standard application report.
Any variance between the business requirements identified in the execution of this task and the capability or features of the application system that are necessary to meet
that requirement (that is, gaps) should be captured in the Reporting Fit Analysis (MC.090) by annotation and additional textual reference, if necessary. Gaps identified
should also be entered in the MoSCoW List (RD.045) and used as input into subsequent tasks (for example, MC.100, Define and Estimate Application Extensions, etc.)
for further analysis.
For projects that involve the upgrade of Oracle products, this task is used to review documentation from the initial implementation that mapped reporting requirements to
the current release functionality. Update this documentation to reflect the new application release and reporting requirements. The new release may include new,
changed, or deleted reports. Enhanced query capability may reduce or eliminate the need for some reports. Determine the final disposition of every report requirement
and seek to minimize custom reports for the new release.
ACTIVITY
MC.090.1
A.ACT.PSUIA Perform Software Upgrade Impact Analysis (Software Upgrade view only)
MC.090.2
Back to Top
WORK PRODUCT
Reporting Fit Analysis - The Reporting Fit Analysis supports the analysis and mapping of report requirements to future business processes and standard application
reports. It contains the final disposition of every report requirement.
Back to Top
TASK STEPS
Component
Description
1 Review current reporting materials that may enhance the team's understanding of the current state reporting
environment.

2 Determine an approach for collecting reporting requirements.
3 Update the Reporting Fit Analysis with information from the current reporting materials. Reporting Fit
Analysis

4 Identify critical reporting issues and document them.
5
Map any previously unmapped report requirements to future business processes using the Configuration Prototype
Environment (MC.070).
Reporting Fit
Analysis

6 Review the reporting strategy to understand the capabilities of placing reporting systems and constraints on designs.
7 Decide on an approach for mapping report requirements and assign responsibilities.
8 Map report requirements to standard application reports. Reporting Fit
Analysis

9 Analyze reports for reduction. Reporting Fit
Analysis

10 Prioritize custom reports. Reporting Fit
Analysis

#TOP #TOP
11 Secure acceptance of the Reporting Fit Analysis.
Back to Top
APPROACH
The Reporting Fit Analysis documents the report mapping process. It is used as the primary repository for all information collected about a report requirement. It should
contain system and report name, business purpose, frequency, priority, user name and contact information.
Report Requirements Collection Approach and Techniques
Possible methods to determine report requirements include:
Review reports on the current system.
Determine future report requirements from the Future Process Model (RD.011).
Conduct a user survey.
You may use one or a combination of these methods.
REPORTS ON CURRENT SYSTEM
The quickest way to catalog current system reports may be to get a composite listing of all current reports from the information systems department. Analyze the reports
in terms of frequency, distribution, and content.
REPORT REQUIREMENTS FROM FUTURE PROCESS MODEL
Business processes contained within the Future Process Model (RD.011) may generate reports as outputs of the process. Each report generated will then link to a future
business process and show functional ownership as a result.
USER SURVEY
For large organizations where it may be difficult for the project team to determine all the critical report requirements, some form of a user survey may be necessary. If the
list produced after extracting requirements from the Future Process Model (RD.011) and researching system report files is not satisfactory, the team may need to survey
the users.
Requirements Mapping to Future Business Processes
Map any previously unmapped report requirements to a future business process (RD.011) and enter the process number in the future process number field of the
Reporting Fit Analysis. Most likely any unmapped report came from a report survey, or other gathering technique. If a report does not map to a future business process,
enter No Match.
Reporting Systems Leveraged from the Technical Architecture
You may be able to leverage use of special reporting systems to reduce the number of reports you need to design and build. Examples of such systems are:
business intelligence systems
data warehouses (operational or decision-support)
online analytical processing (OLAP) systems
ad hoc query systems
If the architecture work completed so far during the project has already identified the need for such systems, work with the system architect to understand how you may
make use of these systems to satisfy reporting needs.
Conversely, if you identify the need for a special reporting system to address common reporting requirements, you should provide the input to the architecture process.
Requirements Mapping to Standard Application Reports
To map successfully, business analysts must have a thorough understanding of the original report requirement and the standard application reports. Otherwise, you may
need to conduct a series of interviews between the user and the individual mapping the process. The following are some of the typical report mapping issues:
Flexfields Data captured in flexfields will not be part of a standard report; therefore, any report requirement using flexfield data will become a custom extension.
Sometimes you do not know whether data will be stored in a flexfield or another application field used by a standard report. In these cases, mark the report as a
match with a note to modify the report, if the data is stored in a flexfield.
Lack of training Users are often trained just before the implementation is complete. Unfortunately, mapping occurs much earlier in the project. If users are going
to do their own mapping they will need the following:
access to a prototype environment
training on future processes
training on how to run report
Even with training, it can be difficult for users to envision the final product because they may be too far removed from the implementation team. If there is not adequate
help from the team, their mapping will be inaccurate and their reports could be useless.
Suggestion: Set up an interview process where the user and the project team member (user liaison role) do the mapping together. The user liaison must invest enough
time before mapping to become familiar with all standard application reports that impact the area in question.
The organization may be such that major divisions within the organization have similar subfunctions. Purchasing might be an example. Each division or group may have a
purchasing function. If the organization of the project is by division or group, the purchasing role might have possible duplication across the project. The mapping of all
purchasing reports by one user liaison will save the time and energy of the rest of the team.
Reports Analysis for Report Reduction
Some form of reduction process must take place when there are more custom reports identified for development than:
are necessary to run the business
can be completed in the allocated time
are expected, potentially placing reporting development over budget
REDUCTION TECHNIQUES
The following are suggestions for reducing the number of report requirements. The process of analyzing and consolidating may continue until well after construction has
begun, so it is important to focus on your most critical reports first, in order to allow time for the analysis to conclude.
Eliminate reports with duplicate file names. Do not delete these requirements from the list, since they represent a valid user requirement that is necessary when
preparing status documents for the user, users department or management.
Analyze based on function. Resort the Reporting Fit Analysis by function. If several reports relate to the same function, you may be able to combine the
requirements from one report into another. This type of consolidation may dramatically reduce the number of requirements. The users and the team need to know
which reports are being consolidated and the name of the new report.
Warning: Track consolidations carefully, especially if they cross departmental boundaries. While initially all parties may agree the consolidation looks good, changes
requested by one group may not be appropriate for others. When this happens, you may need to create another new report and track it separately.
Custom Reports Prioritization
As you map reports to standard functionality, custom requirements may develop. Anything marked as a Build or Modify is a custom requirement. Sort the Reporting Fit
Analysis by Assessment and make sure all custom requirements have a priority. Print this list and distribute it to the team and users, and request that they make any
necessary changes to the priority. This will be an ongoing function. Priority is the basis for the drive for the entire development process and thus needs careful
management. Users should always sign off on the assigned priority to avoid conflicts at later stages.
Reporting Fit Analysis Distribution to Users for Approval
It is important to forward a copy of the documented reporting requirements to users for approval. The user community should confirm that the following are true:
All the reporting requirements documentation is forwarded to each group.
The information gathered about each requirement is correct.
All priorities have been assigned and are correct.
Back to Top
Business Analyst Validate that the standard reports and forms, provided with the functionality being implemented, support the implementing
organizations requirements.
45
System Architect Assist in validating that the standard reports and forms, provided with the functionality being implemented, support the
implementing organizations requirements.
25
Application/Product
Specialist
Assist in validating that the standard reports and forms, provided with the functionality being implemented, support the
implementing organizations requirements.
30
Ambassador User Provide information on the organizations reporting requirements. *
Back to Top
PREREQUISITES
Prerequisite Usage
System Context Diagram (RD.005) The System Context Diagram describes information sharing and information partitioning requirements across
organizations for the key business objects and business process information.
Configuration Prototype Environment
(MC.070)
The Configuration Prototype Environment is a prototype of the standard application functionality based on the results
of the Specify Software Configuration activity.
Reporting and Information Access Strategy
(TA.040)
Planned architecture for reporting systems will influence the type of reports that will be feasible and the magnitude of
the customization effort.
Mapped Business Requirements (MC.030) Mapped Business Requirements specify alternatives to business requirements. Frequently, the documented
alternatives will be a report.
Back to Top
TEMPLATES AND TOOLS
MC-090_REPORTING_FIT_ANALYSIS.XLS MS EXCEL
Back to Top
The Reporting Fit Analysis is used:
to record the appropriate mapping information based on the report mapping activities performed
Distribute the Reporting Fit Analysis as follows:
to all team members
Back to Top
QUALITY CRITERIA
Does the Reporting Fit Analysis include the disposition of every report requirement?
Back to Top
MC.100 - DEFINE AND ESTIMATE APPLICATION EXTENSIONS
In this task, when the approach to addressing a business issue, which was determined during Map Business Requirements (MC.030), requires custom component
development to extend the standard capabilities of a commercial-off-the-shelf (COTS) software product, you must consider the various alternatives to satisfy them and
estimate the effort required to complete them.
ACTIVITY
Back to Top
WORK PRODUCT
Application Extension Definition and Estimates - The Application Extension Definition and Estimates summarizes the business need that standard application features
cannot meet and proposes an alternative approach for satisfying the need that includes a combination of custom components, manual workarounds, and existing
application features. It also includes work estimates for designing, building, and testing the alternative approaches to satisfying gaps.
Typically, you create an Application Extension Definition and Estimates work product for each major business area or process plus one each for interfaces, reports, and
custom support systems. Management must then decide whether the benefits of the customization are worth the time and expense (now and during upgrades) to build
and maintain it.
Back to Top
TASK STEPS
1 Review detailed requirements.
2 Determine potential approaches to
addressing the business issue.

3 Review alternatives with analysts
and users.

4 Select preferred approach.

5 Review estimating guidelines.

6 Prepare an introduction for the
document.
Introduction This component summarizes the business requirements that are not addressed by the standard product
features with a recommended approach for satisfying each requirement.
7 Describe the custom components
required for the customization.
Solution
Section
This component specifies the name of the business issue you are addressing and a unique identifier for each
issue. Copy the Solution Section for each additional business issue.
8 Estimate the effort to design,
build, and test customizations.
Solution
Section -
Estimating
The estimating section is used to prepare an estimate of the number of person days required to implement the
approach and describes the modules and assigns complexity ratings.
9 Estimate the maximum number of
resources that could work
concurrently on each
development task.
Solution
Section -
Recommended
Staffing
In the last part of the Solution Section, recommended staffing levels are entered. The maximum reasonable
number of people who could work on each development phase simultaneously is entered as well. The project
manager uses this information to plan the custom extension development activities and schedule resources.
10 Summarize the custom extensions
to the standard product.
Master
Customization
Worksheet
This component maintains a high-level record of all custom extensions to the product.
11 Secure approval.
Back to Top
APPROACH
Approaches to Satisfying Business Issues
Gaps can be broadly classified as either information that the applications do not store, or functions they do not perform.
INFORMATION GAPS
Information gaps can be further broken down into missing business objects, missing entities, missing data elements, and missing relationships.
Business Objects
Examples of new business objects are service contracts, shipping containers, or material consignees. They may have a many-to-one, one-to- many, or many-to-many
relationship with existing business objects. These require new tables to hold the information and provide the proper association with other objects. A single business
object may be a collection of multiple entities (for example, a service contract may have a single header and multiple service items).
Business Entities
Business objects may consist of entities. For example, the sales order object consists of a sales order header entity and a sales order line entity. Each logical business
entity is usually implemented as a table in the database. If you have a set of information about an existing business object that can occur multiple times for each object,
you have identified a missing entity. An example of this is shipping rates associated with a shipping method. The application supports shipping methods, but you need to
store multiple rates for each method to support automated shipping method selection.
Data Elements
Data elements are attributes of a supported business entity such as customers or inventory items. Descriptive flexfields can usually satisfy this need.
Relationships
Missing relationships (such as associating a customer with preferred suppliers) are actually a class of missing data elements and a descriptive flexfield can usually satisfy
this need. However, if the relationship is many-to-many, the situation may require a new table to store the intersecting relationship.
Basic data modeling techniques are helpful to clarify the requirements. Keep in mind that new tables will require custom forms to enter the information. Descriptive
flexfields often lead to report customization requirements.
FUNCTIONALITY GAPS
Functionality gaps can vary in scope from missing business rules in a function that is supported, to missing functions or even missing systems.
Business Rules
If the gap is at the business rule level and business procedural changes cannot address the situation, determine whether an event triggers invocation of the rule. If so, an
alert or database trigger may suffice. If the required logic is part of a function that executes as a concurrent program, you may be able to create a new program that runs
before or after the existing program. You can combine standard and custom concurrent programs using report sets.
You can use views to dynamically transform the representation of data in standard tables so that standard application functions operate on the altered data to produce a
new result.
Functions
You can supplant missing functions with standalone forms, reports, or concurrent programs. You can integrate custom forms with standard forms using links.
Timing
You do not need to wait until all mapping is complete to begin defining and estimating custom extensions. You can begin writing parts of the application extension
alternatives as soon as you identify a gap and propose a custom approach. You will identify some gaps early while others may not surface until you begin testing
business procedures.
Estimating Guidelines
For each business requirement not fully satisfied by the standard applications, summarize the amount of effort you estimate it will take to build customizations that close
the functionality gaps.
IDENTIFY COMPONENTS
In order to accurately estimate the effort, you must first identify all of the custom elements, which can include any of the following:
new or modified forms
new or modified reports
new or modified programs (SQL*Plus, PL/SQL, Pro*C)
database triggers
user exits
SQL*Loader scripts
standard report submission parameters
alerts
new tables
descriptive flexfields
custom workflows
Some relatively simple requirements actually translate into several components to implement correctly.
ASSIGN COMPLEXITY
For each component, rank the complexity.
CALCULATE BASE ESTIMATES
Consult your Application Extension Strategy (DS.020) for the proper estimating parameters for your project. It should have a table listing raw design and build numbers for
each combination of type and complexity. Calculate the total effort in person days for design and build by multiplying the number of modules of each type by the base
estimates.
RECOMMENDED STAFFING LIMITS
For each development task, indicate the maximum number of resources that could reasonably work on the modules of the customization simultaneously. This is purely a
judgment call. If a single customization requires several forms and reports, you might be able to divide the design and development work between two or three resources
without losing efficiency.
Back to Top
Back to Top
System Architect 80
Business Analyst 20
Project Sponsor *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Data Source Gap Analysis
(RA.160)
The Business Data Source Gap Analysis provides a detailed mapping of legacy data elements to the target applications.
Integration Architecture Strategy
(TA.030)
The Integration Architecture Strategy identifies the interfaces needed to meet integration requirements.
Reporting Fit Analysis (MC.090) The Reporting Fit Analysis identifies new reports or report modifications needed to meet reporting requirements.
Application Extension Strategy (DS.020) The Application Extension Strategy provides guidance on the approach and extent of customization. This work product also
contains the project policy and processes for nominating and seeking approval to create an extension.
Mapped Business Requirements
(MC.030)
The Mapped Business Requirements describe the detailed requirements of business needs that standard functionality does
not satisfy.
Architecture Requirements and
Strategy (TA.020)
The Architecture Requirements and Strategy provides key requirements that underpin the design of the new information
systems architecture.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Application Extension Definition and Estimates is used:
to describe and estimate all modifications, extensions (Including interfaces) and configurable extensions
Distribute the Application Extension Definition and Estimates as follows:
to the project team
Back to Top
QUALITY CRITERIA
Does the document include descriptions of each business requirement?
Does each requirement detail the proposed approach for satisfying the business requirement?
Does it include the estimated effort to design, build, and test the proposed approach?
Does it include staffing recommendations
Back to Top
MC.110 - DEFINE GAP RESOLUTIONS
In this task, the alternative solutions for satisfying gaps are reviewed with the client and the best alternative is identified and documented based on the client's preference.
ACTIVITY
Back to Top
WORK PRODUCT
Gap Resolutions - The Gap Resolutions document the chosen alternative for satisfying each proposed custom extension.
Back to Top
TASK STEPS
Component
Description
1 Conduct a review of the Application Extension Definition and Estimates (MC.100) with client staff members/project
steering committee.

2 Obtain client's preferred alternative solution for each gap.
3 Document client's preferred alternatives. Gap Resolutions
4 Secure acceptance of the Gap Resolutions. Signed Acceptance
Certificate

Back to Top
APPROACH
Back to Top
Back to Top
Business Analyst 50
Application/Product Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for the product(s) being 25
Specialist implemented.
System Architect 25
Back to Top
PREREQUISITES
Prerequisite Usage
Application Extension Definition and Estimates (MC.100) This work product contains the various workarounds from which the gap resolution is chosen.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Gap Resolutions is used:
to represent an acknowledgement that all relevant parties have reviewed the materials produced and agree on the proposed gap resolutions.
Distribute the Gap Resolutions as follows:
to the project team
Back to Top
QUALITY CRITERIA
Does it include type and status of work product?
Are objectives stated clearly?
Are agreements expressed in terms of planned future actions or policy changes?
Does it include key decisions and assumptions?
Are exceptions or references to components requiring change included?
Does it address controls: signatures of approvers and initiators, dates, revisions, etc.
Does it address future direction?
Back to Top
[AN] ANALYSIS
The purpose of Analysis is to refine and structure the requirements into a conceptual object model, called the Analysis Model. Most simply put, the Analysis Model is the
collection of all of the analysis related artifacts, just as the Use Case Model documents the systems functional requirements.
The Analysis Model is intended to provide a more precise understanding of the requirements and provides details on the internals of the system, where the Use Case
Model looked at the system from the viewpoint of the actor or user. Further, the Analysis Model begins to describe the system using the language of the developers as
opposed to the requirements that are expressed requirements in the language of the user, or of the business.
Performing Analysis contributes to a sound and stable architecture and facilitates an in-depth understanding of the requirements. Many of the work products produced
during the Analysis process describe the dynamics of the system as opposed to the static structure. The Analysis Model is also considered the first cut of the Design
Model (see the Design process), since it contains the analysis classes that are further detailed during the Design process.
The recommended approach for completing Analysis is based on the Unified Software Development Process. The standard and recommended notation is to use the
UML. The task guidance associated with many of the core Analysis tasks is, therefore, UP and UML oriented. Wherever possible, however, we have tried to provide
suggestions for alternate approaches or notations that might be employed. For example, while the class diagram is the UML standard and is strongly recommended for
modeling data and operations an entity-relationship diagram (ERD) and a functional decomposition chart may be substituted for this purpose.
As part of the Develop High Level Software Architecture (RA.035) task, the system use cases that you have defined were placed into groupings called Iteration Groups.
These groupings are based on the importance and architectural-significance of the use cases. This may mean that only a portion of the use cases in a use case
packages will be analyzed during a given iteration of Elaboration or Construction. This is considered to be the recommended practice and helps to support the risk-
focused principle of OUM.
The main work product or output of the Analysis process is the Reviewed Analysis Model that includes a set of analysis classes (class diagrams) that realize the use
cases. The Analysis Model is comprised of all of the Analysis work products, resulting from the following Analysis tasks, as appropriate:
Analyze Data Analysis (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Define Service (AN.085)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
In addition, the Conceptual View (AN.040) is added to the Architecture Description (RD.130) that was initially developed in the Business Requirements Process and
updated in the Requirements Analysis (RA.035) process.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
The main goal of the Analysis Process is to detail the Analysis Model that will be used to implement the requirements.
A good starting point for the Analysis process is to review the High-Level Software Architecture Document portion of the Architecture Description (RD.130). This
document is continually modified as the project progresses. Review the High-Level Software Architecture Description, and the Domain Model (RD.065) to identify the
components and the interactions that can occur between these.
The primary objective in the Analysis process it to create the Analysis Model. This is accomplished by analyzing the current use cases to determine how each use case
should be realized. The result from the Develop Use Case Model (RA.023) and Develop Use Case Details (RA.024) together with the Analysis (AN.040) updated
Architecture Description (RD.130) are used as input into the Data Analysis (AN.050), Behavior Analysis (AN.060) and User Interface Analysis (AN.090). The use cases,
written in a language understandable for the customer, are analyzed to identify the analysis classes that are needed to perform each use case's flow of events. These are
written in the language of the developer. The purpose is to identify the internals of the use cases, and to remove inconsistencies and redundancies among the
requirements. This is an important step towards design and implementation. The analysis classes are organized in packages, and an initial outline of the significant entity
classes is created. The attributes, responsibilities and relationships between them are also identified.
As you progress in the use case realization, you analyze the classes you have identified. The focus of this analysis is still on the functional requirements. During this
analysis, add more detail such as attributes, associations, methods, roles, responsibilities, specializations and generalizations that will be necessary to support the
functional requirements. However, during this detailed analysis, you may not be concerned in defining the exact types of the attributes and method parameters. This
analysis still produces a higher-level definition of a design class. Also, during this task, you typically create the different class diagrams for the different types of classes;
the Entity, Boundary and Control Class Diagrams. For complex classes, normally those that participate in multiple use cases, you should also consider creating State
Transition Diagrams to clarify the stages, through which the class may pass during its life cycle.
Interaction diagrams are created to validate the functionality defined in the analysis classes. The interaction diagrams can be created for each scenario in the use cases
of the Use Case Model. The task begins with the selection of the interaction diagram. There are two interaction diagrams; the sequence diagram and the collaboration
diagram. During this whole process you should also attempt to identify commonalities between the use cases and their analysis classes. This is necessary to be able to
identify possible reusable components.
The final task in the Analysis process is to review the Analysis Model. A team consisting of system analysts, ambassador users, designers, architects, and testers reviews
it. The review of the Analysis Model is both technical and functional in nature. The system analysts, and ambassador users focus on determining whether the analysis is
in line with the actual requirements. Often, it is when the requirements are detailed, that discrepancies in the understanding of the requirements become visible. However,
as the Analysis Model is written in the language of the developer, the ambassador users may need assistance in understanding the model. The other reviewers will
review both the technical and functional parts of the Analysis Model.
As a result of the review, feedback is recorded as an input to the next iteration of the tasks. The feedback is prioritized following the MoSCoW principle, as there might
not be sufficient time and resources to include every change request. Also, there are many different types of changes. Attempt to handle all through MoSCoW, but
some changes may affect scope and should therefore be handled differently following a formal change control procedure.
The Analysis Process tasks are performed iteratively both in the Elaboration and the Construction phase, but the further in the project, the more details are added. The
iteration starts with the Analysis tasks, and continues with the Design tasks. At the end of each iteration in the Elaboration phase, the result is fed into a new Functional
Prototype (IM.010) that is reviewed by the ambassador users. The feedback from the validation of the Functional Prototype (RA.085) is prioritized and fed into the next
iteration of the process, or if it was the last iteration, into the Construction phase.
In the Construction phase, the iteration continues with Implementation tasks that ensures that components and database is created following the updated analysis and
design. Finally, the iteration continues with Testing tasks before the result goes into the next iteration until the last iteration has been performed.
Back to Top
Supplemental Guide to access all application implementation supplemental information. You can also go directly to the Analysis process supplemental guidance.
Back to Top
Elaboration Phase
Construction Phase
Back to Top
OBJECTIVES
The objectives of the Analysis process are:
Achieve a precise and detailed understanding of the requirements.
Get a structure of the requirements that can be used as an input to the shaping of the system. This is a precise specification of the requirements, described in the
developers language. In this way, the internal workings of the system are clarified and become more formal.
Structure the requirements in a way that facilitates understanding them and supports preparing, changing, and maintaining them.
Achieve a better understanding of the required design and implementation work. This is useful for the project manager to verify whether existing plans need to be
updated.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
APS Application / Product
Specialist
implemented.
BA Business Analyst Analyze the business rules. Analyze services. Lead facilitated sessions and develop resulting storyboards. Prepare Analysis
Specification.
DES Designer The designer defines and maintains the responsibilities, attributes, relationships and special requirements of the classes making sure
that each class fulfills its requirements. This person is also responsible for the analysis of packages within which the classes are
maintained. There may be several designers depending on the size of the project, each of which may be responsible for certain classes
and packages assigned to them.
DV Developer Review the Behavior Analysis in order to assure that they are compatible with the architecture. This person is also responsible for
analyzing the more complex packages and classes. Review Analysis Model. Present the Analysis Model for review.
QM Quality Manager Review Analysis Model.
SAN System Analyst Assist the team of designers to create and finalize the Data Analysis, verifying if the business goals and requirements have been
captured. Review Analysis Model.
SA System Architect Lead the development of the updated Architecture Description. Participate in definition and review of the Architecture Description.
Develop the Data Analysis and participate in the definition and review of the analysis classes to gain an understanding of the application
and its architecture. Participate in definition and review of the Behavior Analysis to gain an understanding of the application and its
architecture. Analyze services. Review Analysis Model.
Client (User)
KEY Ambassador User Verify that the detailing of the requirements are in line with the higher level requirements, that business and system objects are taken
into consideration, and that priorities are respected. Review Analysis Model.
Back to Top
A Good Understanding of the Business Requirements: During this process, the business requirements are further detailed and analyzed. To prevent going
down the wrong path, it is important to have a good understanding of the business requirements that should be realized. The earlier a misunderstanding is
discovered, the better. Try to verify flows and details that are relevant for the requirements and not too system specific, before going into too much detail. Details
are of importance to the users when the details direct how the business should be performed. The details below that, are system specific, and are only interesting
for those that should implement the system.
Priorities Determined Based on Business Objectives: When the project moves forward, and new or changed requirements are disclosed, they must be
prioritized. It is easy to lose focus on what is really important, as there might be a lot of detailed requirements that need an immediate priority. It is a good practice
to include, as part of the prioritizing exercise, a point to show which objective(s) the requirements support.
Easy to Use Tracking System: Changes, and detailing of requirements, issues, and points of attention must be tracked in some way to prevent being forgotten. If
the tracking system is complex and difficult to use, users and developers tend to delay recording the issue, and it may therefore be forgotten. Also, they tend to
group a number of issues in one record, which makes it more difficult to perform a separate follow up for each separate issue. A good easy-to-use tracking system
with clear routines on how it should be used, ensures that issues do not get lost, and can be handled in the right meetings at the right time.
Good Communication Between Developers, Between Users and Between Developers and Users : Obviously, while analyzing and detailing the requirements,
it is important that all stakeholders have a good communication with each other. Ensure that everyone that, in some way, may need to interact in the project knows
who is who and what their responsibilities are. In small projects, this should be an easy task, but on larger projects this might be more complicated as you simply
do not remember who everyone is and what they do. Make it easy to find any participant. For example, make a list of the participants, with pictures, their roles,
responsibilities and location available for everyone on the project.
Good Knowledge of Analysis and Modeling Techniques : Because a OUM project is focused on quick delivery, there is normally no time for training on the job.
If there are inexperienced OUM participants on the project, there should be at least one experienced practitioner (who is not on the critical path) coaching.
Back to Top
AN.035 - UPDATE EXISTING ANALYSIS SPECIFICATION
In this task, you review and update the clients existing analysis artifacts for custom extensions that have been approved for migration to the new release.
ACTIVITY
AN.035.1
AN.035.2
Back to Top
WORK PRODUCT
Updated Analysis Specification - The Updated Analysis Specification describes the functionality to be provided by a custom extension in business and user terms. A
custom extension generally equates to a Use Case Package in OUM terms.
Users, business analysts, and designers are the audience for this artifact. Therefore, it must communicate all the functionality to be provided by the custom extension.
Back to Top
TASK STEPS
1 Locate any existing analysis artifacts that describe the business requirements and solution that is
addressed with the custom extension in the current software release.
Existing Analysis
Specification (Artifacts)
Examples of existing artifacts
include:
Functional Design
Documents
Business
Requirements
Documents
Use Case Models
Use Case
Specifications
Process Models
existing Analysis
Specification
(AN.100)
2 Update the existing artifacts to match the architecture and platform to which the custom extension is being
migrated.
Updated Analysis
Specification

Back to Top
APPROACH
The format of the Updated Analysis Specification largely depends on the existing artifacts from the current release of the software being upgraded. Examples of existing
artifacts could be, but are not limited to:
Functional Design Documents
Business Requirements Documents
Use Case Models
Use Case Specifications
Process Models
In addition, the format of the Updated Analysis Specification is dependent on the specific application architecture of the new software release.
In any event, the Updated Analysis Specification describes the functionality to be provided by the custom extension.
If existing analysis documentation is inadequate or non-existent, but the code is otherwise well-documented, you can use bottom-up analysis techniques to identify the
required coding changes and maintain a detailed log of update instructions. Use this information to construct a functional summary of the design implications for
functional reviewers.
Back to Top
Business Analyst Gather the information from the work products referenced by this task, and compile the composite Updated Analysis
Specification.
100
Ambassador User Validate that the existing analysis artifacts have been updated correctly and reflect the requirements expected to be satisfied
by the upgraded custom extensions.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Technical Architecture Impact Analysis
(TA.004)
Use the Technical Architecture Impact Analysis to gain an understanding of the Architectural Impact of the new software
release.
Software Release Changes Summary
(RD.134)
Use the Software Release Changes Summary to gain an overall understanding of all the changes being introduced by the
new software release.
Custom Extension Impact Analysis
(RD.136)
Use the Custom Extension Impact Analysis to gain an understanding of which specific custom objects will be impacted by
the upgrade.
Data Impact Analysis (RD.138) Use the Data Impact Analysis to gain an understanding of any data impacts of the new release.
Gap Resolutions (MC.110) The Gap Resolutions document the chosen alternative for satisfying each proposed custom extension.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Updated Analysis Specification is used in the following ways:
to validate that all requirements have been considered in analysis, and reviewed by the business users, prior to moving forward into design
Distribute the Updated Analysis Specification as follows:
to all the business users
to designers
to the development team
Back to Top
QUALITY CRITERIA
Are all of the custom extensions that have been approved for migration to the new release referenced in the Updated Analysis Specification?
Is there adequate detail about the behavior and the data that the custom extension will support?
Are all of the assumptions clearly documented and agreed to by the users?
Back to Top
AN.040 - DEVELOP ANALYSIS ARCHITECTURE DESCRIPTION
The purpose of this task is to update the systems Architecture Description (originally created with task RD.130) to add analysis level details that provide a high-level map
of how the system will meet the functional requirements.
This update will take the form of the Conceptual View that, in the context of an implementation project, has a number of purposes, among them:
Breaking down the complexity of the functionality so that implementers can analyze and design components that are relatively isolated from one another
Analyzing the functionality so that the required technical infrastructure can be identified
Assisting in the analysis of data, behavior, and service-level requirements so that the means of delivering them can be designed
Providing a basis for the specification of the physical computer systems on which the IT system will execute and the mapping of components onto these computer
systems
In OUM, the Conceptual View takes the form of the Use Case Model updated to show use case packages and their interactions. By definition, a use case package is a
collection of use cases, actors, relationships, diagrams, and other packages. Use case packages are used to structure the Use Case Model by dividing it into smaller
parts. Use case packages may be used recursively, meaning that top-level use case package may, themselves, contain use case packages. The choice for the depth of
this structure should be made based upon the size and complexity of the system being architected.
For example, a package diagram for a University Registration System may look like this:
However, there are many notations available to depict software architecture and there are no strict rules about what to include in this view. You should include whatever
additional information that you deem appropriate to assist in ensuring the view accomplishes its purpose. Architects are encouraged to take advantage of evolving
architectural standards and techniques that would enrich the contents of this view.
The Architecture Description work product is the collection point for all of the architectural views of the system. This artifact documents the systems architecture through
these architectural views and highlights the architecturally-significant aspects of the system by documenting the design and development priorities, as determined by an
iterative examination of the implementation risks. A well-formulated Architecture Description is one of the key elements of the Lifecycle Architecture Milestone that
concludes the Elaboration Phase.
In this task, details will be added to the Architecture Description to:
Develop the outline for analysis by creating use case packages
Define the functionality within each package
Define the interactions between the packages.
The Architecture Description also becomes an index for:
Analysis artifacts that are created for each of the Analysis Packages defined in the Package View of the Analysis Architecture Description.
Design artifacts that are created for each of the Design Components defined in the Component View of the Design Architecture Description.
#TOP #TOP
This task is typically utilized on larger projects, but also should be considered when:
on the extent to which the inclusion of a significant custom component (for example, Data Warehouse), large numbers of custom extensions or integration with multiple
COTS or third-party systems leveraging Fusion Middleware, requires a reassessment of the standard application architecture. When this sort of architecturally-significant
custom development impacts the standard application architecture, it is extremely important that this task be performed to guide the development and integration of
custom components.
extensions by promoting leading practice use of standard functionality. Therefore, this task is not included in the pre-defined Solution-Driven Application Implementation
ACTIVITY
AN.040.1
AN.040.2
Back to Top
WORK PRODUCT
these four tasks:
In this task, you add the Conceptual View to the Architecture Description work product. The Conceptual View further details the systems Architecture Description by
grouping the use cases into logical groupings called packages, describing each of the packages, and describing the interactions between the packages through a
sequence of flows.
Back to Top
TASK STEPS
1 Review and structure the
Use Case Model (RA.023).
None Review each use case and partition them into logical groupings keeping "like-functionality: use cases together.
2 Identify packages. Package
Diagram
Create packages for each logical grouping of use cases.
3 Describe each package. Package
Description
For each package, identify a name, brief description, contained use cases, actors, relationships and other dependent
packages.
4 Inspect each package. Package
Diagram
Review each package and identify opportunities for reducing redundancy and maximizing cohesion among the use
cases within the package. Also, look for problems with high coupling between use cases in other packages.
5 Develop package-level
sequence interactions.
Sequence
Diagram
Choose analysis scenarios and create sequence diagrams that show how the actors and packages interact in a
sequence of flows.
Back to Top
APPROACH
When analyzing the requirements of the system, to enable the system to be mostly appropriately designed and implemented, it is important to partition the work into
manageable pieces. If you are using a use case modeling approach, follow these steps to partition the system and describe the packages.
For more information regarding global analysis and architectural views and development approach, see Applied Software Architecture. For the purposes required by
OUM, you may use the Use Case Model, with use case packages, and a sequence diagram showing the connections between the packages to describe this view.
Review Structure and Use Case Model
The first step in structuring the Use Case Model is to understand the requirements that are common to more than one use case. Review each use case, taking notes of
any commonality.
Use these notes (creating included, extended, and generalized use cases) to minimize redundancy. The goal is to make the requirements more understandable and
easier to maintain, NOT to define a functional decomposition that is carried forward into the design.
Group use cases based on their functional similarities. For example, in an Order Management system, partition and group use cases that relate to Ordering, Shipping,
and Accounting processes separately.
Identify Packages
A model structured into smaller units is easier to understand. It is easier to show relationships among the model's main parts if you can express them in terms of
packages. A package is either the top-level package of the model, or stereotyped as a use case package. You can also let the customer decide how to structure the main
parts of the model.
If there are many use cases or actors, you can use use case packages to further structure the Use Case Model. A use case package contains a number of actors, use
cases, their relationships, and other packages; thus, you can have multiple levels of use case packages (packages within packages).
The top-level package contains all top-level use case packages, all top-level actors, and all top-level use cases.
Identify packages (by name only) for each group of use cases that share similar functionality. Draw the package diagram and show the dependencies between each
package.
Describe Each Package
Once the package diagram has been drawn, each package is described to sufficiently convey the role and purpose of the package. Here is the common section headings
used to describe a package:
Name The name of the package
Brief Description A brief description of the role and purpose of the
package
Use Cases The use cases directly contained in the package
Actors The actors directly contain in the package
Relationships The relationships directly contained in the package
Diagrams The diagrams directly contained in the package.
Use Case Packages The packages directly contained in the package.
Inspect Each Package
Each package is inspected to ensure it complies with good principles of functional separation. Even though these are analysis packages, they often become design
components in later steps, so it is important that they follow the rules of high cohesion (within the package) and low coupling (between the packages).
Here are some general guidelines when inspecting packages:
Does the package have a simple, descriptive name?
Does the package relate to a simple diagram?
Is there any redundancy internally or externally to the package?
Are the Use Cases within the package cohesive?
Are the architectural layers identified on the packages as stereotypes?
Do the packages avoid cyclic dependencies between packages?
Do the package dependencies reflect internal relationships?
Develop Package-Level Interactions
Another important architectural aspect of a system is the sequence of steps and the flow of control between actors and packages. One of the best approaches for defining
these interactions is with a sequence diagram. Scenarios are chosen based on business processes and a sequence diagram is drawn to graphically depict the
collaboration between the actors and the packages within the system. Here is an example of a sequence diagram which depicts the interaction between a student, a
professor, a financial administrator, a scheduler and the University Registration System:
Back to Top
System Architect Lead the development of the updated Architecture Description. Participate in definition and review of the Architecture
Description.
80
Developer Participate in definition and review of the Architecture Description. 20
Back to Top
PREREQUISITES
AN.040.1
Prerequisite Usage
Use Case Model
(RA.023)
The Use Case Model provides the graphical view of the use cases.
Use Case
Specification
(RA.024)
The Use Case Specification provides the detailed description of the use cases.
Architecture
Description
The current state of the Architecture Description (originially created during task RD.130) work product that includes the High-Level Software
Architecture (RA.035) and related materials is used as the starting point to create the Conceptual View.
AN.040.2
Prerequisite Usage
Architecture
Description
The current version of the Architecture Description work product that includes the initial Analysis Architecture Description and the latest updates to the
High-Level Software Architecture (RA.035) serves as input to the final version.
Back to Top
TEMPLATES AND TOOLS
Architecture
Description
MS WORD - Add the Conceptual View to the Architecture Description work product originally created in Develop Baseline Architecture
Description (RD.130).
Back to Top
Back to Top
QUALITY CRITERIA
Although underlying precision and consistency are important (and will be achieved through additional tasks), practicality and usability are paramount. The critical factor for
success is whether the resulting set of concepts, terms, and notations is small, simple, and accessible enough to be understood.
Back to Top
AN.050 - ANALYZE DATA
The purpose of this task is to identify and analyze the data elements required to support the functional requirements that have been documented in the use cases
contained in the use case package. You will describe how the data will be notionally organized, structured, and represented for the project. This task may be done in
parallel with Analyze Behavior (AN.060) and Analyze User Interface (AN.090) and is performed for every use case package documented in the Package Diagram in the
Architecture Description (RD.130).
To accomplish this task, you analyze the Use Case Specification (RA.024) for each use case in the package to understand the entities (classes), attributes, associations,
aggregations, multiplicity, and generalizations that will be required. Each data element may also be described in the Glossary (RD.042).
The standard and recommended approach and notation for completing this task is to use a UML class diagram. This task may also be accomplished using a non-UML
approach that uses other notational or textual techniques including entity-relationship diagrams (ERDs) or data tables. An example data table is included at the end of the
Approach section in this guideline.
If your project is using a UML approach, you should update the Domain Model (RD.065) with this additional information or create a UML class diagram if no Domain
Model is available. This class diagram will also be updated in Analyze Behavior (AN.060) task to include the required operations and other behavior information. This will
result in an Analysis Class Diagram for the Use Case Package.
ACTIVITY
AN.050.1
AN.050.2
Back to Top
WORK PRODUCT
Data Analysis - The resulting work product of the Data Analysis is an Analysis Class Diagram. This Analysis Class Diagram is also updated by the Behavior Analysis
(AN.060). The Data Analysis adds the entities (classes), attributes, associations, aggregation, multiplicity and generalizations required to support the Use Case Package.
To accomplish this you may update the Domain Model (RD.065) to capture the results of analyzing the data requirements of the Use Case Package. If no Domain Model
is available, develop a UML class diagram to support each Use Case Package.
If desired, the Data Analysis (AN.050), Behavior Analysis (AN.060), and Interface Analysis (AN.090) may be organized into an Analysis Specification (AN.100) for each
Use Case Package identified in the Package Diagram contained in the Architecture Description (RD.130).
You should also update the Glossary (RD.042) to define the majority of data elements.
Back to Top
TASK STEPS
1 Identify classes (or entities). Class
Diagram
Review each use case and search for the nouns that represent entities or classes. Verify they exist on the
Domain Model or add them if they are missing.
2 Identify attributes. Class
Diagram
Review each use case and search for the nouns that my represent attributes which belong to the classes on
the Domain Model.
3 Identify associations and aggregation
relationships.
Class
Diagram
Review each use case and search for the verbs that could indicate associations on the Domain Model.
4 Identify multiplicity. Class
Diagram
Review each use case and search for business rules that indicate the multiplicity between entities (or classes)
and add them to the Domain Model.
5 Identify association classes. Class
Diagram
Identify association classes that will better define the relationships between domain classes.
6 Simplify the model using
generalization.
Class
Diagram
Look for opportunities to extract redundant attributes from similar entities (or classes) and combine them into a
superclass.
7 Update the Glossary (RD.042) Glossary The Glossary is updated to reflect any new terms identified in the Domain Model.
Back to Top
APPROACH
The goal of this task is to identify and verify that all entities, attributes, and their relationships are fully identified and placed on a Domain Model or in a Data Table.
Additionally, the Glossary (RD.042) is updated to reflect the definition of any new terms identified when analyzing this data. This process is iterative and can be
accomplished throughout the Inception and Elaboration phases of a project. The above seven (7) steps are explained below using an example from a University
Registration System.
Identify Classes (Entities)
While reviewing each use case underline the nouns that may correspond to a class on the Domain Model. Verify that these classes exist, or add them to the model. Make
certain the names of each class are written in singular format using the terminology of the business.
Identify Attributes
Review each of the use cases and identify the nouns that represent attributes and place them on the Domain Model in the appropriate classes. These attributes should
describe a data element (or field) of the class.
Identify Association and Aggregation Relationships
Review each of the use cases and identify the verbs that represent associations and/or aggregations between the Domain Classes and draw them on the diagram.
Indicate the name of the association on the line and show the direction of readability by using a directional arrow next to the verb.
Identify Multiplicity
Determine the correct multiplicity for each side of the association and draw it on the diagram.
Identify Association Classes
Determine which associations should contain an association class to help better define the relationships between the domain classes. Give this association class a name
that relates to the business terminology.
Simplify Model Using Generalization
Review the Domain Model and look for opportunities to extract redundant attributes from entity classes and move them into a superclass. Do not repeat the same
attributes on the subclasses.
Update the Glossary
Review the Glossary (RD.042) and add or update any term that needs clarification. The Glossary needs to reflect the definition of each term used on the Domain Model.
NOTE: It is not necessary to use the Domain Model to capture the data and their relationships for a project. If you are unfamiliar with the UML Class Diagram (shown
above) then data can be captured using a traditional data model (entity-relationship diagram ERD) or can be listed in a data table (below).
Entity Attribute Minimum Value Maximum Value Default Comments
Person
ID 00000 99999 0000
Name This is the first, middle and last name of the person.
Address This is the home address of the person.
Phone Number This is the primary contact number.
Email Address This is the primary email address.
Student
GPA 0.00 4.00 0.00
Major This is the University.
Professor
Credentials
Department
Course
ID A000000 Z999999
Name
Description
# Credits 1 4 3
Cost $0.00 $1000.00 0.00 This is the cost per credit for the course.
Back to Top
Back to Top
System Architect Develop the Data Analysis and participate in the definition and review of the analysis classes to
gain an understanding of the application and its architecture.
60
System Analyst Assist the team of designers to create and finalize the Data Analysis, verifying if the business
goals and requirements have been captured.
40
Back to Top
PREREQUISITES
AN.050.1
Prerequisite Usage
Architecture Description (RD.130.1) The Conceptual View (AN.040) of the Architecture Description defines the use case packages to be
analyzed.
Domain Model (RD.065) or Analysis Class Diagram or
Data Model
The Domain Model, Analysis Class Diagram or Data Model developed in earlier iterations of this task may
be used as input to the current iteration.
Use Case Model (RA.023.1) The Use Case Model provides a graphical view of the use cases and the actors that trigger/support them.
Use Case Specification (RA.024.1) The Use Case Specification provides all the use cases along with each their corresponding details and that
is what is analyzed in this task.
Future Process Model (RD.011.2) The Future Process Model may help to identify use cases and their flows.
AN.050.2
Prerequisite Usage
Architecture Description (RD.130.2) Updates to the Architecture Description (including updates made by RA.035 and AN.040) may impact the
use case package being analyzed and must be taken into account.
Use Case Specification (RA.024.2) The Use Case Specification provides all the use cases along with each their corresponding details and that
is what is analyzed in this task.
Data Design (DS.090.1) Development of the interaction diagram as part of the Data Design may impact the use case analysis, and
vice versa. Therefore these tasks are often done in parallel.
Reviewed Use Case Model (RA.180.2)
Back to Top
TEMPLATES AND TOOLS
ANALYSIS_MODEL.DOC MS WORD - Use this word template to start building the Analysis Model. You will complete it with the
Behavior Analysis in AN.060.
Tool Comments
Getting Started with UML Class Modeling JDeveloper
Use Case Details Viewlet JDeveloper
FROM BUSINESS PROCESS TO USE CASE WITH
ORACLE UNIFIED METHOD (OUM)
Example Comments
Class Model
Back to Top
The output from the Analyze Data task is used in the following ways:
to define and describe the data elements for each use case
as an input to the use case design
as an input into the logical data model
as a verification that a use case is properly understood
Distribute the output from this task as follows:
to the ambassador users by walking them through the Analysis Class Diagram, updated Domain Model, Data Model or data table
Back to Top
QUALITY CRITERIA
Are the class names singular and are they written in business terminology?
Does each class have attributes that define the data that describes the class?
Does each association have a name that describes the relationship between the classes?
Is there an association class for many-to-many relationships?
Does the Domain Model reflect generalized classes (super classes) that eliminate attribute redundancy?
Is each element on the Domain Model described in the Glossary?
Back to Top
AN.060 - ANALYZE BEHAVIOR
The purpose of this task is to determine the system behavior that is required to satisfy the functional requirements that have been documented in the use cases. This task
may be done in parallel with Analyze Data (AN.050) and Analyze User Interface (AN.090) and is performed for every use case package documented in the Package
Diagram in the Architecture Description (RD.130).
To accomplish this task, you review the Use Case Specification (RA.024) for each Use Case in the Package. Each step of each scenario is analyzed to determine what
the system must do to perform that behavior. Once those operations are identified, they are allocated to specific processes, modules, or classes within the use case
package.
For example, a step in a use case scenario states that:
The system displays the student's record to the user
Then during this task you might define the system operations to be:
1. Query the database using the students id
2. Calculate the students GPA using the GPA formula business rule
3. Format the students information for viewing
4. Display the students information on the screen
You would then allocate those operations to specific portions of the system for execution.
The standard and recommended approach and notation for completing this task is to use a UML class diagram and possibly a UML Sequence Diagram (Task Steps 1-7).
This task may also be accomplished using a Non-UML approach that uses other notational or textual techniques including entity-relationship diagrams (ERDs), functional
decomposition charts, or process mapping diagrams (Task Steps 1 3A).
If a UML class diagram is used for this task, the goal is to find and assign controller classes and boundary classes and add them to the entity classes found in the Domain
Model (RD.065) thus creating an Analysis Class Diagram. Operations derived from each use case are added to each class being developed. Also attributes and
associations will be updated or created and added to the Analysis Class Diagram. Depending on the non-functional requirements and your architecture you may need to
consider event dependencies, persistence, and object communication aspects that are independent of any specific design. Finally, the results of the updated analysis
class diagram will be reviewed for functional completeness.
In a commercial off-the-shelf (COTS) application implementation, this task is generally performed only when there is a need to gain further clarification of the data
required to support a Use Case Package. This typically applies to requirements that are to be satisfied through custom-built components, which extend the functionality of
the COTS system and/or integrate the COTS system with other information systems.
ACTIVITY
AN.060.1
AN.060.2
Back to Top
WORK PRODUCT
Behavior Analysis - The resulting work product of the Behavior Analysis is an Analysis Class Diagram. This Analysis Class Diagram is also updated by the Data Analysis
(AN.050). The Behavior Analysis adds the operations, additional attributes, associations, roles, responsibilities, specializations and generalizations required to support
the Use Case Package.
To accomplish this you may update the Domain Model (RD.065) to capture the results of analyzing the data requirements of the Use Case Package. If no Domain Model
is available, develop a UML class diagram to support each Use Case Package.
You might also produce some intermediate diagrams (such as sequence, activity, or state diagrams) that help develop the analysis class diagram and can also provide
insight into missing business rules and/or behavior.
If desired, the Data Analysis (AN.050), Behavior Analysis (AN.060), and Interface Analysis (AN.090) may be organized into an Analysis Specification (AN.100) for each
Use Case Package identified in the Package Diagram contained in the Architecture Description (RD.130).
Back to Top
TASK STEPS
If your project is using a UML approach you should follow steps 1 through 7, skipping step 3A. If your project is using a non-UML approach, you should follow steps 1, 2,
and 3A only.
1 Review functional requirements: Use Case
Model (RA.023), Use Case Specification
(RA.024), Domain Model (RD.065),
Supplemental Requirements (RD.055), and
Candidate Business Rules (RA.027).
None The Use Case Model forms the basis for visualizing the basic functionality of your
system from the actor's perspective. The Use Case Specification provides the
detailed description of the actor's interaction with the system. This diagram and the
specification is developed during Requirement Analysis and refined during Analysis.
The Domain Model is a class diagram showing the entities, their characteristics, and
relationships that are relevant to the problem being solved. The terminology in this
diagram is made up of the language of the user.
Some requirements may come in the form of a Supplemental Requirements
documenting detailed non-functional requirements in text. The Candidate Business
Rules also provides information that will be turned into behavior in the system. After
all some object or process must be responsible for seeing to it that each rule is
followed.
2
Systematize Use Case Descriptions.

Use Case Specification
(RA.024)
Activity Diagram
Sequence Diagram
State Diagram
If necessary the Use Case Specification gets updated with information about what the
system must do (not how to do it) in order to accomplish the scenarios within the use
case.
For complex use cases, it may be necessary to diagram the use case. If the scenario
flow is very sequential then use a Sequence Diagram. If the use case has a number of
alternatives and error flows consider use an Activity Diagram or Flow Chart. If the
use case scenarios are very complex with many intertwined paths consider using a
State Diagram.
3 Find Analysis Classes or entities.
(UML Approach)
Sequence Diagram The Sequence Diagram contains a depiction of the relationship between boundary,
control, and entity classes, one for each major use case scenario.
The Analysis Model is an accumulation of all the classes showing attributes,
operations, and associations that will support the functionality described in the use
cases.
3A Define systems operations.
(Non-UML Approach)
For non-UML Approach,
you may se an ERD,
Functional
Decomposition Chart,
Process Mapping
Diagram
Define the systems operations and assign them to a specific process or module within
the package.
(Skip remaining tasks steps if you are using the non-UML Approach.)
4 Allocate behavior. None Review the Use Case Specifications to decide which classes should own the
behavior described in those specifications.
5 Update Analysis Classes. Analysis Class Diagram The Analysis Class Diagram is updated showing all the operations assigned to each
class.
6 Find analysis mechanisms. Use Case Realization
Diagram, Analysis Class
diagram, Package
Diagram
Annotate the classes in the Analysis Class Diagram with information that is design
independent related to persistence of objects, error handling, event notification, and
special message handling. Organize these classes into a Package Diagram as
groupings by use case and by domain.
7 Review for functional coverage. Analysis Class Diagram Perform a quality check on your Analysis Class Diagram to ensure that in aggregate
the classes have the operation behavior necessary to accomplish the functional
requirements as specified in the use cases.
Back to Top
APPROACH
Review Functional Requirements
During this first step you are gathering and reviewing all the material that has been generated to date that contains functional / behavioral requirements. The objective of
this task is to get a high level sense of what needs further analysis. During this task you should consider the following questions:
Which use cases are well written with lots of detail?
Which use cases are ambiguous, unclear, and have a lot of missing information?
Do the use case scenarios contain information about what the system is doing or purely about the interaction between the Actors and the system?
How much duplication of behavior exists across the use cases?
Are there similar pieces of scenarios repeated in two or more use cases?
Are there operations documented on any of the classes in the Domain Class Diagram?
Is it clear where the business rules tie in with the use cases?
Are some of the business rules specific to a single class?
Systematize Use Case Descriptions
Use cases are a great way of soliciting functional requirements from users. First and foremost they should reflect the interaction between the Actors and the system.
During analysis you need to augment the use case specification with information that describes what (not how) the system does to accomplish the actor's goals. This
often involves describing what the system is doing and when it is doing it to conform to some business rule.
For example, the use case may simply say, System uses the name and SSN to search for any previously entered profile information. This does not say what the system
needs to do in order to provide that information. More detail is needed here that describes what the system must do. The use case may be augmented to provide clarity.
For example:
When the system receives the SSN from the actor, the system first checks to see if it is a valid SSN associated with this student. The system requests
student admission information from the Admissions system using the SSN. If the SSN is not found in the Admissions system then the system tells the
student of the error and requests a corrected SSN from the student. If the SSN is valid, the system then checks that the name of the student that is logged
in is the same as the name of the student listed in the admission information. If the names do not match, this use case terminates in failure with an error
message to the student and a notification is sent to the registrars office. If the names match this use case proceeds to the next step.
The goal of improving the use case is to make clear exactly what the system needs to do and what data is needed at each step to fulfill the goals of the actor.
It is not recommended that you specify exacting details for every line of every scenario of every use case. Focus on areas of ambiguity found during step one's review.
Focus on areas in your use cases that are critical to the success of the project.
As has been often said, a picture is worth a thousand words. So a diagram can say a lot in a small amount of space. At this point you should consider augmenting your
use cases with sequence, activity or state diagrams.
Sequence Diagram: In those cases where the main success scenario has many steps with a few short alternatives consider using a sequence diagram. The sequence
diagram is good for representing a simple flow of sequenced interactions. When you represent a scenario as a UML sequence diagram, create a lifeline for each actor
and a lifeline to represent the system. The steps in the scenario become the messages in the sequence.
Activity Diagram: If you have a use case that is highly interactive it may be better to diagram it as a flow of behaviors in an activity diagram. Activity diagrams lend
themselves to exploring use cases that do not really have a main success scenario as much as they have many equal alternative successful scenarios. The following
diagram shows the Allocate Assets use case in a portfolio management system:
Another kind of activity diagram for use cases involves using swim lanes. The actors each have their own swim lane and the system gets its own swim lane. Then the
behavioral steps of the actors and the system are laid out as an activity diagram.
State Diagram: On some occasions it seems that every step in a use case potentially leads to every other step in the use case. These are highly dynamic use cases with
just a few steps but these few steps can be combined in many ways to form lots of alternatives. These use case often have many steps that loop back to earlier steps.
For this situation, use a state diagram.
Each interactive step of the use case becomes an event on the state diagram. The behavior that the system must perform is described as entry, do, and exit actions
within the states.
Find Analysis Classes (UML Approach)
Follow step 3 if you are using a UML approach on your project. Skip to 3A, is you are using a non-UML approach
During this step you will find those classes that will be necessary to accomplish or realize a given use case. This step is performed for each use case. Taken together all
the classes you find during this step will form the analysis model.
To find analysis classes, do the following for each use case:
1. Review your domain model for all classes that have the information needed by this use case.
2. Add those classes as entity classes on the analysis model.
3. Add a new class to the analysis model and mark it as a controller class. Give it a name like Asset Allocation Manager or Registration Session Manger. This
class will coordinate all the other classes to ensure that the use case scenarios are followed. At runtime an instance of the control class does not do things other
than to tell other objects what to do and when to do it.
4. For each place in a use case scenario where the system must communicate with an Actor, create a boundary class and add it to the analysis model. The boundary
classes are responsible for implementing user interfaces and back-end interfaces with other external systems.
5. Add relationships between the controller, boundary, and entity classes where there needs to be communication between them.
6. Build a sequence diagram showing the interactions among the controller, entity and boundary classes. These diagrams should follow from the text of your use case
scenarios or the diagrams you developed in step two above.
The following Analysis Model shows the classes found for a simple drop course scenario. The Course and Professor are entity classes from the Domain Model. The Drop
Course Manager is the controller class. The user interface or boundary classes are the Drop Session View, the Course View, and the Professor View.

The following sequence diagram shows simplified behavior from an analysis perspective for the main success scenario of the drop course use case. Do not try to perform
design at this stage.
Define Systems Operations (Non-UML Approach)
Assign each of the tasks documented or diagrammed in Step to to a specific process, module, or class within the package. This can be done using a variety of notations
including an entity-relationship diagram (ERD), functional decomposition, or even a simple process mapping diagram.
If you are using an alternate, non-UML approach you can skip the remaining steps in this tasks.
Allocate Behavior to Classes
At this stage, you consider which class should perform the behavior you outlined in step 2 & 3 when you systematized the use cases and found analysis classes. Those
diagrams you put together in that step will help as well. Review the sequence diagrams you put together when finding analysis classes. Any class on these diagrams that
is receiving a message should have the responsibility to receive that message. You can show this on the analysis class diagram as an operation on the class receiving
the message. Any class sending a message should have an operation definition in which the class has the responsibility for sending that message to an instance of the
other class.
Entity classes will contain behavior related to their attributes, such as business validation rules.
Control classes are assigned behavior that represents the major events of the use case scenario. They should embody the flow of control of the use case. For example,
when the user indicates to the system that they want to remove a strategic allocation in a financial portfolio, the control class would have an operation such as:
+ removeAllocation ( type : allocationType, asset : AssetAllocation)
Boundary classes should be assigned behavior that gets information from entity classes for display or to pass to another external system. They may also have behavior
for requesting information from a human actor or another system.
Update Analysis Classes
For entity classes, you should be able to determine many of the required attributes based on the attributes identified in the domain model. The entity classes are used to
model information that will be persistent.
The boundary or interface classes are used to model interaction between the application and its actors. Those classes that should interact with human actors need
attributes representing the items that the user either need to manipulate or see for information purpose. The boundary classes that are used by system actors will need
attributes required by the communication devices the actor uses.
A controller class as the name implies, is responsible for controlling class interactions inside a use case. There will only be a few attributes required for controller
classes. Many controller classes will not have any attributes, while others do need some attributes of a temporal nature, such as derived, summarized or accumulated
values.
The following is a partial Analysis Model. Notice the icons in the upper right hand corner of the class, they indicate the stereotype of the class controller, entity, or
boundary.

Identify additional associations
View the diagram to identify required associations between classes. The links that are shown on these diagrams may result in associations. Be aware that
you should only model those associations that are required for the use case realizations. You may also identify possible aggregations among objects. You
should also define the multiplicity of these additional associations.
Identify possible generalizations
Use the class diagrams to identify commonalities between various analysis classes. A generalization is often referred to as an "is a kind of" relationship. For
example, an analysis class "Vehicle" may be a generalization for a "Car" and a "Truck." A car "is a kind of" Vehicle, and a truck "is a kind of" Vehicle.
Identify special requirements
Determine for each class any special requirements that may apply. Use the special requirements identified in the Analyzed Use Cases as the input. This
would typically be non-functional requirements, such as volumes, and usage frequencies.
Find Analysis Mechanisms
There are a variety of mechanisms that an application will use at runtime. These include persistence, inter-process communication, error handling, event notification, and
messaging between objects. On any given project these mechanisms may already be decided upon when the architecture is chosen. However for many projects analysis
of persistence details are necessary.
Persistence relates preserving the life of an objects information beyond any given application runtime. Characteristics such as object size, number of instances, and
access frequency may be determined during behavior analysis. As an example consider the Student class. The attributes of each Student object will take up anywhere
between 5 and 20 Kbytes of space. Since there are 2,000 students in the university so there should be about 3,000 Student objects at any one time. During the
registration period, about 100 students will be created or deleted each day; there will be up to 500 updates to student records per hour; and there will be up to 1,000
reads of student per hour.
Be careful to specify mechanisms that are independent of the any specific design solution. The persistence information above is independent of whether we use a
relational database or flat file solution. It is independent of how we access the data using SQL or java persistence approach like Hibernate.
Review for Functional Coverage
During this last step you will review the analysis model to see if it has all the required functionality. The basic idea is to simply go back to the use case specifications and
the non-functional requirements to see if you can walk through the classes and accomplish the behavior of the use cases.
A walk through is best performed as a team. Someone reads the use case while another person or persons looks at the class diagrams. Is there a class that has behavior
assigned to it that can perform a step in a use case scenario? Do several classes come together to accomplish the required behavior?
Back to Top
Back to Top
Designer The designer defines and maintains the responsibilities, attributes, relationships and special
requirements of the classes making sure that each class fulfills its requirements. This person is also
responsible for the analysis of packages within which the classes are maintained. There may be
several designers depending on the size of the project, each of which may be responsible for certain
classes and packages assigned to them.
60
Developer Review the Behavior Analysis in order to assure that they are compatible with the architecture. This
person is also responsible for analyzing the more complex packages and classes.
20
System Architect Participate in definition and review of the Behavior Analysis to gain an understanding of the application
and its architecture.
20
Back to Top
PREREQUISITES
B.AN.060.1
Prerequisite Usage
Architecture Description (RD.130.1) The Conceptual View (AN.040) of the Architecture Description defines the use case packages to be analyzed.
Domain Model (RD.065) or Analysis Class
Diagram or Data Model
The Domain Model contains the significant business objects, represented as a UML class diagram, which provide
an important input to analyze classes.
Use Case Model (RA.023.1) The Use Case Model provides a graphical view of the use cases and the actors that trigger/support them.
Use Case Specification (RA.024.1) The Use Case Specification provides all the use cases along with each their corresponding details and that is
what is analyzed in this task.
C.AN.060.2
Prerequisite Usage
Architecture Description (RD.130.2) Updates to the Architecture Description (including updates made by RA.035 and AN.040) may impact the use
case package being analyzed and must be taken into account.
Use Case Specification (RA.024.2) The Use Case Specification provides all the use cases along with each their corresponding details and that is
what is analyzed in this task.
Data Design (DS.090.1) Development of the interaction diagram as part of the Data Design may impact the use case analysis, and vice
versa. Therefore these tasks are often done in parallel.
Reviewed Use Case Model (RA.180.2)
Back to Top
TEMPLATES AND TOOLS
ANALYSIS_MODEL.DOC MS WORD - Update the Analysis Model created in AN.050 with the Behavior Analysis details.
Tool Comments
Example Comments
Analysis Model-Activity Model
Analysis Model-Collaboration Model
Analysis Model-Sequence Model

Class Model
Back to Top
The output from the Analyze Behavior task is used in the following ways:
as an input to the use case design
as a verification that the use case realizations are properly understood
Distribute the output from this task as follows:
Back to Top
QUALITY CRITERIA
Does each class diagram represent one aspect of the system?
Does each class diagram only contain elements that are needed to understand that aspect of the system?
Are the class diagrams laid out so that they are easily read?
Does each analysis class contain a not to large and well-defined set of responsibilities (or, would it have been better to split into more and smaller classes)?
Do the analysis classes contain only analysis information, that is, there are no implementation aspects included?
Are the attributes for each class (if many) organized in a logical manner?
Are the responsibilities for each class (if many) organized in a logical manner?
For each step in the use case scenarios, can you find a combination of interacting objects whose classes have the responsibilities necessary for completing that
step in the scenario?
For each use case is there a class or combination of classes (usually control classes) that are responsible for controlling the flow of the scenarios of the use case?
Are there boundary classes for each major user interface needed by each use case?
Back to Top
AN.070 - ANALYZE BUSINESS RULES
During this task, you analyze each candidate business rule (RA.027) to determine the nature of the rule. First, perform a categorization of the rules, and then determine
which rules are volatile and which are fairly static. Next, document how each rule traces back to the initial requirement. Depending on how you do requirements analysis,
this could be through the appropriate use cases, business processes, domain model or directly to the functional or supplemental requirements. At this point, you also
verify the identified rules with the organization.
In a commercial off-the-shelf (COTS) application implementation, business rules may be realized through standard configuration options, or through custom-built
components, which extend the functionality of the COTS system. Perform this task only when there is a need to gain further clarification of the business rules represented
in the use cases. Business rules, which can be realized through standard configuration options, such as the selection of a Match Approval Level (i.e., 2, 3, or 4 way
matching) for invoices, may not require the additional analysis called for in this task. However, complex business rules, or those realized only through custom-built
component or a business rules engine, may require the additional analysis afforded by this task.
ACTIVITY
AN.070.1
AN.070.2
Back to Top
WORK PRODUCT
Business Rules Analysis - The Business Rules Analysis documents what kind of business rule categories are used to categorize the rules and how each rule has been
categorized. The analysis also includes traceability for each rule to the appropriate use, case, business process or supplemental requirement.
Back to Top
TASK STEPS
1 Determine rule category types. Rule Category
Types
The Rule Category Types is a list of all the rule categories with a name and a description explaining
the characteristics for the category.
2 Perform an initial categorization and
determine the volatility of the rules.
Categorized
Business Rules
The Categorized Business Rules contains a list of all the business rules within a category. This
includes an initial evaluation of the expected frequency of change for each rule.
3 Perform rule traceability and define rule
sets.
Business Rules
Traceability
Business Rule
Sets
The Business Rules Traceability shows how each business rule can be traced back to the original
requirement.
The Business Rules Sets lists all the business rules grouped into logically related related rule sets
or groups.
4 Quality check the list of business rules. Business Rules
Analysis
The Business Rules Analysis is comprised of all the previous components, quality checked and
ready for review.
5 Review business rules with project
stakeholders.
Business Rules
Analysis (updated)
The Business Rules Analysis is updated as a result of the stakeholder review.
Back to Top
APPROACH
Determine Rule Category Types
You should first determine how you should categorize the rules. Business rules can be categorized in many ways. Some examples are:
#TOP #TOP
Example 1
Structural - Structural rules are rules that define the static aspects of a business.
Behavioral - Behavioral rules are rules that are concerned with the execution of tasks in a business.
Managerial - Managerial rules are rules that an organization uses to adjust or correct performance.
Example 2
Data-Related Rules - Data-related rules are rules that restrict the state of the data at a stable point (invariants), must hold true before a particular change of the
data can take place (preconditions), or concern derivations.
Workflow/Process-Related Rules - Workflow/process-related rules are recognizable as decisions with guards in activity diagrams/business process diagram and
determine the flow.
Security Rules - Security rules restrict access to the resources a system offers to specific users or user groups. A distinction can be made between security rules
that define if a user (group) is authorized to execute a specific action (Are you authorized to start this use case?) or define (generic) restrictions on the use of data
(Are you authorized to view, insert, update, delete this data?).
Note that as this task is an analysis task and not a design task, this categorization abstracts from any implementation. Performing such a categorization should help to:
Improve the quality regarding completeness and consistency of the set of business rules.
Ease the communication with the user community.
Determine a strategy for business rule implementation.
The size and scope of the rule set and the background of the rules team dictates the nature of the rule categories that are used. If the team has a high involvement with
business analysts and users, then a more business oriented set of categories would be implied, such as Example 1 above. If the rules team consists of technical staff
with development experience, a classification similar to that of the Business Rules Group might be used. If the rules team consists of cross-functional line of business
users, then something similar to Example 2 might be used.
Perform an Initial Categorization and Determine the Volatility of the Rules
Perform a first categorization of all the business rules you have identified so far following the categories determine in the previous step. Some business rules are valid
during a specific point in time. For example, there might be business rules that the business wants to enforce, however, existing data might not comply with those rules.
For rules like this, the validity should be carefully considered. Or there might be a requirement to define rules that are related to some sales campaign, and therefore are
only valid during that campaign. If this is the case, then this is a strong indication that in the future the nature of existing rules might change, or even that new rules might
emerge. Another example would be (security) rules that restrict access to sales data during the quiet period of an enterprise before the results are published.
It also may be required that some business rules should be implemented in a flexible way, allowing to change one or more arguments used in a rule. For example, when
reviewing a business rule such as No employee may earn more than $10.000, it might already be obvious that you should not hard-code the amount in the business
rule, but anticipate on using some parameter mechanism instead.
During the review of the business rules, the time span during which the rules are valid should be considered. If there is any reason to expect a rule not to be valid
indefinitely, it should be noted. Discuss any requirement to be able to change the nature of business rules over time or to add new business rules in the future. In
addition, make notes where you expect that flexibility might be needed by using a parameter mechanism.
Business rules that are valid only during a limited period in time, for which the nature might change over time, or that require a parameter mechanism, are volatile rules.
Typically, this volatility is initiated by changes in the way the enterprise does its business or by changes in the environment in which the enterprise operates (such as
legal or regulatory changes).
Volatile rules are likely candidates to be implemented using a business rules engine such as Oracle Business Rules, while static business rules are often better
implemented in the code of an application. Therefore, in order to know where and how a business rule is best implemented, it is important to determine whether a rule
has a volatile nature, and if so, how volatile is it.
Perform Rule Traceability and Define Rules Sets
In the end all rules should be traceable to either a specific use case, a supplemental requirement, or one or more specific classes from the Analysis Class Diagram [which
is part of the Analysis Specification (AN.110)]. Rules that were originally discovered via requirements, policies, domain models, etc. should now be revisited to map to use
cases. Rules that are used by logically-related use cases can be grouped into rule sets (for example "High risk auto loan" rule set, "Credit scoring" rule set) to
assist/complement subsequent use case testing.
Quality Check the List of Business Rules
When you have completed a first list of business rules (which evolves over time), you should quality check the business rules. Ensure that each rule is described
consistently and in a consistent type of language. Business rules should be documented in a way that is understandable to the business reader, as owners of the
requirements need to be able to verify the rules.
Review Business Rules with Stakeholders
Project stakeholders should verify the business rules and initially indicate the criticality of each rule, whether or not it should be implemented and prioritize it, preferably
using the MoSCoW principle. Keep in mind that rules sometimes may prove to be too strict. For example, constraints may have been identified to exclude situations that
in principle are unwanted, but in practice may occur nevertheless and therefore must be dealt with. You could call it the exceptions to the rule. Therefore, you must ask
the organization whether they can think of any such exceptions. If there are, this may either lead to a decision that the rule will not be implemented, or that the exceptions
should be implemented as part of the rule itself.
Back to Top
Back to Top
Business Analyst Analyze the business rules. If possible, you may want use a business analyst with extensive business rules experience. 100
Back to Top
PREREQUISITES
AN.070.1
Prerequisite Usage
Analyzed Business Rules (ENV.IP.030) Use this Envision work product, if available.
Candidate Business Rules (RA.027.2) The Candidate Business Rules are being analyzed in this task.
AN.070.2
Prerequisite Usage
Candidate Business Rules (RA.027.3) Any new or revised Candidate Business Rules are being analyzed in this task.
Business Rules Analysis (AN.070.1) Update the Business Rules Analysis with new and refined business rules.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
suite.html
Rules Designer for capturing business rules and associating them with use cases.
Back to Top
The Business Rules Analysis is used in the following ways:
to understand which business rules are required to support the requirements supporting the Business Strategy
to provide enough understanding of the business rules, to be able to make a final decision for implementation
Distribute the Business Rules Analysis as follows:
to requirements stakeholders to review the analyzed business rules supporting the requirements
Back to Top
QUALITY CRITERIA
Has a set of business rules categories been described, including criteria on how business rules should be categorized?
Has each business rule been categorized following the set of business rules categories?
Is there a clear trace between all the business rules and originating requirements?
Have the business rules been reviewed by project stakeholders?
Back to Top
AN.080 - ANALYZE SERVICES
During this task you analyze all the candidate services listed in the Service Portfolio - Candidate Services (RA.025). Once this task is completed, the Service Portfolio is
updated to contain the list of service candidates that are required to support the project requirements. The service candidates are organized to indicate how to move
forward with each candidate.
For SOA services you will typically have a list with required new services, a list of change requests against existing services, and a list of reuse requests for existing
services proposed by the project.
For Cloud services, you may choose to organize the service candidates similarly if the Enterprise is the provider of Cloud SaaS services. In another Cloud scenarios
however, you may find another approach for organizing the services to be more suitable.
In addition, the proposed services are registered in the Enterprise Repository to allow other projects to discover the proposed changes.
It is a leading practice to have the proposed services from the project reviewed by service portfolio management and enterprise architecture. For each entry on any of the
lists in the Service Portfolio, define who should be given the responsibility of delivering each service. For most points, the delivery and reuse or consumption of services
will be the responsibility of the project. However, in the case of existing services that need revisions, the delivery will often need to be provided by the original creators, or
owners of that service (either internal or external if the provider is external to the Enterprise).
ACTIVITY
AN.080.1
AN.080.2
Back to Top
WORK PRODUCT
Service Portfolio - Proposed Services - The Proposed Services includes both the set of services the project proposes as new services to be created by the project team
and the set of existing services the project plans to consume.
When an Enterprise Repository has been established, the service portfolio is updated with the new services or service versions.
Back to Top
TASK STEPS
1 Perform
classification.
Classified
Service
Candidate
The Classified Service Candidates shows how the service candidates are classified against the classifications defined by Service
Portfolio Management.
2 Determine
evaluation and
weighting
criteria.
Evaluation
and
Weighting
Criteria
The Evaluation and Weighting Criteria explains the method and criteria against which each service candidate will be analyzed.
3 Evaluate
candidates.
Evaluated
Service
Candidates
The Evaluated Service Candidates list all the service candidates with their evaluation result and reasoning.
4 Determine
dependencies.
Service
Dependencies
The Service Dependencies describes existing service dependencies.
5 Assign
ownership.
Service
Candidate
Ownership
The Service Candidates Ownership documents the Identified owner for each service candidate.
6 Update the Service The updated Service Portfolio - Proposed Services is updated with the results of the analysis. When an Enterprise Repository is
#TOP #TOP
Service
Portfolio.
Portfolio -
Proposed
Services
being used, the Service Portfolio is part of the repository.
7 Perform service
traceability.
Service
Traceability
The Service Traceability shows the traceability from requirements (use cases, business processes, or supplemental
requirements) to the service(s) that should implement the requirements. Optionally, you can use the MoSCoW List-Excel
(RD.045) for traceabiilty of requirements when there is no Enterprise Repository.
8 Review results. Service
Assets
Review the results of your analysis.
Back to Top
APPROACH
Perform Classification
Here you perform a first categorization of all the new service candidates you have identified so far. Typically you will use some predefined categories that may have been
defined by the Service Portfolio Management process of the Enterprise. If no classification of categories have been defined earlier, then it will be your responsibility to
develop one that is appropriate for the situation.
During this exercise, you may discover new candidate services. If so, include these in the list of candidates, and document these in a similar way as defined by the
service portfolio management process and the enterprise repository. If a service cannot be classified against exactly one category, this typically shows a service
boundary violation. For each boundary violated, you should split the service to fit. As a result you may see a single candidate service become multiple candidate services,
each with a finer granularity than the original. In that case, check the repository again to avoid creation of a duplicate. In that case, check the repository again to not
create a duplicate. For SOA Services, refer to the SOA Service Boundary Analysis technique for more information.
For each new candidate service proposed for the project:
Select a category for the service from the Service Category List, based on the service goal and its capabilities;
If the service fits more than one category:
Find out the reasons for the multiplicity of categories.
Refactor the service to create fine-grained services and ensure that each new service is of a single category.
Aggregate fine-grained service to form coarse-grained services, where applicable.
Select category for each newly discovered service candidate.
Ensure that every new service created through refactoring is not a duplicate.
SOA Services Example:
In a time management project, the Time Management Service is a process service that manages the submission of invoices based on employee timesheet submitted for
projects.
The Time Management Service (service candidate) includes the following capabilities:
Get hours worked by project and client.
Verify timesheet.
Invoice customer for billable hours.
Update employee personal information.
Update employee hours worked on a project.
The service is classified as follows:
Data (entity) service it provides the capability to maintain employee information related to time keeping.
Business Process service it manages the process of submitting an invoice to a client.
Further analysis of the components of the service operations results in the refactoring the service into three services:
Employee Service this is an entity-type services that manages employee information.
Time Management Service this service manages time for employees and projects.
Invoice Service computes an invoice to be submitted to clients.
The Domain Model shown below is used to allocate responsibilities to each service based on the classes in the model.
Determine Evaluation and Weighting Criteria
Before starting the evaluation of the service candidates, you need to determine exactly what should be evaluated. For example for a SOA engagement, you typically
evaluate whether or not you want to develop or reuse a candidate. However, for a Cloud type of engagement you may evaluate whether a service candidate is
appropriate for the cloud, and if so whether it is best suited to be deployed in a private or public cloud. You will also need to determine the evaluation criteria, and what
weighting criteria you will use for of those evaluation criteria.
The evaluation criteria must be chosen so that you will be able to validate the benefits and evaluate the risks for either developing each new service, or for reusing or
consuming a known existing service (internally or externally).
If the service candidates are SOA service candidates, consider evaluating for the following types benefits:
benefit arising due to the planned scope of the service candidate, e.g., on what level will it be available, e.g., multi-enterprise, enterprise, intra-application (LOB),
inter-application
level of reusability of the service candidate, i.e., probability of additional consumers having an interest on the service candidate - A service may also be deemed to
be an intra-application service.
level of business agility created by the service candidate - that is, will a change in the business process be accommodated by the service model
level of enterprise compliance created by the service candidate
enablement to create the service candidate from already existing assets - can the service be created by composing other services, existing or planned
Also if the service candidates are SOA service candidates, consider the following risks factors:
availability of the skill set to create the functionality in sharable style
need and availability of additional tools or technology needed to create a sharable service
impact on all projects incurred by realizing a shared service
level of difficulty to realize all requirements as a shared service
ability to create a service that satisfies the service level agreement, such as response time under the projected demand scenarios
availability of runtime governance technology that monitors service execution and enforces service policies
availability of security control
See the SOA Service Identification and Discovery technique for more guidance in the justification criteria for SOA services.
On the other hand, if the service candidates are cloud service candidates, you may consider evaluating against a completely different set of criteria, such as the following:
What are the availability requirements?
What are the latency requirements?
Are there any government regulations to consider?
What are the security requirements?
and other similar questions
There are many organizations, including Oracle, that have defined candidate cloud selection tools. Refer to the Cloud Resources on the Supplemental Guidance page for
further information.
The whole purpose of the analysis is to maximize the business benefit ensuring that you best meet the requirements, and minimizing the risks for the organization.
Evaluate Candidates
For each new candidate, evaluate against all criteria as defined in the previous step that are relevant for the type of service candidate.
When you have evaluated a service candidate against the criteria, you should be able to determine the potential business value of moving forward with the candidate, and
how it fits the requirements. You should also be able to determine the potential risks, and whether the risks can be mitigated. For each service candidate, you should
summarize the potential business benefits, and the known risks, including potential risk mitigation strategies.
Reflect the results of the benefits and risks analysis and decide if the candidate can be abandoned. Abandoned candidates need to be further analyzed in application
scope to decide upon an implementation strategy.
VALIDATE SERVICE REUSE
For each service listed to be reused with or without revisions, or each service listed to be consumed from another supplier, follow the validation process to prove the
usability in the scope of the current project. Consider the following aspects:
prove that the requirements match (between the current project and the existing service), especially if the service needs to be updated for reuse. In the case that
updates are needed, how important are those requirements? Is it feasible to reuse even if updates are not granted?
verify that the reuse of a service is authorized in the scope and requirements of the current project.
determine if the capacity provided by the current services fits the new needs, or that capacity can be enhanced to the load expected from the current project
The SOA Service Identification and Discovery technique provides more guidance on the reuse validation process.
In the case of using an existing known service, contact the owner of the service (internal or external) that you are evaluating for reuse. Preferably, you work together with
the service originator to consider the new requirements and to decide whether the service can be reused, or if the requirements themselves need to change.
ANALYZE THE QUALITY OF SERVICE (QoS) REQUREMENTS
For each new service candidate, identify the QoS attributes that include:
expected response time by operation
scalability demand (requests per minute) at peak hours and average
trends demand forecast for the service and especially operations (functions) that are most critical
availability requirements
security provisions
For each existing service expected to be used:
Analyze the additional demand that the project will generate.
Capture service level requirements for the project. Use the information to discuss the new demand with the service owner.
Forecast the demand for a planning horizon such as 1-2 years.
Example:
The service candidate Time Recording Service is a new service, which exposes an existing COTS application. It is expected to increase the demand on the existing
legacy application. Analysis suggests the following non-functional requirements, derived from the use case descriptions, or the equivalent requirements document.
Response time
submit timesheet 1-3 seconds
get timesheet by employee 3-5 seconds
Demand
peak demand - 25,000 requests per minute, between 10am -11:30am
average demand 12,000 requests per minute
ANALYZE CHANGES TO EXISTING SERVICES
Identify existing services that the project requires to reuse and identify changes that will be needed for reuse.
Changes may include, among others:
additional operations
changes to the signature of existing operations Consider adding operations so that to minimize the impact on existing consumers.
logic changes Changes to the logic of one or more operations.
Investigate any dependencies for the service. For a SOA composite service candidate, what are the dependencies to other services? Do they exist and can they be
reused, or do they also need to be developed? For a cloud service candidate, what affinities exist to other components, and what level of affinity exist?
Assign Ownership
Each new service candidate should have an assigned owner. Typically, services should have a business owner. Check with the business sponsor for the project
ownership of new service candidates. Typically, the business sponsor will become the owner. But a different owner may be applicable as well, for example, if the service
provides access to a legacy system owned by a different line of business.
If the service candidate is provided by an external supplier, the external supplier is the owner, but you should also identify an internal owner, to ensure the required
sponsorship.
Typically, for services that need to be changed, the owner will not be changed.
Update the Service Portfolio
Depending on the governance approach chosen, you may need to document the results of your analysis. Specifically, if you want to be able to provide your results to the
business, or if you need to initiate a review of your results, a document summarizing the results can be very helpful.
Update the Service Portfolio you created in task RA.025. Add a new chapter Analysis Results document the results of the analysis, including potential new service
candidates, new service usage candidates or new service revision candidates.
When an Enterprise Repository is being used, the Service Portfolio should be considered to be an asset-type stored within the enterprise repository. The list of new
service candidates proposed should have an entry for each new service candidate added to the enterprise repository with status proposed (if not already done as part of
Envision work). Create all dependency links to models, requirements, etc. that apply.
For each service that needs to be changed for reuse, create a new version of the service asset already available in the Enterprise Repository. Update the links to the new
model versions and requirement versions.
For each service used in the project, regardless if that service is to be reused or is a new service, create a usage agreement asset in the enterprise repository in proposed
state and link it to the service asset. If already known, link to the consuming part as well, i.e., another service or an application. In the case where a new application is a
new consumer of the service, you might need to create a new asset for the application. Analyze the business requirements to understand the expected load the project
will create on the services. For that purpose, analyze the expected increase in volume the business expects over time including peak times on day, week and year.
Attach the information to the usage agreement and if already possible translate the business forecast into number of requests against the service.
Review the IT Asset Management technique for further details on the meta data descriptions for services and usage agreements.
If you use an enterprise repository, you may use a report generated from the repository to include the description of the service in the work product. In addition, you may
provide the protocol for the justification of the service.
You may also use the tool to create a list for the new service version when that is appropriate. Also, when relevant, you may provide a change requests needed for
existing services. For that purpose you can collect the changes resulting from the review of the project requirements, list those requirements to be addressed as a result
of the change request.
Before the list for proposed service usage, you should consider including the business forecast you have used to describe the load on each service. The list will need to
contain all services to which you have created a usage agreement and should provide a short description covering the scope of planned usage. You may copy this from
the Service Portfolio created in RA.025.
If the organization does not have a physical Enterprise Repository, and previous services have been captured in the Service Portfolio template (IP.014), use that same
Service Portfolio template (IP.014) to capture the Proposed Services in the same format. This will allow you to easily merge a candidate service into the Service Portfolio
at a later point, as appropriate.
Perform Service Traceability
All services should be traceable to specific textual requirements, high-level use cases, business processes, or supplemental requirements. Linking the services to those
requirements provides useful information for later, in particular for change impact analysis and test preparation.
During the task to identify candidate services (RA.015), you should already have documented the origin of the candidate (i.e., the source of discovery). Services that were
originally discovered via captured requirements, policies, domain models, etc. should be revisited to see whether they can be mapped to use cases or to a high-level
business process. If, so add the corresponding dependency to the Enterprise Repository.
Review the Results
If the governance process defines an external review of your results, you can use the Service Portfolio as handover to the reviewing team or person. In that case, the
reviewer will be responsible for changing each service candidate state from proposed, to validated or declined.
Otherwise, you should ask for an enterprise architect to support you on the review of your analysis. Change the state of the services to validated or declined according to
your results.
For all declined candidates, new versions or usage agreements for an alternative solution need to be identified possibly triggering another analysis cycle.
Back to Top
Back to Top
Business Analyst Analyze services. 50
System Architect Analyze services. If possible, you may want use a system architect with extensive SOA experience. 50
Back to Top
PREREQUISITES
AN.080.1
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
Service Portfolio -
Candidate Services
(RA.025.2)
The document provides the scope for the analysis and will be updated with the results
AN.080.2
Prerequisite Usage
Service Portfolio -
Proposed Services
(AN.080.1)
Update the Service Portfolio with new and refined services.
Governance
Implementation
(ENV.GV.100)
Back to Top
TECHNIQUES
Technique Comments
SOA Service Lifecycle Use this technique to understand the service lifecycle and the Enterprise Repository assets used.
Analysis
Use this technique to understand how to define services in the right level of granularity using boundary analysis.
SOA Service
Identification and
Discovery
Use this technique to understand the approach to discover, reuse and identify new service candidates with the help of models and
requirement documents. Includes a description of the justification process to analyze benefits and risks.
Back to Top
TEMPLATES AND TOOLS
Technique Comments
IP-
Service Portfolio template (IP.014), use the Service Portfolio template (IP.014) to capture the Proposed Services in the same format
as the Service Portfolio. This will allow you to easily merge a candidate service into the Service Portfolio at a later point, as
appropriate.
Tool Comments
Repository.
Back to Top
The Service Portfolio Proposed Services work product is used in the following ways:
to understand which services are proposed to best support the project requirements
to provide enough understanding of the proposed services, to be able to make a final decision for implementation
Distribute the Service Portfolio Proposed Services as follows:
to requirements stakeholders for review of the suggested services supporting the requirements
to (candidate) service owners for review
to enterprise architects for review
Back to Top
QUALITY CRITERIA
Have all service candidates been classified against the classifications defined by the Service Portfolio Management process of the enterprise (if present)?
Has the evaluation and weighting criteria for the analysis been clearly documented?
Has each service candidate been evaluated and weighted consistently against the same evaluation and weighting criteria?
Has each service candidate any dependencies been documented?
Has an owner been assigned to each service candidate?
Have the service candidates been included or updated within the Enterprise Repository?
Is there a clear trace from requirement to each service candidate?
Back to Top
AN.085 - DEFINE SERVICE
During this task, you define one particular service that culminates with the creation of a Service Contract for that service. In creating the Service Contract, you specify the
functional and supplemental requirements of the service. You also take into account any standard policies that may apply given the hosting environment, the scope, type
or layer of the service. While creating the Service Contract you also update the Service Contracts Portfolio in order to add the service and contract to the project's
portfolio. This task is executed for each service.
ACTIVITY
AN.085.1
AN.085.2
Back to Top
WORK PRODUCT
Service Definition - The Service Definition provides the concise definition of what function(s) the service performs, the operating constraints of the service (such as QoS
requirements), security requirements, as well as any service enablement requirements, such as SLA enforcement, exception handling, logging, etc. If the organization is
using physical Enterprise Repository, the Service Contract is represented as an asset within the repository.
If the organization does not have a physical Enterprise Repository, capture the Service Definition for each service in the Service Contract template and Project Contracts
Portfolio template.
The Service Contract defines the service. It provides the concise definition of what function(s) the service performs, the operating constraints of the service (such as QoS
requirements), security requirements, as well as any service enablement requirements, such as SLA enforcement, exception handling, logging, etc. If an Enterprise
Repository is not being used, the Service Definition for each service is made up of the individual Service Contract (Word template) and a corresponding row in the
Project Contracts Portfolio. The Project Contracts Portfolio is a spreadsheet listing the Service Contracts used by this project. You could also use the Service Portfolio
(IP.014) template.
If an Enterprise Repository is being used the Service Contract is added to the Enterprise Repository with a link to the Service, Project and other related assets, and a
reference to the actual document that describes the Service Contract would make using the Project Contracts Portfolio template unnecessary.
Back to Top
TASK STEPS
1 Provide a definition of the
service.
Service
Contract -
Definition
The Definition provides a detailed description of the service along with any supplemental requirements, including:
Header
Interactions
Description
Usage Terms
Usage Agreements
Release Terms
Quality of Service
Management and Logging
Deployment
Test Cases
2 Detail the functionality of the
service.
Service
Contract -
Functionality
The Functionality provides the operations for the service, including:
Operation Name
Request and Response messages
Any Operation Specific Usage Terms
3 Add the Service Contract to
the Contracts Portfolio,
including supplemental
requirements.
Project
Contracts
Portfolio
The Project Contracts Portfolio contains the Service Contracts supplemental requirements such as Quality of Service
attributes that lend themselves to spreadsheet form. Plus, it serves the purpose of providing one place to look for a
list of all Services/Contracts used by a project with each row corresponding to a different Service/Contract.
Ensure you have completed the row corresponding to this Service Contract and have provided values for all the
attributes.
Back to Top
APPROACH
In this task, you define a Service Contract for an identified Proposed Service (AN.080). You execute this task for each Proposed Service identified from the task, Analyze
Service (AN.080). You either update the Enterprise Repository for the Service Contract or complete the Service Contract template as well as add a row to the Project
Contracts Portfolio that contains a list of all service candidates to be used on the project.
Define Service Contract
The Service Contract describes the functions of the service as well as other supplemental requirements, such as, the service level agreement, security level, etc. The
primary purpose behind the contract is to provide a textual specification for the service that will facilitate reuse. Either enter the Service Contract information into the
Enterprise Repository or complete the Service Contract template. The Service Contract template is organized into two main components:
Definition This component provides a description of the service along with any supplemental requirements.
Functionality This component describes the behavioral aspects of the service.
For more details on what makes up a Service Contract, see the Create Service Contracts section of the Service Definition technique.
DEFINITION
Provide a definition of the service by providing all the Service Contract Meta Data Description information as defined in the IT Asset Management technique. This Service
Contract Meta Data Description information is only a recommendation. You should customize these to fit the specific needs of the enterprise. It is also possible that the
organization already has a defined Service Contract Meta Data Description. Keep in mind that over time the service may need to change, and with that one or more of the
artifacts that make up the definition of a service.
During this step, be sure to consider any standard service architecture policies developed by the enterprise for services of a given scope and service type/layer. For
example, the enterprise may prescribe policies around Quality of Service, Security and Logging for all services of a given scope and type. For more information on this
subject, see the Contract section of Determine Service Architecture Policies in the Service Architecture technique.
FUNCTIONALITY
Provide a list the operations to be provided by the service. For each operation, provide a high-level description and the input and outputs. Again, these descriptions should
be provided in business terms as they will be used by possible new consumers to determine whether this service will help solve their problem. The outputs should include
both successful responses and errors.
If there are Usage Terms that differ from those of the service as a whole (i.e., operation specific usage terms) be sure to describe those as well.
Create / Update Project Contracts Portfolio
If the organization does not have a physical Enterprise Repository, add a entry (i.e., a row) to the Project Contracts Portfolio for the Service Contract.
Back to Top
Back to Top
Business Analyst Define services. 50
System Architect Define services. If possible, you may want use a system architect with extensive SOA experience. 50
Back to Top
PREREQUISITES
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
Proposed Services
(AN.080)
The Proposed Services provides you with the list of services you need to define.
Back to Top
TECHNIQUES
Technique Comments
SOA Service Lifecycle Use this technique to understand where this task sits in the overall service lifecycle.
SOA Service Boundary Analysis Use this technique to understand how to use boundary analysis to define services to the right level of granularity.
Service Definition Use this technique to understand how to create contracts for services.
Service Architecture Use this technique to understand how to write a service contract.
Service Modeling Use this technique to understand how to model services.
IT Asset Management Use this technique to access information on the meta data descriptions for services definitions and service contracts.
Back to Top
TEMPLATES AND TOOLS
AN-085_SERVICE_CONTRACT.DOC MS WORD - If you are not using an Enterprise Repository, use this template to create a Service Contract for EACH
service.
AN-
085_PROJECT_CONTRACTS_PORTFOLIO.XLS
MS EXCEL - If you are not using an Enterprise Repository, use this template to create a summary report of ALL
contracts.
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Service Definition is used by possible new consumers to understand if they could use each service to solve their problem.
Distribute the Service Definition to the project architect and the SOA leadership.
Back to Top
QUALITY CRITERIA
Check the Service Definition against the Service Contract Meta Model Description in the IT Asset Management technique.
Back to Top
AN.090 - ANALYZE USER INTERFACE
The purpose of this task is to develop a deeper understanding of the look and feel of the user interface as well as the flow that the users will experience when interacting
with the system. In this task, you do not design how the user interface will work, but verify your understanding of the users needs and validate the feasibility of the
functional requirements. By adding visual elements of a user interface, tied to use case scenarios, you are also able to explore and understand the behavioral
requirements in a more meaningful way. This task may be done in parallel with Analyze Data (AN.050) and Analyze Behavior (AN.060) and is performed for every use
case package documented in the Package Diagram of the Conceptual View in the Architecture Description (RD.130).
In this task, the terms surface features and flows have been chosen specifically to help characterize this work. It is not the intent of Analysis to design the specific
screens and reports that will be required. The intent is simply to list and describe the user interface elements that are necessary to satisfy the functional requirements
documented in the use cases. It is likely that your understanding of the specific elements will begin to emerge and you will likely refer to these as forms, screens, reports,
flows, etc. but you should avoid specifying layouts or detailed navigation.
There is nothing that is specific to UML in this task. Therefore, the same techniques are employed regardless of the modeling approach that is being used on the other
Analysis tasks.
In a commercial off-the-shelf (COTS) application implementation, this task is generally performed only when there is a need to gain further clarification of user interface
elements that need to be developed to support a use case package. This typically applies to requirements that are to be satisfied through custom-built components,
which extend the functionality of the COTS system and/or integrate the COTS system with other information systems.
ACTIVITY
AN.090.1
AN.090.2
Back to Top
WORK PRODUCT
User Interface Analysis - The User Interface Analysis is comprised of wireframes and storyboards that depict a high-level representation of the users interaction with the
system.
A work product template is not provided for this task as the storyboards developed may take any number of forms both electronic or hard copy. The storyboards for a
given use case package should be organized together.
If desired, the Data Analysis (AN.050), Behavior Analysis (AN.060), and User Interface Analysis (AN.090) may be organized into an Analysis Specification (AN.100) for
each use case package identified in the Package Diagram of the Conceptual View contained in the Architecture Description (RD.130).
Back to Top
TASK STEPS
1 Use the Use Case
Specification to
define stories.
None Each scenario, especially the main success scenario, within a Use Case Specification provides the textual portion of a story.
2 Develop user
interface
elements.
Surface
Features
(Wireframes)
Flows
(Storyboards)
During facilitated sessions with users, each part of a story is augmented with visualizations that include capturing the user
interface surface features (wireframes), along with a diagram that illustrates the sequence of interactions between actors in the
story and the system to achieve the goal of the story (storyboard flow).
3 Update use case. (Updated)
Use Case
Specification
As the storyboard evolves, new requirements are often discovered. These must be captured in the appropriate use case
documentation.
Back to Top
APPROACH
Keep in mind, the purpose of analyzing user interfaces is to gain a deeper understanding of the flow of scenarios in a use case as well as information needed by the actor
during the use case. The flow and the information should all be in support of achieving the success post condition or goals of the use case and the actor. Do not worry
about exactly which interface widgets will appear on some screen or web page; that would be design. Do not worry about the details of web links, buttons for navigation,
or color schemes; that would be design. All the design issues will be handled during the design of the user interface not the analysis of the interface.
Define Stories
A story is comprised of characters (actors and the system) that interact to achieve some goal and the steps they go through along the way. The Use Case Specifications
should provide you with all the stories you need. Each use case has a goal, the success post condition that the actor and the system are trying to achieve. The scenarios
in a use case provide the steps along the way for achieving that goal.
Review each use case and develop stories from them using the following guidelines:
Simple use cases with a main success scenario and not much else become a single story.
Break up more complex use cases into a few stories.
Each story should have a clear goal to be achieved, a set of actors, and the system.
Each story should help the actors achieve something significant to them.
Well written use case descriptions are natural stories. If you are having trouble getting the use case as written to tell a story, consider revising the use case.
Develop User Interface Elements
For this step, you conduct facilitated sessions to explore each story and then document them as a set of user interface elements. For each session, choose just a few
stories and related use case(s). More complicated stories may require a dedicated session. The participants in the session should be representatives of the actors
involved in the use case(s). Ideally, they would be the individuals who will play the role of those actors when using the new system. Consider also inviting individuals who
will be impacted by what these actors can accomplish with the new system.
The most effective and efficient sessions involve stories that involve closely-related actors. If you have people in the facilitated session that do not relate to each other,
then you will get boredom.
During the facilitated session you will:
Present a story actor(s), goal, and steps to the goal
Go through each step of the story and ask about information necessary for that step. What information is being given by the actor to the system? What information
does the actor need from the system at this point in the story? What can the actor request of the system and what can the system request of the actor?
Arrange the information in some visual way (more on visualization techniques later)
Repeat for each of the steps in the story generating visualization for each step if necessary until you achieve the goal of the story.
Review the storyboard from beginning to end and get feedback from the participants as to how well the storyboard holds together. Update storyboards if necessary.
After the facilitated session, you should capture the resulting visualizations and relate them to the scenarios in the appropriate use case.
Visualizations come in many different forms. It is up to you to choose the form that will work best to elicit information given your projects unique characteristics and user
stakeholders. Visualization can be as simple as a paper sketch or as complex as a Visio diagram. The visualization typically has two aspects:
Surface Features
Flows
You might hear the term wireframe used as a visualization technique. A wireframe is a simple drawing showing the user surface features such as information and the
structural relationships between features. A wireframe does not have detail or internal substance. Where the user interface to support a use case may require more than
one wireframe, you can couple the wireframes with a diagram that illustrates the flow between wireframes.
Consider using one of the following techniques:
Place sticky notes on a whiteboard or wall to simulate one of the boards in your storyboard.
Use a drawing tool instead of a paper sketch.
Use a sequence of slides to show a storyboard
Use a web page simulation tool. Be careful with this one because the tendency is to start designing the details.
The following is a simple wireframe for a part of the storyboard related to the Sign up to Teach use case:
Update Use Case
The development of storyboards inevitably leads to new information about your use cases. You might uncover more scenario steps or whole new scenarios. If so, update
the Use Case Specification (RA.024).
Back to Top
Back to Top
Business Analyst Lead facilitated sessions and develop resulting storyboards. 100
User Participate in the facilitated sessions and critique the storyboards. *
Back to Top
PREREQUISITES
B.AN.090.1
Prerequisite Usage
Use Case Model
(RA.023)
(RA.024)
The Use Case Model and Use Case Specifications are analyzed to understand the user interface elements required to support the
functional requirements documented in the use cases.
Conceptual Prototype
(IM.005)
If available, this prototype may already include a definition of user interface surface features and flows that could be used as input to this
task.
C.AN.090.2
Prerequisite Usage
Architecture Description (RD.130.2) Updates to the Architecture Description may impact the user interface and must be taken into account.
Use Case Specifications (RA.024)
Updates to the Use Case Model and Use Case Specifications may impact the user interface and must be taken into account.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Back to Top
The User Interface Analysis is used in the following ways:
to understand and document user interaction and data requirements
as a starting point for the design of the user interface
to develop user interface prototypes
to develop tests of the user interface
to critique the users interaction and data requirements
Distribute the User Interface Analysis as follows:
to the development team; that is business analysts, (user interface) designers, testers and stakeholders
Back to Top
QUALITY CRITERIA
Is the storyboard readable and understandable by the user stakeholders?
Do the user stakeholders concur that the storyboard captures the behavior they require of the system?
Is the chosen storyboard visualization easy to change / manipulate?
Back to Top
AN.100 - PREPARE ANALYSIS SPECIFICATION
The purpose of this task is to assemble all the information that is required to describe a use case package into a complete Analysis Specification, ready for review. In
general, there would be one of these specifications written for each use case package on a project. Prior to being passed on to the designers, the Analysis Specification
is reviewed for defects and, as necessary, the defects are corrected.
It is very important to note that executing this task is not a substitute for executing the individual Analysis tasks, specifically:
AN.040 Develop Analysis Architecture Description
AN.050 Analyze Data
AN.060 Analyze Behavior
AN.070 Analyze Business Rules (optional)
AN.080 Analyze Services (optional)
AN.085 Define Service (optional)
AN.090 Analyze User Interface
However, this specification task and its work product can serve as a structure for completing analysis of each use case package by providing pointers back into these
Analysis tasks. Also, the Analysis Specification (AN.100) is not intended to specify individual software components or describe the design of those components. The
decomposition of each Analysis Package into the software components that will be required to implement the functionality defined in the use-case package will happen
during the Design process.
The High-Level Software Architecture (RA.035) included in the Architecture Description (RD.130) work product puts the system use cases into prioritized groupings called
Iteration Groups. The priorities are based on a number of factors including importance and risk which ultimately determine the level of architectural significance of
each use case. Higher priority Iteration Groups are, naturally, addressed in earlier iterations. Therefore, it may be that only a portion of the use cases in each use case
package will be analyzed during a given iteration. This is an appropriate and recommended practice that helps to support the Risk-Focused and Architecture-Centric
principles of OUM.
In a commercial off-the-shelf (COTS) application implementation, the Analysis Specification (AN.100) describes the overall functionality that must be provided by an
extension or customization, expressed as a package of one or more Use Cases. The Analysis Specification (AN.100) will also describe how the package will integrate
with the underlying commercial-off-theshelf (COTS) software and will include descriptions of the user interface elements, data, and system behavior from the users
perspective. The users must be able to understand the terms used to describe all business logic. Diagrams and examples can help clarify complex issues.
ACTIVITY
AN.100.1
AN.100.2
Back to Top
WORK PRODUCT
Analysis Specification - The Analysis Specification describes the functionality to be provided by a use case package (customization in case of COTS) in business and
user terms.
Users, business analysts, and designers are the audience for this artifact. Therefore, it must communicate all the functionality to be provided by the use case package in
non-technical terms.
Back to Top
TASK STEPS
1 Prepare the Overview by describing the
purpose of the use case package and
listing the use cases within the package
that is being described by this Analysis
Overview The Overview describes the package, and a list of the use cases and actors that make up the use
case package being analyzed. Use the package name as defined in the Conceptual View (AN.040)
of the Architecture Description (RD.130).
Specification.
2 Provide traceability back to specific
business objectives as documented in the
work product.
Business
Objectives
The Business Objectives highlight the objectives that relate to this package from the Business and
System Objectives (RD.001). If your project is using the MoSCoW List (RD.045) to provide
traceability back to the Business Objectives, you may also reference the MoSCoW List.
3 Provide a summary of the use case
descriptions for all use cases included in
the package.
Major Features Use the Use Case Model (RA.023) to list the use case name and the brief description. You may also
reference the location of the RA.023 work product rather than re-state the brief descriptions in this
work product.
4 Provide a definition of any unique terms
that may be required for the reviewer to
understand this Analysis Specification.
Definitions The Definitions specifically define any terms that the reader may require in order to understand the
Analysis Specification you are preparing for this package. You may also reference the project
Glossary (RD.042).
5 Define the User interaction with the
system interface, and all
othecollaboratingr actors (systems,
human, etc).
Scenarios Reference the locations of the individual Use Case Specifications (RA.024) for the Use Cases
included in this Package rather than re-state the details of the scenarios in this work product.
If needed for clarification, you should include an additional section that provides real-world
examples, with actual data.
6 Provide an inventory of the Business Rules
that are used by this package.
Business Rules Consolidate, define, and describe each business rule that corresponds to the use cases contained in
this package.
If a Business Rules Analysis (AN.070) has been completed for your project, you may reference that
artifact.
Otherwise, the Use Case Specification (RA.024) for each use case may also contain Business Rule
information in the Related Information section.
7 List any overall assumptions that may
impact the preparation of this Analysis
Specification as it moves into Design.
Assumptions Individual use cases already include lower-level assumptions for each use case within the package.
List only the overall assumptions at the package level.
8 Summarize the User Interface Descriptions
for the package that will be provided in the
subsections.
User Interface
Descriptions
Provide a simple summary of User Interface Descriptions to be provided in the subsections in steps
8a and 8b.
9 List and describe the user interface
Surface Features that are required to
support the package.
Surface Feature
Descriptions
(Form and
Report
Wireframes or a
UI Feature List)
Surface features Form/Report Wireframes or UI Feature Lists documented in the User Interface
Analysis (AN.090) may be referenced or reproduced here.
You may also include or reference applicable elements of the Conceptual Prototype (IM.005) work
product.
10 Describe the User Interface Flows that
apply to this package.
User Interface
Flow
Descriptions
(Storyboards)
User Interface Flow Descriptions (Storyboards) documented in the User Interface Analysis (AN.090)
and Conceptual Prototype (IM.005) may be referenced or reproduced here.
11 Capture all of the data attributes
associated with each of the use cases in
the package.
The standard and recommended
approach is to use a UML class diagram
to capture and express the data required
to support the package.
Data Analysis At this level data should include entities, attributes with their minimum, maximum and default values,
if they are mandatory or optional and comments. Also associations with roles,
specialization/generalization and aggregation is specified.
When the Data Analysis (AN.050) has been performed, you should include or refer to it for this
package.
UML Approach
If you are using a UML approach, you should include or reference the Analysis UML Class
Diagram created in Analyze Data (AN.050). This diagram will provide the data analysis information
about the Use Case Package. If this is the case, exclude the individual Data subsections from the
template.
Non-UML Approach
If you are not using UML, you may leave this section blank or include summary information. Then
you should use the individual Data Analysis section.
If none of this is available or if the data requirements are very simple, you may use the table
provided in the template.
12 Capture an analysis of the system behavior
that will be required to support the
package.
The standard and recommended
approach is to use a UML class diagram,
and/or any of the behavior or interaction
types of diagrams to capture and express
the behavior required to support the
package.
Behavior
Analysis
Behavior analysis can result in adding operations to data related classes, with additional attributes,
associations, roles, responsibilities, specializations/generalizations and aggregations. Behavior can
include operations, attributes, associations, roles, responsibilities, specializations and
generalizations for each use case. Typically, behavior analysis also adds strictly behavior related
classes.
When the Behavior Analysis (AN.060) has been performed, you should include or refer to it for this
package.
UML Approach
If you are using a UML approach, you should include or reference the Analysis UML Class Diagram
created or extended during Analyze Behavior (AN.060). The latter task may also have added
Analysis Activity Diagrams, Analysis Sequence Diagrams, or other types of behavior or interaction
diagrams. These diagrams will provide behavior analysis information about the Use Case Package.
If this is the case, delete the individual Behavior subsection from the template.
Non-UML Approach
If you are not using UML, you may leave this section blank or include summary information. Then
you should use the individual Behavior Analysis section. You may use a functional decomposition,
process mapping, or other acceptable notations to express this information.
13 Provide analysis of the interfaces
components, other packages, and/or
external systems from the point of view
of this package.
Interface
Analysis
Describe the high-level exchange of messages and information from this package to other use case
packages or external interfaces.
Refer to or include the applicable portions of the Package Diagram and Sequence Diagram from the
Architecture Description (RD.130). For simple use case packages, you may use the table provided in
the template.
Back to Top
APPROACH
The Analysis Specification collects the Analysis work products for a use case package into a single document. This equates roughly to the functional design document
that was used in some older methodologies.
The following illustrates the various tasks where work products might be incorporated into the Analysis Specification.
The approach to preparing this work product is to gather the information from the work products of the other OUM tasks you completed and compile them into this single
work product. Your project may not require that you have this full work product, as each individual task may have already produced the work product that was needed or
the individual artifacts produced by the related tasks may be held in an artifact repository. Completion of this consolidated work product is important if remote resources
will complete Design and Construction. This work product will be very important to describe and package the work for those who were not part of the onsite requirements
and analysis teams. This work product may also be used as a simple reference to all of the other work products associated with the given use case package.
Prepare Overview
Prepare an overview of the use case package being described by this Analysis Specification. First, describe the purpose of the package in terms of its overall
responsibility. Next, list the names of each use case within the package. You should review the results of the Analysis Architecture Description (AN.040) that are included
in the Architecture Description (RD.130) work product to ensure that you have provided the correct name and a brief overview of the use case package.
Map Use Cases to Business Objectives
Describe the Business Objectives that are satisfied by this use case package. Provide traceability back to the Business and System Objectives (RD.001) and to the
MoSCoW List (RD.045) by listing each business objective that is satisfied by the use cases in this package. It is important that the relationship between the business
objectives and the package is preserved, as the use case package will move into Design of components next.
Describe Major Features
Reference the Use Case Model (RA.023) in order to include the use case descriptions for each use case in the package. Be sure to include the most important features
and goals of this use case.
Define Terms
Reference the project Glossary (RA.042) and the OUM Glossary to describe any specific acronyms or words that may not be familiar to those who are going to access
the Analysis Specification. You may decide to repeat just those words in this section. In this way, everything that is needed to understand this use case package will be
included in the Analysis Specification.
Describe Scenarios
Reference the appropriate Use Case Specification (RA.024) for each use case within the use case package. In particular, focus should be placed on the Main, Alternate,
and Exception flow, that describe the interactions between the actor(s) and the system for this specific function.
Define Business Rules
The intent of this section is to consolidate, define, and describe each business rule that corresponds to the use cases contained in this use case package. Refer to the
Business Rules Analysis (AN.070) for the inventory of all business rules for the project. You may also refer to the Related Information section of the Use Case
Specification (RA.024), which may also contain business rules related to the individual use cases.
Assumptions
The intent of this section is to summarize the overall assumptions for the package. Since the individual use cases already include lower level assumptions for each use
case within the use case package, you should list only the overall assumptions at the package level, without repeating assumptions from the individual use case details.
List User Interface Descriptions
The intent of this section is to list and describe all of the user interface elements surface features (wireframes) and flows (storyboards) that are needed to satisfy the
requirements of the Use Case Package. You should provide a high-level description of each required item or a simple reference to wireframes and storyboards described
in the User Interface Analysis (AN.090). You may also include or reference applicable items from the Conceptual Prototype (IM.005).
In this task, the terms surface features and flows have been chosen specifically to help characterize this work. It is not the intent of Analysis to design the specific
screens and reports that will be required. The intent is simply to list and describe the user interface elements that will be necessary to satisfy the functional requirements
documented in the use cases. It is likely that your understanding of the specific elements will begin to emerge and you will likely refer to these as forms, screens, reports,
flows, etc. but you should avoid specifying layouts or detailed navigation.
Capture Data and Behavior Analysis
The intent of this section is to capture the data attributes and behavior associated with each of the use cases within this package.
You may reference the Analysis Class Diagram, which resulted from Data Analysis (AN.050) and Behavior Analysis (AN.060), if this was created. In this case, you may
delete the individual Data Analysis and Behavior Analysis sections of the Analysis Specification template.
If your project is small or you have not chosen to use a UML approach, you may choose to use another means of describing the data and behavior required for the
package. Again, it is preferable to refer to the Data Analysis (AN.050) and Behavior Analysis (AN.060) work products, if available. To populate the Analysis Specification
work product for smaller projects or simple use case packages, you may use a small data table to describe the data attributes and include a simple functional
decomposition or process mapping to describe the behavioral elements. A blank data table is provided in the Data Analysis section of the Analysis Specification template.
Interface Analysis
The intent of this section is to describe all external interfaces (components; other packages and/or external systems) from this use case package point of view. This
describes the high-level exchange of messages and information from the use case package to other use case packages or external interfaces. Refer to or include the
applicable portions of the Conceptual Diagram and Sequence Diagram from the Architecture Description (RD.130) work product. For simple use case packages, you may
use the table provided in the template.
Back to Top
Back to Top
Business Analyst Gather the information from the work products referenced by this task, and compile the composite work product.
For Applications Implementation projects, the application/product specialist would assume the role of the business analyst.
If an Analysis (or other) team leader has been designated, the effort would be allocated between the team leader and the
business analyst or application/product specialist.
100
Ambassador User Validate that the use case details have been carried forward and the business requirements are satisfied by the analysis
contents for each package.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Business and System
Objectives (RD.001)
Use the Business and System Objectives to provide traceability to the business objectives.
MoSCoW List (RD.045) Use the MoSCoW List to provide traceability to project requirements.
(RD.130)
Use the Architecture Description to understand which use cases are included in this package and to understand the high-level exchange of
messages between this use case package and other use case packages or external interfaces.
Use Case Model
(RA.023)
Use the Use Case Model to gather or reference the use case descriptions.
(RA.024)
Use the Use Case Specifications to understand the major features and scenarios of each use case in the package.
Data Analysis (AN.050) Use the Data Analysis or complete the Data Table in the Analysis Specification template to describe the data for each use case in the
package.
Behavior Analysis
(AN.060)
Use the Behavior Analysis to understand the system behavior that will be required to support the each use case in the package.
Business Rules Analysis
(AN.070)
Use the Business Rules Analysis to reference the catalog of business rules for the system and to determine which business rules may apply
to this use case package.
Service Portfolio
(AN.080)
Service Definition
(AN.085)
Include the information in these work products If your project involves service-oriented architecture.
User Interface Analysis
(AN.090)
Use the User Interface Analysis to understand the user interface surface features (wireframes) and flows (storyboards) required for each use
case in the package.
(IM.005)
Use the Conceptual Prototype to reference applicable user interface elements and prototypes that may be applicable to this use case
package.
Back to Top
TEMPLATES AND TOOLS
AN-100_ANALYSIS_SPECIFICATION.DOC MS Word
Example Comments
AN-100_SKINOW_ANALYSIS_SPECIFICATION.DOC Ski-NOW Case Study Recycled Packaging Rebate Processing Example
Back to Top
The Analysis Specification is used in the following ways:
to validate that all requirements have been considered in analysis, and reviewed by the business users, prior to moving forward into design
to validate that the Analysis Architecture is acceptable to the designers to design the components that will provide functionality described in the Analysis
Specification
Distribute the Analysis Specification as follows:
to the business users
to the designers
Back to Top
QUALITY CRITERIA
Are all of the use cases in the package referenced by the Analysis Specification?
Is there adequate detail about the behavior and the data that the use case package will support?
Back to Top
AN.110 - REVIEW ANALYSIS MODEL
The purpose of this task is to review the Analysis Model before these materials are passed to the design team. In OUM, the Analysis Model refers to the complete
collection of work products that are developed as part of analyzing the use cases during Analysis. Once work on these materials for a given iteration has been completed,
and the materials are ready for review, a team consisting of analysts, users, designers, and architects review the Analysis Model, and suggest changes as needed.
Formal and peer review activities should be used to review the Analysis Model. Any defects discovered in the elements of the Analysis Model are recorded. As
necessary, these defects may require attention and therefore, another review.
This task should be executed during each iteration in which Analysis work is completed. This typically means that the task will be executed in all iterations of Elaboration
and sometimes in early iterations of Construction.
ACTIVITY
AN.110.1
AN.110.2
Back to Top
WORK PRODUCT
Reviewed Analysis Model - The Reviewed Analysis Model contains the Analysis components updated as determined by the review, including the list of defects found in
the model during the review(s). The Analysis Model represents a collection of all Analysis work products, as available, resulting from the following tasks:
Back to Top
TASK STEPS
3 Prioritize changes Prioritized Defects The Prioritized Defects is the same list of defects, including priorities, indicating the importance of the changes.
Back to Top
APPROACH
When the analysis work has been completed for a given iteration, the materials should be assembled for review. A team consisting of analysts, users, designers, and
architects review the Analysis Model, and suggest changes as needed. There are a variety of approaches that can be used to accomplish this sort of review. Typically,
reviewers are given time to look through the materials in advance of a call for review comments. The review team may either be assembled in one place or review
comments submitted via electronic means.
#TOP #TOP
As a result of such a review, defects can be found and change requests can be triggered. There are many different types of changes. Some changes can affect scope
and these require change requests. Other changes do not affect scope, these should be handled through use of a MoSCoW List.
Different types of review can be used. However, OUM recommends the use of inspections to improve the quality of the Analysis work products (Analysis Model) and the
productivity of the inspectors.
Use the following to access task-specific custom BI supplemental guidance.
Back to Top
Back to Top
System Architect Review the Analysis Model to gain understanding of the application. Participate in the review meeting to verify if the final
Analysis Model is compatible with the architecture.
20
Developer Lead the walkthrough. Present the Analysis Model. 20
Quality Manager Review the Analysis Model from the point of view of the Testing process. Gain understanding of the internal structure of the
application.
20
Designer Participates in the review to verify is the final Analysis Model correctly realizes the use cases. You may want to use an object
designer to fill this role or in addition to this role.
20
Systems Analyst Participate in the review meeting in order to verify if the Analysis Model realizes the requirements. 20
Ambassador User Review the Analysis Model. *
Back to Top
PREREQUISITES
Prerequisite Usage
(RD.130)
The Use Case Priorities and Iteration Groups describe the expected contents of the Analysis Model during any given iteration. The
Conceptual View of the Architecture Description provides an index of use case packages to be analyzed as part of Analysis.
Analysis Model The Analysis Model is reviewed in this task and represents a collection of all of the Analysis work products, if available, resulting from the
following tasks:
Analyze Data (AN.050)
Analyze Business Rules (AN.070)
Develop Analysis Specification (AN.100)
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
[DS] DESIGN
In the Design process, the system is shaped and formed to meet all functional and supplemental requirements. This form is based on the architecture created and
stabilized during the Analysis process. Thus, the work products produced during Analysis are an important input into this process. Design is the focus during the end of
Elaboration phase and the beginning of Construction iterations. The major work products created in this process ultimately combine to form the Design Model that is used
during the Implementation process. The Design Model can be used to visualize the implementation of the system.
The main work product or output of this process is the Design Model. The Design Model represents a collection of all Design work products, as appropriate, resulting from
the following tasks:
Design Software Components (DS.080)
Design Data (DS.090)
Design Behavior (DS.100)
Design Business Rules (DS.110)
Design Services (DS.120)
Design User Interface (DS.130)
Prepare Design Specification (DS.140)
Develop Database Design (DS.150)
Ultimately, the Design Model includes an object model that describes the design realization of the use cases and design classes that detail the analysis classes outlined in
the Analysis Model. In addition, the Architecture Description initially developed in the Business Requirements process (RD.130), and enhanced in both the Requirements
Analysis (RA.035) and Analysis (AN.040) processes is enriched with the new Module and Execution Views (DS.040).
Back to Top
PROCESS FLOW
Back to Top
APPROACH
The main goal of the Design Process is to detail the Design Model that will be used to implement the requirements.
First, take the Architecture Description (RD.130/RA.035/AN.040) and complete the architectural design by adding the Design Properties and the Module and Execution
Views (DS.040). The Module View corresponds to the Architectural View of the Design Model from UP, while the Execution View corresponds to the Architectural View of
the Deployment Model.
The Architecture Description (DS.040) provides an outline for the Design Model and the architecture. When defining the Module View, the analysis classes, and packages
are mapped to modules and layers depending on the chosen software platform technology. Here the architect addresses how the conceptual solution can be realized
with today's software platforms technologies. On the other hand, the Execution View describes the structure of system in terms of runtime platform elements and captures
how the Module View will be assigned to these platform elements. Before completing the Architecture Description, it is reviewed and defects and changes are recorded
and may be fed back to the design as a following task.
In the Component Data Design (DS.090), and the Component Behavior Design (DS.100) tasks, we take the work from the Analysis process further. Although the tasks
have a different focus (Analysis versus Design), the tasks are often done in parallel, or back and forth, with the tasks, Analyze Data (AN.050) and Analyze Behavior
(AN.060).
During Design, we move from a more generic model to a very specific design to determine the actual implementation of the requirement. The Component Data Design
(DS.090) and Component Behavior Design (DS.100) describe how a specific use case will be realized, in terms of design classes and their objects. This also ensures
traceability all the way to the Use Case Model (RA.023), via the Analysis Model. During these tasks, you will create MVC (Model/View/Controller) activity diagrams to fully
design the use case's flow of events. The interaction diagrams you created in the Analysis Model are detailed to better specify message exchange among classes.
Complex transaction processing is designed in sequence or collaboration diagrams.
Each Use Case Realization contains behavioral requirements for each class or subsystem it embraces. These requirements are specified and integrated into each class
as part of the User Interface Design (DS.120), and Design Software Components (DS.080) tasks. For each class, various aspects are considered, such as operations,
attributes, relationships, methods and interfaces, states pertaining to the class, dependencies and implementation of non-functional requirements. The design is split into
the design of entity classes, boundary classes and control classes. For entity classes, the database technology and persistent mechanisms play an important role in
shaping the design of entity classes. This task is closely related to the activity related to the Develop Database Design (DS.150) task. The analysis boundary classes
pass via a design process and will often result in several boundary design classes. Any existing Functional Prototypes (IM.010) are to be used as inputs to this step. The
user interface boundary classes are specified in terms of the software development tool in which the user interface is to be developed. Depending on the architecture
chosen for the project, the approach for designing boundary classes may differ. The control classes are responsible for coordinating, sequencing, transactions, and
controlling of other objects. Again, depending on the mechanism chosen to support these classes, the approach used to transform analysis control classes in design
control classes might differ. Finally, you will refine the state diagrams of complex classes that you created in the Analysis process, and possibly create new ones based
on the needs highlighted during the Design process.
When performing Develop Design Architecture Description (DS.040) task, you identify and optimize dependencies between components. Dependencies should be
minimized wherever possible. Preferably, these dependencies should be with the interface of the component rather than the component itself. This ensures that the
component may be substituted by another component that provides the same interface but a different internal design without affecting the dependent components.
In parallel with the tasks above, you also develop the Logical Database Design (DS.150). In this task, you translate the Domain Model into a Logical Database Design,
applying the rules and principles of relational systems design. You may choose between various approaches. For example, in a bottom down approach, the design of the
entity classes is used to create the database. Alternatively, in a bottom up approach, the database is modeled in parallel with the design of the entity classes. The Logical
Database Design is used to create the physical database.
The output of these tasks is organized and combined to create a Design Model that is reviewed to discover defects before it is implemented. In an offshore project, this
task is essential, since in many of the cases the implementation may be performed in an offshore environment by a different team of people than those who created the
design Model. By discovering defects before the design model is shipped for implementation, rework is reduced and the productivity of the project as a whole is improved.
On projects with a single, small team and short communication lines, and where the same team will perform the implementation, you may choose to skip this review.
In the same way as for the Analysis process, the Design process is performed iteratively, both in the Elaboration and the Construction phase, adding more detail with
each iteration. The iteration starts with the Analysis tasks, and continues with the Design tasks. At the end of each iteration in the Elaboration phase, the result is fed into
a new Functional Prototype (IM.010) that is reviewed by the ambassador users. The feedback from the validation of the Functional Prototype (RA.085) is prioritized and
fed into the next iteration of the process, or if it was the last iteration, into the Construction phase.
In the Construction phase, the iteration continues with Implementation tasks that ensure that the components and database are created following the updated Analysis
Model and Design Model. Finally, the iteration continues with Testing tasks before the result goes into the next iteration until the last iteration has been performed.
Back to Top
Supplemental Guide to access all application implementation supplemental information. You can also go directly to the Design process supplemental guidance.
Back to Top
Elaboration Phase
DS.020 Define Application Extension Strategy Application Extension Strategy
DS.050 Determine Design and Build Standards Design and Build Standards
DS.060 Define Business Rules Implementation Strategy Business Rules Implementation Strategy
DS.070 Define SOA Implementation Strategy SOA Implementation Strategy
Construction Phase
Back to Top
OBJECTIVES
The objectives of the Design process are:
Produce a design that meets the functional and supplemental requirements, within the given technical constraints.
Optimize the Logical Database Design to meet design standards and performance requirements.
Create an appropriate design for subsequent Implementation process activities by capturing requirements on individual subsystems, interfaces and classes.
Capture important interfaces between subsystems early. This is helpful information when discussing architecture and the interfaces can be used as a boundary and
synchronization between development teams.
Define manageable pieces/partitions of implementation that may be handled by different (possibly concurrent) development teams.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
Specialist
implemented.
BA Business Analyst Provide assistance with Application Extension Strategy. Define the Business Rules Implementation Strategy. Design the business
rules.
DD Database Designer Develop all aspects of the data models for the system. Participate in the review of the Design Model.
DES Designer Define and maintain the responsibilities, attributes, relationships and special requirements of the classes making sure that each class
fulfills its requirements. Analyze packages within which the classes are maintained. There may be several designers depending on the
size of the project, each of which may be responsible for certain classes and packages assigned to them. You may want to use an
object designer also. Define and maintain the responsibilities, attributes, relationships and special requirements of the classes making
sure that each class fulfills its requirements. Responsible for the analysis of packages within which the classes are maintained.
Responsible for the integrity of use cases as assigned. Ensure that all requirements are met and the diagrams, specifications and
models are clear and precise. Design the services. Define major interfaces, navigation paths and widget details for each storyboard.
DV Developer Participate in definition and review of the Module and Execution Views. Collect, produce and write Design and Build Standards. Review
the design classes in order to assure that they are compatible with the architecture. Design the more complex packages and classes.
Review the Component Data Design in order to assure that it is compatible with the architecture. This person is also responsible for
designing the more complex packages and classes. Participate in definition of the Component Behavior Design. Design the most
complex use cases. Review the Logical Database Design in order to assure that the Design Model is compatible with the Logical
Database Design. Participate in the review of the Design Model.
QM Quality Manager Participate in the review of the Design Model.
SA System Architect Define Application Extension Strategy. Lead the development of Module and Execution of Views and update the Architecture
Description. Participate in the definition and review of the Module and Execution Views to gain an understanding of the application and
its architecture. Provide input on the technical constraints to which the Business Rules Implementation Strategy must adhere. Define
the SOA Implementation Strategy. Participate in definition and review of the design classes to gain an understanding of the application
and its architecture. Participate in definition and review of the Component Data Design to gain an understanding of the application and
its architecture. Participate in definition review of the Component Behavior Design. Participate in the review of the Logical Database
Design to gain an understanding of the application and its architecture. Participate in the review of the Design Model.
Client (User)
KEY Ambassador User Provide feedback on the user interface prototypes. Participate in the review of the Design Model.
Back to Top
Flexible Design: When going into more detail, new or changed requirements will be discovered, and in the future, new requirements will be desired. By having a
design resilient for changes, the required effort, and thereby the total costs will be less when more detail, or changes have to be implemented.
Visible Dependencies: For each change or new requirement, it is important to determine the impact on the change. This task is made easier by keeping visible
dependencies, from the lowest level, all the way up to the Use Case Model.
Understanding of Supplemental Requirements: During the Design process, there is a strong focus on the supplemental requirements. Therefore, it is important
that these are properly understood in order to determine the proper impact on the design.
Back to Top
DS.020 - DEFINE APPLICATION EXTENSION STRATEGY
In this task, you prepare a strategy document that describes how your project responds to customization requests.
For projects that involve the upgrade of Oracle products, the focus is on migrating existing extensions to the new release, rather than the development of new extensions.
Therefore, the focus for this task includes defining the strategy for migrating the following:
legacy character based GUI to Web-based access methods
legacy client/server applications to SOA/Web-based solution
batch application to real time SOA-based services
ACTIVITY
Back to Top
WORK PRODUCT
Application Extension Strategy - The Application Extension Strategy outlines the policies and procedures governing the process of extending the functionality of Oracle
commercial off-the-shelf (COTS) application products .
Back to Top
TASK STEPS
1 Review background materials.
2 Describe the purpose, background,
scope, and application of the
Application Extension Strategy.
Introduction This component documents the purpose, background, scope, and application of the Application Extension
Strategy.
3 Define the customization policy. Customization
Policy
This component states the general policies to be followed during the customization process when determining
which requirements can be satisfied using standard features of the application versus requirements that can
only be addressed by building new modules or by modifying existing ones.
4 Determine the design tools you will
use.
Design Tools This component identifies and describes the design tools that will be used during the customization process.
5 Determine the development tools
you will use.
Development
Tools
This component identifies and describes the development tools that will be used during the customization
process.
6 Describe the design and
development process.
Development
Process
This component describes the process that all designers and developers will follow to develop changes to
Oracle Applications.
7 Describe the approach for
identifying alternative answers to
functionality gaps.
Mapping
Approach
This component establishes guidelines for identifying and classifying functional gaps in the standard
applications. Gaps can be broadly classified as either information that the applications do not store or
functions they do not perform.
8 Define the approach to estimating. Estimating
Approach
This component lists all of the potential customization needs and quantifies the necessary development effort.
9 Describe the testing process. Testing
Process
This component identifies and describes the testing activity on the resulting Application extensions.
10 Describe the upgrade procedure. Upgrade
Procedures
This component lists and describes all of the steps needed to preserve the functionality of the customized
modules after upgrades to new releases of the applications.
11 Seek acceptance of the deliverable
from the project sponsor or steering
committee.
Acceptance
Certificate
(PJM.SM.040)

Back to Top
APPROACH
The Application Extension Strategy influences the types of responses to business issues the project team considers and proposes during Develop Future Process Model
#TOP
(RD.011.2) and Develop Use Case Details (RA.024), the satisfaction of your users, and ultimately the final cost and duration of your project. Your basic options are as
follows:
no customization
extensions only
customization allowable
Regardless of your strategy, you need to provide some guidelines to direct the project team in the application of the options they have.
No Customization
If you decide that you will not customize the applications, your strategy is simple. However, this also means that your only option to add new features to the product is to
submit requests to Oracle Corporation.
Query Tools
If you plan to use a user reporting and query tool, your customization strategy should describe it and explain storage and catalog procedures for user-developed reports
and catalogs. Some query tools require significant setup and maintenance. You must also deal with database changes in new releases, just as you would with any other
custom reports.
Flexfields
Technically, flexfields are customizations, although fully supported by Oracle. Descriptive flexfields can vary in complexity from a few nonvalidated fields on a form to
context-sensitive flexfields with complex validation rules. If your strategy includes the use of flexfields, emphasize the importance of standards and careful documentation.
Extensions Allowable
If you limit customizations to reports and other pure extensions, your strategy should make a distinction between extensions and modifications. Extensions add modules
but do not change any code in the base application. Modifications change code in the application and require significant analysis during upgrades. Because it is additive,
incorporating a new field into a form or report may be considered an extension, but this is a pure modification that should be avoided.
When you build new components and integrate them with the applications, you take on the responsibility of maintaining and supporting the new components for your
users. A formal help desk can make sure that help requests and problems are routed to the appropriate group for resolution (internal help desk versus Oracle Support).
For more information, see Implement Production Support Infrastructure (TS.052).
Customization Allowable
When all types of customizations are permitted, your strategy should provide guidelines for when each type is appropriate. A modification should only be considered when
the business need is vital, there are no procedural workarounds, and all other alternatives have been exhausted.
Whenever you modify a standard application component, treat the modified module as if it is a custom component that you have designed and built from scratch. The
original source and executable code must remain in its original location. The storage of the modified version must be in a custom directory structure and registered in
Application Object Library (AOL) as part of a custom application.
Upgrades
The biggest challenge with any type of customization is upgrading to a new release of the base application. You must design customizations so that the impact of
upgrades is minimal. You must also define the process to follow when you perform an upgrade.
Preserving Custom Components
To prevent an applications upgrade from deleting some of your customizations, implement them in a way that insulates them from upgrades. A summary of the specific
techniques is listed below:
Custom Code Store source and executable code for new and modified modules in a separate directory structure.
Database
Objects
Name all database objects with a unique prefix that does not conflict with any current or reserved Oracle product prefixes. Create one or more separate
database users to hold custom database objects.
Program
Logic
Use views for all database access.
Application
Objects
Create a new custom application in AOL and register all objects in this application. This includes forms, tables, responsibilities, menus, Oracle IDs,
alerts, report security groups, messages, and help text.
In special cases you must replace existing modules with customized versions to implement custom functionality. For example, to implement zooms in web-client forms,
you must add code to a special code library provided with the applications.
Analyzing the Impact of Upgrades
Some of the possible impacts an upgrade or patch can have on various types of customizations are as follows:
Custom Reports The underlying tables or views may change.
Custom Forms The underlying tables, views, and shared library functions may change.
Any Modified
Modules
The standard module may change and you must reapply your changes to the new version of the module or choose to keep your version and
implement improvements to your code.
Database
Triggers
The underlying tables may change. The business rules that cause the trigger to fire may change. The business rules that act on the data in tables
you update may change.
Alerts The underlying tables may change. The business rules that cause the trigger to fire may change. The business rules that act on the data in tables
you update may change.
Interfaces The underlying tables may change. The business rules that act on the data in the tables you update may change.
Custom Menus Oracle may eliminate functions that are included in your menus or add functions that you need to include.
Custom
Responsibilities
Oracle may eliminate menus or add new ones that affect your responsibilities.
Process
Navigator
Oracle may eliminate functions that are included in your process navigator definitions or add new functions that you may need to include. These
definitions need to be revalidated with subsequent releases.
Workflows As workflows navigate the user from screen to screen, business function to business function, Oracle may change workflow destinations. Workflows
must be revalidated with subsequent releases.
Work Product Guidelines
Do not attempt to describe standards in the Application Extension Strategy because Design and Build Standards (DS.050) is a separate work product. The strategy
focuses on policy, scope, techniques, and procedures.
After you write the Design and Build Standards, you may wish to combine them with the Application Extension Strategy and publish the set as an application
customization developers guide. Make each deliverable a chapter of the consolidated document. This provides a single document that new developers on the project can
read and reference.
Back to Top
Back to Top
System Architect 75
Business Analyst 25
Project Sponsor *
Back to Top
PREREQUISITES
Prerequisite Usage
(PJM)
Testing Requirements
(TE.005)
Testing Strategy (TE.010)
The Project Management Plan describes the high-level customization approach and may include a list of known customization
requirements. It also includes the quality assurance process for custom designs and programs.
Some information in the Application Extension Strategy overlaps with the Project Management Plan and the Testing Requirements
and Testing Strategy). However, the strategy content found in those work products is rather general in nature. The Application
Extension Strategy contains greater detail and is directed specifically at developers.
Back to Top
TEMPLATES AND TOOLS
DS-020_APPLICATION_EXTENSION_STRATEGY.DOC MS WORD
Tool Comments
Use Case Details Viewlet JDeveloper
Back to Top
Distribute the Application Extension Strategy as follows:
to the project team
Back to Top
QUALITY CRITERIA
Does the document include guidelines regarding customization policy?
Does it include automated tools to aid design and development?
Does it include a description of the development procedures to be employed?
Does it include guidelines for the identification of functionality gaps?
Is there a process to nominate and seek approval for proposed customizations?
Does it provide estimating guidance?
Does it include requirements for testing?
Are there procedures for upgrading the applications during the course of the project?
Back to Top
DS.035 - UPDATE EXISTING DESIGN SPECIFICATION
In this task, you review and update the clients existing design artifacts for custom extensions that have been approved for migration to the new release.
ACTIVITY
DS.035.1
DS.035.2
Back to Top
WORK PRODUCT
Updated Design Specification - The Updated Design Specification pulls together all design elements for a custom extension into a single document so that they can be
easily assessed against each other, against the design guidelines, and against the requirements.
Back to Top
TASK STEPS
1 Locate any existing design artifacts that describe the technical details of each custom
extension being upgraded to the new release.
Existing Design
Specification (Artifacts)
Examples of existing artifacts include:
Technical Design Documents
Screen Designs
Data Flow Diagrams (including
any UML models)
existing Design Specification
(DS.140)
2 Update the existing artifacts to match the architecture and platform to which the custom
extension is being migrated.
Updated Design
Specification

Back to Top
APPROACH
The format of the Updated Design Specification largely depends on the existing artifacts from the current release of the software being upgraded. Examples of existing
artifacts could be, but are not limited to:
Technical Design Documents
Screen Designs
Data Flow Diagrams (including any UML models)
existing Design Specification (DS.140)
In addition, the format of the Updated Design Specification is dependent on the specific application architecture of the new software release.
In any event, the Updated Design Specification describes the technical details to be provided by the custom extension.
Back to Top
System Architect Ensure that the design specification is consistent with the overall design guidelines and fully captures all design elements
relevant to the chosen custom extension. Document open and closed design issues.
70
Designer Review the Updated Design Specification for consistency. You may want to include a designer who specializes in user
interface designing as well.
20
Database Designer Review the Updated Design Specification for consistency. 10
Back to Top
PREREQUISITES
Prerequisite Usage
Updated Analysis
Specification (AN.035)
The system architect uses the Updated Analysis Specification to understand the functionality to be provided by the custom extension
or extension in business and user terms.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Updated Design Specification is used in the following ways:
to make sure the design meets both the functional and non-functional requirements
to ensure that the design meets the architecture's design guidelines
to provide input into the implementation of the system as designed
Distribute the Updated Design Specification as follows:
to the system architect for review
to component designers for updates / revisions to their design
to database designers for updates / revisions to their design
to user interface designers for updates / revisions to their design
to the project manager for schedule modifications due to design issues that must be addressed
Back to Top
QUALITY CRITERIA
Are all of the custom extensions that have been approved for migration to the new release, referenced in the Updated Design Specification?
Is there adequate detail about the behavior and the data that the custom extension will support?
Does the Updated Design Specification fit in and is it consistent with the overall architecture of the new software release?
Can all data required by the user interface be traced through the components to a source in a data store?
Can all behavior required by the user interface be traced into the components that support that interface then to the operations on classes and finally into the
methods for those operations?
Are attribute data types, parameter data types, and operation return data types consistent?
Is duplicate behavior minimized?
Are classes defined once, not several times, in different areas of the design?
Can each component be realized through object interaction by their provided interfaces?
Back to Top
DS.040 - DEVELOP DESIGN ARCHITECTURE DESCRIPTION
The purpose of this task is to update the systems architecture to add design related details that establish a set of components to be designed, the structure of those
components within the system at runtime, and priorities for proceeding with detailing the design of the identified components.
In this task, you add design-level details to the Architecture Description (originally created with task RD.130). These details take the form of:
Design Priorities that highlight the architecturally-significant aspects of the system by documenting the design and development priorities that have been
determined by an iterative examination of the implementation risks
A Module View that depicts how subsystems are decomposed into components, and components are assigned to layers in accordance with their use-
dependencies
An Execution View that describes the structure of system in terms of runtime platform elements
The Architecture Description work product is the collection point for all of the architectural views for the system. This artifact documents the systems architecture through
these architectural views and highlights the architecturally-significant aspects of the system by documenting the design and development priorities that have been
determined by an iterative examination of the implementation risks. A well-formulated Architecture Description is one of the key elements of the Lifecycle Architecture
Milestone that concludes the Elaboration phase.
The Architecture Description becomes the index for:
Analysis artifacts that are created for each of the Analysis Packages defined in the Conceptual View (Package View) of the Analysis Architecture Description
Design artifacts that are created for each of the Design Components defined in the Module View of the Design Architecture Description.
This task is typically utilized on larger projects, but should also be considered when:
on the extent to which the inclusion of a significant custom component (e.g., Data Warehouse), large numbers of custom extensions or integration with multiple COTS or
third-party systems leveraging Fusion Middleware, requires a reassessment of the standard application architecture. When this sort of architecturally-significant custom
development impacts the standard application architecture, it is extremely important that this task be performed to guide the development and integration of custom
components.
extensions by promoting leading practice use of standard functionality. Therefore, this task is not included in the pre-defined Solution-Driven Application Implementation
ACTIVITY
DS.040.1
DS.040.2
Back to Top
WORK PRODUCT
these four tasks:
In this task, you add Design Architecture Description (DS.040) material to the Architecture Description work product. The Design Architecture Description further details
the Architecture Description with the Design Priorities, the Module View, and the Execution View.
The Module View may consist of diagrams showing packages, subsystems, modules, interfaces, layers, classes, function collections, part-of relationships, and
dependencies.
The Execution View may consist of diagrams showing deployment diagrams with nodes, artifacts, communication links, runtime environment specifications, and
dependencies.
Back to Top
TASK STEPS
1 Identify Design
Priorities.
Design Priorities Design Priorities provide guidance to the design team, helping them make the right choice among all the
possible design choices for developing the system solution.
2 Define Module View. Module View The Module View depicts how subsystems are decomposed into components, and components are assigned to
layers in accordance with their use-dependencies.
3 Define Execution
View.
Execution View The Execution View describes the structure of the system in terms of runtime platform elements.
4 Review Architecture
Description.
Architecture Defects /
Change Requests
The Architecture Defects/Change Requests is a list of defects found in the Design Architecture Description.
Back to Top
APPROACH
The Conceptual View of the architecture organized analysis or use case packages for the purpose of grouping related functionality together which will subsequently be
developed into a design solution. During Design, these packages are broken up into smaller, more manageable pieces. Each of these pieces should lend themselves
more easily to a solution. Once each of the pieces are designed, they work together to form a solution to the original problem.
The Module View consists of units of software that can be designed, coded, and delivered in an executable environment. These components organize all the elements
from analysis and other design elements into a structure that matches the quality needs of the system. The Executable View shows the runtime instantiation of the
components. While the Module View describes what the software elements are and their dependencies, the Execution View describes the environment in which those
software elements run.
The task of architecture design is accomplished iteratively. Standard architecture practice takes different perspectives or views of the problem. Each view focuses on a
small set of issues before moving on to other concerns. Because of these different perspectives, it is important to use an iterative process. Whats learned from working
on one view provides insight into another view. Do not try to develop a Module View in its entirety and then move on to the Execution View. Instead, develop a tentative
Module View, then a tentative Execution View. Go back to the Module View and refine issues about the overall structure of the design.
Identify Design Priorities
There are many possible design solutions for a system. Which design choices will meet the needs of the architecture? How will you know which design choice is best?
What criteria should be used to find the right solution? This step will answer these questions.
First understand the relative importance of issues like performance, cost, schedule, meeting the functional requirements, and quality of service to the stakeholders. A
design that favors performance over everything else is usually more costly, takes longer to implement, and often sacrifices such things as flexibility, modularity, and
maintainability. An architecture that is cheap to build may sacrifice user requested functions or use cases.
Next, prioritize the capabilities that the system must have. Are some use cases more important than others? Are there special conditions under which the system must
operate without fail? Look carefully at the supplemental requirements such as reliability, availability, scalability, and maintainability. How important are each one of these
in terms of the quality of service your system provides? What are the systems operational scenarios under which these quality of service items may become very
important? For example, during peak work week hours the system must be available 99.9999% of the time, but on weekends there is no need for general user
availability.
Finally, write down your design guidelines. As you go through the design process, the team has criteria to assess whether any particular design decision is better than
another.
Define Module View
In this step, the Analysis Architecture is enriched with the Module View.
In the Module View, the analysis packages are decomposed into modules or components, and these components are assigned to layers in accordance with their use-
dependencies. Component dependencies are explicitly modeled with the help of component interfaces. In the Module View, the analysis classes, and packages are
mapped to components and layers. Here the architect addresses how the conceptual solution can be realized with today's software platforms and technologies. The
primary concerns that must be addressed when defining the Module view are:
How is the product mapped to the software platform?
What system support/services does it use, and exactly where?
How can dependencies between components be minimized?
How can reuse of components and sub-systems be maximized?
What techniques can be used to insulate the product from changes in COTS software, in the software platform, or changes to standards?
There are many possible architectures for a system. If you have not already done so, start by choosing an architecture pattern as the basis for your design. Most of
todays information systems are based on the three-tier architecture pattern: presentation, business logic, and data management. The presentation tier contains design
elements that are responsible for interacting with the user. The business logic tier is responsible for performing calculations, verifying that business rules are followed,
and that the right content is delivered to the presentation tier at the right time. The data management tier is responsible for storing all persistent data. Each element of an
architecture pattern can be considered as a subsystem with specific relationships between those subsystems. In the three tier architecture mentioned above, the
presentation tier is dependent on the business logic tier. The business logic tier is in turn dependent on the data management tier.
Given the chosen architecture pattern and its logical subsystems, you can now decompose those subsystems into subsystems or components. Those components may
need to be decomposed into yet more detailed components. Generally, when you decompose subsystems into components, try to have high cohesion within the
component and low coupling to other components. You can use one or more of the following techniques for grouping elements into Components:
Use Cases embody a group of classes that must work together to accomplish major functionality for the system. Putting the control class and boundary classes
together provides for a highly cohesive grouping. For example, create an Enrollment Component to mirror the Enrollment use case.
Look for an aggregation relationship between a class representing the whole and classes representing the parts. This forms the basis for strong encapsulation,
high cohesion within the aggregate and low coupling outside of the aggregate. For example, a Catalog Component to encapsulate the Catalog and its courses.
If the domain class diagram from analysis has a group of closely associated classes with loose coupling to surrounding classes that can form the basis for a high
cohesion, low coupling Component. For example, the Department, Major, Building, and Body of Knowledge classes may be closely associated to form a
Department Component.
As cohesive components are developed, assign responsibilities to them. If a component is going to realize a use case, then assign it the responsibilities of performing the
scenarios in that use case. If a component is to implement an aggregation, then the Component should have the responsibilities of the class representing the whole
aggregate.
Once a group of components is defined, consider the dependencies among the components. Can a component stand alone? Does one component need the data of
another?
For example, an Enrollment Component would need information from a Component that encapsulates all things related to student.
Does a component need to make requests of another component?
For example, a Drop Course Component would invoke the Course Component requesting that a student be taken off the roster in a specific course being
held at a certain time.
Show these dependencies in your Module View. If you are providing a diagram for the Module View you can use a dashed line with an arrow pointing in the direction of
the dependency.
Once the components have been assigned responsibilities and dependencies, add provided interfaces to each component that provides behavior and/or data to other
Components. The interfaces should bundle a group of related behavior that other components will need.
For example a Student Component might provide an iBasicStudent interface that has an operation allowing other Components to obtain basic student data
such as name and major. Further the Student Component might provide an interface called iFullStudent that has an operation allowing other Components
to get more sensitive data about a Student such as SSN.
With the provided interfaces specified you can proceed to the required interfaces. For each component that is dependent on another Component and thus requires some
interface, document that fact. Now you can seen which components must be connected and, how due to the behaviors, provided by various components.
Once you have the basic layout for the components based on the use case and class, consider the analysis mechanisms that were specified as part of the Analysis
Model. These mechanisms include persistence, inter-process communication, event handling, messaging, and error handling. Add to this list other design mechanisms
such as signals, semaphores, mutex locks, RPC, security, transaction management, and other system services. As an Architect you must decide how the analysis
mechanisms will be designed. You do not have to design the details of each mechanism but you will have to show the any components that will implement your choices.
For example, you may choose to have a Catch All Error Reporting Component that other Components use to report problems. You could decide to create a
publish and subscribe Component to handle event notifications.
Getting your Module View correct may take several passes through the steps outlined above. Remember to use the design priorities from step one of this task to guide
you during each iteration of the Module View development.
The following diagram is a sample of what a Module View might look like showing Components within layers and the provided / required interfaces for each Component:
For each component interface, document the operations that realize that interface. These interfaces can be documented using text and describing the signature of each
operation for that interface. You can use a UML diagram to accomplish the same thing. The following is a diagram that shows the operations of an interface provided by
the iCourse Component:
Notice in the above diagram, you can use notes attached to interfaces to describe the nature of the behavior that interface entails as well as any other details you need to
communicate with the design team.
For SOA Implementations, in this step you gather all dependencies, including hosting system and policies in order to perform service boundary analysis in the next step.
Define Execution View
The Execution View describes the structure of the system in terms of runtime platform elements and captures how the Module View will be assigned to these platform
elements. An important part of the Execution View is the flow of control. The conceptual view describes the logical flow of control, but in the execution view interest lies in
flow of control from the point of view of the runtime platform.
Start with the hardware platforms and their communication paths. Describe the hardware nodes and any of their capabilities that are important to the design. You can
show this on a deployment diagram by using nodes for hardware platforms and connections for communication paths. Add stereotypes to the paths indicating what
communication mechanism and/or protocol will be used to implement the communication between elements on the respective nodes. Add stereotypes to the nodes
indicating the type of hardware platform the node represents.
Look to your Module View and decide which modules or components will be placed on which nodes. Place the component on the appropriate node. Indicate any runtime
information that is necessary for the operation of that component on that node that is significant to your design. If multi processors is important to your design consider
showing <<process>> nodes contained within <<device>> hardware nodes. Then place components on the different processor nodes to indicate how they run separately
in different processes at runtime. Caution: do not try to show every process for your system. Only show those that are significant for your design.
The following diagram is a sample of what can be done using J2EE in the Execution View:
Review Architecture Description
The Architecture Description is reviewed and defects and change requests are recorded. There are many different types of changes. During the review, take care to
make sure all the elements of the Conceptual View are mapped to the Module View and that all the elements of the Module View are mapped to the Execution View. If
there are missing mappings or a design concern has not been met, make changes to each of the views. Some changes can affect scope and require change requests.
Other changes do not affect scope and should be handled through a MoSCoW List.
Back to Top
Back to Top
System Architect Lead the development of Module and Execution of Views and update the Architecture Description. Participate in the definition
and review of the Module and Execution Views to gain an understanding of the application and its architecture.
80
Developer Participate in definition and review of the Module and Execution Views. 20
Back to Top
PREREQUISITES
DS.040.1
Prerequisite Usage
Architecture Description The current state of the Architecture Description (originally created with RD.130) document that includes the Global
Analysis, High-Level Software Architecture, and Conceptual View materials is used as a starting point to create the
Module View.
Reviewed Analysis Model (AN.110) The Analysis Model is comprised of all of the Analysis work products. The analysis classes and packages that are part of
the Analysis Model are used as a basis to identify components, subsystems, and layers. The Analysis Model represents
a collection of all Analysis work products, as available, resulting from the following tasks:
These work products are organized by package as defined in the Conceptual View of the Architecture Description and
will vary based on the type and contents of each Analysis Package.
DS.040.2
Prerequisite Usage
Architecture Description The current version of the Architecture Description (originally created with RD.130) document that includes the initial
Module and Execution Views and the latest updates to the Global Analysis, High-Level Software Architecture, and
Conceptual View serves as input to the final version.
Integration Architecture Strategy (TA.030)
Initial Architecture and Application
Mapping (TA.070)
Backup and Recovery Strategy (TA.080)
Security and Control Strategy (TA.090)
Capacity Plan (TA.160)
During the development of these Technical Architecture work products, new factors may have been identified that should
be reflected in the Architecture Description.
Back to Top
TECHNIQUES
Technique Comments
SOA Service Lifecycle Use this technique to understand where this task sits in the overall service lifecycle.
SOA Service Boundary Analysis Use this technique to understand how to use boundary analysis to define services to the right level of granularity.
Service Architecture Use this technique to understand how to write a service contract.
Service Modeling Use this technique to understand how you can model services.
Back to Top
TEMPLATES AND TOOLS
Template File
Name
Comments
Architecture
Description
MS WORD - Add the Design Priorities, the Module View, and the Execution View to the Architecture Description work product originally created in
Develop Baseline Architecture Description (RD.130).
Back to Top
The Module View and Execution View of the Architecture Description are used in the following ways:
by technical reviewers to see if it conforms to the quality criteria as outlined below
by stakeholders of other systems must review content to raise any issues related to the impact of the architecture on their system
by designers use the design priorities, component responsibilities/interfaces and executable information related to the component they must design
by test designers use the interface information to organize internal integration testing among the Components defined for the system
by database developers need this information to understand the relationship of the database management system to the other layers of the architecture. They
focus on persistence mechanisms called out in the Component and Execution Views.
by the interface designers use design priorities, design guidelines and performance issues specified by the architecture when designing user interfaces
Back to Top
QUALITY CRITERIA
Is the architecture stable? Ask, what would happen if small changes were made to the requirements? If this leads to big architectural changes that is not stability.
As work proceeds on the architecture, how many changes are being made on a daily or weekly basis?
How well does the architecture meet the design priorities outlined in step one of this task?
Is the required functionality to include use case realizations accomplished with the minimum complexity necessary?
Is there enough information about each part of the architecture for the designers of individual components to complete their design task?
Are the interfaces for each component well defined allowing different teams to work independently on these components at the same time?
Does the test designer have enough information to proceed with internal integration test specification?
Does the architecture account for security, availability, reliability, maintainability, and persistence requirements?
Does the architecture account for how performance requirements will be achieved at an aggregate level?
Do individual components and layers tend to have high cohesion?
Do components tend to be loosely coupled?
Does the architecture take into account changing technology?
Does the architecture design provide mechanisms for startup, graceful shutdown, backup, and recovery?
Back to Top
DS.050 - DETERMINE DESIGN AND BUILD STANDARDS
In this task, you determine the design and build standards to which designers and developers should adhere when designing and building the new system. The standards
should provide consistency within the system, and also assist less experienced designers and developers on how to use the tools.
Before writing any of your own standards, you should gather already existing standards from various sources, for example from previously run projects. The collected
standards are evaluated for reuse. For areas where the standards are not sufficient or completely missing, you will write your own standards.
In a commercial off-the-shelf (COTS) application implementation, you define the design and build standards that designers should follow when designing custom
extensions to the COTS application products. Clear and detailed design and build standards help ensure that all designs are in a consistent format and include the
appropriate level of detail. Standards enforce a high level of quality.
For projects that involve the upgrade of Oracle products, this task is focused on defining the Design and Build Standards that will be used during the migration of existing
custom extensions to the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Design and Build Standards - The Design and Build Standards documents which standards and guidelines are applicable for designing and building the application, or
extending a COTS application product. They are added to the project library to which the team readily has access. They allow for consistency of work over all project
team members.
Back to Top
TASK STEPS
1 Determine what kind of standards are required. None
2 Collect existing standards. None
3 Evaluate existing standards. None
4 Add project specific standards. None
5 Collate all standards into project standards, and document use of
standards.
Design and Build
Standards
This is the complete document consisting of all project standards,
including a section where the use of the standards is documented.
6 Distribute standards to project team and communicate mandatory
nature of adherence to standard documents and their availability.
Easily Accessible
Design and Build
Standards
Make the Design and Build Standards easily accessible for all project
members.
Back to Top
APPROACH
This task is mandatory if your project includes development of custom components, and should be performed once. However, changes and additions may be made on an
ongoing basis throughout the project, as a need for new standards may emerge.
The overriding principle in this task is that of reuse. It is assumed that most of the inputs to the task are pre-existent. In the case where these inputs are not present, then
it is advisable to look at undertaking a separate project in order to produce them as it can be a fairly time-consuming task to produce a full set of standards.
Before creating new standards, review all other design and development standards sources. Standards are available for most tools, either from earlier projects, as
corporate standards, or from other parties. It is recommended that these be reused, whenever possible, in order to save time. It is a rather time consuming and costly
task to produce a full set of well-defined standards.
Determine what standards are needed. This will depend on what kind of tools and programming languages the project uses. For each tool and programming language you
will need standards to ensure consistency of use.
When it is clear what kind of standards are needed, search for existing standards that can be reused. Typically first look into your own organization to see what kind of
standards have been used in earlier projects to see whether any of these can be reused. You can also search for standards using the Internet. If you can obtain
standards from other organizations for a fee, this is often more cost efficient than creating the standards from scratch. You may not even have the experience in your own
organization to produce well-defined standards. If possible, obtain an evaluation copy first so that you can evaluate their usefulness before buying the standards.
Look for standards for every software tool and programming language you use. Look for standards to cover the following aspects:
general standards for the tool and programming language
layout of source code header template, use of uppercase, format of in-line documentation, etc.
naming conventions of tool and source code objects for example, naming of java classes, libraries etc.
dos and dont's while using the tool the most important section, guiding the programmers in applying similar techniques and constructs to build the desired
functionality
When you have determined the set of standards to reuse, there might be gaps where you have not been able to find appropriate standards, or where you want to deviate
from the standards you have collected. This is typically an ongoing activity throughout the project as the need for new or changed standards may be discovered when you
start designing and developing the system. For each change or addition, you will need to distribute and inform the project participants.
The Validated User Interface Standards Prototype (IM.095) may give an direction on how some standards should be, and what kind of standards are needed to ensure
that the applications look and feel will be as agreed in the prototype.
Provide an identifier for each standard you create so it is easier to reference if necessary. For each standard, also document the reason why the standard is as it is. This
makes it easier for everyone to understand the rationale for complying with the standard. It also makes it easier to maintain the standards, as tools and programming
languages change. For example, a practice that was adopted early in the project in order to obtain good performance, may not be the same at a later point - if the tool
changes. If the reason is documented, it is easier to determine if a standard has become obsolete.
These standards are gathered and distributed throughout the team in order to provide awareness and compliance. Ensure that the standards are easily accessible for
everyone in the project. If you have a project site, it is recommended you include a link to all standards from there. Organize the standards with a general section that
contains all standards that are generic, and per tool and programming language, so that it is easy for the designers and developers to find what they are looking for.
Whenever the standards are updated, inform everyone on the project with the changes, so that they will know what has been changed or added.
Ultimately, the adherence to these standards should result in the development of a consistent application.
What Makes a Good Standard? A good standard has the following qualities:
unambiguousclearly communicates the standard and is easy to read and understand
consistentconsistent with existing standards and your development philosophy; it is self-consistent as well
easy to useleverages existing standards and tools and increases your productivity; it is not awkward or impractical
Present to Project Team
Handing out a standards document to the team may not be enough to ensure conformance or even understanding. Plan to hold a learning session and include all
analysts, designers, and developers. Those who will be reading the design documents must also understand the standards.
Back to Top
Back to Top
Developer Collect and produce standards, as well as ensure that they are available to the project participants. Communicate additions
and changes to the standards. You may want to consider using a lead system developer to evaluate and help write standards.
You may want to consider using a tool specialist to write standards for specific tools that are used by the project.
100
Back to Top
PREREQUISITES
Prerequisite Usage
Standards (ENV.EA.010) or Existing
Standards
Use this Envision work product or a similar enterprise-level document, if available. Existing standards should be
evaluated for applicability to the project.
Technology Architecture (ENV.EA.130) Use this Envision work product or a similar enterprise-level document, if available.
Validated User Interface Standards
Prototype (RA.095)
The Validated User Interface Standards Prototype provides input for how the actual application should work, and how it
should look. This should give directions on what certain standards should be, and what kind of standards may be
needed.
Application Extension Strategy (DS.020)
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Design and Build Standards are used in the following ways:
to ensure consistency across the application with regards to user interface, design and coding
as a reference during the Design and Implementation processes
Distribute the Design and Build Standards as follows:
to all project participants that perform design and build of the application
to the quality assuror that should verify design and build quality
to the organization for possible reuse
Back to Top
QUALITY CRITERIA
Do the designers and developers know which standards are used in the project?
Do the developers understand how to use the standards?
Are there standards available for all tools and programming languages used in the project?
Are the standards consistent with the Validated User Interface Standards Prototype?
Back to Top
DS.060 - DEFINE BUSINESS RULES IMPLEMENTATION
STRATEGY
During this task, you review the business rules that have been identified. Based on the nature and amount of the business rules found per category, you determine and
document an implementation strategy for business rules.
For any situation that involves a set of business rules of any significant size, it is important to determine and document a consistent strategy for implementation of
business rules. Failure to establish such a strategy might result in an inconsistent implementation of rules and may jeopardize the overall quality of the implementation.
Choices may include more than one means of rule implementation depending on the categorizations used and the size of the rule bases involved as well as the overall
process and technical architecture goals.
components, which extend the functionality of the COTS system, or through a business rules engine. Perform this task only when there is a need to gain further
clarification of the business rules represented in the Use Case Specification (RA.024) and Future Process Model (RD.011). Business rules, which can be realized through
standard configuration options, such as the selection of a Match Approval Level (i.e., 2, 3, or 4 way matching) for invoices, may not require the additional effort called for
in this task. However, complex business rules, or those realized only through custom-built components, or business rules engine, may require the additional effort
associated with this task.
ACTIVITY
Back to Top
WORK PRODUCT
Back to Top
TASK STEPS
Component
Description
1 Review the Architecture Requirements and Strategy (TA.020) and the enterprise Business Rules
Implementation Strategy (ENV.EA.160), if available.

2 Determine Business Rules Implementation Strategy. Business Rules
Implementation Strategy

Back to Top
APPROACH
Any business rules implementation strategy is influenced significantly by the technical architecture (which has been derived from the requirements), and the options for
implementing business rules as provided by that technical architecture. Therefore, review the Architecture Requirements and Strategy (TA.020) to determine the
constraints to which the Business Rules Implementation Strategy must adhere.
For example, in a system with a lot of data entry and retrieval screens, you might have chosen to implement using Oracle
Application Development Framework (ADF).

When using ADF, you can also choose to use Oracle
ADF Business components (ADF BC) as the persistence layer or for providing other kinds of business services.
ADF BC offers specific features for implementing specific types of (static) business rules. Next to that, you may choose to use a business rules engine for implementing
business rules with a volatile nature.
Another example is where several existing applications need to be integrated, or (reusable) services need to be provided, and you have chosen to implement that using
the Oracle
SOA Suite. With that associated technical architecture, a persistence layer may play only a marginal role in the architecture, and most business rules may be
related to decisions in (business) processes, and therefore of a nature that makes implementation as decisions in a BPEL process or a routing rule in an ESB project
#TOP #TOP
more applicable. Especially in the case of a service oriented architecture, the use of a business rules engine for implementing rules with a volatile nature becomes
eminent.
There might be an existing Business Rules Implementation Strategy at the enterprise level. If so, you should review this strategy to verify whether this strategy could be
applicable for your project situation. If so, you should reuse this strategy, rather than create a new one. On the other hand, if the strategy is not applicable, it is preferred
that the enterprise-level strategy is expanded to cover the new situations valid for the current engagement, so that whenever a new project starts with similar
characteristics the strategy can be reused.
Determine Business Rules Implementation Strategy
Independent of the type of architecture, for any situation that involves a set of business rules of any significant size, it is important to determine and document a consistent
strategy for classification and implementation of business rules before designing rules on a large scale. If an existing strategy is reused, you should document the
strategy as a part of the standards and guidelines for the project. If a new strategy is created, it should feed back into the enterprise-level strategy.
Back to Top
Business Analyst Define the Business Rules Implementation Strategy. If possible, you may want use a business analyst with extensive business
rules experience.
55
System Architect Provide input on the technical constraints to which the Business Rules Implementation Strategy must adhere. 35
Application/Product
Specialist
Provide knowledge and guidance regarding the functionality and capabilities of the product(s) being implemented.
If your project involves custom development that is outside the domain of an existing Oracle product, you may decide to
allocate all or part of the effort allocated to the application/product specialist, back to the business analyst and system architect
roles.
10
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.EA.160)
Use this Envision work product, if available.
(TA.020)
Use the Architecture Requirements and Strategy to determine the constraints to which the the Business Rules
Implementation Strategy must adhere.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
ADF (Application Development Framework) Business Components. When using ADF Business Components, a strategy
for classifying and implementing business rules using ADF BC could be based on this white paper.
Oracle Application Server - Oracle Business Rules provides a classic rules engine approach that can be called as a
SOA decision support service. Oracle Business Rules is included in the "rules" directory of the Application Server.
Back to Top
The Business Rules Implementation Strategy is used in the following ways:
to determine and document a consistent strategy for the implementation of business rules
as a reference during the Design and Implementation processes
Distribute the Business Rules Implementation Strategy as follows:
to all project participants that perform Design and Implementation activities
to the quality auditor, who should verify Design and Implemention quality
Back to Top
QUALITY CRITERIA
Do the designers and developers understand the methodology to define business rules?
Do the designers and developers understand which development tool(s) is used to manage business rules?
Back to Top
DS.070 - DEFINE SOA IMPLEMENTATION STRATEGY
In this task, you define how and when your projects services are going to be released. You determine if they are going to be released as one or several groups or
individually and which service should be released first.
An enterprise SOA Implementation Strategy may already exist because of an earlier enterprise-level effort or because it was created in another project. If this case, you
should use this strategy as a starting point.
Related tasks include:
Define Technology Reference Architectures (SOA) (ENV.EA.075)
Define Project Reference Architecture (RA.019)
Refer to the SOA Release Planning Technique for more details.
ACTIVITY
Back to Top
WORK PRODUCT
SOA Implementation Strategy - The SOA Implementation Strategy describes the order and timing for the implementation of project services.
Back to Top
TASK STEPS
Refer to the SOA Release Planning Technique for details on how to perform this task.
Back to Top
APPROACH
Refer to the SOA Release Planning Technique for details on how to perform this task.
Back to Top
Back to Top
System Architect Define the SOA Implementation Strategy. If possible, you may want use a system architect with extensive SOA experience. 100
#TOP #TOP
Back to Top
PREREQUISITES
Prerequisite Usage
Architectures (ENV.EA.075)
If available, use the Technology Reference Architecture for SOA to gather details on the enterprise version of the Technology
Reference Architecture for SOA for guidance on developing the SOA Reference Architecture at the project level.
MoSCoW Improvement List
(RD.045.2)
Use the MoSCoW List to view the priorities of the various elements of the future architecture.
Project Reference Architecture
(RA.019)
Use the Project Reference Architecture to understand the service deployment strategy, if any.
(TA.020)

Back to Top
TECHNIQUES
Technique Comments
Service Definition Use this technique to identify the software package to which the service should belong.
SOA Release Planning Use this technique to define how to perform SOA release planning.
SOA Service Lifecycle Use this technique to understand the SOA service lifecycle.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
DS.080 - DESIGN SOFTWARE COMPONENTS
The purpose of this task is to develop the detailed design for a software component. A software component is an executable module (.exe) that contains a number of
interoperating processes or classes, which work together to perform the high-level functional responsibilities for a major part of the system.
For example, one component for a University Registration System might be the Catalog Manager. The Catalog Manager component provides services to
update, publish, query, print, and maintain the catalog of courses offered by the University. This component would have a well-defined interface that would
be used by other components (such as the Course Registration Manager and Professor components) to access catalog related information while
encapsulating or hiding the inner details of its processing.
The main focus of this task is to design the inner-workings of the component for efficient, accurate processing. Design patterns may be used to improve the run-time
architecture of the component, and its operational interface(s) will also be designed and promoted to ensure proper use of the components functionality.
Information from the Module View that was added to the Architecture Description (created in RD.130) work product during DS.040, Develop Design Architecture
Description, is also used as input to the software component under design. The Module View specifies what behavior the component must perform, the interfaces it must
provide, and the interfaces it will require of other components. Also, data and behavior from the above tasks will be utilized and decomposed into a set of steps that guide
the developer in fulfilling the various use cases in whole or part. This typically takes the form of a simple design document that contains the relevant pieces of the
component design and the dependencies between them.
The standard and recommended notation for completing this task is to use the UML component, class, sequence, and/or state diagrams. This task may also be
accomplished using a non-UML approach that employs other notational or textual techniques including entity-relationship diagrams (ERDs), functional hierarchy charts,
pseudo-code or other descriptions of navigation or control logic, or an interface control document (ICD).
In a commercial off-the-shelf (COTS) application implementation, this task is performed only for those requirements that can only be satisfied through custom-built
components that extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems.
ACTIVITY
DS.080.1
DS.080.2
Back to Top
WORK PRODUCT
Software Component Design - The Software Component Design work product consists of the set of models required to illustrate that the component is independent of
other components and their interfaces, that the component provides all the interfaces it is expected to provide, and the realization of the interfaces and the required
operations are correct.
Typically, this work product would exist as part of the overall Design Model in a repository. In some cases, when it is necessary for sign-off or hand-off to a remote
implementation team, the Software Component Design may be organized, along with other design work products, into a Design Specification (DS.140). Please see the
Develop Design Specification (DS.140) task overview for further information and guidance.
Back to Top
TASK STEPS
1 Collect relevant design
elements from the
None From the Conceptual View of the Architecture Description (RD.130) extract information about all of the classes, use
cases, and functions for which this component is responsible. From the Module View of the Architecture Description
(RD.130).
extract all required interface information about your component.
2 Decompose components. Composite
Structure
The Composite Structure diagram shows the relationships among the parts within a module.
3 Utilize Design Patterns. Design
Patterns
Design Patterns provide guidance for proven ways of solving design problems.
4 Design classes. Class
Diagram
The lowest level component is comprised of classes that realize the behavior required of the module. Each attribute,
operation, and method must be detailed according to the nature of the class (active, passive, semi-active).
5 Define class lifecycle. State
Diagram
Use a State Diagram to design the dynamic behavior for classes with significant state changes during an instances
lifecycle.
6 Design class interactions. Interaction
Diagram
Use an Interaction Diagram, such as the sequence diagram, to explore then specify the behavior needed to
accomplish the interaction.
Back to Top
APPROACH
During Design, you identify and optimize dependencies between software components.
In general, dependencies between the designed components should be minimized wherever possible. Preferably, the dependencies should be with the interface of the
component rather than the component itself. This is done to provide stability between the components often referred to as "loosely coupled". This technique ensures that
the component may be substituted by another component that provides the same interface but a different internal design without affecting the dependent components.
In addition, component interfaces and contents (classes contained within the components that provide the interfaces of the component) are identified and documented.
Collect Relevant Design Elements
In this step, you are working on a specific component. Look to the Module View of the Architecture Description (RD.130/DS.040) to understand the context of your
component with all the other parts of the system and the interfaces you must provide as well as the interfaces you will use from other components. Look to the
Conceptual View in the Architecture Description (RD.130/AN.040) to find design elements that were mapped from the Conceptual View into the Module View. These
elements may include use case realizations, classes, and functions. There may be interaction, state, and activity diagrams that will give you further insight as to the
behavioral and dynamic nature of the elements for your component. Look to the Execution View of the Architecture Description (RD.130/DS.040) to help you understand
the runtime issues to which you must design.
Decompose Component
To fully design the component, you start with all the elements when you focused on the relevant module in the first step. Unfortunately, the word component is overloaded
with lots of different meanings from UML, Systems Design, Architecture Best Practices, and software platform technologies such as Java EE and .Net. Here component
is defined as a modular, replaceable unit that provides well-defined interfaces to the outside of the component whose internal fully encapsulated parts perform the
behavior of the component without outside knowledge.
Arrange the collected classes as parts inside your component. Now consider which classes will perform boundary, control, or entity behavior. This is similar to what
happens when developing classes to realize a Use Cases behavior. This time you are developing classes to realize the behavior of the component. Which class or
classes will be the components delegate to handle its provided interface(s)? Add classes when necessary. Which class or classes will handle the internal flow of control
for the component? To increase cohesion and decrease coupling you may need to add classes that handle the required interfaces.
If you are designing to a specific software platform, such as Java EE, you may need to add interfaces such as a Home, Session Bean, and Entity Bean. You should add
any new classes required by the software platform.
The following component diagram is a simple example of how you can show your static design for the internals of a component:
Utilize Design Patterns
As you work on the internals of your component, various design issues will come up. For instance, you want to make sure that at runtime there is only one instance of a
designated control class created for your component. This is a common problem that the Singleton pattern solves. The boundary class that is the delegate for the
provided interface could use the guidance of the Faade pattern. For each of your design issues see if there is a pattern that already solves the problem. Look up the
pattern and design your classes accordingly.
Design Classes
Once you have all your classes for your component it is time to design the details of each class. This involves the full specification of each attribute to include visibility,
name, data type, multiplicity, (if it is not the default of 1) and any constraints the attribute value must adhere to. Specify each operation to include visibility, name,
parameters, and if necessary return type. Specify a method for each operation by describing pre and post conditions for the operation. Then add a description as to how
the method will get from the pre to the post condition. Some operation methods are very simple and do not need pre and post conditions. For example the getter
operation name():String for the CourseVO class is simply going to return the value of the name attribute so there is not much to say.
Another way to look at a design class is to consider whether they have their own thread of control or not. If instances of a class at runtime initiate method calls to other
objects then the class is considered active. Many time control classes are active. If the classs objects are always invoked by other classes then they are considered
passive objects. Value Object type classes are usually passive. Identifying active objects allows you to consider whether to provide them with their own thread of control
or not. More threading can lead to better performance at the cost of some complexity.
All the associations for your classes must be designed as well. If a method needs to invoke an instance of another class it needs a reference to it. Add attributes to the
class whose data type is the class that needs to be referenced. For example, an instance of the Course Manager class needs to invoke the behavior of one instance of
the Course Class. Add an attribute in the Course Manager class, say courseEntity and make its data type Course. In the case where an association is to-many
instances of the other class you will need to have a reference to a container. For instance, the Course needs to reference many CourseVO objects. Add a
courseDataList attribute with a List or Dictionary for the data type.
Please note, a class should be defined in one and only one place. If several different teams design different versions of the same class your system will be very hard to
maintain and prone to error. If you find that more than one team needs the services of a particular class, place that class and other similar classes into its own package.
Then import the package into your component and reuse the class.
The following is a portion of a class diagram showing attribute and operation details. Normally Value Objects would get defined in their own package and imported into
the Course component as well as other components. But it is here in this example for illustration purposes.
Define Class Lifecycle
Each object at runtime has a lifecycle. It gets allocated at some point and comes into being. The object lives out its life performing its behavior when asked and at some
point it gets de-allocated. Some objects do not have very interesting lives. They are often passive objects that simply perform some method when they are invoked.
These passive objects do not have to remember what has happened in the past nor care about which method might be invoked in the future. For these classes it is not
necessary to understand its states of behavior. But other classes, especially active classes have a more exciting life. These classes provide method responses to an
operation depending on what has already happened according the state of the object at the time the operation was invoked.
You should explore and then document the design behavior of a stateful class using either a state diagram or a two dimensional table showing start states, state
transitions, and end states. As the state diagram develops you will be identifying behavior that must be performed in the different states. Update the class in the class
diagram with that behavior and add an attribute that will keep track of the state of instances of the class at runtime. A private attribute that holds the state of the instance
helps you maintain encapsulation and ensure that the object only performs the correct behavior at the right time in the right state.
Define Class Interactions
In order to realize the provided interface(s) of the component instances of your class will interact at runtime. For the most important interactions use one of the types of
interaction diagrams such as the sequence diagram to specify who invokes whom and in what order. As you detail the sequence diagram, detail out the messages being
sent between the lifelines. Make sure these messages have their counterpart as operations on the class diagram. If not, then add them as operations to the respective
class. Do not forget to add the methods pre and post condition information if the method is complex enough.
Back to Top
Back to Top
Designer Define and maintain the responsibilities, attributes, relationships and special requirements of the classes making sure that
each class fulfills its requirements. Analyze packages within which the classes are maintained. There may be several
designers depending on the size of the project, each of which may be responsible for certain classes and packages assigned
to them. You may want to use an object designer also.
60
Developer Review the design classes in order to assure that they are compatible with the architecture. Design the more complex
packages and classes.
20
System Architect Participate in definition and review of the design classes to gain an understanding of the application and its architecture. 20
Back to Top
PREREQUISITES
DS.080.1
Prerequisite Usage
Reviewed Analysis Model (AN.110) The Analysis Model is used as input for designing the components and interfaces. The Analysis Model is comprised of all of
the Analysis work products. The analysis classes and packages that are part of the Analysis Model are used as a basis to
identify components, subsystems, and layers. The Analysis Model represents a collection of all Analysis work products, as
available, resulting from the following tasks:
These work products are organized by package as defined in the Conceptual View of the Architecture Description (RD.130)
and will vary based on the type and contents of each Analysis Package.
(RD.130/RA.035/AN.040/DS.040)
The Conceptual View, Module View, and Execution View from the Architecture Description must be taken into account to
ensure that the design fits within the architectural framework.
Design and Build Standards (DS.050)
DS.080.2
Prerequisite Usage
Reviewed Analysis Model (AN.110) Updates to the Analysis Model may impact the Software Component Design.
Use Case Model (RA.023) Updates to the Use Case Model may impact the Software Component Design.
(RD.130/RA.035/AN.040/DS.040)
Updates to the Architecture Description, especially the Module View and Execution View, may impact the design of the
components, and therefore must be taken into account.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Back to Top
The Software Component Design is used in the following ways:
by technical reviewers to see if it conforms to the quality criteria as outlined below
by architects to ensure it conforms to their guidelines and that architecturally significant features have not been left out of the design
by designers requiring the interfaces that this component provides to check to make sure the interfaces have not changed and that they are using the interfaces in
the proper manner
by test designers who use the interface information to organize unit and internal integration testing within and among the modules defined for the system
Back to Top
QUALITY CRITERIA
Have proper naming conventions for classes, attributes, data types, operations, parameters, interfaces, parts, and components been used?
Does each class maximize internal cohesion while minimizing external coupling?
Is there a clear execution path from all operations on the provided interfaces through each internal class that accomplishes the post condition of the interfaces
operations?
Does each significant method have clearly defined pre and post conditions as well as a description of how the post condition will be achieved?
Does each method have access to the data it needs to reach its post condition?
Are attributes specified to support the associations between classes to allow object instances to invoke each others methods?
Does each class have a few related responsibilities?. Does every attribute, operation, and method supports those responsibilities?
Does each class have the behavior necessary for its lifecycle?
Are all behaviors on state diagrams accounted for?
Are all behaviors on interaction diagrams accounted for?
Is each class uniquely defined in the system?
Back to Top
DS.090 - DESIGN DATA
The purpose of this task is to create design level details for the data that is required for a component. The Data Analysis (AN.050) for each use-case package is
reviewed, along with the Conceptual and Module Views of the Architecture Description.
The standard and recommended approach and notation for completing this task is to use a UML class diagram. If your project is using a UML approach, the data design
is developed by updating the class diagram for the classes identified in Analysis and by adding additional classes when necessary. Various aspects to be considered for
each design class are: attributes, attribute types, default values, attribute accessibility, attribute visibility, associations, interfaces, states pertaining to the class,
dependencies and implementation of non-functional requirements. If no classes are identified or if your project does not require class diagrams, you do not need to
execute this task.
This task may also be accomplished using a non-UML approach that employs other notational or textual techniques including entity-relationship diagrams (ERDs) or data
tables.
components, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems.
ACTIVITY
DS.090.1
DS.090.2
Back to Top
WORK PRODUCT
Component Data Design - The result of designing the data is captured in a design-level class diagram (or in another, non-UML notation like an ERD) which shows the
design details for each of the attributes and related data access.
implementation team, the Component Data Design may be organized, along with other design work products, into a Design Specification (DS.140). Please see the
Back to Top
TASK STEPS
1 Design entity class
attributes.
Design Class
Diagram
Add attribute types, default values, attribute visibility, attribute accessibility, to entity classes.
2 Design boundary class
attributes.
Design Class
Diagram
For each external interface (i.e., boundary classes), add the attributes and accessor operations to provide
accessibility to the data being viewed.
3 Design controller class
attributes.
Design Class
Diagram
For controller classes, add the attributes to help object(s) maintain stateful transitions.
4 Refine states for classes. Design Class
Diagram
For classes that have significant dynamic behavior, state diagrams should be developed to show how events,
actions, states, and transitions occur.
Back to Top
APPROACH
The language used to describe the classes is the same as the programming language to be used to implement the classes. Attributes and their visibility, parameters,
operations and their visibility, interfaces etc. are very specific to the implementation environment. The way in which the class is to be implemented (for example, file name
and extension) can also be defined in terms of the programming environment.
In order to define attributes of a design class, the attributes of the analysis class are re-used as a starting point. Sometimes, several attributes or even a separate class is
required to support a single attribute of the corresponding analysis class. Relationships between classes are described in the manner in which they will be
implemented (for example, adding any reference attributes in classes). Refine multiplicities, role names, association classes, n-ary associations according to the support
provided by the programming language to be used.
Pseudo code or descriptive language is used to describe the implementation of the operations (algorithm for the methods) of the classes. The responsibility of the analysis
class is used to identify the operations required to be supported by the class. Finally, supplemental requirements that apply to the classes are identified and designed.
Design Entity Class Attributes
Design your persistence classes: the entity classes. The database technology and persistent mechanisms play an important role in shaping the design of entity classes.
This task step is closely related to the task, Develop Database Design (DS.150). An Analysis Entity Class may be decomposed in several Design Entity Classes.
Depending on the persistence mechanism used to persist objects, different approaches are used to transform Analysis Entity Classes into Design Entity Classes. For
instance, Oracle BC4J, Oracle TopLink and EJB each have a different way to support Design Entity Classes. Thus, the Design Entity Classes is very dependent on the
persistence mechanism used to support object persistence.
When the Analysis Entity classes are designed, each attribute is assigned a type, a visibility indicator (+ = public, # = protected, - = public, and ~ = default), a default
value (optional), primary/secondary key, and accessor operations for each public attribute. Here is an example of the type of detail that would be added to the analysis
Entity classes that would transform it into a Design Entity Class diagram:
Design Boundary Class Attributes
The Analysis Boundary Classes pass via a design process and generate several Boundary Design Classes. Any existing user interface prototypes are to be used as
inputs to this step. The user interface boundary classes are specified in terms of the software development tool in which the user interface is to be developed. Depending
on the architecture chosen for the project, the approach for designing boundary classes may differ. For instance, Java application and Java applets may require more
elaborate designs. UIX-based interface may require less boundary class diagrams since most of the boundary classes are generated automatically. JSP and Servlets
may also require a lower amount of classes, etc.
An example of a boundary class is CatalogView in the diagram below:
Design Controller Class Attributes
Controls classes are responsible to coordinating, sequencing, transactions, and control of other objects. Depending on the mechanism chosen to support these classes,
the approach that will be used to transform Analysis Control Classes into Design Control Classes might differ. The Design Control Classes should contain the operations
the control classes will provide to their clients. Design-by-contract should be used to specify the behavior of the methods that implement such operations. Depending on
the technology chosen to support the control classes (for example, BC4J, EJBs, etc.), the design approach for the control classes may also be different.
An example of a controller class is the Drop Course Manager. Notice how the operation signature (including the arguments) is defined at this stage of design.
Refine States for Classes
Refine already existing state diagrams of complex classes and create new ones based on the needs highlighted during the Design process. The State Transition
Diagrams are now updated to reflect modifications (if any) required based on the use case analysis done earlier during the Design process. The state diagrams provide a
rich source of information for defining design-by-contract constraints on the control classes.
An example of a state diagram for the controller class Drop Course Manager is below:
Back to Top
Back to Top
System Architect Participate in definition and review of the Component Data Design to gain an understanding of the application and its
architecture.
20
Developer Review the Component Data Design in order to assure that it is compatible with the architecture. This person is also
responsible for designing the more complex packages and classes.
20
Designer Define and maintain the responsibilities, attributes, relationships and special requirements of the classes making sure that each
class fulfills its requirements. Responsible for the analysis of packages within which the classes are maintained. There may be
several designers depending on the size of the project, each of which may be responsible for certain classes and packages
assigned to them. You may want to use an object designer to fill this role or in addition to this role.
60
Back to Top
PREREQUISITES
DS.090.1
Prerequisite Usage
Reviewed Analysis Model (AN.110) The Analysis Model, including the various class diagrams (entity, boundary and control class diagrams), is used as
input for designing the classes. Also, the State Transition Diagrams will be updated, if necessary. The Analysis Model
is comprised of all of the Analysis work products. The analysis classes and packages that are part of the Analysis
Model are used as a basis to identify components, subsystems, and layers. The Analysis Model represents a
collection of all Analysis work products, as available, resulting from the following tasks:
These work products are organized by package as defined in the Conceptual View of the Architecture Description
(RD.130) and will vary based on the type and contents of each Analysis Package.
(RD.130/RA.035/AN.040/DS.040)
The Conceptual View and the Module View of the Architecture Description must be taken into account to ensure that
the design fits within the given framework.
Validated Functional Prototype (RA.085)
Validated User Interface Standards
Prototype (RA.095)
If there are any existing Functional Prototypes or User Interface Standards Prototypes, these are used as an input to
design Boundary Classes.
DS.090.2
Prerequisite Usage
Reviewed Analysis Model (AN.110) The Analysis Model, including the various class diagrams (entity, boundary and control class diagrams), is used as
input for designing the classes. Also, the State Transition Diagrams will be updated, if necessary. The Analysis Model
is comprised of all of the Analysis work products. The analysis classes and packages that are part of the Analysis
Model are used as a basis to identify components, subsystems, and layers. The Analysis Model represents a
collection of all Analysis work products, as available, resulting from the following tasks:
These work products are organized by package as defined in the Conceptual View of the Architecture Description
(RD.130) and will vary based on the type and contents of each Analysis Package.
(RD.130/RA.035/AN.040/DS.040)
Updates to the Architecture Description may impact the design of the data, and therefore, must be taken into account.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Example Comments
Class Model
Back to Top
The primary audience for these Design-level classes is the developer. If done properly the translation from these models into code should be relatively straight forward. If
one is using a code-generating modeling tool, many of the features that are placed on the Design Model will be directly translated into code.
Back to Top
QUALITY CRITERIA
Are all data requirements covered by the system design?
Is each requirement traceable to a subsystem and then to an element (class, attribute, operation) within that subsystem?
Do all new attributes have visibility, accessibility, attribute type, default values (optional) identified?
Do boundary classes exist for all interfaces outside the system?
Have attributes been designed for controller classes?
Is the persistence mechanism designed for each entity class and for any other data that must persist beyond the life of the application?
Back to Top
DS.100 - DESIGN BEHAVIOR
The purpose of this task is to create a design for each operation that has been assigned to a particular component. The operations defined in the Behavior Analysis
(AN.060) for each use-case package are reviewed and designed by defining the format, sequence, and responsibility required to support the Use Case scenarios.
In addition, design details are added that augment the architectural views to define the components, their interfaces, and the nodes on which they will reside at runtime.
Each operation is refined by adding more details to make it implementable (i.e., name, arguments, data types, and return values, etc.), and the responsibility of each
component interface is designed by describing the process flow and algorithms (if necessary) for each.
For example, if during the Analyze Behavior (AN.060) task, the system operations were identified as:
Query the database using the students id
Calculate the students GPA using the GPA formula business rule
Then the design of those operations would look like this:
1) Operation signature: getStudent (studentID:Integer): StudentRecord
SQL statement: SELECT * FROM Students WHERE StudentId = 12345
Student Record returned:
- Student ID
- Student Name (last, first, mi)
- Address (street, city, state, zip)
- Home Phone
- Major
- Grade points earned
- Status
2) Operation signature: calculateGPA (totGradePointsEarned:int, totCreditHoursAttempted:float): GPA
Calculation: GPA = total amount of grade points earned / total amount of credit hours attempted
Result: A=4 grade points
B=3 grade points
C=2 grade points
D=1 grade point
WF/F=0 grade points
Once the behavior for each operation is designed, the overall functionality is organized into a runtime architecture based on the components responsibility and the
technology being used.
The standard and recommended notation for completing this task is to use a UML class diagram, component diagram, and deployment diagram. If UML is used for this
task you will specify how the required behavior of the system will be realized in the design components for each scenario in your use cases. This process validates that
the data and access models can support the use cases and the Design Models are updated with design elements. This complements and supplements the Analysis
Class Diagram previously defined in the Behavior Analysis (AN.060) work product.
This task may also be accomplished using a non-UML approach that employs other notational or textual techniques including entity-relationship diagrams (ERDs),
pseudo-code or other descriptions of navigation or control logic, functional hierarchy charts, or flowcharts.
Ultimately, the Behavior Design is organized along with the Architecture Description (DS.040), the Software Components Design (DS.080), the Data Design (DS.090), and
the User Interface Design (DS.130) into the Design Specification. The Design Specification is reviewed for defects prior to implementation and as necessary, the defects
are corrected.
ACTIVITY
DS.100.1
DS.100.2
Back to Top
WORK PRODUCT
Component Behavior Design - The behavior design for a component reflects the detailed interaction between the classes and components for each scenario. This
complements and supplements the diagrams and models created in the Analysis Model and the Module view of the Architecture Description (RD.130) to better explain
them.
implementation team, the Component Behavior Design may be organized, along with other design work products, into a Design Specification (DS.140). Please see the
Back to Top
TASK STEPS
1 Organize the
design.
Deployment, Component,
Package Diagrams
Deployment Diagrams describe runtime artifacts and on which nodes they reside.
Component Diagrams provide information about the required and provided interfaces for each component in the
system.
Package Diagrams provide a means to organize the design elements such as subsystems, classes, use case
realizations, and various diagrams.
2 Design the use
cases.
Use Case Realization Take each existing Use Case Specification document and and organize the classes and diagrams that will be used
to realize the use case.
3 Create/refine
Interaction
Diagrams.
Interaction Diagrams Interaction diagrams show the detailed interaction between the design classes. You can use Sequence,
Communication, or Timing diagrams depending on the way you need to understand interactions.
4 Create/refine Class
Diagrams.
Design Class Diagram The Design Class Diagram is simply a class diagram in which the design details of each class, attribute, operation
and association should be implemented.
Back to Top
APPROACH
The goal of this task is to create a complete design structure that includes a package view, deployment view, component view, and any other low-level design artifacts
necessary to move into Construction. You do this by enriching the existing Analysis Model (e.g., activity diagram, sequence diagram, collaboration diagram, etc.), adding
the level of design detail necessary to build the components. Use Case Realization can be used as an organizing principle as you dig into the details of designing each
element of your system. Similar to the Behavior Analysis task (AN.060), we use the Use Case Model (RA.023) and Use Case Specification (RA.024) to transform the
Behavior Analysis into a Component Behavior Design.
Organize the Design
Using the Behavior Analysis (AN.060) and Use Case Specification (RA.024) as a starting point, define the package structure and components being used. Work with the
architect to decide how these components will be organized and work in the runtime environment.
ORGANIZING THE DESIGN WITH PACKAGES
Complex applications usually have several layers to them. Each layer has a number of discrete subsystems or components. Work with the architect to organize your
subsystems into packages. You can use a package diagram like the one below to give a layout of your system design at an aggregate level. The little forks in the diagram
indicate that the package is a subsystem. The dashed lines indicate dependencies among the packages.

For each subsystem / component specify what behavior that design element is responsible for. Often a subsystem is responsible for implementing one or more closely
related use cases. Some components are responsible for implementing the behavior of an entity class to include interfacing with an underlying database management
system. Without specifying all the details major functionality required by the system has been allocated to individual subsystems.
SPECIFY COMPONENT INTERFACES
When your design involves treating your subsystems as components with interfaces, a component diagram can be used to show both the required and provided
interfaces. This is another way to understand the design dependencies among your subsystems. The component diagram below shows how the front-end Enrollment
subsystem interfaces with the Student component via the iStudent interface and the iInvoice interface.
SPECIFY RUNTIME DEPLOYMENT
With systems that have many artifacts deployed across several hardware platforms it is necessary to specify where those artifacts reside and their dependencies. This
helps the designer make decisions about placing behavior on the most capable platform and not to overload one platform with too many responsibilities. The deployment
diagram below shows the placement of executables, java jar files, and the contents of a J2EE container.
Design the Use Cases
The Use Case Specification (RA.024) is comprised of a set of use case details (specifications) for each individual use case. Update the details of each use case to
include design details for a number of scenarios, to better outline the development of classes, components, and structures used to realize the use case.
At this point you have an architecture showing a set of subsystems and their individual responsibilities. In this step you are being very specific about which classes will
implement any given use case. You may have to add more boundary classes as you carefully consider each step of the use case. If the use case is complex with many
alternatives, you may need multiple control classes for those scenarios with one master control class for the whole use case.
For each use case realization a class diagram is created that contains those classes that must be designed to satisfy the behavioral needs of the use case, thus the
subsystem, being realized.
Create/Refine Interaction Diagrams
Refine the Interaction Diagrams created during Analysis. Complex transactions are fully modeled using Interaction Diagrams using sequence or collaboration diagrams.
The exchange of messages among design classes is used to create methods. Unlike the Interactions Diagrams created during Analysis, Design Interaction Diagrams
also take into account message parameters. You should also consider what happens when things go wrong. How will your classes recover from improper data? What will
a class do when it is asked to perform some behavior out of sequence?
Create/Refine Class Diagrams
Take the results of the last step with interaction diagram and update your class diagrams with the proper operation signatures that are the equivalent of the messages in
the interaction diagrams. Carefully review each class as you add operations to ensure that they have the necessary attributes. Check your classes to see if they are
becoming too big. Does each class have a focus? Does each class do a few things well? Or, do you have classes that try to do too much? Check the number of
associations between a specific class and the other classes. The more associations you have the more coupled the class is to other classes. Higher coupling leads to
maintenance problems, and makes your system less flexible.
During this step you will uncover design problems related to coupling, cohesion, and performance. Many of the problems have been solved before by others. Consider
looking for design patterns that may help solve these problems as they come up. After you choose a specific design pattern, modify your class diagram accordingly.
Back to Top
Back to Top
System Architect Participate in definition review of the Component Behavior Design. 20
Developer Participate in definition of the Component Behavior Design. Design the most complex use cases. 20
Designer Responsible for the integrity of use cases as assigned. Ensure that all requirements are met and the diagrams, specifications
and models are clear and precise. You may want to use an object designer to fill this role or in addition to this role.
60
Back to Top
PREREQUISITES
DS.100.1
Prerequisite Usage
Supplemental Requirements (RD.055) The Supplemental Requirements are used as an input to determine any non-functional requirements for a use case.
Use Case Specification (RA.024) The Use Case Specification is used as a starting point for organizing the design of the component.
(RA.055.1)

(MC.050.1)

Reviewed Analysis Model (AN.110) The Analysis Model, especially the Behavior Analysis portions related to the use-case package that the component is
helping to satisfy, are used as input for designing the behavior of the components. The Analysis Model is comprised of all of
(RD.130/RA.035/AN.040/DS.040)
The Conceptual View, Module View, and Execution View of the Architecture Description must be taken into account to
ensure that the design fits within the given framework.
DS.100.2
Prerequisite Usage
Use Case Model (RA.023.2) Any updates to the Use Case Model must be reflected in the Component Behavior Design.
Reviewed Analysis Model (AN.110) The Analysis Model, especially the Behavior Analysis portions related to the use-case package that the component is
helping to satisfy, are used as input for designing the behavior of the components. The Analysis Model is comprised of all of
(RD.130/RA.035/AN.040/DS.040)
Any updates to the Architecture Description may impact the Component Behavior Design, and must therefore be taken into
account.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Example Comments
Class Model
Back to Top
The Component Behavior Design is used in the following ways:
as an input to test design
as input to programmers during construction
to assist in making architectural decisions.
as a verification that the overall design meets the requirements
Distribute the Component Behavior Design as follows:
to the technical reviewer
to the test designer
to the system architect
Back to Top
QUALITY CRITERIA
Do the subsystems balance the coupling of the components with the cohesion within each component?
Are all requirements covered by the system design?
Is each requirement traceable to a subsystem and then to an element (class, attribute, operation) within that subsystem?
Do the classes balance coupling among classes with the cohesion within each class?
Have performance requirements been addressed?
Is error handling addressed at each level of the design subsystem, component, class, operation, method?
Is the persistence mechanism designed for each entity class and for any other data that must persist beyond the life of an application run?
Does the design take into account the startup and shutdown of the application?
How well does the design handle abnormal/unexpected situations?
Back to Top
DS.110 - DESIGN BUSINESS RULES
During this task, you transform the format of the rules from the one used in the rules repository into the format needed for the implementation approach defined in the
Business Rules Implementation Strategy (DS.060). For example, if a specific rules engine, such as ILOG or Oracle Business Rules, is chosen, then the business rules
must be transformed into the format needed for that engine. Depending on the tools used, this transformation may be automatic or manual. You also perform the initial
setup of the rules engine in order to to start implementing business rules (such as, importing fact definitions into Oracle Rules Author).
components, which extend the functionality of the COTS system, or through a business rules engine. Perform this task only when there is a need to gain further
clarification of the business rules represented in the Use Case Specification (RA.024) and Future Process Model (RD.011). Business rules, which can be realized
through standard configuration options, such as the selection of a Match Approval Level (that is, 2, 3, or 4 way matching) for invoices, may not require the additional effort
called for in this task. However, complex business rules, or those realized only through custom-built components, or a business rules engine may require the additional
effort associated with this task.
ACTIVITY
DS.110.1
DS.110.2
Back to Top
WORK PRODUCT
Business Rules Design
Back to Top
TASK STEPS
Component
Description
1 Determine rules design format template and standards.
2 Transform each rule from the Rules Repository from the standard business user format to the needed

3 Design Business Rules Support. Business Rules
Support

Back to Top
APPROACH
Determine Rules Design Format Template and Standards
Review the Business Rules Implementation Strategy (DS.060), and determine the rules design format templates and standards that should be used to transform the
business rules into a format required to implement the rule. The way you format your rules is dependent on the tool you use.
For example, when using a business rules engine such as Oracle Business Rules, every rule is implemented using the format "if [condition] then [actions]". The condition
part activates the rule whenever there is a combination of facts that make the condition part true, and the action part of a rule is executed when the rule fires. For every
rule that is going to be implemented using Oracle Business Rules, you must be able to express it in this format.
Import Fact definitions
#TOP #TOP
Some types of rules engines operate on so-called facts, for which the definitions or model should come from the system(s) calling the rules engine. Therefore, the
application (which might, for example, be a BPEL process or a Java application) asserts these facts to the rules engine, after which the rules engine processes those
facts and returns some result. The facts are or can be compared with specific instances of some classes. Fact definitions can be compared with class definitions.
As an example, Oracle
Business Rules supports two types of fact definitions: XML schemas (XSD) and Java classes. XML schemas are used when using Oracle
Business Rules in a BPEL process, while Java classes can be used in combination with a Java application.
In order for a rules engine to understand the facts that are to be asserted, business rules engines that work this way need to have the fact definitions deployed in the
rule engine. After deploying or importing fact definitions into the rules repository of the engine, those definitions will reflect the Java class or XML schema definitions, and
therefore probably will be technical. For a Business Analyst to understand those definitions, you might need to translate that into business vocabulary. In case of Oracle
Business Rules you can add aliases to facts and their attributes or operations (methods). When implementing business rules, you use those aliases instead of the
technical terms. ILOG has a similar distinction between the Technical Rule Language (TRL) and Business Action Language (BAL). The TRL comes out of the box, but the
BAL needs to be defined and mapped explicitly to the TRL.
Transform the Rules
Transform each rule in the Rules Repository from the standard business user format to the needed implementation format. Transform each business rule using the
design format template and the standards determined. Ensure that during this transformation, the rule is always traceable back to the "human readable" version of the
rule.
Design Business Rules Support
For some business rules, you need additional supporting custom code to validate the rule. During this task, you determine what supporting custom code would be needed
to perform this validation.
The way business rules support is implemented depends on your implementation mechanism. For example, in the case of ADF Business components, you might
recognize generic patterns in business rules, such as, begin date end date comparisons for which you can implement (reusable) so-called registered rules.
If you are using Oracle Business Rules, you might need to add specific functions to the Java or XML fact definitions to support rules, or (as an alternative) add functions in
RL (Rule Language) to the Rules Repository.
Back to Top
Back to Top
Business Analyst Design the business rules. If possible, you may want use a business analyst with extensive business rules experience. 100
Back to Top
PREREQUISITES
DS.110.1
Prerequisite Usage
Business Rules Analysis (AN.070.1) The Business Rules Analysis are being designed in this task.
(DS.060)
This work product defines the strategy for designing the rules.
DS.110.2
Prerequisite Usage
Business Rules Analysis (AN.070.2) Any new or revised business rules are being designed in this task.
(DS.060)
This work product defines the strategy for designing the rules.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
When using ADF Business Components, this white paper provides guidelines how to transform specific types rules to an
When using Oracle Business Rules, the Oracle Business Rules User Guide provides information on how to import fact
definitions into the rule engine, how to add business vocabulary to that, and how to implement rules.
Back to Top
The Business Rules Design is used in the following ways:
to transform the format of the rules from that used in the rules repository to the format described in the Business Rules Implementation Strategy (DS.060)
to describe any additional supporting custom code used to validate the business rules
Distribute the Business Rules Design as follows:
to all project participants that perform design and build of the application
to the quality assuror that should verify design and build quality
Back to Top
QUALITY CRITERIA
Do the designers and developers understand which format the business rules must be stored in?
Do the designers and developers understand when and how additional custom code can be used to create business rules?
Back to Top
DS.120 - DESIGN SERVICES
During this task, you perform the design of the services based on the service analysis (AN.080) and the service definition (AN.085) you have performed, following the
service architecture defined in the Project Reference Architecture (RA.019). In addition, each Service Interface is registered in the Enterprise Repository to allow projects
to discover the changes, and for future reference.
Service Design is responsible for crafting the interface for a service. Although this sounds like a relatively straight forward task, the goal of service design is to come up
with an interface that will maximize reuse while conforming to the demands of the service contract. The Service Interface must be designed with the service consumers
needs in mind, but also with an eye towards the non-functional and service enablement requirements dictated through the services contract. Service design may include
a series of trade-offs where a balanced interface between service consumer and contract are achieved.
The process begins with the service contract which is defined through service definition. The service contract provides most of the information necessary to develop an
interface which is geared towards fulfilling the contract. The second influencing factor of service design is the service consumer. Analysis with respect to how service
consumers (and potential service consumers) will utilize the service must also be considered in order to achieve a balance between maximizing service reusability and
convenience for the service consumers, but also an interface that meets the demands of the contract.
ACTIVITY
DS.120.1
DS.120.2
Back to Top
WORK PRODUCT
Service Design - The Service Design contains a detailed technical design for all service components. This includes a technical design for message formats, business
process rules, data sources, process security, exception handling, service dependency and human workflow. When a physical Enterprise Repository has been
established, a new Service Interface or Service Interface version is created in the Enterprise Repository for each new or modified service.
Back to Top
TASK STEPS
For each service, perform the following steps:
1 Identify known and potential service
consumers.
Identified Service Consumers Refer to the Service Design Technique for a detailed description on how to complete
this and each subsequent task step.
2 Define the Interface Style. Interface Style
3 Define Interface Protocol and
Transport.
Interface Protocol and Transport
4 Model Service Operations. Service Operations
5 Define Message Exchange
Patterns.
Message Exchange Patterns
6 Explore Implementation Paths. Implementation Paths
7 Define Message Structures. Message Structures
8 Cross check against the Service
Architecture.
None
9 Cross check against the Service
Contract.
None
10 Review the Interface Design with
SOA Leadership
Reviewed Interface
#TOP #TOP
11 Develop the Physical Service
Interface.
Physical Interface
12 Publish the Service Interface. Published Interface (in the
Enterprise Repository)

Back to Top
APPROACH
Review the IT Asset Management technique to see what kind of elements should be captured for the Service Interface design.
For each service that has been defined in AN.085, Define Service, a detailed technical design should be provided for the following design components included in the
Module View determined during DS.040, Develop Design Architecture Description. These may be service components such as:
Message Formats - XML definitions for inbound and outbound objects. There could also be other formats besides XML, such as, EDI, flat file, and large binary
data.
Business Process Rules - Component design to meet business process rules. Consider using a rules engine (comes with the application server of third party blaze
advisor). Design a common framework to lookup and invoke the rules engine.
Data Sources - Detailed sequence diagrams for interacting with application APIs, EJB methods, Java class methods, etc.
Process Security - Define configuration details for service security (e.g., App Service JAAS configuration, WS-Security usage). Consider using the Oracle WSM for
policy driven security and management for BPEL process.
Exception Handling - Detailed error processing options and components necessary for error handling. Possible design options include error trapping, editing, and
replay capabilities; detailed service fault definitions. Consider using the database to store the error messages along with the transactional data message. The
design of the error handling service should be a standalone web service.
Service Dependency - Identify other services this service depends on for functionality.
Human Workflow - Design of the human workflow system and interaction with the business process. Include user interface design and page flows.
When doing this, you should follow the service architecture defined in the Project Reference Architecture (RA.019).
In order to provide or consume a Business Service, the involved systems/partners must agree on the interaction pattern with the corresponding business semantics
along with the message binding contracts and policies such as enveloping, addressing, reliability and security profiles for every business service and action pair. The
SOA Project Delivery Service Interoperability Guidelines provide guidelines, patterns and templates to capture all the necessary information related to service
interoperability.
Detailed fault handling and compensation handling should be designed into the model at this stage. Data transformations should be detailed in this task. Typically, data
transformations occur when converting inbound data to a canonical business object that the business process is standardized on, as well as converting the canonical
format to outbound data structures required by destination systems (i.e., applications, B2B partners). A data transformation specifications should provide detailed node-
to-node mappings. Typically, these specifications are defined in spreadsheet format with the following data:
Column Description
Source Node Name Node name in the source object
Source Node Path
Path to node within source object
Source Node Description
Description of node
Source Data Format Definition Data type (that is, char, integer, float, date/time, binary encoded); max length
Mapping Type Straight (no data conversion) - Derived (derived from multiple inbound nodes), Complex (complex mapping logic;
database/table lookups).
Mapping Details Detailed description of mapping logic
When applicable, design in the B2B solution during this task. The B2B solution should address the following:
Trading partner exchange protocols for each partner
Trading partner document protocols for each partner
Trading partner message types for each partner
Trading partner constants for selected protocol
Trading partner end points (https, email, ftp)
Solution design for SLA failures
Trading partner contact information
Refer to the Service Design technique for further guidelines related to this task.
Back to Top
Back to Top
Designer Design the services. If possible, you may want use a designer with extensive SOA experience. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Service Portfolio - Proposed Services
(AN.080)
Service Definition (AN.085)
Your are designing the services based on the analysis and definition documented in these work products.
Executed Policy Implementation
Processes (GV.100)
(optional) when during the governance implementation an Enterprise Repository has been established, the Service Portfolio
typically will be captured in Enterprise Repository.
Project Reference Architecture (RA.019) Your are designing the services based on the service architecture defined in the Project Reference Architecture.
(RD.130/RA.035/AN.040/DS.040)
The Design portion (DS.040) of this work product produces the service contracts on which to base the service design.
Back to Top
TECHNIQUES
Technique Comments
Service Design Use this technique to understand how to perform this task.
Service Architecture Use this technique to understand the service interface and its relation to other parts of the service.
SOA Service Lifecycle Use this technique to understand where this task fits in the overall SOA service lifecycle.
IT Asset Management Use this technique to understand what kind of elements are relevant for service design.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Service Design is used in the following ways:
as a source of format templates to implement services
to understand how each service should be developed, operated and invoked
Distribute the Service Design as follows:
to developers
to the Enterprise's repository of artifacts to ensure availability of design format templates and standards to all interested parties
Back to Top
QUALITY CRITERIA
Back to Top
DS.130 - DESIGN USER INTERFACE
The purpose of this task is to transform the storyboards and wireframes in the User Interface Analysis (AN.090) and specify how they will be implemented. You also
specify the navigation sequences between each of the interfaces in the storyboard(s).
This task is executed for each component that is defined in the Module View of the Architecture Description. However, it is important to weave together a cohesive user
interface to support the functionality defined in the use case package, as a whole.
ACTIVITY
DS.130.1
DS.130.2
Back to Top
WORK PRODUCT
User Interface Design - The User Interface Design consists of a navigation map, and a series of detailed interface specifications.
Back to Top
TASK STEPS
1 Define major
interfaces.
None Use the Use Case Specification, Storyboard, and Boundary Classes to group the necessary data and behavior of the interfaces
into major windows, web pages, or other user interface mechanism.
2 Define interface
navigation.
Navigation
Diagram
The Navigation Diagram shows the structure and allowable flow through the major user interface elements from step one.
3 Design interface. Prototypes
Interface
Specifications
The creation of prototypes, screen shots, or filled-out wireframes is where you capture the details of the user interface design
down to the widget level.
4 Design reports. Report
Prototypes
Report
Specifications
The creation of report prototypes, report layouts, or a report specification definition table may be used to capture the report
design to a detailed level.
5 Define interface
features.
Interface
Specifications
The Interface Specification describes other elements of the interface design (help, undo, window management, etc.) not
captured in the preceding steps.
Back to Top
APPROACH
Define Major Interfaces
The system will be comprised of a small group of important user interface windows and a number of secondary windows, panels, or screens. If your system is to be web
based, then you will have major web pages and minor web pages.
For interface design begin by defining the major windows. These should be in line with the use cases that were defined during the requirements definition and analysis
phases as well as the storyboards defined in the User Interface Analysis (AN.090). Each storyboard consists of a sequence of wireframes. Categorize the wireframes as
essential to the main success of the story or a supporting element of the story. Essential wireframes are always seen by the actor. Supporting elements may or may not
come up during the story.
Combine essential wireframes together into one window if they contain some of the same information. Combine essential wireframes together that serve similar
purposes. These combined wireframes form the basis for your major windows. Name these major windows and adjust the wireframes to accommodate any combinations
of wireframes that have occurred.
Another way of finding major windows is to look at the Boundary classes defined as part the use case realization process. The Boundary classes represent a stand-in for
the user interface for the purpose of defining behavioral interactions among objects with will realize the scenarios of a use case. What information do these Boundary
classes display? What requests do they handle? Compare what you have found in the Boundary classes with the wireframes you have from the storyboards. Use this
comparison to come up with major windows that realize the Boundary classes and the wireframes in the storyboards.
Define Interface Navigation
In this step you describe the sequencing or navigation paths through the major windows of your interface design. This navigation ties all the different storyboards
together. It also provides a view into the realization of use cases with interface sequencing. The navigation must show all the major windows and the paths to get from
one window to other windows. Each path of the navigation is labeled with the user interface element (such as a button, link, or menu item) that causes the system to
transition from one window to another.
Sometimes you have windows that can be reached at any time from just about any other window. In that case call them out as global windows. Show the paths to these
windows without connecting them up to all the other windows when describing interface navigation.
Once you have the interface navigation together, review it for completeness. Do the paths through the navigation cover all the use cases? Can the user navigate from the
general to the specific and back again? Will the user get lost in a sea of windows?
The follow diagram is an example of interface navigation for part of the University Registration System:
Design Interfaces
At this point, each major window has to be designed in detail. To do that, you take the wireframe for each window and replace the high level interface elements with
technology specific elements / window widgets such as text fields, combo boxes, radio buttons, text labels, visual grouping techniques, etc. When laying out each window
keep the following in mind:
Every window has a clear purpose and every element in the window contributes to that purpose.
Data and requests that the user considers to be related should be together, not separated across many interfaces.
If a task has just a few steps than the interface should be simple. More complex tasks may require more complex windows and sub-windows.
Keep in mind what the user is trying to accomplish at each step. Provide the user with what they need without overwhelming them.
If the system changes as a result of a user action, use a visual element to keep the user informed about what is happening.
Presentation of information should be consistent. Similar information presented in different windows should be presenting in a similar way.
Requests for similar action should be done in a similar what across windows. For instance if a cancel request is presented as a button in the lower left corner of
one window, think about other cancel request on other windows being done in the same way.
The tips in the list above are just a few of the many things to consider when designing a user interface.
Once you have a representative prototype show it to the user stakeholders and get their feedback. Make changes and then show it to them again. The following is a
simple window for part of the Sign Up to Teach use case.
Design Reports
All of the formatting for the required reports needs to designed in detail. To do that you will take the wireframe, prototype, or other set of functional requirements for each
report and replace the high level elements with technology specific elements and report specific information such as text fields, headings, columns, labels, and other
output formatting specifications.
Define Interface Features
Once the major elements of the user interface are done, you can focus on other features such as search, undo, browsing, window defaults, preferences, and help.
Search is often a good feature for users giving them a handy way of finding things they are interested in. For instance instead of providing students with a long list
of courses to chose from, provide them with some search criteria they can set. Then give them a list of courses the match the criteria.
Undo is a feature for handling mistakes. Everybody makes mistakes. Consider allowing the users to undo certain work. Be sure to discuss this with users to make
sure it makes sense and to discuss this with the development team because they will have to design it.
Browsing or user navigation is useful when dealing with complex groups of windows. This often involves having a sidebar with folders that can be opened and
closed. The folders often represent major tasks or information groups and the items in those folders allow the user to navigate to a specific location related to the
enclosing task or see the detailed information contained in an information folder.
Window defaults involve positioning, data values, and actions. As a designer you can enhance usability by setting up standard window positions or having the
system remember the last positions of windows set by the user. Users appreciate not having to enter obvious or default data. Present that data to the users first. If
there is a default action or request that user needs to make most often provide that as the first item they see in a list of actions they might have to choose from.
Preferences allow the user to tailor their experience. These preferences are remembered by the system the next time the system runs.
Help is a feature that goes a long way to making difficult or little used elements of the user interface understandable by the user.
Remember, each one of these features adds overhead to the design and programming effort. Work with the project manager and other Design team members to weigh
the balance between adding these features, performance, cost, and schedule.
Back to Top
Back to Top
Designer Define major interfaces, navigation paths and widget details for each storyboard. You may want to use a designer who
specializes in interface design.
100
Ambassador User Provide feedback on the user interface prototypes. *
Back to Top
PREREQUISITES
Prerequisite Usage
Reviewed Analysis Model (AN.110) The Analysis Model, especially the User Interface Analysis (AN.090), is used as input for developing the design of the user
interface to support the functionality described by the use-case package. The Analysis Model is comprised of all of the
Analysis work products. The analysis classes and packages that are part of the Analysis Model are used as a basis to identify
components, subsystems, and layers. The Analysis Model represents a collection of all Analysis work products, as available,
resulting from the following tasks:
User Interface Standards Prototype
(IM.095)
The standards established in the User Interface Standards Prototype must be considered when designing the user interface.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Back to Top
The User Interface Design is used in the following ways:
for review by User Stakeholders to ensure their buy-in to the system
by implementers of the user interface
by designers who build components that interact with users
Distribute the User Interface Design as follows:
to user stakeholders
Back to Top
QUALITY CRITERIA
Do the navigation paths allow all interactions described in use case scenarios to be accomplished?
Are the navigation paths not too long to accomplish an actors goal?
Do the navigation paths and the major windows map back to the storyboards?
Does each major set of paths and their windows have a consistent theme that sets them apart from other path sets?
Have user stakeholders reviewed and agreed to the prototyped interfaces as well as the interface navigation?
Can user stakeholders use the interfaces without help or prompting?
Do the interfaces not slow the users down in the completion of their tasks?
Is the language on each window in the language of the user, i.e., not difficult to understand information technology speak?
Can the user interface recover from user mistakes?
Is the user interface not over designed with lots of extras that are not required by the system?
Back to Top
DS.140 - PREPARE DESIGN SPECIFICATION
The purpose of this task is to assemble all the information that is required to describe the design of a software component into a complete Design Specification, ready for
review. Prior to being passed on to the developer, the Design Specification is reviewed for defects and, as necessary, the defects are corrected.
It is very important to note that executing this task is not a substitute for the individual Design tasks, specifically:
DS.040 Develop Design Architecture Description
DS.080 Design Software Components
DS.090 Design Data
DS.100 Design Behavior
DS.130 Design User Interface
However, this specification task and its work product can serve as a structure for completing the design for each component by providing pointers back into these Design
tasks. The Design Specifications that specify the designs for the set of components required to support the implementation of a use case package, along with the
Analysis Specification for that use case package comprise the detailed design for a use case package.
ACTIVITY
DS.140.1
DS.140.2
Back to Top
WORK PRODUCT
Design Specification - The Design Specification pulls together all design elements for a component into a single document so that they can be easily assessed against
each other, against the design guidelines, and against the requirements.
Back to Top
TASK STEPS
1 Prepare the technical overview by reviewing the technical components necessary to implement the use case
package.
Technical
Overview
The Technical Overview is a textual
overview for the component.
2 List all of the building blocks that are required to design the designated component. Building Block
List
This component is a list of classes,
modules, objects, etc.
3 Draw a block relationship diagram to graphically depict how the component under consideration interfaces to
related components, external systems, and other actors. If available, reference the class diagram prepared
as part of the Software Component Design (DS.080).
Block
Relationship
Diagram
This component is a graphical
depiction of how the component
under consideration interfaces to
related components, external
systems and other actors.
4 Document the design of the screens for the component.
You may reference or include the User interface Design (DS.130) where individual screen designs were
prepared.
Screen
Design(s)
The Screen Design(s) is a list of
screen designs by use case.
5 Identify the sequence of screen navigation for each use case.
You may reference or include the Navigation Diagram from the User Interface Design (DS.130) that
represents the screen navigation for each Use Case Scenario.
Navigation
Logic
This component is a list of screen
navigation scenarios by use case.
6 Design the report layouts for each use case within the component. Report
Design(s)
This component is a list of the report
designs that apply to this
You may reference or include the User Interface Design (DS.130) for the storyboard that represents the
screen navigation for each Use Case Scenario.
component by use case.
7 Define the design details of each attribute - format, length, accessibility, visibility, validation rules, mandatory
or optional, etc. - that is required for each entity or class within the component for each use case. If available,
include the class diagram from the Component Data Design (DS.090),
Data Design
Data Design
Table
Data Sources
Validation
Logic
This component contains a class
diagram for the component or
tables that define the Data Design
Table, Data Sources and Validation
Logic.
8a Define the tables, the attributes and the SQL statements that are necessary to create, read, update, and/or
delete the attributes for each use case from the database. Include the Software Component Design (DS.080).
The focus is on creating the SQL documents for the CRUD processes. If no use cases are available, provide
the SQL for your module here.
SQL Design This component contains the SQL
statements.
8b Prepare the Performance Considerations by defining the design considerations necessary to achieve the data
retrieval and storage requirements for performance. Include performance supplemental requirements as
specified in the Supplemental Requirements (RD.055) work product for service level requirements (i.e., 1
minute response time, etc.).
Performance
Considerations
The Performance Considerations
define the design considerations
necessary to achieve the data
retrieval and storage requirements
for performance.
9a Define the details of each operation (to include pseudo code) required for each entity, module or class within
the component. Refer to the Design Class Diagram within the Component Behavior Design (DS.100), if
available, with a focus specifically on the Operations section for the class. If not available, complete the table
provided in this section of the work product.
Behavior
Design
Function (Operation) Design
9b Define the implementation strategy for each business rule within this component. Refer to the Business Rules
Design (DS.110) to capture the business rules for this component.
Business Rule
Design
This component contains the details
for the business rule design.
10 Design the services between the components and the interfaces with external systems for each Use Case.
Refer to Software Components Design (DS.080) and focus on calling arguments (that is, service signature)
and logic definition.
Document the services that are provided by this component, for each use case. Refer to the Component
Behavior Design (DS.100), if available.
Document the External interface messages (i.e., name, arguments etc.) that are sent or received by this
component for all external systems for each Use Case.
Define the design considerations necessary to achieve the performance requirements for each interface.
Include performance supplemental requirements as specified in the Supplemental Requirements (RD.055)
work product for service level requirements. Include the Software Component Design (DS.080) with a focus
on the interface performance design.
Interface
Design
Service Design
External Interface Design
Performance Considerations
11 The intent of this section is to document the design considerations for the component regarding the non-
functional requirements. Refer to the Supplemental Requirements (RD.055). You may refer to the Software
Component Design (DS.080), if available. Otherwise, use the sections in this work product to record the
design considerations, add additional sections for various Supplemental Requirement types.
Quality of
Service
Design
Considerations
Restart Strategy
Crash Recovery
Security
Performance
12 The intent of this section is to design the physical schema of the database, or changes to the database for this
component. Refer to the Component Data Design (DS.090) and Logical Database Design (DS.150).
Database
Design
Database Diagram, Desired Table
Changes, Table Indexes,
Sequences, Archiving
13 Add to or modify this list as appropriate. Provide additional details where necessary to facilitate the creation of
the installation routines.
Installation
Considerations
This component contains a list of
performance considerations.
14 Review for consistency. Review the design for the specific use case package according to quality guidelines. Design
Specification
None
15 Maintain Issues List Issues List The Issues List is used to track the
resolution of design issues.
Back to Top
APPROACH
The Design Specification can be created for every module or component to be developed. This artifact collects all of the Design work products into a single document and
equates roughly to the technical design document that was used in some older methodologies.
The following illustrates the various tasks where work products might be incorporated into the Design Specification.
The intent of this document is to refine the analysis view and create one of the components required to implement the use case package analyzed during Analyze
Behavior (AN.060). In this task, you add the design level details. Refer to the specific Behavior Analysis (AN.060) to determine the scope and level of design for the
Design Specification.
Provide a Technical Overview
Typically, each design specification is focused on a single component, though it might be appropriate for a single design specification to encompass all of the
components required to implement a use case package. Choose a component and describe the major features of its design. You should specifically link the Design
Specification to the Analysis Specification (AN.100) to which it applies. In this way the combination of the Analysis Specification (stated in Business Terms) and the
Design Specification(s) (stated in System terms) provide the materials that the implementer will need to implement the components.
Describe the Building Blocks
The intent of this section is to list the building blocks that are required to design the designated component. This includes classes, objects, modules, etc. Reference the
Module View of the Architecture Description (RD.130/DS.040) and appropriate Software Component Design (DS.080) to derive the list of classes and their relationships.
Draw Block Relationship Diagram
The purpose of this section is to draw a block relationship diagram to graphically depict how the component under consideration interfaces to related components,
external systems and other actors. If available, reference the Conceptual View and Module View of the Architecture Description (RD.130/AN.040/DS/040) and the class
diagram included in the Component Behavior Design (DS.100) and Software Component Design (DS.080).
Document Screen Designs
In this section, you document the design for the screens for the component. If available, reference or include the User Interface Design (DS.130) for individual screen
designs. Otherwise, attach a screen prototype or insert a diagram that shows the screen design.
Describe Screen Navigation Logic
In this section, you identify the sequence of screen navigation for the component. Reference or include the applicable User Interface Design (DS.130) for this component.
You should provide the navigation flow between screens for the different scenarios in the use cases supported by this component design. There are a variety of
techniques available to show this navigation control, you may simply reference a navigation prototype, or document specific flow between wire frame diagrams, for the
use case to which they apply.
Define Report Layouts
Design the report layouts for each use case within the component. For Applications implementations, you will want to provide a report layout for any custom reports
prioritized in the Reporting Fit Analysis ( MC.090) or other tasks in which you have identified reporting requirements.
Define the Data Design
The intent of this section is to define the design details of each attribute (format, length, accessibility, visibility, validation rules, mandatory or optional, etc.) that is required
for each entity or class within the component. If available, reference or include the class diagram (or other data design model) from the Component Data Design (DS.090)
for this component.
If the class diagram is not available, you may complete the Data Design Table, Data Sources, and Validation logic tables that are provided in the template. Guidance for
completing these tables is included below:
Data Design Table Use this table to identify and define the design details of each attribute for each entity or class required by the component. You should
include format, length, accessibility, visibility, validation rules, mandatory or optional, and any other attributes that you feel are required to provide a detailed
data design.
Data Sources Table Use this table to identify and define the table, columns, and source values that are needed for the individual data elements listed in
the Data Design Table. Refer to the Physical Database Design (IM.040) to identify the existing tables where the above attributes are located.
Validation Logic Table Use this table to identify and define the rules that are necessary to verify the format, length, relationships, etc., of the attributes
listed in the Data Design Table.
Define SQL Design
SQL Statements and performance considerations required to support this component are included in this section of the work product.
Define the tables, the attributes and the SQL statements that are necessary to create, read, update, and/or delete the attributes for each use case from the database.
Include the Software Component Design (DS.080). The focus is on creating the SQL documents for the CRUD processes. If no use cases are available, provide the SQL
for your component here.
Prepare the Performance Considerations by defining the design considerations necessary to achieve the data retrieval and storage requirements for performance.
Include performance supplemental requirements as specified in the Supplemental Requirements (RD.055) work product for service level requirements (i.e., we need to
respond within 1 minute, etc.)
Define Behavioral Design
In this section, you describe the operation (and its operation signature) of each of the design classes required for this component. Define the details of each operation (to
include pseudo code) required for each entity, module or class within the component. Refer to Component Behavior design (DS.100) and the Design Class diagram, with
a focus specifically on the operations section for the class.
Function (Operation) Design In the event that you do not have a class diagram use the table provided in this section.
Business Rule Design The intent of this section is to define the implementation strategy for each business rule that is being implemented by this component. Refer to
the Business Rules Design (DS.110) to capture the business rules for this component.
Define Interface Design
Design the services provided by the component and the interfaces with external systems. Refer to Software Component Design (DS.080) and focus on calling arguments
(i.e., service signature) and logic definition.
If your component is at the level of a service in a using Service-Oriented Architecture, document the services that are provided by this component. Refer to the Service
Design (DS.120) .
Document the external interface messages (i.e., name, arguments, etc.) that are sent or received by this component for all external systems for each use case.
Define the design considerations necessary to achieve the performance requirements for each interface. Include performance supplemental requirements as specified in
the Supplemental Requirements (RD.055) for service-level requirements. Include the Software Component Design (DS.080) with a focus on the interface performance
design. Design the services provided by the component and the interfaces with external systems. Refer to Software Component Design (DS.080) and focus on calling
arguments (i.e., service signature) and logic definition.
If your component is at the level of a service in a using service-oriented architecture, document the services that are provided by this component. Refer to the Service
Design (DS.120).
Document the external interface messages (i.e., name, arguments, etc.) that are sent or received by this component for all external systems for each use case.
Define the design considerations necessary to achieve the performance requirements for each interface. Include performance supplemental requirements as specified in
the Supplemental Requirements (RD.055) for service-level requirements. Include the Software Component Design (DS.080) with a focus on the interface performance
design.
Define Quality of Service (QoS) Design Considerations
The intent of this section is to document the design considerations for the component regarding the non-functional requirements. Refer to the Supplemental Requirements
(RD.055). If no Software Component Design (DS.080) exists then use the sections in this work product to record the design considerations. Add additional sections for
various supplemental requirement types.
Define the DB Physical Scheme
The intent of this section is to design the physical schema of the database, or changes to the database for this component. These component-level database design
elements should ultimately be incorporated into a single Logical Database Design (DS.150).
Define Installation Considerations
Add to or modify this list, as appropriate. Provide additional details where necessary to facilitate the creation of the installation routines for the component.
Review for Consistency
Once you have all the design elements for a use case package in one place you can check to see that all the elements fit together. For instance, are the components
data needs satisfied by the data, SQL, and database design? Are the data types of the classes attributes in line with the data design? Do elements in the user interfaces
align with component behavior and the data in the database? Additionally, use the quality criteria at the end of this document to continue your review for consistency.
Since this document is for a specific use case package, do not forget to review this document in the context of the other Design Specification documents for other use
case packages.
Maintain Issues List
As this document is being put together and even more so during the consistency review, design issues will crop up. These should be captured, noted, and tracked in the
Open and Closed Issues section of the document.
Back to Top
Back to Top
System Architect Ensure that the design specification is consistent with the overall design guidelines and fully captures all design elements
relevant to the chosen use case package. Document open and closed design issues.
70
Designer Review the Design Specification for consistency. You may want to include a designer who specializes in user interface
designing as well.
20
Database Designer Review the Design Specification for consistency. 10
Back to Top
PREREQUISITES
Prerequisite Usage
(RD.055)
The Supplemental Requirements are used as an input to determine any non-functional requirements for a use case.
Use Case Specifications (RA.024) Use the Use Case Specification is used as a starting point for organizing the design of the component.
(RD.130/RA.035/AN.040/DS.040)
The Conceptual View, Module View and Execution View of the Architecture Description are the starting points and must be
taken into account to ensure that the design fits within the given framework.
Design and Build Standards
(DS.050)

Software Component Design
(DS.080)
The Software Component Design for this component contributes directly to the Design Specification.
Component Data Design (DS.090) The Component Data Design for this component contributes directly to the Design Specification.
Component Behavior Design
(DS.100)
The Component Behavior Design for this component contributes directly to the Design Specification.
User Interface Design (DS.130) The User Interface Design for this component contributes directly to the Design Specification.
Back to Top
TEMPLATES AND TOOLS
DS-140_DESIGN_SPECIFICATION.DOC MS Word
Back to Top
The Design Specification is used in the following ways:
to make sure the design meets both the functional and non-functional requirements
to ensure that the design meets the architectures design guidelines
to provide input to implementation of the system as designed
Distribute the Design Specification as follows:
to the system architect for review
to component designers for updates / revisions to their design
to database designers for updates / revisions to their design
to user interface designers for updates / revisions to their design
to the manager for schedule modifications due to design issues that must be addressed.
Back to Top
QUALITY CRITERIA
Does this Design Specification fit in and is it consistent with the overall architecture and all use case packages?
Are all elements of each use case realization accounted for and designed?
Is there any missing behavior? Is all behavior called out for a use case designed?
Can all data required by the user interface be traced through the components to a source in a data store?
Can all behavior required by the user interface be traced into the components that support that interface then to the operations on classes and finally into the
methods for those operations?
Are all scenarios including main success, alternative, and error scenarios accounted for in the design?
Are attribute data types, parameter data types, and operation return data types consistent?
Is duplicate behavior minimized?
Are classes defined once, not several times in different areas of the design?
Can each component be realized through object interaction by their provided interfaces?
Back to Top
DS.150 - DEVELOP DATABASE DESIGN
In this task, you translate the Domain Model (RD.065) into a Logical Database Design. You do this by applying the rules and principles of relational systems design. For
example, in a top down approach, the design of the entity classes is used to create the database. Alternatively, in a bottom up approach, the database is modeled in
parallel with the design of the entity classes.
components, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems. In this task, you design the new
database objects, such as tables, indexes, views and sequences required by the application extensions, and illustrate how the customizations integrate with the existing
applications database schema.
For projects that involve the upgrade of Oracle products, this task is used to review any existing custom database objects including tables, indexes, views and sequences
in order to determine the migration options to the new release.
During a BI project, you enhance the business model already developed into a Logical Database Design model applying the rules and principles of relational star schema
(dimensional) design.
ACTIVITY
DS.150.1
DS.150.2
Back to Top
WORK PRODUCT
Logical Database Design - The Logical Database Design documents the following design elements:
Table, column and view definitions
Primary, unique and foreign key definitions
Column and row level validation rules (check constraints)
Rules for populating specific columns (sequences, derivations)
Back to Top
TASK STEPS
Back to Top
APPROACH
Back to Top
Back to Top
Database Designer Develop all aspects of the data models for the system. If your project includes Business Intelligence and Analytics
implementation, you may need a designer who understands the rules and principles of relational star schema (dimensional)
design.
60
System Architect Participate in the review of the Logical Database Design to gain an understanding of the application and its architecture. 20
Developer Review the Logical Database Design in order to assure that the Design Model is compatible with the Logical Database Design. 20
Back to Top
PREREQUISITES
DS.150.1
Prerequisite Usage
Design Model
Software Component Design (DS.080)
Component Data Design (DS.090)
Component Behavior Design (DS.100)
Business Rule Design (DS.110)
Service Design (DS.120)
User Interface Design (DS.130)
Design Specification (DS.140)
The Logical Database Design depends on the persistent classes.
DS.150.2
Prerequisite Usage
Logical Database Design (DS.150.1) The initial Logical Database Design serves as input to the final version.
Architecture Description (RD.130) Any updates to the Architecture Description may impact the Logical Database Design, and therefore must be taken into
account.
Design Model
Software Component Design
(DS.080)
Component Behavior Design
(DS.100)
Updates and additions to the enterprise classes must be reflected in the final Logical Database Design.
Back to Top
TEMPLATES AND TOOLS
DS-150_LOGICAL_DATABASE_DESIGN.DOC MS WORD
Tool Comments
Example Comments
Logical Database Design
For further detail on relational database design principles, refer to the Oracle
JHeadstart User Guide.

Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
DS.160 - REVIEW DESIGN MODEL
The purpose of the task is to review the Design Model along with the Logical Database Design (DS.150) in order to discover defects before they are implemented. In
OUM, the Design Model refers to the complete collection of artifacts that are developed to design the software to be developed. Once work on these materials for a given
iteration has been completed, and the materials are ready for review, a team consisting of users, designers, developers, and architects review the Design Model, and
suggest changes as needed.
Formal peer review activities should be used to review the Design Model. Any defects discovered in the elements of the Design Model are recorded. As necessary, these
defects may require attention and therefore, another review.
This task should be executed during each iteration in which Design work is completed. This typically means that the task will be executed in later iterations of Elaboration
and in most iterations of Construction.
In an offshore project, this task is essential, since in many of the cases the implementation may be performed in an offshore environment by a different team of people
who created the various components of the Design Model. By discovering defects before the Design Model is shipped for implementation will reduce rework and improve
the productivity of the project as a whole.
ACTIVITY
DS.160.1
DS.160.2
Back to Top
WORK PRODUCT
Reviewed Design Model - The complete collection of artifacts to design the software to be developed is included in the Design Model that goes through a review. The
Reviewed Design Model contains the Design components updated as determined by the review, including the list of defects found in the model. The Design Model
represents a collection of all Design work products, as available, resulting from the following tasks:
Design Business Rules (DS.110)
Design Services (DS.120)
Prepare Design Specification (DS.140)
Back to Top
TASK STEPS
3 Prioritize changes Prioritized Defects The Prioritized Defects is the same list of defects, including priorities, indicating the importance of the changes.
Back to Top
APPROACH
When the design work has been completed for a given iteration, the materials should be assembled for review. A team consisting of users, designers, developers, and
architects reviews the Design Model, and suggest changes as needed. There are a variety of approaches that can be used to accomplish this sort of review. Formal and
peer review activities should be used to review the Design Model. Reviewers are typically given a period of time to look through the materials in advance of a call for
review comments. The review team may either be assembled in one place or review comments submitted via electronics means.
As a result of this review, defects may be found and change requests triggered. There are many different types of change that may be required. Some changes can
affect scope and therefore require that formal change requests be completed. Other changes do not affect scope and some may be very minor in nature. These should
be handled through use of a MoSCoW List.
Different types of review techniques can be used. However, OUM recommends the use of inspections to improve the quality of the
Design work products (Design Model) and the productivity of the inspectors. OUM provides specific guidelines about how to review
UML diagrams and Design Models through techniques and checklists.
Back to Top
Back to Top
Database Designer Participate in the review of the Design Model. 25
Developer Review the Design Model in order to assure that the Design Model is compatible with the database design. 25
System Architect Review the Design Model from the point of view of the application architecture. 25
Quality Manager Participate in the review of the Design Model to gain an understanding of the application and its architecture. 25
Ambassador User Participate in the review of the Design Model. *
Back to Top
PREREQUISITES
Prerequisite Usage
Design and Build Standards
(DS.050)

(RD.130/RA.035/AN.040/DS.040)
The Module View of the Architecture Description depicts how subsystems are decomposed into components, and components are
assigned to layers in accordance with their use-dependencies. The Execution View of the Architecture Description describes the
structure of system in terms of runtime platform elements.
Design Model The Design Model represents a collection of all Design work products, as available, resulting from the following tasks:
Software Component Design (DS.080)
Component Behavior Design (DS.100)
Back to Top
TECHNIQUES
Technique Comments
Review and Inspection (Peer
Review)
This technique provides guidance in peer reviews. You should use the standard work product template from this task with the
guidance in this technique when UML diagrams are a part of your project.
Back to Top
TEMPLATES AND TOOLS
REVIEW_RESULTS.DOC
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
[IM] IMPLEMENTATION
Through a number of steps, mostly iterative, the final application is developed within the Implementation process. The results from the Design process are used to
implement the system in terms of source code for components, scripts, executables etc. During this process, developers also implement and perform testing on software
components.
Implementation is the main focus of the Construction phase, but it starts early in the Inception phase in order to implement the architecture baseline (trial architecture and
prototype). During Transition, it occurs in order to handle any defects or bugs discovered while testing and releasing the system.
The main work product or output of this process is the final iteration build that is ready to be tested. In addition, the Architecture Description, initially developed in the
Business Requirements process and enhanced in the Requirements Analysis , Analysis and Design processes, is also enriched with the Implementation View to create
the Architectural Implementation.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Depending on your project (e.g., large, complex, etc.), the project manager may designate an Implementation team leader and/or team leaders for the various prototypes
being built or even team leaders for development teams. If the project manager designates team leaders, they are responsible for leading their team and reviewing the
work products produced by their team. The team leader plans, directs, and monitors the day-to-day work of the team. The team leader assigns work packages to the
team members and makes sure they understand the requirements. The team leader is responsible for building team cohesion, motivating the teams, and providing
assistance and encouragement to the team members. Each team leader performs the final quality control and quality assurance for the team by reviewing all work
products. The team leader also signs off on team work completion and quality. Work that is not up to quality standards is returned. Team leaders review work products
from other teams when these work products may impact aspects of the system. The team leader reports the team's progress to the project manager. Refer to Project
Management in OUM for additional information on team leaders.
The process of developing the system is iterative. The Implementation process starts off with a Conceptual Prototype (IM.005). This is a mockup prototype that contains
the functional requirements known at this time, and is done as early as possible in the Inception phase. How the prototype is made depends on the tools you have
available, but it may be as simple as using flip charts, whiteboards or presentations. It is important to get a first cut verification on the developers' understanding of the
requirements demonstrating what the screens/pages may contain when developed. There might very well be known requirements with lower priorities that have not been
prototyped, because the end of the timebox is reached before the completion of these requirements. The prototype is used as a communication means between the
Ambassador Users and Developers to determine any further requirements and verify the existing requirements for the development of the new application. Through the
prototype, the Ambassador Users can verify the requirements and easily identify shortcomings/misunderstandings.
The process continues with two new prototypes, the Functional Prototype (IM.010), and the User Interface Standards Prototype (IM.085). The main purpose of the
Functional Prototype is to communicate the functional requirements between the ambassador users and developers. In most situations, the feedback from the
Conceptual Prototype leads to updates in both requirements and design, and gives a new starting point for the Functional Prototype. This prototype is delivered towards
the end of each iteration in the Elaboration phase, and if possible is preferably a fully generated prototype containing the functional requirements known at the time based
on the decisions made during the workshops.
The main purpose of the User Interface Standards Prototype is to agree how the new application should look in general terms, and what kind of general features should
be used. The User Interface Standards Prototype is validated by the ambassador users, and other participants that are familiar with corporate standards. The result of the
prototype should feed into the projects Design and Build Standards (DS.050).
The next task is another prototype, the Architectural Foundation (IM.020). This task should start as early as possible during the Elaboration phase. The Architectural
Foundation has a different focus than the previous ones, namely to address architectural design decisions. What is prototyped depends on the type of system that should
be built, and where the architectural challenges may be found. However, the prototype usually takes the form of ideas on how the major components should be built. It
may also be used to test the integration of technical products and services to be used for the system. The purpose of the prototype is to mitigate technological risks that
may be encountered. The biggest technological risks are inherent in how the components of a design fit together rather than in the components themselves. The
prototype is discussed with the key client representatives, and the outcome of this discussion provides the input for the Construction phase. The outcome can be to add
new requirements, to add more detail, or may even result in changing the existing requirements or tools and technologies to be used.
When moving into the Construction phase, the system is developed through a number of predefined iterations. We start with updating the Architecture Description that
was last updated in the Design process (DS.040) with the implementation view, also called the code view. The code architecture view contains files and directories.
Modules and interfaces from the module view are partitioned into source files in a particular programming language. The source files are organized into directories. This
document will be updated throughout the process whenever necessary. When the Architectural Implementation has been defined, you start planning the system
integrations required by the current iteration as a sequence of builds. This is the planning part of the Integrate Services (IM.080) task.
During the Implement Database (IM.040) task, the physical database is produced based on the Logical Database Design that was created in the Design process
(DS.150). During the Implement Components (IM.050) task, the actual components of the application are built. A component is the physical packaging of model
elements, such as design classes created in the Design process. Components have a trace relationship to the model elements they implement. Some standard types of
components include executables, files containing source code, library etc. This task is immediately followed by the Perform Component Review (IM.060) task where the
components are unit tested, and a peer-review is performed, and where the main purpose is to discover errors in the components.
When the components are complete for a build, they are integrated into the logical assembly of components (IM.070) to which they belong. A logical assembly, can
consist of components, services, interfaces, business rules and other logical assemblies of components from previous builds. An implementation logical assembly is
manifested by a packaging mechanism in the Implementation environment, for example, a package in java. This task ensures that the role and requirements of a logical
assembly (use cases and scenarios) are identified as part of the iteration and correctly implemented.
Finally, all the components and services are integrated into the build of the system that should be delivered as part of an iteration (IM.080). This activity focuses on
creating an integration build plan describing all the (smaller) builds required in an iteration including the services (for example, middleware, system services). Each build
then expands upwards to the application-specific layers and is integrated according to plan. For each build, the functionality that should be implemented and the parts of
the implementation model that will be affected are described. The system integrator selects the right versions of the code (corresponding to the components and services
within the iteration), compiles them and puts them together. Software should be built incrementally in manageable steps so that each step yields small integration or test
problems. The executable version of the software is then subject to integration tests.
How you define your implementation iterations, and how intertwined the process will be with the other processes (RD, RA, AN and DS) depends mainly on the size of the
system to be built, the complexity of the application, and the kind and number of skilled resources available (both for the client and developer organizations). Iterations
can roughly be defined as either growing, or additional. A growing approach focuses on delivering the same components through a number of iterations, with each
iteration providing more detail and refinements to each component. An additional approach focuses on adding different (new) components for each iteration. Most often
you will use a combination of the two approaches, but with one approach providing the main focus, or one main focus per business use case.
What main approach you choose again depends on the project situation. For example, for very complex or completely new (uncertain) business areas, it may be difficult
to use the additional approach as you need some iterations to explore and investigate before you find the final solution. On the other hand, for simple business areas
where the requirements are clear and unambiguous, the additional approach can be used with success. It is likely, that the more the growing approach is used, the more
intertwined the Implementation process will be with the other processes as the nature of that type of iterations is to get feedback on both requirements, analysis and
design, which then again should be reflected in the other processes. In that situation, all the new/changed requirements must be evaluated and given MoSCoW priorities
so that it can be brought into the new development iteration. At the end of the next incremental iteration, the ambassador user again verifies whether the accepted
changes have been included, and also verifies whether the requirements are complete and correct. Naturally, this does not go on indefinitely. The number of iterations
must be decided up front, and there should not be too many to ensure that the reviewers keep focused to find gaps and inconsistencies as soon as possible.
Before choosing which approach to use, you should also be aware that the additional approach is nothing else than a number of mini-waterfall cycles, as you will not
refine the same components, just build smaller bits before releasing them. This means that if you use this approach partly or fully, you will not have the possibility to
incorporate changes to already developed components as part of the implementation process.
Within each iteration, the developers develop components according to the given MoSCoW priorities. The developer has a certain amount of time (a timebox) to deliver
the next version. It is therefore vital that the priorities are properly managed as there is usually not enough time to develop all functionality. Ambassador Users tend to
classify everything as a Must have, which results in an impossible job for the developers as they cannot actually prioritize their job. This may result in the undesired
situation that not all of the Must Have functionality can be developed, while some less important parts have. This principle must be completely understood by the
Ambassador Users, as well as the developers. The developers must be able to trust the priorities they have been provided.
Provide a fixed set of components, including the priorities for those components to each developer, so that the developer can work as independently as possible during a
set timebox. However, monitor that the effort between each developer is similar in order to prevent one developer struggling to complete the Must have requirements,
while another is already working on the Could have components. Also, make sure that developers do not invent functionality because they think that something would be
really nice for the users.
Back to Top
Supplemental Guide to access all application implementation supplemental information. You can also go directly to the Implementation process supplemental guidance.
Back to Top
Inception Phase
Elaboration Phase
IM.010 Develop Functional Prototype Functional Prototype
IM.020 Develop Architectural Foundation Architectural Foundation
IM.085 Develop User Interface Standards Prototype User Interface Standards Prototype
Construction Phase
IM.050 Implement Components Implemented Components
IM.070 Assemble Components Assembled Components
IM.080 Integrate Services Integrated Services
IM.090 Create Installation Routines Installation Routines
Back to Top
OBJECTIVES
The objectives of the Implementation process are:
Validate the requirements via delivered prototypes and components to refine these work products to optimally meet the business requirements within the set
project timeframe.
Plan iterations, their builds and the system integrations required for each iteration.
Implement the design classes and components through well-written and tested components that meet the functional and non-functional requirements according to
the MoSCoW priorities.
Document the component design in an accessible way, facilitating and supporting future maintenance of the system.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
Specialist
BA Business Analyst Perform services registration. If possible, you may want use a business analyst with extensive SOA architecture experience. Perform
rules implementation. If possible, you may want use a business analyst with extensive business rules experience.
DBA Database Administrator Determine and set up the database schema structure, create and set up database. Preserve database integrity, tune performance, give
advice, control allocation of disk space, monitor space usage, and generate DDL scripts.
DD Database Designer Create physical database design, assist in analyzing column usage, define constraints, create the authorization scheme, specify initial
database configuration, and provide volume estimates.
DES Designer Design graphical interface for the Conceptual Prototype. Ensure that the Functional Prototype is in line with the generic graphical user
interface design.
DV Developer Lead the team responsible for building the Conceptual Prototype. Create the Conceptual Prototype. Lead the team responsible for
building the Functional Prototype. Create the Functional Prototype and ensure that the most useful use cases are prototyped within the
given timeframe. Build the prototypes that make up the Architectural Foundation. Create database objects and database object logic for
both the logical and physical database design. Create database object test scripts and procedures. Test the database objects and the
database object logic. Review Design Model mapping with database. Preserve database integrity, tune performance, give advice,
control allocation of disk space, monitor space usage, and generate DDL scripts. Lead the team of developers and implement the
components. Lead the team of developers and implement the component interfaces and help define subsystem integration constraints.
Lead peer-reviews of the packages. Perform code review on components. A lead application developer may be designated to review the
components from the point of view of design. Create the Installation Routines.
QM Quality Manager Review components from the point of view of testing.
SAD System Administrator Prepare parts of the application environment.
SAN System Analyst Assist in the creation of the graphical interface for the prototypes by providing information about business rules and requirements and
generic rules and requirements.
SA System Architect Participate in Development Environment setup. Lead the development of the prototypes that make up the Architectural Foundation.
Participate in the peer-review of implemented components in order to assure adherence to the architecture. Coordinate the offshore
software developers and the technical activities related to the implementation the defined architecture. Manage issues related to
services integration. Plan and subsequently build the system in each iteration. You may wish to use a system architect who specializes
in system integration. Lead the team responsible for building the User Interface Standards Prototype. Build the User Interface Standards
Prototype.
SA
(IA)
System Architect
(Information Archtiect)
Participate in the peer-review of the database in order to assure adherence to the Information Architecture. Preserve database integrity,
tune performance, give advice, control allocation of disk space, monitor space usage, and generate DDL scripts when offshore
resources are utilized. Preferably, this should be done by a system architect that specializes in Information Architecture.
Client (User)
KEY Ambassador User Assist in interpreting requirements, and provide input to the creation of the prototypes, including interpretation of relevant business rules.
Validate the prototypes that make up the Architectural Foundation and provide information about existing system. Assist in finding
existing graphical user interface rules and provide information for setting up a set of suggested rules.
CSM Client Staff Member Ensure that physical resources are in place in time, and that proper software licenses are obtained.
Back to Top
The critical success factors of the Analysis process also apply to the Implementation process. Additional critical success factors are:
A Well Thought Out Build and Iteration Plan: It is important, up front, to determine the number of iterations through which the system should be delivered in the
Construction phase. It must be clear what kind of approach should be used (growing, additional, or a combination), and which requirements are included in each
iteration. If the system to develop is large, you may want to split the build into a number of partitions that each go through a number of iterations. For each
iteration, a build plan should be created. It is recommended to build the iteration through a number of smaller manageable builds.
Good Understanding of Prioritizing/Timeboxing Principle by Both Developers and Users: The users that determine the priorities must understand the
MoSCoW principle and the effect of setting priorities. It is important that they understand that there is a large risk of an undesired effect if they prioritize too much
as Must have, as the developer will not know what functionality is the most critical, and may therefore start with developing less critical components. On the other
hand, the developer must understand the importance of developing according to the given priorities. If the developer sees dependencies/links with lesser
prioritized requirements, this should be flagged.
Visible Dependencies: For each change or new requirement that may come up during this process, it is important to determine the impact of the change. This
task is made easier by keeping visible dependencies, from the lowest level, all the way up to the Use Case Model.
Adequate Developers Skills (Tools, etc.): The skills of the development team are especially critical in this process. OUM focuses on keeping the same resources
throughout the life cycle of the project. Therefore, these resources need a combined set of skills so that they can take on different roles, as they become
appropriate for each phase and process. OUM is new to many developers who may feel uncomfortable without the structures and procedures of a traditional
(waterfall) development approach. Developers need to deliver quickly, meeting fixed deadlines, often from minimal requirements. Because a OUM project is
focused on quick delivery, there is normally no time for training on the job. If there are inexperienced OUM participants on the project, there should be at least one
experienced practitioner (who is not on the critical path) coaching. It is also important that the developers know the capabilities and limitations of the available
technology.
Clear Focus on Delivering Quality Solutions at Each Iteration in Order to Maintain the Confidence of the User Community: When delivering small builds in
iterations, using timeboxes, there is a strong focus on delivering quickly, and it is tempting to make short cuts just to be able to deliver. Keeping focus on delivering
quality solutions throughout the process, and in particular during the peer-reviews prevents an "I'll fix that later" mentality.
Back to Top
IM.005 - DEVELOP CONCEPTUAL PROTOTYPE
In this task, you create the Conceptual Prototype. The purpose of this prototype is to visually show the users your understanding of an agreed set of requirements.
Typically, you should not only visualize your understanding of how the flow should be from one screen to the next, but also verify what kind of data should be input,
viewed and changed by a user on a screen. You do this by creating a prototype that shows a proposed layout and execution flow reflecting these requirements. This is a
mockup prototype and is usually created using low-fidelity tools such as sketches on whiteboards or flip charts representing general ideas behind the user interface but
not the details. Not all requirements can easily be prototyped through a proposed layout, for example batch programs or interfaces. However, these often can be
successfully prototyped for example through flow diagrams.
This task can also be be used for prototyping the reports. This could be marking up an existing report, or anything that the user can see. For a phone-based system, this
may be a voice recognition script. Any type of user interface; audible, graphical or textual can be prototype in this task.
This task should be timeboxed. It is very important to provide users and the Implementation team the same context to determine any further requirements and verify the
existing requirements for the development of the new application.
In a commercial off-the-shelf (COTS) requirements-driven application implementation, this task is generally performed only when there is a need to gain further
clarification of the business requirements represented in the use cases. This typically applies to those requirements that can only be satisfied through architecturally-
significant, extensive and/or complex custom-built components, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or
legacy systems.
This task is not normally performed in a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach, which seeks to minimize
custom extensions by promoting leading practice use of standard functionality. Therefore, this task is not included in the pre-defined Solution-Driven Application
Implementation view Work Breakdown Structure (WBS). However, if your solution-driven application implementation includes architecturally-significant custom
extensions, you should consider including this task in your project.
ACTIVITY
IM.005.1
IM.005.2
Back to Top
WORK PRODUCT
Conceptual Prototype - The Conceptual Prototype is also known as a mockup-prototype, an abstract prototype or a paper prototype. It is comprised of a series of wire
frames/sketches of screens via which the user will interact with the system and the execution flow within, and between such screens (story boards). For programs that will
not be implemented through screens, the prototype only shows the execution flow. This includes report prototypes that can be marking up an existing report, or anything
that the user can see. For a phone-based system, this may be a voice recognition script. Any type of user interface; audible, graphical or textual. This prototype may
consist of presentation slides, flip chart sheets or whiteboards illustrating how the layout will work. It should also highlight the main navigational methods necessary for
the system. Activity diagrams may also be used to demonstrate the flow. The Conceptual Prototype is validated in the Validate Conceptual Prototype task (RA.030).
Back to Top
TASK STEPS
1 Analyze the existing systems to which the end users are accustomed in order to understand
their habits and possible difficulties.
None None
2 Optionally, look for existing organizational guidelines for UI and for corporate identity
recommendations. Do not spend a lot of time on this step unless it will make the prototype
look more familiar to the users. The general look and feel for the new application is
prototyped in the User Interface Standards Prototype (IM.085).
Existing
Guidelines or
Corporate
Identity
Elements
Many companies (for example, Oracle does) have
some graphical elements of Corporate Identity
Elements (such as logos or recommended colors)
that should be used in every system.
3 Review the requirements as determined, and agree on which requirements should be Prioritized This is the list of prioritized requirements that should
#TOP #TOP
prototyped Requirements be prototyped.
4 Prepare the prototype.
For the first iteration of the prototype you would analyze the requirements and make an initial
version of the prototype. Talk through your ideas with the Ambassador Users, and make any
required adjustments. If you are uncertain, also check with the system architect whether to
verify that the prototype looks architectural sound.
For the next iterations, you make agreed adjustments to the previous version of the
prototype.
Conceptual
Prototype
This is the actual prototype that should be validated.
Back to Top
APPROACH
This task duration should receive special attention. It is common that the project team together with the ambassador users spend too much time in detailing screens and
worrying with aesthetical factors. Remember, the purpose of the task is only to make an initial mockup prototype (for the first iteration) or only to make the agreed
adjustments to it (for later iterations), and not to make a "perfect" layout.
There are two aspects that should be covered by the Conceptual Prototype:
1. to understand the workflow within, or between application pages, or for programs with no user interaction, to understand the execution flow (e.g., for batch
programs)
2. to understand the data to be input, viewed or changed by the user in a screen
For the first, storyboarding can be used. A story board shows a series of pages, or execution steps (each page/step drawn as a box), showing how to move from
page/step to another using arrows with an explanation what the arrow represents, such as select, accept, cancel, etc.
For the second, so called wire frames may be used. A wire frame is a page sketch drawn as a grayscale block diagram. It illustrates the blocks of elements of the page,
such as content, functionality, and illustrates the overall navigation. It does not contain pictures and will in not link to anything. It just demonstrates what elements a web
page or application screen will contain and roughly where they might be placed. It does not include visual design.
The purpose of the prototype is to verify our understanding of the requirements. It is recommended to produce a prototype for each use case (in priority order) to verify the
following:
What data elements are required to complete a use case. For each page that should represent the use case, show the data elements, single or multi-record,
mandatory, size, data type, etc.
The use case scenarios: What happens when the user walks through the main success scenario, and the other scenarios, and what happens when the user
selects cancel, reset, copy and other options?
Use low-technology tools for this prototype; possibly even a whiteborad or slide presentation. Low technology tools are simpler and often quicker to operate and users can
often show their ideas using the same tools. In addition, the richness of details available in high-technology tools can be distracting and encourage too much detail too
much early in the process. High-technology tools may provide the false impression that HTML is easy and therefore, developing the system will be easy. Finally, because
the architecture has not yet been defined, the high-technology tools may use a visual framework that could add some undesired constraints to the UI.
It is also important to think about how you will walk through the prototype before determining the tool you will use and whether you plan to make changes to the prototype
during the walkthrough workshop. The objective for the prototype is to be able to produce the prototype quickly, to easily make changes to it, and that it is easy to
understand for an average user. If the audience is large, a power point presentation can be useful to demonstrate screen layout. It may also be used to produce
storyboarding diagrams. However, if you are experienced in using Activity Diagrams, then you may use this to represent the execution flow.
For small audiences, whiteboards or post-its can be very powerful. Use different colors to represent different elements. If you are using a whiteboard, use a digital camera
for capturing the diagrams. There is software available that automatically improves the images if necessary. Although we recommend not showing HTML at this point, for
clients that are not used to web interfaces (or other types of UI), it may be useful to show pages from other systems to provide a general overview.
If you only have a small user community, and only a small set of requirements that need to be prototyped, you may decide to combine this prototype and the Validate
Conceptual Prototype (RA.030) tasks. If you decide to do so, it is recommended that you still produce an initial version of the prototype prior to the workshop so that you
have a starting point to walk through in the workshop. But, from that point on, you make the adjustments to the prototype during the workshop until it is agreed upon. You
may also choose such an approach in larger projects, by using a number of smaller working groups working on a small set of requirements. In this situation you should be
aware that you would often need to perform a final validation or presentation to a larger user community. However, if you choose this approach, you have to be even
more aware about the time available for the task, as making the changes during the workshop might be quite time consuming.
Gain approval for the Conceptual Prototype. In some situations, it may be necessary to gather a big group and have a discussion in order to gain approval. In other
situations, approval is as simple as showing the sketches to one ambassador user. Be sure to receive an approval that is accepted by the other users.
Back to Top
Back to Top
Developer Lead the team responsible for building the Conceptual Prototype. Create the Conceptual Prototype.
If an Implementation (or other) team leader has been designated, 20% of this time would be allocated to this individual,
leaving 60% allocated to the developer. The team leader would then lead the team responsible for building the
Conceptual Prototype.
80
System Analyst Assist in the creation of the graphical interface by providing information about business rules and requirements. 20
Ambassador User Assist in interpreting requirements, and provide input to the creation of the prototype, including interpretation of relevant
business rules.
*
Back to Top
PREREQUISITES
Prerequisite Usage
System Context Diagram
(RD.005)
High-Level Business
Descriptions (RD.020)
(RD.055)
(RA.015)
Candidate Business Rules
(RA.027)
These work products determine the functional parts of the Conceptual Prototype.
MoSCoW List (RD.045.1) The MoSCoW List helps focus on the most important requirements that should be included on the Conceptual Prototype.
Back to Top
TEMPLATES AND TOOLS
The following supplies may prove useful:
whiteboard
flip chart
post-its of different colors
power point presentations
Avoid high-tech tools at this time - see the Approach section.
Back to Top
The Conceptual Prototype is used in the following ways:
as input to the task to validate the Conceptual Prototype
Distribute the Conceptual Prototype as follows:
to the workshop team
Back to Top
QUALITY CRITERIA
Does the prototype show the requirements that were agreed upon should be prototyped?
Does the model provide a high-level view of the layout for the relevant screens?
Does it represent the general ideas behind the layout for the screens, and not the exact details?
Does the prototype show not only screen wire frames but also execution flow details?
Back to Top
IM.007 - PREPARE DEVELOPMENT ENVIRONMENT
In this task, you create the Development Environment that you will need during the development. In most cases it will be required to define and set up the following:
development directory structure
modeling software
development software
unit testing tools
operating system
physical development database
configuration management
This task should be performed as early as possible in your project, but at the latest early in the Elaboration phase, as you will need the environment for the creation of
your Functional Prototype (IM.010). You also need to consider how to do version control in your project, as you continuously will deliver a new versions of your
application components.
For each iteration, it is necessary to revise your development environment to reflect the agreed on changes from the previous iteration.
In a commercial off-the-shelf (COTS) application implementation, this task is performed only when there are requirements that can only be satisfied through custom-built
ACTIVITY
IM.007.1
IM.007.2
Back to Top
WORK PRODUCT
Development Environment - The Development Environment work product is a working environment that includes all servers, existing applications, infrastructure,
development tools, configuration and testing tools required to develop and test application components. It should address the following:
available disk space
development directory structure
modeling and development tools
unit testing tools
physical development database
configuration management tools
tablespace requirements for the Oracle RDBMS user accounts
a checklist for verifying the installation and configuration of the system
Back to Top
TASK STEPS
1 Review Architecture Requirements and Strategy (TA.020) to
understand the strategy for deployment of project environments
in general, and the Development Environment in particular.
None None
2 Determine which development tools are required for
development.
Environment -
Development
Tools
This component describes what development tools should be used for
development, including version information and configuration of those tools.
3 Determine which unit testing tools and other automated
development tools that will be used during development (if any).
Environment -
Development
This component describes what testing and other software tools that are
required to support the development activities of the project. This is including
and Testing
Tools
version information and configuration of those tools.
4 Review the Configuration Management Tools (PJM.CM.020) to
understand what is required for the development environment.
None None
5 Detail the Development Environment Directory Structure Setup. Environment -
Directory
Structure
Setup
This component describes the drives that will be used for development, and the
directory structure.
6 Determine the configuration of all servers within the database,
applications and desktop client tiers.
Environment -
Development
This component describes the configuration for the database tier, applications
tier, and desktop client tier servers in detail. It also describes the configuration
of the hardware platforms on which these server environments execute.
7 Set up the Development Environment with all required
components, configurations and tools.

Back to Top
APPROACH
This task describes procedures either to verify completeness of previously installed environments or to perform the installation of the development environment for the first
time.
The purpose of this work product is to confirm that an adequate Development Environment exists to support development and unit testing.
Installations
The Physical Resource Plan (PJM.IFM.030) prepared early in the project outlines the required systems for the entire project, but you may need to reevaluate the plan and
consider new issues at this time.
Multiple Environments
The Development Environment is typically very volatile since programs are constantly changing and there may be temporary test data. Therefore, the development
environment must be separate from any other testing environment with the exception of unit testing that normally is performed in the development environment.
Interface programs may be developed and tested in the Development Environment or in a separate environment. Interface testing may involve loading large batches of
data and then deleting the data and starting over. If testing the interfaces could disrupt other development activities, create a separate environment, as documented in
Prepare System Test Environments (TE.060).
Detail Development Environment Directory Structure Setup
One of the steps in defining the Initial Development Environment is to define where you want to locate your developed software and the directory structure used. It is
recommended to define a general directory structure, which is to be used by every developer. This makes it easier for another developer to find his/her way if they
change working places, but more important, it is easier for anyone that will perform the configuration for any developer. You will also be less vulnerable for strange
environment-related problems and errors.
Describe the exact directory structure for every development tier, and where everything developed should be placed. Also define any settings that are related to the
chosen directory structure (path variables), and provide exact definitions of how the settings should be defined.
Define Development Database Schema Structure and Setup
Define how you decide to structure your development database. What name(s) will you provide for your database schema. Do you choose to use a new schema for every
iteration, and if so, what will you name the different schemas? Do you use different schemas for different kinds of objects?
This task is very much related to your chosen configuration management system. Make sure that the defined development database schema structures support the
chosen system.
Install Software
Install all the required software for your project. Typically this would be the installation of RDBMS, Oracle JDeveloper, etc. Make certain that the software versions are
certified against each other.
Building the Database
Even though it is not always required, in many cases you need to create a new database for the iteration. Consider the advantages and disadvantages for changing the
existing database. Obviously, if there are major changes to the previous version, you would create a new database, but you might even choose to do so if there only are
minor changes. The advantages of keeping the existing database can be summarized as follows:
The test data that you have entered in previous versions is not lost.
In most cases, the end users think it is frustrating losing the data they have entered in previous iterations. When you keep the database in the development
environment, you will also do so for the end users.
The advantages of creating a new database are:
Old data might be corrupt because certain database checks were not implemented in the previous iterations. This might result in unexpected and undesired side
effects.
It is easier and quicker to create a database from scratch, than it is to modify an existing one.
You are certain that the physical database is consistent with the current Database Design.
Upgrades
Throughout the course of the implementation, you may implement major and minor upgrades of various types of software. The Development Environment may be the first
environment where the upgrade takes place in order to test and update components.
Back to Top
Back to Top
System Administrator Prepare parts of the application environment. 50
Database Administrator Determine and set up the database schema structure, create and set up database. 25
System Architect Participate in environment setup. 25
Client Staff Member Ensure that physical resources are in place in time, and that proper software licenses are obtained. *
Back to Top
PREREQUISITES
Prerequisite Usage
Physical Resource Plan (PJM.IFM.030) The Physical Resource Plan outlines the plan for all computer environments needed to support the implementation, including
the Development Environment.
Procedures (PJM.CM.010)
The Configuration Management Procedures describe how the development will be affected by the configuration management
tools.
Strategy (TA.020)
The Architecture Requirements and Strategy provide disk space requirements, initial hardware and the required operating
system for the Initial Development Environment.
Design and Build Standards (DS.050) The Design and Build Standards provide the developer with the standards and guidelines required for the project.
Logical Database Design (DS.150) The Logical Database Design provides the object definitions required for this task.
(MC.050)
In a commercial off-the-shelf (COTS) application implementation, such as an Oracle E-Business Suite or PeopleSoft
Enterprise implementation, the Application Setup Documents include the required setups to support the to-be business
processes.
Back to Top
TEMPLATES AND TOOLS
IM-007_DEVELOPMENT_ENVIRONMENT.DOC MS WORD
Back to Top
The Development Environment is used in the following ways:
to give developers usernames and passwords for the development environment
to document all of your installation and configuration steps
to maintain the integrity and performance of the system, completing a thorough log documenting the changes and updates to the environment
to execute queries against system tables and capture the output to document tablespaces, database files, and users
to use available worksheets and checklists to plan, track, and verify the installation process
to perform any modifications to the development environment
Distribute the Development Environment as follows:
to all developers
Back to Top
QUALITY CRITERIA
Are all required development tools available for development?
Does every developer have access to the database?
Does every developer have access to the development tools and other required tools?
Does every developer have a working place with correct installations?
Do the developers understand how to use the environment and the standards?
Is the development from the previous iteration protected from any new developments within the new iteration?

Back to Top
IM.010 - DEVELOP FUNCTIONAL PROTOTYPE
In this task, a Functional Prototype is created to demonstrate the elements as defined in the Conceptual Prototype. As for the Conceptual Prototype, the purpose of the
prototype is to show the users your understanding of an agreed set of requirements, but now including changes/additions you agreed upon from the Conceptual
Prototype, and if feasible, in actual code. The Functional Prototype can be presented in a prebuilt demonstration environment or some other existing environment. If the
prototype is built in code, this would often be the first version of the prototyped screens that eventually, through iterations, evolve into the final version of the screens.
This task should be timeboxed. It is very important to provide ambassador users and the development team the same context to determine any further requirements and
verify the existing requirements for the development of the new application.
In a commercial off-the-shelf (COTS) requirements-driven application implementation, this task is used to prototype the custom extensions that require development of a
prototype at this stage of the project due to the technical complexity of the extension, or other risks associated with them.
In a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach that leverages pre-defined setup parameters and/or tools for
rapidly establishing a working application environment, this task is used to build functional prototypes of architecturally-significant custom extensions at this stage of the
project.
ACTIVITY
Back to Top
WORK PRODUCT
Functional Prototype - The Functional Prototype demonstrates the user interface functionality without necessarily implementing that functionality. For web-based
applications, the Functional Prototype shows screens via which the users interact with the system and the possible execution flow of such screens.
Back to Top
TASK STEPS
If you produce the prototype in code (i.e., custom-built application or custom extension to a COTS application), you should follow these steps:
1 For the first iteration of the Functional Prototype, review the result of the Validated
Conceptual Prototype (RA.030). The Functional Prototype should include prioritized agreed
changes and additions to the Conceptual Prototype.
If this is the second iteration (or later) of the prototype, review the previous Validated
Functional Prototype as this should include prioritized agreed changes and additions to the
Prototype.
None None
2 Review the result of the design (use case and class design) and determine how and what
can and should be prototyped.
Prioritized
Prototyping
List
The Prioritized Prototyping List contains a list of
elements that the prototype may include. Each list
element refers to one or more requirements.
3 Review Design and Build Standards, and the User Interface Standards Prototype (IM.085) to
ensure that the prototyped layout will be in line with these, or at a minimum does not
suggest solutions that are contrary to these.
None None
4 Develop the prototype following the Prioritized Prototyping List. Functional
Prototype
The actual prototype
Back to Top
APPROACH
This task is a refinement of the work done in the Conceptual Prototype (IM.005) or of previous iterations of this prototype. Its output is validated in task, Validate
Functional Prototype (RA.085).
If you produce the prototype in code, it is recommended that you make use of code generators whenever possible to perform this task. Using this, you should be able to
create a first version of (parts of) the prototype fairly quickly. Keep on regenerating until manual changes are inevitable.
#TOP #TOP
While creating this prototype, it is important to keep in mind that the main purpose of the prototype still is to communicate your understanding of the requirements to the
user. Therefore, carefully select the use cases to prototype that will provide the most benefit talking it through with the users. If you produce the prototype in code, do not
spend a lot of time implementing complex use cases. On the other hand, it is often the complex use cases that need prototyping the most, and if so, you should include
these in your prototype. But, do not forget that communication is the main purpose, so make short-cuts where it does not harm the understanding, and think about using
other means than code, or support the code with supplemental means, such as flow diagrams, drawings and so on.
Consider the similarity between different use cases. Can you prototype one use case, and use it as an example for other use cases as well? If so, only prototype one of
these use cases, but during the Validation task, verify all the use cases with an explanation of your understanding of the differences. It is important to keep the effort to
product the prototype within the given timebox, and that you get as much as possible ready to validate as many requirements as you can.
Other areas that especially need prototyping are the areas where the requirements are vague, often because the users themselves are uncertain. If this is the situation,
the prototype has an additional purpose, namely to help the users clarifying their own requirements, or to help them form ideas on how the requirement should be. If this
is the case, the first version of the prototype should be thin, but powerful. That is, you should not spend too much time creating the prototype by including lots of details
and specialties. A simple initial version of a screen is often the most powerful. If you have special ideas and suggestions, note these, and talk them through during the
validation session before you include them in the prototype. However, if you have access to an ambassador user while doing the prototype (as is preferred), you could
talk through various ideas, and agree upon what should be prototyped. Be careful though, so that you keep the effort within the given timeframe. It is easy to be caught in
the moment when you both come up with new ideas and changes.
In secondary iterations, only prototype the areas where there still are uncertainties, or use cases that have not yet been prototyped but where it seems necessary. During
the validation of the previous prototype, you have agreed upon areas that require changes. Some of these will require an updated prototype, while others are so obvious
that it will be a waste of effort to update that part of the prototype. You must communicate this to the user, so that there will be no misunderstandings about this.
Back to Top
Back to Top
This task involves the following project roles when the Functional Prototype being validated is built with custom software (e.g., custom application code and/or custom
extension of a COTS product):
Developer Lead the team responsible for building the Functional Prototype. Create Functional Prototype and ensure that the most useful
use cases are prototyped within the given timeframe.
If an Implementation (or other) team leader has been designated, 20% of this time would be allocated to this individual, leaving
60% allocated to the developer. The team leader would then lead the team responsible for building the Functional Prototype
and ensure that the most useful use cases are prototyped within the given timeframe.
80
System Analyst Assist in the creation of the graphical interface by providing information about business rules and requirements. 20
Ambassador User Assist in interpreting requirements, and provide input to the creation of the prototype, including interpretation of relevant
business rules.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Current Business Baseline (RD.034)
Validated Conceptual Prototype (RA.030) The first iteration of this task is a refinement of the work done in the Conceptual Prototype.
Software Component Design (DS.080.1)
Component Data Design (DS.090.1)
Component Behavior Design (DS.100.1) Business
Rules Design (DS.110)
These work products provide the current design.
Validated User Interface Standards Prototype (RA.095)
These work products provide the standards, or the input to the standards (if not yet existing or complete), on
the user interface for the system.
Static Test Data (TE.018.1) In order to show data in the prototypes, test data may be needed.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Getting Started with Unit Testing using
JDeveloper
JDeveloper-Unit-Testing using a framework like JUnit is only effective when integrated in the development process
itself.
Use code generators whenever possible to create this prototype. For J2EE projects, you should consider to use Oracle JHeadstart
that can be used on top of ADF

(Oracle Application Development Framework
) using Oracle JDeveloper
to quickly generate your prototype pages.

Back to Top
The Functional Prototype is used in the following ways:
as input to the task to Validate Functional Prototype (RA.085)
Distribute the Functional Prototype as follows:
to the workshop team
Back to Top
QUALITY CRITERIA
Does the prototype show the requirements that were agreed upon to be prototyped?
Does the prototype include the areas with the highest uncertainties in requirements?
Is the user interface of the prototype in line with agreed user interface standards?
Is it possible to get an understanding of how the use cases finally will work through the prototype?
Back to Top
IM.020 - DEVELOP ARCHITECTURAL FOUNDATION
In this task, you develop the Architectural Foundation by creating prototypes to address architectural design decisions and test the integration of technical products and
services to be used for the system. Architectural design decisions usually takes the form of ideas of how the major components should be built. This is particularly
important in a distributed system / Internet environment. Testing the integration helps in mitigating technological risks that may be encountered by trying out the pieces of
technology to be used in developing the system. The biggest technological risks are inherent in how the components of a design fit together rather than in the
components themselves.
Architectural prototypes should be developed early in the implementation process to address identified architectural risks, so this is usually done during the Elaboration
phase. Such risks could be related to new technology introduced to the team, new technology in general, compatibility issues between systems, and so on. Architectural
prototypes will provide valuable hands-on experience within the risk areas and assist in making adjustments to the design of the architecture.
The prototype is discussed with the key client representatives, and the outcome of this discussion provides the input for the Construction phase. The outcome can be to
add new requirements, to add more detail, or may even result in changing the existing requirements or tools and technologies to be used. Some of the decisions that may
need to be made involve answering questions such as, what will happen if a piece of technology does not work as anticipated and what will happen if two pieces cannot
be connected together.
In a commercial off-the-shelf (COTS) requirements-driven application implementation, the depth to which this task is performed will typically depend on the extent to
which the inclusion of an architecturally-significant custom component (for example, Data Warehouse), or integration with multiple COTS or third-party systems
leveraging Middleware, requires a reassessment of the standard application architecture.
ACTIVITY
Back to Top
WORK PRODUCT
Architectural Foundation - The Architectural Foundation consists of all the architectural prototypes that have been developed to address architectural design decisions
and test the integration of technical products and services to be used for the system.
Back to Top
TASK STEPS
Back to Top
APPROACH
Back to Top
System Architect Lead the development of the prototypes that make up the Architectural Foundation. 40
Developer Build the prototypes that make up the Architectural Foundation. 60
Ambassador User Validate the prototypes that make up the Architectural Foundation and provide information about existing system. *
Back to Top
PREREQUISITES
Prerequisite Usage
Architecture Description (RD.130) The Architecture Description (updated by DS.040) is used to determine which components should be built as part of the prototype.
Back to Top
TEMPLATES AND TOOLS
Back to Top
This section is not available.
Back to Top
QUALITY CRITERIA
Back to Top
IM.040 - IMPLEMENT DATABASE
In this task, you create the physical database to support the application.
components, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems. In this task, you implement the
new database objects, such as tables, indexes, views and sequences required by the application extensions.
ACTIVITY
IM.040.1
IM.040.2
Back to Top
WORK PRODUCT
Implemented Database - This work product defines the physical environment that brings the Logical Database Design into physical existence.
In a commercial off-the-shelf (COTS) application implementation, this work product consists of the custom database object creation scripts required to support approved
application extensions.
Back to Top
TASK STEPS
1 Create Database
Object Authorization
Scheme.
Database Object
Authorization
Scheme
The Database Object Authorization Scheme is used to grant users or user groups access to database objects.
2 Create Physical
Database Design.
Physical Database
Design
The Physical Database Design consists of a narrative description of the database design decisions and a number of
listings of the physical storage aspects of the database and its associated objects. They typically include the
following:
Database, rollback segment, table space definitions
File and storage definitions Database object definitions (physical storage)
3 Create Production
Database DDL.
Production
Database DDL
The Production Database DDL is a set of scripts containing SQL statements for creating the database as needed in
the Production Environment.
Back to Top
APPROACH
Create Database Object Authorization Scheme
Define which users or groups of users have access to database objects and the type of access they need.
Create Physical Database Design
Define the physical environment that brings the Logical Database Design into physical existence.
Create Production Database DDL
Create the data definition language SQL scripts to build the production database and its objects.
Back to Top
Back to Top
Developer Create database objects and database object logic for both the logical and physical database design.
Create database object test scripts and procedures. Test the database objects and the database object
logic. Review Design Model mapping with database.
If an Implementation team leader has been designated, 10% of this time would be allocated to this
individual, leaving 40% allocated to the developer. The team leader would then assist in the database
creation by reviewing the Design Model mapping with the database.
50
System Architect (Information Architect) Participate in the peer-review of the database in order to ensure adherence to the Information Architecture.
Preferably, this should be done by a system architect that specializes in Information Architecture.
10
Database Administrator Preserve database integrity, tune performance, give advice, control allocation of disk space, monitor space
usage, and generate DDL scripts.
20
Database Designer Create physical database design, assist in analyzing column usage, define constraints, create the
authorization scheme, specify initial database configuration, and provide volume estimates.
20
Back to Top
PREREQUISITES
IM.040.1
Prerequisite Usage
Logical Database Design (DS.150.1)
The Logical Database Design is transformed into the physical database objects that support the application.
IM.040.2
Prerequisite Usage
Logical Database Design (DS.150.2)
The Logical Database Design is transformed into the physical database objects that support the application.
Implemented Database (IM.040.1) The initial Implemented Database serves as input to the final version.
Back to Top
TEMPLATES AND TOOLS
IM-
040_PHYSICAL_DATABASE_DESIGN.DOC
MS WORD
Example Comments
Physical Database Design
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IM.050 - IMPLEMENT COMPONENTS
In this task, you implement the components of your application. A component is the physical packaging of model elements, such as design classes created in the design
process. Components have a trace relationship to the model elements they implement. Some standard types of components include executables, files containing source
code, library etc. This activity focuses on developing and maintaining components (fixing defects when the class has been tested). When applicable, the components are
registered in the Enterprise Repository to allow projects to discover the changes, and for future reference.
Developing components may include the following:
Outlining the file component that will contain the code. This depends on the programming language to be used. Sometimes, several classes may also be
implemented in one file component.
Generating source code from the design class and the relationships in which it participates. This depends on the case tool being used to model the system and the
target programming language and the support provided for it by the case tool.
Implementing the operations of the design class in terms of methods (implementation of operations).
Ensuring that the component provides the interfaces as specified by the design class which it is implementing.
Creating custom extract, transform, and load components (or enhancement of packaged ETL processes)
Implementing system extracts
Creating or enhancing reports (new custom reports or modifications of packaged reports)
Creating control scripts or automating component execution (example workflow)
For the implementation of SOA services, refer to the Service Implementation Technique for guidance.
components, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems. In this task, you produce the
custom modules to support custom extensions to the applications. You also perform the first round of testing as part of this task.
For projects that involve the upgrade of Oracle products, this task is used to apply the software changes as described in the Updated Requirements Specification
(DS.035).
ACTIVITY
Back to Top
WORK PRODUCT
Implemented Components - The work product of this task is the Implemented Components. The View, Control and Persistence Components are implemented. The
Entity, Control and Boundary design classes are the main inputs to produce this work product.
When a physical Enterprise Repository has been established, a new component or component version is created in the Enterprise Repository for each new or modified
component. Review the IT Asset Management technique Implementation Meta Data Description for a suggestion and description of properties that can be captured
regarding implementation components.
In a commercial off-the-shelf (COTS) application implementation, this work product consists of the actual program code for the approved application extensions.
Back to Top
TASK STEPS
1 Implement View
Components.
View Components The View Components contain the implementation of the view components. The boundary classes are the main
input to produce this work product.
2 Implement Control
Components.
Control
Components
The Control Components contain the implementations of the control components. The control classes are the main
input to produce this work product.
3 Implement Persistence
Components.
Persistence
Components
The Persistence Components contain the implementation of the persistent components. The entity classes are the
main input to produce this work product.
4 Update Enterprise
Repository.
Implementation
Assets
The Implementation Asset is created or updated in the Enterprise Repository.
Back to Top
#TOP #TOP
APPROACH
Implement View Components
First, build the user interface source code. This involves the conversion of the user interface design into source code using the user interface framework. Creating the
user interface begins with the instantiation of the user interface framework in the development environment. The user interface framework defines the class and sub-class
requirements for the production user interface. The User Interface Prototype provides the model for the implementation, and the actual coding of the interface is based on
the user interface design documentation. The class model provides both the class names for the user interface and the reference classes for back-end processing.
Implement Control Components
Next, code the business logic. The business logic is coded for the state transitions found in the state diagrams, for the business rules that should be implemented through
coding, and in the descriptions of the operations in the business object model and the class model. The unit tests for the business logic are also coded in this task. The
analysis and design control classes are transformed into code.
Implement Persistence Components
Then code the persistence interface method logic. The persistence interface method logic is the code that connects the business source code and the database. The unit
tests for the persistence interface method logic are also coded in this task step. The Analysis and Design entity classes are, thus, transformed into high performance
code that retrieves, updates and creates data in the underlying persistent technology. In most of the cases, a relation database will be used to support persistent objects.
Finally, create new entries or update existing entries in the Enterprise Repository for all components that should be discoverable. This is especially important for
components that are reusable, like XSDs, reusable Java libraries, etc. It is also important when the Enterprise Repository is also used for impact analysis. In that case
any (major) component that should be included in an impact analysis should have an entry in the Enterprise Repository.
Back to Top
Back to Top
System Architect Participate in the peer-review of implemented components in order to assure adherence to the architecture. 20
Developer Lead the team of developers and implement the components.
If an Implementation (or other) team leader has been designated, 50% of this time would be allocated to this
individual, leaving 30% allocated to the developer. The team leader would then lead the team of developers and build
the most complex packages and components.
80
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how
to govern the proposed assets (implemenation assets) and their relationships to other IT assets. In addition, ensure that the final
proposed asset and their relationships are added/updated in the repository.
Reviewed Design Model (DS.160.2) The Reviewed Specification provides the necessary input to develop the components for the application.
Back to Top
TECHNIQUES
Technique Comments
Service Implementation Use this technique to understand how to perform this task for SOA service implementation.
Service Architecture
Use this technique to understand the service implementation and its relation to other parts of the service for SOA service
Implementation.
SOA Service Lifecycle Use this technique to understand where this task fits in the overall service lifecycle for SOA service implementation.
Service Modeling Use this technique to understand how you can model SOA services.
IT Asset Management Use this technique to understand what kind of elements are relevant for service design.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Getting Started with Unit Testing
using JDeveloper
JDeveloper-Unit-Testing using a framework like JUnit is only effective when integrated in the development process itself.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IM.053 - REGISTER SERVICES
During this task, you register all services in a service registry. This task is only relevant if you use a service registry for service implementation. A service registry support
runtime discovery and binding of the service. Typically the registry will require each service to make available the document it expects as an argument, binding and IP
addresses, and possibly relevant meta data.
When you start this task, it is assumed that all the services are ready for service registration. This means that if you reuse existing components, if any additional coding is
required, this has already been completed, as well as if you are creating services from scratch the coding has completed for this. The coding is done as part of the
Implement Components (IM.050) task.
If a service registry is used, then, in principle, all services should be registered there. It may however be that the service registry you are using does not support all types
of services.
ACTIVITY
IM.053.1
IM.053.2
Back to Top
WORK PRODUCT
Populated Services Registry - The Populated Services Registry contains all registered services that should be used by the system so that they all can be executed
properly.
Back to Top
TASK STEPS
1 Prepare the Service Registry.
2 Register each service in the Service Registry.
3 Verify service execution.
Back to Top
APPROACH
Prepare the Service Registry
Depending on the type of services registry you use, you need to perform some preparations (configurations) prior to the service registration. View the documentation
belonging to the service registry to see what steps are required.
Register Each Service in Service Registry
When the services registry is ready, then start registering the services that are ready for deployment. How this should be done is dependent on the service registry, but
will typically include steps like defining a service package category, and to register the service package itself. The service package typically would consist of various
descriptor files, and service request and response definition files.
Verify Service Execution
When the service has been registered in the services registry it should be possible to execute the service. Verify whether this is indeed possible to make certain it is
available for test.
Back to Top
Business Analyst Perform services registration. If possible, you may want use a business analyst with extensive SOA architecture experience. 100
Back to Top
PREREQUISITES
IM.053.1
Prerequisite Usage
Business Services Design (DS.120.1) You are implementing the services based on the Business Services Design.
IM.053.2
Prerequisite Usage
Business Services Design (DS.120.2) You are implementing the services based on the Business Services Design.
Implemented Components (IM.050)
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IM.055 - PERFORM BUSINESS RULES IMPLEMENTATION
(RULES ENGINE)
The scope of this task only concerns volatile business rules that are implemented using a business rules engine and for which a (client) business analyst should have
prime responsibility. This task would be done when there are business rules the client organization will maintain in a rules engine after the project has finished.
All other kinds of business rules, like (static) business rules that are implemented through coding, are implemented in the task, Implement Components (IM.050).
Although a (client) business analyst should have the prime responsibility for this task, in practice, it is likely done by an implementation team. The team may include client
business analysts, technical staff such as, a business rules specialist, a developer, and in some cases a rules librarian.
components that extend the functionality of the COTS system, or through a business rules engine. Perform this task only for business rules implemented using a
business rules engine.
ACTIVITY
IM.055.1
IM.055.2
Back to Top
WORK PRODUCT
Implemented Business Rules (Rules Engine)
Back to Top
TASK STEPS
1 Implement business rules.
Back to Top
APPROACH
Implement Business Rules
Depending on on the tool you are using, and how you have accomplished the Business Rules Design (DS.110), either an automatic import is used, or each rule must be
entered manually.
If the rules are entered manually, determine what kind of rules are the easiest to implement, and help the client implement these first. The detailed rules classification
may help in determining what rules are similar, and what kind of rules must be implemented differently. Start the client off with an easy category, and move onto more
difficult cases. In this way, business analysts may implement a large body of the rules. However, in some cases, and very much dependent on your rules engine, or the
understanding on how rules are tied together, you may need a rules librarian to approve the implementation of changes. A rules librarian should have a better
understanding of how the given rules engine works and would ensure that the change will produce the desired behavior. A rules librarian would also verify that the
original perception of the required rule has been based on a correct diagnosis and understanding of how the engine behaves.
Estimating Considerations
The level of effort required to perform this task varies heavily depending on the rule engine you have chosen, whether or not the rules can be automatically imported, and
the client skills. The less supportive your rules author is, the more effort required. Preferably during the Inception phase let the client practice with the rule author and see
how well he can work with it. If most of the work must be done by the development organization, assume a 70% development organization effort and a 30% client effort to
implement this task.
Back to Top
Back to Top
Business Analyst Perform rules implementation. If possible, you may want use a business analyst with extensive business rules experience. 100
Back to Top
PREREQUISITES
IM.055.1
Prerequisite Usage
Business Rules Design (DS.110.1) You are implementing the rules based on the Business Rules Design.
IM.055.2
Prerequisite Usage
Business Rules Design (DS.110.2) You are implementing the rules based on the Business Rules Design.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
In case of Oracle Business Rules, rules are implemented using the Rule Author. Specifically the link to the Business
Rules User Guide provides guidance on how to use the Rule Author.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IM.060 - PERFORM COMPONENT REVIEW
In this task, you perform a peer-review on the Implemented Components. This is a complement to the unit testing that is performed in the Perform Unit Test (TE.030) task.
Peer-review includes a verification of whether various aspects of the component have been implemented as required. The project should decide up-front what should be
included in the peer-review. The peer-review should as unit testing reveal errors in the components.
Typically, the peer-review includes a verification of whether the Implemented Components have been implemented following the various project standards, such as user
interface standards. Most often it also includes code reading. The code reading should include a verification whether the code is written in compliance to coding
standards, and whether it is written in a way that is easily understood by other developers (using sufficient documentation in the code). Other aspects may be included as
well, for example to verify whether the code will perform well - but the latter will require reviewers that have good performance-skills.
In a commercial off-the-shelf (COTS) application implementation, this task is performed only for custom-built components that extend the functionality of the COTS system
and/or integrate the COTS system with other COTS or legacy systems.
ACTIVITY
IM.060.1
IM.060.2
Back to Top
WORK PRODUCT
Component Review Results - Component Review Results contain the results of the reviewed components. Based on this review, defects may be logged and change
requests can be triggered.
Back to Top
TASK STEPS
Back to Top
APPROACH
Back to Top
Back to Top
System Architect Participate in the review of implemented components in order to assure adherence to the architecture. 10
Developer Lead peer-reviews of the packages. Perform code review on components. A lead application developer may be designated to
review the components from the point of view of design.
60% allocated to the developer. The team leader would then lead the peer-reviews of the packages and perform reviews of
complex components.
80
Quality Manager Review components from the point of view of testing. 10
Back to Top
PREREQUISITES
IM.060.1
Prerequisite Usage
Implemented Database (IM.040.1) Quality assurance is performed on the Implemented Database.
IM.060.2
Prerequisite Usage
Implemented Database (IM.040.2)
The Implemented Database and Components are those on which the quality assurance should be performed.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IM.070 - ASSEMBLE COMPONENTS
In this task, you integrate the components into a logical assembly of components. Such an assembly can consist of various types of components, including interface
components and other types of components. The assembly is manifested through an assembling mechanism in the implementation environment. This task ensures that
an assembly fulfills its role and that the requirements (use cases and scenarios) identified for the assembly are correctly implemented. In addition, the component
assembly is registered in the Enterprise Repository as a Software Package and linked to the applicable individual components that apply.
An implementation assembly should have a one-to-one trace to the corresponding design. For example, a component assembly can be the complete set of components
required to implement a service. Each interface included in the corresponding design must also be provided by the assembled components. Therefore the assembly must
contain a component that provides the interface.
The developers implement the components as required by the design. They unit test them and assemble them. The resulting assembly is then passed on to the system
integrator for integration (IM.080).
For SOA implementation, this task consists of creating a deployment package for one or more services and documenting the configuration. Refer to the Service
Packaging and Deployment Technique for more details. A set of Assembled Components is a type of a Software Package. In the remainder of this task guidance, the
terms Assembled Components and Software Package will be used interchangeably, unless specified otherwise.
ACTIVITY
Back to Top
WORK PRODUCT
Assembled Components - The Assembled Components is an Implementation Model that reflects the design. It helps organize the system into manageable and logical
pieces (e.g., for example, to collect required set of components into various services). The Assembled Components implement the hierarchy as defined during the Design
process.
When a physical Enterprise Repository has been established, a new software package or software package version is created in the Enterprise Repository for each new
or modified software package.
Back to Top
TASK STEPS
1 Name the software package and
determine components to include.
Named set of identified
components
Consists of a list of Components to include in the software package
2 Organize software package Software package structure
and component location.
Determines the structure of the software package and the location of the components to
include.
3 (optional) Create software package
profile
Software package profile Consists of a software package profile that is used to automatically create the software
package as a deployable unit.
4 Create software package Software package The actual software package which can be deployed.
5 Validate software package Validated software package Validation of the software package to assure that no component is missing, nor are there
any superfluous components in the package.
6 Update Enterprise Repository. Software Packages Assets The Software Package Asset is created or updated in the Enterprise Repository. This
includes meta data regarding the contents of the software packages.

Back to Top
APPROACH
Name Software Package and Determine Components to Include
Software packages may come in various formats, and typically have a file name extension of JAR (Java ARchive) , WAR (Web Application ARchive), EAR (Enterprise
Archive), SAR (SAP Business Systems file type) , DLL (Dynamic-link Library), EXE (Executable file), and DRV (Device DriVer).
The Design Specifications (DS.140) for the application components or services should already list most, if not all of the components to include by means of building
blocks. As a matter of fact, the Design Specifications might already have named the building blocks. The individual Design Specifications provide the starting point to
determine the name and content of the software package. During implementation some extra or finer grained components may have been realized, that were not
recognized during the design. The Design Specification should have been updated to reflect this for future use, but that may have not been done for various reasons.
The software package may also need to include (standard) components or packages that were not implemented by the project, but need to be included in the software
package. An example would be a standard ADF (Oracle Application Development Framework) library when creating the software package for a UI (User Interface)
application that has been developed with ADF. Another example would be some standard DLL that needs to be included in some application package, in order for it to
function.
The name of a software package should give a good impression of its contents to any of its stakeholder without them needing to review what is in it. Giving a software
package a proper name is an important task, and helps in determining the scope of what needs to be included in a package. For example, in case of a reusable Java
library you may find that you have difficulties with giving a library a proper name that sufficiently describes its contents. This may indicate that the library contains
components that better are included in some other library, with a different purpose. Techniques to determine the proper content of a Software Package are similar to
those used for Use Case packages, and concern principles like loose coupling, tight-cohesion and responsibility-driven design. In case of SOA see also the Service
Packaging and Deployment Technique.
Organize Software Packages
For the most part the organization of the software package will be derived from the organization structure and location of the individual components to include. It primarily
concerns the projects folder structures at file and version control system level including where to retrieve the individual components. Standard components typically are
not included in the projects file and version control system, but may be part of in the installation of the IDE (development environment of the C++ programming language)
being used, or be present at the target environment, The location of all components to be included in the package needs to be determined. In addition determine if their
current location is appropriate for deployment to test and other environments.
For example in case of a Java web application, in some standard Java libraries might better be included in the EAR file of the web application, whereas in some other
cases reusable Java libraries better are deployed on the target environment individually. When considering what standard libraries to include in the package and which
one to deploy individually, it is important to know what other solutions are deployed on the target environment now and in the foreseen future. Updating a reusable library
on the target environment might have unwanted side effects on other solutions.
Create Software Package Profile
In many cases the assembly of the software package is defined by means of some sort of a software package profile. For example, in case of JDeveloper, one can create
deployment profiles that define which components to include in a JAR, WAR, EAR or SAR file. For different target environments different configuration plans may be
needed to configure the target environment-specific server names, port numbers, etc. Software package profiles can also be used, or be determined by automatic build
scripts, like for example ant scripts. (Note: an Ant script is an XML build file)
Create Software Package
This concerns the actual creation of the software package by means of the appropriate tool (typically a function of the IDE, or a build script).
Validate Software Package
Before deploying on any target environment it is better to review the actual contents of the software package. This is especially important for determining that there are no
superfluous components in the package, as in most cases testing will not reveal that, while at the same time it may have a negative impact on the deployment process, or
cause future issues. For example, accidentally including large reusable libraries in an EAR file will make it unnecessarily big and may result in a long duration of the
deployment and server restart, which could have been avoided. It could also have unexpected side effects, for example when some reusable library that also is deployed
individually, it suddenly may turns out that this is not used because the application accidentally uses a library that was included in the EAR file.
If an Enterprise Repository is being used, for each new Software Package or update of an existing one, update the Enterprise Repository with the meta data regarding this
package. This is very important to make a Software Package discoverable, and capture its relationship to the components it consists of, especially with respect to impact
analysis.
Refer to the IT Asset Management technique Software Package Meta Data Description for a suggestion and description of properties .
Back to Top
This task has supplemental guidance that should be considered if you are doing a WebCenter implementation. Use the following to access the task-specific supplemental
Back to Top
System Architect Participate in the peer-review of implemented components in order to assure adherence to the architecture. 20
Developer Lead the team of developers and implement the component interfaces and help define subsystem integration
constraints.
If an Implementation (or other) team leader has been designated, 30% of this time would be allocated to this
individual, leaving 50% allocated to the developer. The team leader would then lead the team of developers and
build the implement the most complex component interfaces.
80
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes
how to govern the proposed assets (software packages) and their relationships to other IT assets. In addition, ensure that the
final proposed assets and their relationships are added/updated in the repository.
Component Review Results (IM.060.2) This work product contains the developed components that should be integrated into the subsystems.
Back to Top
TECHNIQUES
Technique Comments
Service Packaging and Deployment Use this technique to understand how to package SOA services.
SOA Service Lifecycle Use this technique to understand where service packaging fits in the SOA service lifecycle.
IT Asset Management Use this technique to understand what information can be stored in an Enterprise Repository regarding Software Packages.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Getting Started with Unit Testing
using JDeveloper
JDeveloper-Unit-Testing using a framework like JUnit is only effective when integrated in the development process itself.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IM.080 - INTEGRATE SERVICES
In this task, you focus on the following:
Create an Integration Build Plan describing the builds required in an iteration and the requirements on each build.
Integrate each build according to plan.
It is recommended that software be built incrementally in manageable steps so that each step yields small integration or test problems. The executable version of the
software is then subject to integration tests.
ACTIVITY
Back to Top
WORK PRODUCT
Integrated Services - In the Integrated Services, the components and services are compiled and integrated according to the building plan. Integrating such components
and services creates a new build.
Back to Top
TASK STEPS
1 Develop
Integration
Build Plan.
Integration
Build Plan
In order to identify and implement the functionality to be incorporated in a build, a plan is developed. The Integration Build Plan is used
by component engineers to build the system. Subsequently, the system is built according to the plan.
2 Integrate
Services
according
to plan.
Integrated
Services
The right versions of the code (corresponding to the components and services within the iteration) is collected, compiled and linked. The
Integrated Services is subject to testing in the Testing process. The system integrator, thus, incrementally integrates the services and
their corresponding components into the system executable(s) based on the integration sequence worked out in the integration build
plan.
Back to Top
APPROACH
Develop Integration Build Plan
Define the Integration Build Plan. The plan identifies what functionality will be incorporated in a build. The developers use that plan to build the system. Subsequently,
the system is built according to the plan. Some criteria to be considered for a subsequent build include:
The build should add functionality to the previous build by implementing complete use cases and / or their scenarios. It is crucial to identify the right requirements
to be implemented in each build.
The build should start in the lower layers (for example, middleware, system services before application services which are based on the system services and
middleware) and then expand upwards to the application specific layers. For each use case / scenario to be included in the build, trace its realization in analysis,
design (design classes and services) and implementation (implementation components and services) and capture this in the build plan. This is then
communicated to the component engineers who then build the corresponding components and services.
Integrate Services According to Plan
Select the right versions of the code (corresponding to the components and services within the iteration), compile them and put them together. The integrated services
#TOP #TOP
will be subject to testing in the Testing process. The system integrator, thus, incrementally integrates the services and their corresponding components into the system
executable(s) based on the integration sequence worked out in the integration build plan.
Back to Top
Back to Top
System Architect Manage issues related to services integration. Plan and subsequently build the system in each iteration. You may wish to use a
system architect who specializes in system integration.
If an Implementation team leader has been designated, 30% of this time would be allocated to this individual, leaving 70%
allocated to the system architect. The team leader would then manage issues related to services integration.
100
Back to Top
PREREQUISITES
Prerequisite Usage
Component Review Results (IM.060.2)
Assembled Components (IM.070)
These work products contain the components and services that should be integrated.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
JDeveloper
itself.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
IM.085 - DEVELOP USER INTERFACE STANDARDS
PROTOTYPE
In this task, you develop the prototype to define the user interface standards for the application. It is beneficial if the task is performed as early as possible in the
Elaboration phase, so that the standards are defined and can be used as early as possible.
Depending on the type of pages and reports that your application may contain and the different varieties that are possible in terms of layout, various designs and layouts
could be produced and reviewed with the users to ascertain what the user interface should look like. Focus both on design aspects, such as color, fonts, spaces, page
layout as well as the generic feel of the application, such as navigation principles and type of search mechanisms you will use in the application.
The different design and layouts should cover the generic framework for the application, such as logo, company name, colors, generic text and links, frames, headers,
page organization, menus, trees, tabs and so on. In addition you should prototype different layout styles for pages and reports that you expect to be produced during the
project, such as form and table layouts, shuttles, trees, master-detail pages and so on. Agree on what kind of layout styles should be used for the application, and how
they should fit in within the generic framework, how each page should be accessed (through menus, tabs, links, trees etc), and how the navigation should be within the
application.
A common style guide can be produced that forms the basis for the rest of the project. Such a style guide saves time and improves the consistency of the user interface
throughout the whole system, no matter how many different developers work on the project, now and in the future.
In a commercial off-the-shelf (COTS) application implementation, this task is performed only when there is a requirement to alter the standard look and feel of the COTS
application system via supported means, such as Oracles Siebel Tools.
ACTIVITY
Back to Top
WORK PRODUCT
User Interface Standards Prototype - The User Interface Standards Prototype is a piece of code that demonstrates the look and feel of the application to develop. In
most situations it contains a number of example pages through which the users can discuss the generic user interface, specific page layouts to use, and various
mechanisms on how the pages should be used, for example, how to navigate within and between pages, how data could be queried and so on. As part of the work
product is preferably a chosen framework, including customer specific graphical elements defined in as a generic skin for the application.
In a commercial off-the-shelf (COTS) application implementation, the User Interface Standards Prototype is an applications environment with the user interface modified
using Siebel Tools, or comparable toolset (if applicable), to demonstrate the look and feel required by the client.
Back to Top
TASK STEPS
1 Review the result of the Validated Conceptual Prototype (RA.030). The User
Interface Standards Prototype should include agreed changes and additions to
the Conceptual Prototype that relate to the generic look and feel of the
application.
None None
2 Obtain graphical elements and standards used in the organization (fonts, image
files, color codes).
Graphical
Components
The Graphical Components consists of any graphical elements and
standards used in the organization (for example, logos, image files,
recommended colors, etc.).
3 Determine a candidate visual framework (Java Server Pages, Java Server
Faces, etc) that seems the best fit to prototype the user interface following the
output from step 1 and 2.
Candidate
Visual
Framework
The Candidate Visual Framework is the initially chosen framework
that will be used for the application.
4 Determine candidate use case(s) to demonstrate the UI. Candidate
Use
Case(s)
The Candidate Use Case is the chosen use case with the
developed UI applied. Be sure to select use case in which the
discussion can be directed to discussing the user interface and not
the functionality.
5 Using the candidate visual framework and the collected elements, develop a User The User Interface Standards Prototype does not need to have any
#TOP #TOP
user interface prototype for the chosen use case(s). Interface
Standards
Prototype
functionality. If necessary, edit the HTML directly to create a flow
example.
Back to Top
APPROACH
This task is mandatory unless the look and feel of the application has been determined earlier, typically in a previous increment, or project.
During the task it is recommended that you determine to use a framework that can be used to develop the application. A framework may impose certain standards for the
look and feel, so you need to consider the available frameworks against the look and feel requirements that you have decided during the Conceptual Prototype, or that
the organization uses. Preferably, you should attempt to develop a standard skin for the application. A skin is a global style sheet that only needs to be set in one place
for the entire application. Therefore, instead of having to style each component in each page you develop, or having to insert a style sheet on each page, you can create
one skin for the entire application. Every component should then automatically use the styles as described by the skin. Whenever the skin needs to be adjusted at some
point in the future, all effected components will be "adjusted" automatically.
When presenting the User Interface Standards Prototype, it is often that discussions starts about system functionality instead of the user interface standards and
framework. Be sure to keep the focus on the UI elements. To prevent this, you may choose to prototype use cases that are not related to the application to develop.
However, keep in mind that if the type of use case is too far off the users own business, they might loose focus as they may loose interest. There are pro's and con's for
both alternatives. It may be a good idea to choose a (set of) use case(s) that are within their own business area, but not relevant to the application to develop. Either way,
be certain that the users understand the purpose of the prototype, to validate the user interface, and not the functionality.
When the situation requires that uses cases of the system are used, then use those use cases that are expected to raise the least amount of discussion about
functionality.
In smaller projects, you might choose not to develop a separate User Interface Standards Prototype, but to combine it with the Functional Prototype (IM.010). If you
choose to do this, you must ensure that you prototype use cases that allow you to discuss and agree on the user interface standards, as well as functionality. When
validating the prototype, you must also ensure that you separately focus on and agree on a standard look and feel independent of the functionality, preferably before
discussing the functionality. Let the users know in advance that the purpose of the validation is dual (see the approach section for validating the User Interface Standards
Prototype (IM.095) for more details).
In larger projects, you will probably choose to keep the prototypes separate. Often, you will use different developers as well as different users for the two prototypes. The
developers might be specialists on developing user interface, while the users may be those that decide on business branding.
Remember that for the User Interface Standards Prototype it is not necessary to generate the whole set of pages for the application or to create a piece of code running in
the server. It is better to have the user interface approved sooner than testing the environment (this can be done while testing the first use cases).
Even when you use a graphical designer to create the UI, it is recommended to have the UI generated by the visual framework that will be employed. The proposed UI
should be feasible and preferably not very complex and compatible with the framework.
As mentioned before it is advised to perform this task early in the project. There can be situations where the users are not involved in the project right from the start, and
that it therefore is difficult to determine a definitive look and feel at the very beginning. Also, be aware of consequences of inexperienced users in a graphical user
interface environment.
If this task is performed early and the graphical user interface environment is new to the users, they might come back on some decisions later in the project. If you have
chosen a framework where you use a generic skin, a global style sheet, you will be less vulnerable in such situations, as all pages will change accordingly if the generic
skin changes.
Back to Top
System Architect Lead the team responsible for building the User Interface Standards Prototype. Build the User Interface Standards Prototype.
60% allocated to the system architect. The team leader would then lead the team responsible for building the User Interface
Standards Prototype.
80
System Analyst Assist in the creation of the graphical interface by providing information generic rules and requirements. 20
Ambassador User Assist in finding existing graphical user interface rules and provide information for setting up a set of suggested rules. *
Back to Top
PREREQUISITES
Prerequisite Usage
Use Case Specification (RA.024.1) The Use Case Specification details are used to determine which user interfaces should be prototyped.
Architecture Description (RD.130) The Architecture Description (updated by DS.040) is needed as a basis to develop the User Interface Standards Prototype.
Conceptual Prototype (IM.005) This task is a refinement of parts of the work done in the Conceptual Prototype.
Back to Top
TEMPLATES AND TOOLS
If your project is a J2EE project, consider using the Oracle Application Development Framework (ADF) as the overall framework for your application. This is a part of
JDeveloper. ADF is an end-to-end application framework that builds on J2EE standards and open-source technologies to simplify and accelerate implementing service-
oriented applications. If you develop enterprise solutions that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces it
is recommended that you consider ADF.
You may also consider to use JHeadstart that can be used on top of ADF to generate various kind of user interface pages, such as for example form, table, shuttle, and
tree layouts.
Back to Top
The User Interface Standards Prototype is used in the following ways:
to allow the end users to familiarize themselves with the look and feel of the new application
to define the look and feel standards and the generic skin for the new application
Distribute the User Interface Standards Prototype as follows:
to all users involved in the project
to all developers
Back to Top
QUALITY CRITERIA
Does the User Interface Standards Prototype present a sufficient number of elements, and page styles, to allow user validation of the proposed UI?
Does the User Interface Standards Prototype show navigation principles?
Does the User Interface Standards Prototype allow users to navigate adequately?
Does the User Interface Standards Prototype comply with the UI standards and guidelines being proposed for the project and for the organization?
Does the User Interface Standards Prototype show various search mechanisms?
Back to Top
IM.090 - CREATE INSTALLATION ROUTINES
In this task, you develop automated functions and detailed instructions to install customizations in the testing and production environments.
For projects that involve the upgrade of Oracle products, this task is focused on creating routines in order to install migrated custom extensions into the appropriate
environments.
ACTIVITY
Back to Top
WORK PRODUCT
Installation Routines - The work product of this task is a set of Installation Routines. These routines include documented instructions for installing all of the custom
modules in the testing and production environments. Not all custom components can be installed with an automated script, so the instructions may include manual steps
as well.
Back to Top
TASK STEPS
1 Determine the installation technique for each custom component.
2 Confirm proper installation and configuration of components in the
Development Environment (IM.007).

3 Export data for components supported by a seed data loader. Seed Data
ASCII Files

4 Create PL/SQL scripts for supported application programming interfaces
(APIs).
PL/SQL Scripts
5 Write lookup seed data population scripts. Seed Data SQL
Scripts

6 Initialize the test environment.
7 Test discrete installation steps.
8 Package scripts and commands into an operating system script. Master Install
Routine

9 Document manual steps. Installation
Instructions
This component provides detailed step-by-step instructions to install
and set up each single system.
10 Refresh the Test Environment.
11 Test final installation process.
12 Place finished routines under source control.
Back to Top
APPROACH
The objective of Create Installation Routines is to create an installation process for each custom component that a system administrator can reliably execute to install the
required modules and supporting setups into any destination environment. You should strive for fully automated installation, but manual steps are acceptable as long as
the instructions are clear.
Environment Preparation for a Commercial Off-the-Shelf (COTS) Applications
Before you can install individual custom modules into a new environment, you must prepare the target environment for the custom components. You can automate some
of the steps, but you must perform others manually. To prepare a new environment you must perform these actions:
1. Create a directory structure for each customization/custom application.
2. Add environment variables for the root directory structures to the application environment file.
3. Register customizations as custom applications with Application Object Library.
4. Shut down and restart the concurrent manager, or its equivalent.
5. Create custom database users, or their equivalent.
6. Register custom ORACLE IDs.
Suggestion: If you have a master setup instance that you plan to import into future environments, you can preconfigure the master setup instance with the required
custom applications.
Custom Module Installation
Although you can simply copy some types of source and executable code to the proper destination directory, most Applications extensions require you to register the
modules in the Application Object Library, or its equivalent or perform some other configuration. For example, to install a custom report you need to perform the following
actions:
1. Copy the source and executable report files to the proper custom directory.
2. Register the executable file in Application Object Library, or its equivalent.
3. Create custom value sets for program arguments.
4. Register the concurrent program and arguments.
5. Create a custom report set.
6. Add new report to custom report set.
7. Add other standard reports to report set.
8. Associate report set to a custom responsibility.
Although you can perform all steps manually in each target environment, this is tedious and error prone.
PROGRAM FILES
Installing the actual source and executable program files is the easy part. Use one of the following techniques to move or install these files:
direct copy over the network
direct copy over the network
Oracle Installer
APPLICATION OBJECT LIBRARY
You can use several techniques to register the proper information in Application Object Library:
supported open interface
supported command-line utility
supported PL/SQL application programming interface (API)
custom SQL*Plus scripts
keyboard capture and playback
manual entry
Test Environment Refresh
In order to debug your installation routines, you may need to delete information from Application Object Library tables and then re-execute your scripts. The easiest way to
do this is simply refresh the entire environment or specific tables from a backup. This also confirms that your routines will work properly in a completely generic target
environment.
Back to Top
Back to Top
Developer Create the Installation Routines. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Design and Build Standards (DS.050) Follow the Design and Build Standards when building scripts to automate the custom module installation.
Validated Functional Prototype (RA.085)
Back to Top
TEMPLATES AND TOOLS
IM-090_INSTALLATION_INSTRUCTIONS.DOC MS WORD
Back to Top
Use the Installation Routines to package multiple commands and scripts for a customization into a single, easily executed operating system script (such as a UNIX Bourne
shell script). You should be able to re-execute all scripts without errors, even if custom modules are already installed.
Back to Top
QUALITY CRITERIA
Apply the same quality criteria to installation routines as you do to other custom modules. Include standard headers and use comments liberally. Follow the build
standards for SQL*Plus scripts and PL/SQL procedures. Be sure to include installation routines for all customizations.
Back to Top
[TE] TESTING
The Testing process is an integrated approach to testing the quality and conformance of all elements of the new system. Therefore, it is closely related to the review
tasks in the Quality Management (QM) process of PJM and to the definition and refinement of requirements in the Business Requirements process. The Testing process
addresses both functional testing and testing of supplemental requirements (with the exception of performance testing as this is done in the Performance Management
process, and operational testing, backup and recovery testing and disaster recovery testing as these are done in the Technical Architecture process). It also includes
systems integration testing for projects with requirements for interfaces to external systems.
Testing should start as early as possible in the project, and developed components should be integrated and tested as an integrated set, as early as possible. This
means that testing should start after the very first iteration in Elaboration. This allows for early discovery of errors that eventually reduces the risk of project delays that
often are caused by heightened error detection at the end of the project.
Testing activities are a shared responsibility of developers, quality assurance engineers, and ambassador users, working together as an integrated project team. The
Testing process presupposes that there is a highly visible user interface from which system events can be driven and results validated. The higher proportion of artifacts
that are visible to the ambassador users (for example, user interfaces and reports) the more they will be able to participate in the Testing process.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Depending on your project (e.g., large, complex, etc.), the project manager may designate a Testing team leader and/or team leaders for various other reasons that the
project manager deems necessary. If the project manager designates team leaders, they are responsible for leading their team and reviewing the work products
produced by their team. The team leader plans, directs, and monitors the day-to-day work of the team. The team leader assigns work packages to the team members
and makes sure they understand the requirements. The team leader is responsible for building team cohesion, motivating the teams, and providing assistance and
encouragement to the team members. Each team leader performs the final quality control and quality assurance for the team by reviewing all work products. The team
leader also signs off on team work completion and quality. Work that is not up to quality standards is returned. Team leaders review work products from other teams
The intent of the Testing process is to provide a formal and effective approach to the challenge of testing. Its approach is integral to the entire development effort, and
structured to build upon itself. Done well, the primary deliverable is high quality software and early delivery of a dependable system with real business benefits.
The Testing process starts off with determining the Testing Requirements (TE.005) and continues in determining the Testing Strategy (TE.010). These documents should
provide the foundation for what kind of tests should be performed and how testing should be performed during the whole projects lifecycle. This also covers the
acceptance criteria. The client takes an active role in these tasks, and approves the final work products.
OUM recommends that testing is started as early as possible in the project lifecycle. Every component should be tested in a Unit Test (TE.030). A unit test is a test of a
distinct unit of functionality. A unit of functionality is not directly dependent on the completion of another unit of functionality. Unit tests are the finest level of granularity in
testing. Examples of units are:
a single method within a Java application
a function or procedure of PL/SQL
a check constraint
a business rule (when using Oracle Business Rules)
an operation of a service
anything that has a clear defined interface and based on some input is expected to return some predictable result or perform some predictable action.
The unit test is automated as much as possible and performed using the Unit Test Scripts (TE.020).
The unit test is the first test that is performed as part of the Testing process. When a unit test is completed with success, the component is integrated with other
components developed during the iteration.
These components are then tested in an integration test (TE.040). In OUM, integration testing is twofold:
1. use case testing
2. additional integration testing (for example, test the interaction, or linkage, between related application extension modules)
First, as use cases are completed, they are tested. The use case scenarios (Main Success Scenario and Alternate Scenarios) are transformed into Integration Test
Scenarios (TE.035) and used to execute an integration test to verify the use case. Second, you may decide to perform additional integration testing on a group of
interrelated components (for example, test the interaction, or linkage, between related application extension modules). In this way, you allow for early discovery of
integration problems. These tests are performed as a continuous process throughout the iteration. As soon as a component is ready for test, and has passed the unit test,
it goes on to the integration test. This presents a challenge in that you always have to have the Integration Test Environment (TE.038) up-to-date and consistent with the
developed components. Also, keep in mind that use cases are also developed iteratively and therefore, you may need to test a use case more than once during the
iteration.
At the end of each iteration, you perform a system test (TE.070) to see whether all the components (and use cases) that have been developed so far work together as a
whole. The integration system test is a high-level integration test that validates the integration of ALL the components that have been developed during the iteration. If
you have grouped your development components into a number of smaller partitions that are iterated as separate iteration groups, you should at this point also test the
integration between all the partitions that have been completed in the iteration. Again, the earlier the integration between the partitions is tested, the earlier integration
issues can be discovered and dealt with. In projects where the partitions are tightly coupled (the partitions are tightly related and dependent on each other), users can
perform some of this integration testing informally as part of the prototype validation tasks (RA.085 - Validate Functional Prototype) to discover possible issues even
earlier. The system test is performed following the System Test Scenarios (TE.025) in the System Test Environment (TE.060).
As the system evolves through the iterations, all the testing scripts and scenarios must also evolve through the process as new or changed functionality is known and
implemented. This means that you need to update the Unit Test Scripts, Integration Test Scenarios and System Test Scenarios to be consistent with what is developed.
Also, in a similar way, the testing environments need to be refreshed to be consistent with the actual development.
Testing of generated and reused components is only performed at a functional level using black-box techniques, except for any components that are modified after
generation or reuse.
At the end of all the iterations, you perform a final full system test (TE.070). At this point, all components should be ready and the integration between components, and
partitions should be complete. This test is often more complete than the previous iterations of the system test, but this depends on the chosen approach for system
testing. During the earlier iterations of the system test, you generally use a subset of the System Test Scenarios (TE.025) but for the final system test, you test them all.
Your chosen approach for your project should be documented in the Testing Strategy (TE.010).
The last test that is performed before handing the system over to the client for the acceptance test is the systems integration test (TE.100). This test is performed only if
the system integrates with other systems. During this test all the Systems Integration Test Scenarios (TE.090) are tested. The purpose of the test is to test whether all
integration points work as they should, and that the business flows that cover more than a single system perform as expected. The system is in this way tested
thoroughly, using both black-box and white-box techniques, before it is delivered to the client for the acceptance test.
In a Custom BI project, after the creation and population of the Production Environment, the development team walks through business critical data and data access
components.
Finally, the ambassador users validate the solution against the critical business requirements during the acceptance test, to confirm that the system is ready to go into
production.
The Testing process starts off by defining the Testing Requirements (TE.005). An established, universal rule of software testing is that before you can run a test (or
perform a test step), you need to know the correct outcome of that test (or test step).
In a project using a waterfall approach, the testing focus is on conformance with defined requirements. The lack of complete and detailed requirements at the start of a
OUM project makes close collaboration between developers and users a necessity. Requirements are developed, documented and prioritized throughout the lifecycle of
a OUM approach project. Also the testing requirements may evolve throughout the project, in particular for projects where they still are in the learning process for this
type of projects.
The Testing Requirements (TE.005) specifies what type of tests should be performed, for what purpose, at what project stage they should be performed, to what level,
and with what kind of output should be produced, such as the form and scope of test reports.
The testing requirements are detailed through the project. It attempts to take full advantage of all opportunities that contribute to the identification of testing requirements.
For example, you identify business scenarios while developing the Business Use Case Model (RA.015), and they contribute to unit, integration, system, and systems
integration testing. Your functional modeling produces testing requirements that are specific to use case testing. User interface and functional testing is performed with
reference to the Functional Prototype (IM.010). The Integration Architecture Strategy (TA.030) contributes to the systems integration testing requirements. These detailed
requirements are documented in the work products describing testing scenarios and sequences.
Testing is performed progressively against functional and supplemental requirements as the requirements are defined and the components are delivered. Regression
testing is essential, and should be automated, wherever possible, using standard tools. A regression test is a test to uncover whether previously working software stops
to work as intended.
Also, the business Domain Model (data model), the data acquisition approach, data access approach and administration approach help identify business or functional test
requirements. The Technical Architecture process identifies supplemental requirements in such areas as integration, security and availability, from which you plan
supplemental (non-functional) testing.
Testing Strategy
The Testing Strategy describes the actual approach that should be used for the different kind of tests that should be performed as described in the Testing Requirements.
It describes the project direction as it relates to testing. It includes how testing should be performed in the various stages of the project, which tools should be used (if
any), how and what metrics should be collected, how test data should be produced and what testing environments should be used in the tests. The strategy also defines
the acceptance criteria of the solution.
In a project where components are developed and evolved through a number of iterations, it is important to document how the tests should be performed as part of each
iteration, as the focus should differ dependent in which iteration you perform the test. A component developed in the first iteration is likely to change when feedback has
been received as part of the validation, so less effort should be spent to discover all errors, but just as much as it fits the purpose for that phase in the project. The test
should become more complete throughout the iterations, and at the last iteration, it should be as complete as possible.
Also, for the iteration system tests versus the final system test, you should document how much and what kind of scenarios should be tested as part of each test.
The testing approach describes the method that should be used for testing. Many existing approaches to testing do not fully utilize common testing information. Testing
activities can be disassociated with each other, and you can end up reinventing material instead of reusing it. Your Testing Strategy (TE.010) should define an integrated
and proportionate approach. This is described in the Testing Strategy and/or test plans.
Test Planning and Test Design
Test planning should be started early in the project lifecycle. A test plan is a guide for how a specific test should be performed at various stages of the project. A test plan
is produced iteratively along with the development iterations to ensure that the plan reflects what is actually developed in the iterations. The test plan details the approach
described in the Testing Strategy, and includes information about tester roles and responsibilities, test types, test data and test estimates and scheduling. The test plan
evolves from high-level test cases into more detailed test cases.
A test case is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. A test case could
be a step in a test scenario, or a part of a test suite.
A test scenario is a test often formed as a scenario, or hypothetical story. The scenarios should be based on likely occurrences, most often built based on use case
scenarios, or business processes. A scenario should include steps to execute a test from end-to-end. The test scenario may be used to test whether functional or
supplemental requirements are met. Each scenario is described including the objectives for the test scenario, the setup requirements for the test, what the pre-conditions
are to be able to perform the test, and the required test data on a detailed level. It includes detailed steps that are needed to execute the test, and each step contains the
expected result.
A test suite is a collection of test cases that should be used to test a software program to show that it has some specified set of behaviors. A test suite often contains
detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing, including the required test data on a
detailed level. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests. A test suite and a test scenario are used
interchangeably.
The term, test scenario is used interchangeably with test suite. If you use both terms, the difference is typically that a scenario is based upon some story or process,
where a suite does not necessarily need to be based upon some story or process. Using that distinction, every test scenario is a test suite, but not every test suite is a
scenario.
An executable test suite is a test scenario that can be executed by a program, typically by means of a test harness or automated test framework (such as JUnit).
A test script is a collection of test cases that should be used to test a software program to show that it has some specified set of behaviors. These steps are often
executed automatically, but can just as well be executed manually.
The test sequence is the order in which something is tested.
A test item is something that should be tested. This could be indicated on various levels. As the lowest level test items (the actual implemented components) will vary
during the iterations, at an early stage the test items may be indicated on a higher level for example, functional/non-functional area, application, subsystem, module.
A test type is any possible kind of test to which a test item can be subjected (functional and non-functional). Test items evolve through iterations, and therefore the test
types may also evolve with the iterations. In the early iterations, the test types typically are to focus on the basics and foundations of the test item. Test criteria describe
the conditions under which a test has passed or failed. This is documented for each test item and for each test that should be performed. The test criteria might vary
depending on the iteration level of the test item, as in an early iteration it is likely, and acceptable, that there are more errors than there should be at the end of the last
iteration.
The test plans need to be revised, as requirements are refined by the ambassador users or as the solution's design changes. The continuity of the project team is
assumed in an OUM project and reduces the need for early, detailed test planning that is typical of a waterfall approach.
You start the test planning in the Elaboration phase with the development of the Integration Test Plan (TE.015). This plan contains the formal procedures for testing the
Use Case Model, the Analysis Model, the Design Model and the Architectural Implementation and the updates to these models that occur during the project by testing the
individual use cases as well as other identified related components together to make sure that they can be executed in a way that is consistent with what the users
expect, and that the integration between those components works together as a whole, in order to detect possible problems, inconsistencies and omissions. At this level,
you should be able to concentrate on testing aspects of the integration between the components rather than the individual components.
Next, you start developing the first version of the System Test Plan (TE.050) that is used for the system tests (TE.070.1) at the end of each iteration. The System Test
Plan (TE.050) is updated in Construction as requirements are refined and eventually become more stable. The most updated version of the plan is used for each system
test, and the final version is used for the final system test at the end of all the iterations.
The Systems Integration Test Plan (TE.080) is created at the end of the Elaboration phase, when the interface requirements and models have become relatively stable.
However, this plan must also be updated if there are any changes that impact the plan.
The planning of the acceptance test is a client task. However, you should assist the client in the acceptance test planning (TE.082) and motivate the client to start
planning the acceptance test as early as possible. This would give a valuable feedback on what their expectations are to the final work product. You might, based on this,
discover discrepancies in the understanding of parts of the system.
Designing tests is a key element of the Testing process and, in practice, contributes to defect prevention. The review of requirements during the design of a test scenario,
test sequence or individual test, can often prompt a change to the component, partition or system design or even to refining those requirements.
Tests are designed in the Develop Unit Test Scripts (TE.020), Create Integration Test Scenarios (TE.035), Create System Test Scenarios (TE.025), and Create Systems
Integration Test Scenarios (TE.084) tasks. In these tasks, test scripts, test case and test scenarios are created based on use case scenarios (RA.015/RA.023), use case
realizations (RA.024), and supplemental requirements (RD.055/RA.024). These scripts and scenarios are developed iteratively to ensure that they evolve as the
requirements evolve.
In particular, the Systems Integration Test Scenarios (TA.090) contains test scenarios that focus on the interaction between the systems. The Integration Architecture
Strategy (TA.030) and the High-Level Business Process Model (RD.011) are important inputs to determine these test scenarios.
Test Data
OUM emphasizes the need for early testing with real business data that usually must be converted from legacy systems or developed from new data sources (for
example, catalog data). As well as supporting more effective and realistic testing, users find it easier to test a system that contains recognizable business data. You
should analyze the data domains (or equivalence classes) in order to make sure that they are all covered in batch loading or during manual data entry as appropriate.
Sufficient code data should be loaded into the code tables as early as possible.
Also for the prototype validations, it is recommended to use as much realistic data as possible. All test data, both for prototype validation and other testing, is produced as
part of the Prepare Static Test Data (TE.018) task. However, as the requirements are changing through the process, it might be too much of an effort to produce a full set
of test data during early tests. Therefore, focus on providing test data for the most stable areas first, such as reference data (code tables).
Test Management
The Testing process defines the defect tracking, resolution, and regression test infrastructures required for providing dependable defect correction and trend analysis.
This is based on standard tools and integrated with the PJM Configuration Management (CM) process.
Components and Integration Testing
Integration testing is testing the integration of solution components (or test items).
As in all structured approaches to testing, the Testing process in OUM emphasizes early testing (and verification in general) at each appropriate level. Not only is it
important to start early with the testing of each individual component (unit testing), but it is also important to validate the developed use cases and any other additional
integration testing between those components as early as possible. Including this as an integral part of the development process allows for early discovery of integration
issues, and eventually makes the solution more solid.
Components included in the project would typically fit into one of the following categories, the generated components, the reused components and the hand-coded
components. All components, independent on how they are produced and unit tested, should move on to the integration test as soon as the unit test has been completed
to ensure that they work properly as a whole. The unit test for the various types of components may vary.
For the generated components, adequate review of the use case design effectively prevents defects at the component level. Less unit testing is often required for these
components. However, additional testing is needed in cases where the component has been modified after generation. For generated components, such modifications
should be avoided, however, because of the regression testing overhead they entail.
Reused components require, at a minimum, functional testing, followed by user review and validation. A function test is designed from a business perspective and is used
to ensure that the software delivers to the expectation and requirements of the business.
Hand-coded programs should be both white-box and black-box tested. Adequate review of the design prevents many defects. Involve ambassador users in the design in
order to reduce the time and effort needed in testing and reworking later.
Where the component has a visible user interface (for example, a web page or operator's report), it is beneficial if the ambassador user takes part in the integration test
(TE.040). However, the responsibility that a proper test is performed following the Integration Test Scenarios (TE.035), is still with the person in the role as a tester. The
purpose of inviting the user to join the test, is to allow for an even earlier discovery of discrepancies in the understanding of the requirements.
Wherever possible, make effective use of standard testing tools.
To allow for continuous integration throughout the iterations, you need an Integration Testing Environment (TE.038) that contains all the most up-to-date components.
This can be a challenge and makes proper configuration management a must. When a component is complete and unit tested, it should be released in the Integration
Test Environment as soon as possible, so that the integration can be tested.
The integration test of the components are continuously tested as part of the task Perform Integration Test (TE.040) and Perform System Test (TE.070) tasks.
System Testing
The preparation of the System Test Environment (TE.060) must be done early to make certain the client has all the required hardware and software in place when the
setup of the environment starts.
At the end of each iteration, you should perform a system test to validate the integration between all components that have been developed so far. This allows for an early
discovery of integration issues.
Therefore, the system test (TE.070) can be performed as many times as there are iterations in the Elaboration and Construction phases. The last system test is performed
at the end of the last iteration in the Construction phase.
The system test is performed according to the System Test Plan (TE.050), using the System Test Scenarios (TE.025). The system tests that are performed at the end of
each iteration, may not be as complete as the final system test. The size of the system test may vary from testing that everything compiles correctly as a whole, to a
complete test of all the System Test Scenarios. The approach you choose is often dependent on how the tests can be performed, and thereby how much effort is
involved in the test. Generally, the system test is more substantial If most of the scenarios can be tested using testing tools. If most scenarios must be tested manually,
the test is often less thorough as it takes too much time to complete them all. However, you should choose a number of key scenarios to test in order to discover possible
key integration issues.
Adequate review of the system design prevents many defects at the system level. Involve ambassador users in the high-level design reviews in order to reduce the time
and effort needed in testing and reworking later. Make as much as possible effective use of the standard testing tools. Testing should, at a minimum, cover all of the Must
have and Should have requirements. Testing of Could have requirements should be given a lower priority but make sure that the implementation of any such
requirements does not compromise data integrity or application stability. Having said that, code that should have been system tested, but falls out of the test because of a
low priority should not be delivered for acceptance testing. Therefore, all code that should be released into acceptance testing must be properly tested.
At the system level, some testing for supplemental requirements is performed. Performance testing is performed as part of the Performance Management process.
When planning testing of supplemental requirements, refer to the Security and Control Strategy (TA.090), and the Supplemental Requirements (RD.055). Operational
testing, backup and recovery testing and disaster recovery testing are performed as part of the Technical Architecture process.
Systems Integration Testing
Systems integration testing is performed where external systems interface to the new system. The procedures and tools involved in systems integration testing depend
upon the nature of the interface, the operating environment and procedures of the external system, and the kind of solution chosen (for example, XML, messaging, flat
files, transparent gateways, procedural gateways or ODBC). Special attention should be given to testing when interfacing to other databases (for example, locking
situations).
Acceptance Testing
Acceptance tests are typically used for end user acceptance and are often performed manually.
Performing the acceptance test is a client task, but helping the client to both plan and perform a proper acceptance test will decrease the risk for future problems. Assist
the client in the planning of the acceptance test (TE.082), and motivate the client to start with this at the end of the Elaboration phase. Seeing the clients expectations
while planning the acceptance test may reveal misunderstandings that then can be handled at an earlier stage.
When the test is performed by the client, you should support the client as part of the Support Acceptance Test (TE.120) task. The ambassador users along with other
users test the system following the given priorities of the requirements. This test should be performed with full production data volumes, but in a separate Acceptance
Test Environment (TE.110).
Test Metrics
For the purpose of process improvement, test metrics should be collected. Some of these are defined in the Quality Plan and others in the Testing Strategy. Some are
also used as an acceptance criteria. Typical test metrics include:
number and category of defects per component
number and category of defects per subsystem
number and category of defects per iteration (per partition)
average effort taken to correct a defect in each category
number of defects found per hour of testing, by category
number of defects per use case point
Project Learning
As multiple tests are performed through a number of iterations, both in the Elaboration phase, and the Construction phase, you gain experience in which aspects of the
tests work well and those that may not work that well. This may depend on a number of aspects, such as, the project members experience and type of application. At the
end of each iteration, plan a lessons learned workshop, involving all participants that have been involved in the test, including participants from development and
configuration control.
Adjust your testing approach according to your experience, and update the test plans accordingly.
Back to Top
TOOLS
Tool Guidance Application/Note
Oracle
Application
Test Suite
(OATS)
Testing and
Quality
Management
Tools
This process has supplemental guidance for using using Oracle Application
Test Suite (OATS) Testing and Quality Management Tools. Use the following
to access the process-specific supplemental guidance. To access all Oracle
Application Test Suite (OATS) Testing and Quality Management Tools
supplemental information, use the OUM Testing and Quality Management
Tools Supplemental Guide.
Oracle Application Test Suite (OATS) Testing and Quality
Management Tools is a complementary Oracle suite of tools that is
used to manage software testing for a project as well as to develop
test automation and performance testing, when used together these
tools can be used to maximize system performance and ensure the
quality and success of a project.
Back to Top
Inception Phase
Elaboration Phase
TE.010 Develop Testing Strategy Testing Strategy
TE.080 Develop Systems Integration Test Plan Systems Integration Test Plan
TE.082 Develop Acceptance Test Plan Acceptance Test Plan
Construction Phase
TE.065 Perform Installation Test Tested Installation Routines
TE.085 Prepare Systems Integration Test Environment Systems Integration Test Environment
TE.090 Develop Systems Integration Test Scenarios Systems Integration Test Scenarios
TE.100 Perform Systems Integration Test Integration-Tested System
Transition Phase
TE.105 Prepare Users for Testing Prepared Users for Testing
TE.110 Prepare Acceptance Test Environment Acceptance Test Environment
TE.120 Support Acceptance Test Acceptance Test Results
Production Phase
Back to Top
OBJECTIVES
The objectives of the Testing process are:
Produce usable systems, yielding early business benefits.
Validate that the requirements are met.
Improve quality of the system by early identification of defects
Secure project resources needed for testing. Obtain early user acceptance through participation in progressive validation.
Obtain early user acceptance on quality, suitability and meeting functional requirements through participation in progressive validation.
Introduce Testing activities early in the software development lifecycle.
Provide for traceability from tests to prioritized requirements.
Build on and reuse Testing work products in all phases of the process.
Secure ambassador user acceptance of the solution against critical business requirements.
Validate the business critical data and data access components prior to production release.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
BA Business Analyst Assist in creating the Unit Test Scripts. Provide input to preparation material for acceptance testing.
DBA Database
Administrator
Install and configure the user acceptance test database. Ensure all user acceptance testers have access to the database.
DD Database Designer Participate in determining what kind of data is required to execute the tests and participate in quality checking of the test data.
DV Developer Create Unit Test Scripts. Perform the unit test. Walk through problems from the installation test with the system administrator, and provide
other required assistance. Provide support for user acceptance tests by answering questions and helping resolve potential issues.
Represent the project team.
SAD System
Administrator
Install application software. Provide support for the testing. Perform the installation test. Install and configure hardware and operating
system. Install and configure application code. Ensure that login IDs exist for the user acceptance testers. Support user acceptance tests.
SAN System Analyst Determine and document the Testing Requirements. Assist in creating the Unit Test Scripts. Oversee, review and approve the development
of the System Test Scenarios. Assist in performing the unit test. Assist the client in developing the Acceptance Test Plan. Support user
acceptance testing by providing assistance about business requirements.
SA System Architect Participate in the preparation of the technical architecture environment to support testing. Support user acceptance testing by providing
assistance about system architecture.
SA
(IA)
System Architect
(Information
Architect)
Participate in determining what kind of information (data) is required to execute the tests. Participate in the preparation of the Information
Architecture for the environment to support testing. Support user acceptance testing by providing assistance about Information Architecture.
TE Tester Develop Testing Strategy and Integration Test Plan. Develop the System Test Scenarios. Create the Integration Test Scenarios. Provide
support for the creation of the various Testing environments and prepare Testing tools. Perform quality check of the environments. For
some projects, this may be a lead tester. Develop test details and perform test. Review test details and monitor test results. Provide support
for integration tests by reconciling differences between design requirements and the application and represent the project team. Develop
System Test Plan. Perform the system test. Manage the system test. Answer questions and resolve potential issues. Represent the project
team. Monitor test execution and results. Develop the Systems Integration Test Plan. Assist the client in developing the Acceptance Test
Plan. Develop the Systems Integration Test Scenarios. Oversee, review and approve the development of the Systems Integration Test
Scenarios. Perform the systems integration test. Manage the systems integration test. Provide support for systems integration test by
answering questions and helping resolve potential issues. Assist the Validation Coordinator in preparing material and the test instruction
class for acceptance testing. Ensure facilities, hardware, and software are configured and installed properly. Ensure availability of facilities
coordinator, system administrator, and database administrator. Ensure facilities, hardware, and software are configured and installed
properly for acceptance testing. Ensure availability of facilities for acceptance testing. Review and resolve any issues that arise for
acceptance testing.
Client (User)
KEY Ambassador User Participate in the determining the Testing Requirements. Assist in providing appropriate test data to execute the tests and participate in
quality checking the test data. Review the System Test Scenarios to verify relevance relative to business. Participate in the various tests.
Review the System Integration Test Scenarios to verify relevance relative to business. Provide input to preparation and class material for
acceptance testing.
CDA Client Data
Administrator
Assist in providing appropriate test data to execute the tests and participate in quality checking the test data.
CPM Client Project
Manager
Ensure availability and commitment of users. Ensure availability of hardware, software and facilities. Develop sense of teamwork and
ownership of the new application. Review and resolve any issues that arise from acceptance testing.
OS IS Operations Staff Set up hardware and system software configuration for the various Testing environments. Provide support for the Acceptance Test
Environment.
SS IS Support Staff Provide support for the creation of the various Testing environments. Provide support for the Acceptance Test Environment. Provide support
for the user acceptance tests.
USR User Read preparation material and attends test instruction class for acceptance testing. Ensure the application functions properly so that user
acceptance testing can begin. Conduct user acceptance tests and log results.
VC Validation
Coordinator
Develop the Acceptance Test Plan. Lead the production of the preparation material, prepares and conduct the test instruction class for
acceptance testing. Lead and coordinate the user acceptance test from the client side.
Back to Top
A Project Plan that Endorses an Integrated Testing Approach: Only if the testing is planned throughout the project as an integrated part of the iterations, will it
be tested. Therefore, ensure that testing is a visible task on the Project Plan for each build and iteration.
The Development of Testable Requirements: Requirements can be of different quality. Requirements where you cannot define a proper Testing Strategy are
often vague and confusing. While making or reviewing the requirements, determine how they can be tested. If it is difficult or impossible to find a testing approach,
a clarification and/or detailing of the requirement must be performed.
Design for Testability: In a similar way as for the requirements, the design must also be testable.
Effective Verification of Analysis, Design and Test Planning in Order to Prevent Defects and Reduce the Test and Rework Effort: Testing must start before
the actual components have been developed. The models (Analysis, Design) must be tested (reviewed) each time they are created/updated. Detecting errors at
this level will prevent those errors being taken further into the next level.
User Commitment and Availability to Provide Progressive Validation: One of the reasons for an integrated testing approach is to get early feedback on the
designed or developed components. Having users take part in this validation makes the benefit even larger, as you get early feedback on errors,
misunderstandings and even changes in requirements. Therefore, it is important to get the users committed to making themselves available and taking part in this
task.
Effective Testing Through Use of Standard Tools: A number of tests are repetitive and can be made more productive by using either tools/components that are
available on the market or those that you build yourselves.
Back to Top
TE.005 - DETERMINE TESTING REQUIREMENTS
In this task, the testing requirements for the project are defined. This covers the requirements for all tests that should be performed in the project, from unit testing to user
acceptance testing. Also the customer's sign-off requirements for user acceptance testing are defined. These sign-off requirements are usually specified in the customer's
contract. Testing Requirements must be appropriate to the significance, or critical nature, of the solution to the business.
The Testing Requirements are used as a baseline to determine the Testing Strategy (TE.010) and to plan all the tests that should be performed on the project. The task is
mainly performed in the Inception phase, but there may be a need to make some updates in the details during the Elaboration phase.
For projects that involve the upgrade of Oracle products, this task is focused on determining the number of upgrade test iterations and the differing prerequisites for each
iteration. For example, the first upgrade test may be performed against a vanilla environment with no custom extensions using the standard upgrade steps; therefore,
updated custom extensions and migration routines are not needed. The final upgrade test is performed against a copy of the production instance with all custom
extensions and integrates all special upgrade steps for custom extensions and data migration needs.
ACTIVITY
TE.005.1
TE.005.2
Back to Top
WORK PRODUCT
Testing Requirements - The Testing Requirements define the requirements for testing. This work product includes the testing requirements that are of a significant or
critical nature to the business. The Testing Requirements also define the scope of non-functional testing.
Back to Top
TASK STEPS
1 Review the testing
requirements in the
Reviewed Project
Approach (PJM.BT.060).
None None
2 Obtain and review any
existing test plans and
standards.
None None
3 Determine testing
objectives
Objectives The Objectives lists the objectives for the Testing Requirements.
4 Develop testing
requirements.
Introduction
General
Testing
Process
Requirements
Functional
Testing
Requirements
Non-
The Introduction states the purpose of the Testing process which is to check that the system is fit for the business
purpose. Tests will be executed in order to find and correct defects.
The General Testing Process Requirements describe the general testing requirements as stated by the client
organization. These requirements are usually obtained from the organizations Quality Management System. If the
organization has no previous history of IT development, then requirements might need to be formulated and agreed
on.
The General Requirements may also include requirements about which testing tools should be used and what testing
environments will be required.
The Functional Testing Requirements component states any special requirements that the client organization has
made to functional testing. There are several things to consider when completing this component, such as:
Functional
Testing
Requirements
Acceptance
Testing
Requirements
Identify the testing requirements at a detailed level.
In a BI Custom engagement, this could be a detailed list of all data acquisition components or data access
components.
For ease of use, you may categorize the requirements by Business Areas or any other logical grouping
Focus on the fitness for business purpose, in relation to the defined business objectives.
The Non-Functional Testing Requirements component states any special requirements that the client organization has
made to non-functional testing. There are several things to consider when completing this component, such as:
Focus on its fitness for business purpose in relation to the defined business and system objectives.
Include like architecture, integration, security, recovery, etc.
The Acceptance Testing Requirements component states the requirements related to user acceptance testing.
5 Review and comment on
the Testing Requirements.
None None
6 Review, approve and sign
off on (cover page) Testing
Requirements.
None None
Back to Top
APPROACH
An established, universal rule of software testing is that before you can run a test (or perform a test step), you need to know the correct outcome of that test (or test step).
In a project using a waterfall approach, the testing focus is on conformance with defined requirements. However, using an OUM approach, the lack of complete and
detailed requirements at the start of a project makes close collaboration between developers and users a necessity. Requirements, including requirements for testing, are
developed, documented and prioritized throughout the lifecycle of an OUM approach project. Testing is performed progressively against functional and non-functional
requirements as the requirements are defined and the components are delivered. Regression testing is essential, and should be automated, wherever possible, using
standard tools.
Requirements to the Testing process may have been stated or implied during scoping. If not, the lead tester should, together with the client, suggest a set of minimum
requirements for testing throughout the project. This includes requirements to acceptance testing. The requirements will depend on the type of application, its criticality,
use and complexity. These requirements serve as an input for developing the Testing Strategy (TE.010). Any existing test plans or standards previously used by the
client should be examined for possible reuse. Discussion of testing at this stage should contribute to reducing any remaining concern about the approach, especially if the
clients IT department only has experience and faith in a waterfall lifecycle.
OUM recommends a testing approach that allows for continuous integration. This means that you perform integration tests (on use cases as well as on any additional
identified group of interrelated components) as part of the iterations, and a system test at the end of each iteration. This system test at the end of each iteration is not a
full system test, in the same way as the test that is performed at the end of the last iteration, but should, at a minimum, cover the essential system test procedures. You
should document in the requirements what kind of test scenarios should be performed at the end of each iteration at an overview level. At a minimum, this could just be to
ensure that everything compiles, up to the maximum where all system test scenarios are performed. Which approach to choose is dependent on the size or complexity of
the application, as well as available testing resources and environments. For small, relatively simple applications, you might choose to do a full system test, but for a large
and complex project this might not be feasible.
Start with identifying the testing requirements the clients quality systems require and then defining the scope of testing after the prioritization exercise. The requirements
are then categorized to functional and non-functional requirements. Performance is excluded from the scope of this task as it is performed as a separate task in the
Performance Management (PT) process.
Set Correct Expectations for Tests During the Iterations
It is important that appropriate user expectations are set for the result that is presented or delivered during the development iterations. Typically, during the early
iterations, the custom built software contains more errors, because the developers focus is to develop components to verify their understanding of the requirements
rather than produce error-free code. Also, at this stage, the users focus should be to verify the conformance to and completeness of the requirements, rather than
discover errors in the code. Discovering errors is at this stage a positive "side-effect", and should still be reported. During the later iterations, the focus changes for both
developers and users; the requirements stabilize and the focus should be to produce complete and error free code, but still in conformance to the requirements as they
have been agreed upon up until that point.
If the Testing Requirements are determined to find every error in a component during all the iterations, then this would make an unnecessary overhead, and work against
the flexibility intended using an iterative process.
Obtain Existing Testing Documentation
You should locate and review any testing documents from earlier projects completed by the organization. Try to identify any principles that the organization might expect
to apply to the current project, and any opportunities for reuse. If existing documentation shows that only waterfall kind of projects have been performed in the past,
ensure that the difference between that and testing in an iterative project is made clear and understood.
Develop Detailed Testing Requirements
You should document what the client organization requires from Testing activities in the project. This covers user acceptance testing requirements, but it also covers the
requirements for all the other tests during the project. The requirements should be determined together with the client, to ensure that the requirements reflect the clients
expectations. You should also include requirements for non-functional testing, except for performance testing is covered in a separate work product. Include requirements
to test various kind of non-functional requirements. For example, most clients have requirements that the system be maintainable, therefore, include requirements for
maintenance testing.
The testing requirements from the client might be as simple as, We expect you test everything before our users try it, but most clients have more detailed requirements
imposed by corporate policies, a Quality Management System or regulatory bodies. You should also inquire about any applicable quality standards to which the project is
expected to comply.
Testing Tools
If the client has specific requirements for using certain testing tools, it should be documented as part of the Testing Requirements. Be aware that more detailed
documentation about how testing tools should be applied in the different test phases, should be documented in the Testing Strategy (TE.010). Also if the client already
knows the requirements for the testing tools, but has not yet selected the actual tool, then document the requirements for the testing tool(s) in this document.
If various testing tools should be tried out as part of the selection process, the results should be documented in the Testing Strategy document.
Testing Environments
Document the requirements for the testing environments that are needed for the various tests during the project. More details about the environments, and when and how
they should be used is documented in the Testing Strategy (TE.010).
Obtain Executive Review and Approval
This task provides an opportunity to discuss with the project sponsor the costs associated with meeting the Testing Requirements in the time available. This discussion
might focus on what might be gained by the introduction of testing tools. Do not forget to consider the training needs related to these tools. Once the Testing
Requirements have been signed off, work can begin on the development of the Testing Strategy (TE.010).
Back to Top
Back to Top
System Analyst Determine and document the Testing Requirements.
If a Testing (or other) team leader has been designated, 20% of this time would be allocated to this individual, leaving
80% allocated to the business analyst. The team leader would then assist in determining the Testing Requirements.
100
Ambassador User Participate in the determining the Testing Requirements. *
Back to Top
PREREQUISITES
Prerequisite Usage
Reviewed Project Approach
(PJM.BT.060)
The Reviewed Project Approach may include a high-level approach to testing, along with definitions. The first step in this task is
to review and, if necessary, modify the testing approach as defined in the Reviewed Project Approach.
(PJM.WM.010)
The Project Workplan provides the overall timeframes, estimates, and resources that have been allocated to Testing, by phase.
This part of the Workplan may need to be revised once the Testing Requirements have been established.
(RD.001)
The Business and System Objectives provide an indication on how thorough the system should be tested. It also provides an
understanding of the project purpose, project schedule, complexity, and significance of the new system to the business.
MoSCoW List (RD.045) The MoSCoW List contains the prioritized requirements which may have an impact on the Testing Requirements.
(RD.055)
The supplemental requirements may have an impact on the Testing Requirements.
Skilled Project Team (TR.050)
Back to Top
TECHNIQUES
Technique Comments
Service Testing Use this technique to help you define the testing requirements for services.
SOA Service Lifecycle Use this technique to understand where service testing fits in the overall SOA service lifecycle.
Back to Top
TEMPLATES AND TOOLS
TE-005_TESTING_REQUIREMENTS.DOC MS WORD
Back to Top
The Testing Requirements is used in the following ways:
to reach agreement on the scope of testing and the approach to testing
to build confidence in the development approach
to make visible the staffing issues related to testing
Distribute the Testing Requirements as follows:
to the project sponsor for approval
to the internal auditor for review
to the acceptance test leader for review
to other stakeholders
You should distribute this work product to other team members together with the Testing Strategy (TE.010) when both documents have been completed and approved.
Back to Top
QUALITY CRITERIA
Is it clear from this work product what is expected from the Testing process?
Are all functional and non-functional testing requirements clearly defined?
Are the requirements for user acceptance testing clearly defined?
Are all resource and tool requirements that could impact the testing process stated and understood?
Have testing considerations started in the early phases of the project?
Will the testing be objective and performed by an independent test team where feasible and appropriate (other than the programmers responsible for the
component)?
Back to Top
TE.010 - DEVELOP TESTING STRATEGY
The purpose of this task is to develop the project direction as it relates to testing. This should include how testing should be performed in the various stages at the project,
which tools should be used (if any) and how, what metrics should be collected, how test data should be produced and what testing environments should be used in the
tests. The strategy should also define the acceptance criteria of the solution.
Specific considerations include test data to be used, system interfaces, the scope of testing, the types of testing, testing scenarios and integration testing, data loads, and
ad hoc access if required. It defines the recommended approach to testing, and how to manage testing errors, the types of tests to run, what is required to run the tests
(including the test environment requirements), when and how (for example, manual versus automated) to run them. It also includes the sequence in which to run the
tests. The aim should be to identify test cases and procedures with a minimum overlap, to test the most important use cases, and to test requirements that are associated
with the highest risks.
At a minimum, the Testing Strategy must address all of the requirements documented in the Testing Requirements.
ACTIVITY
Back to Top
WORK PRODUCT
Testing Strategy - The work product for this task is the Testing Strategy. Based on the characteristics of the system to be built, specific testing activities may be more or
less important to a successful implementation. Specific considerations include converted data, performance, system interfaces, the scope of testing, the types of testing,
and the significance, or critical nature, of the system to the business.
Back to Top
TASK STEPS
1 Review the Reviewed
Project Approach to verify
whether something has
been determined about
testing (PJM.BT.060).
None None
2 Review the Testing
Requirements (TE.005) to
ensure that the Testing
Strategy will support
these requirements.
None None
3 Obtain and review any
existing test plans and
standards.
None None
4 Determine testing
objectives and benefits.
Objectives
and Benefits
The Objectives and Benefits components list the objectives of the Testing Strategy, and the benefits that should be
provided by following this strategy.
5 Identify the scope of the
testing, testing types and
relationships to other
projects and systems.
Scope The Scope defines the tests that should be performed, and what needs to be confirmed in the various tests. It also
includes the interfaces with other systems that should be tested.
Work with ambassador users in deciding the testing approach, and the type of tests that need to be performed.
6 Develop Testing Approach Approach The Approach describes how the various testing tasks should be performed in the project. Determine for each test the
approach and the focus for each phase and iteration.
The Approach looks at the characteristics of the system to be built, technical risks, and plans the breadth and depth of
the testing effort. It influences tasks related to test planning, test types, test script development, and test execution.
Review the OUM Testing work products with the project team and obtain agreement on those suitable for the project.
7 Determine required test
data.
Test Data
Converted
The Test Data component lists the kinds of test data that are required for the various tests. It defines how to obtain the
test data, and when it will be needed. It documents the requirements for test scripts and test data and explains how they
will be managed.
#TOP #TOP
Data
Sources
Other Test
Data
The Converted Data Sources component specifies which converted data sources are required for the tests.
The Other Test Data component specifies which other kind of test data will be required, or test data that will be needed
before the data have been converted.
8 Determine constraints for
the test.
Constraints The Constraints document all the constraints in which the testing must occur and that may impact the way testing
activities must be performed. Document the constraints in the following categories: Time, Required System Resources,
Business and Technical.
9 Determine use of testing
tools and testing
environments.
Testing Tools
Testing
Environments
Both Testing Tools and Testing Environments might have been defined as part of the Testing Requirements. If this has
not been done, you should do that as part of the Testing Strategy, and if it has already been defined, you should verify
whether the tools and environments best support the chosen Testing Strategy. This should include the identification and
documentation of the configurations of test environments and capacity requirements.
The Testing Tools component describes the testing tools that will be available for the various test, and with what
purpose they will be used. Review with the project team any existing testing tools they may have used and assess their
fitness of use on the project.
The Testing Environments components describe for each test that should be performed, which testing environment will
be used.
10 Document Acceptance
Criteria.
Acceptance
Criteria
The Acceptance Criteria show the actual criteria for the client to accept the final system. This information is normally a
part of the contract, but you may decide to duplicate the information here as it might be that not every project participant
has access to the contract. Most often the acceptance criteria is based on an accepted level of known defects/problems
of different criticality.
11 Document how problem
management will be
performed.
Problem
Management
Problem Management is normally determined as part of the Project Management Process (PJM), Issue and Problem
Management Process. Problem management should be adopted at the overall project level. Therefore, the Testing
Process uses the same Issue and Problem Management Process that each of the other OUM processes use, so
therefore this section would only include a reference to the documents that describe the Issue and Problem
Management procedures. Review the PJM Issue and Problem Management Process with the client.
Indicate the tool (e.g., MS Excel, Bugzilla) that will be used for Issue and Problem Management. The defect
categories for example, functionality, navigation, usability, manual data, conversion data, performance, help text,
or test script are documented using the tool. In addition, the fix priority categories (for example, critical, high,
medium, and low) and expected time of completion are held in this system.
Insert a process diagram that shows the Issue and Problem reporting and resolution steps.
12 Determine critical success
factors.
Critical
Success
Factors
The Critical Success Factors associated with meeting the objectives of the process within the context of the overall
project are also identified within this component.
13 Determine risk and
contingency plans
Risk and
Contingency
Plans
Any risks and their associated contingency plans are documented in the Risk and Contingency Plans component.
14 Determine testing metrics
and collection
mechanisms.
Testing
Metrics and
Measures
The Testing Metrics and Measures describe the testing metrics and measures that should be collected at the various
tests during the project. This also gives a high-level idea of the amount of the testing that needs to be done.
15 Review and comment on
the Testing Strategy.
None None
16 Review, approve and sign
off on (cover page)
Testing Requirements.
None None
Back to Top
APPROACH
Use the Testing Strategy to document the testing strategy, the approach, and the scope of testing involved. The Testing Strategy includes a listing of the types of testing,
and the purpose of each testing task. Unless it has been described in the Testing Requirements, the strategy also contains a description of the required testing
environments, what tests will use which environment and the tools that will be used to perform testing. Define how to manage testing errors, the types of tests to run,
what is required to run the tests (including the test environment requirements), when and how (for example, manual versus automated) to run them. The aim should be to
identify test cases and procedures with a minimum overlap, to test the most important use cases, and to test requirements that are associated with the highest risks.
In the Testing Strategy you establish or provide the following:
a list of testing requirements
an understanding of the type and purpose of each testing task
an understanding of the work products for each testing task
an overview of the testing tools
detailed acceptance criteria for testing
Obtain a formal acceptance of the testing approach from the client.
Scope and Approach
In an OUM project, test results are accepted whenever the system performs in a way that meets the business needs. In order to achieve a business-oriented measure of
fitness for purpose, the emphasis in testing should be placed on whether the business process, with its supporting application system, meets the objectives stated in
Business and System Objectives (RD.001). You should describe all aspects of the Testing process in simple terms.
OUM recommends a testing approach that allows for continuous integration. This means that you perform integration tests (on use cases as well as on any additional
identified group of interrelated components) as part of the iterations, and a system test at the end of each iteration. This system test at the end of each iteration is not a
full system test, in the same way as the test that is performed at the end of the last iteration, but should, at a minimum, cover the essential system test procedures. As
part of the Testing Requirements (TE.005), you should have documented what kind of test scenarios should be performed at the end of each iteration at an overview
level. Document, in more detail, the approach that should be taken for earlier system tests (TE.070) versus the final system test in the Testing Strategy. Which approach
to choose is dependent on the size or complexity of the application, as well as available testing resources and environments. For small, relatively simple applications, you
might choose to do a full system test, but for a large and complex project this might not be feasible.
The approach you choose to use may also vary depending on how far you have approached in your project. For example, if you have already delivered a version of the
application to production, you may want to approach the iterative development in a way where you typically would deliver a release at the end of each iteration. If that is
the case, you need to perform a full system test (for the areas that are affected) at the end of each iteration to prevent production problems.
Integration Tests are performed continuously during the iteration, whenever components (or use cases) are ready for integration testing.
Test Scripts and Scenarios
Test scripts and test scenarios are used to guide the Testing process and record the test results. Test script development should be based on key project work products,
requirements, acceptance criteria and risks. OUM recommends that test scripts for unit tests and test scenarios for integration tests are produced as early as possible,
and the developer developing the actual components should be involved. In particular for unit testing, OUM recommends that the test scripts are produced by the
developer before the actual code has been produced. This allows the developer to think through the problem in a different manner than when the component first is
developed, and eases the testing of the component after it has been developed. In a similar way, OUM recommends that the Integration Test Scenarios for testing the
use cases are produced before the components that implement the use cases are developed . By doing that, it becomes more clear how the components should interact
in a certain scenario. For more details about these work products, see the guidelines for Unit Test Scripts (TE.020) and Integration Test Scenarios (TE.035). The Testing
Strategy should document how these tests should be performed, and how and when their related scripts and scenarios should be produced.
Test Data
Make sure that the requirements for testing data are clearly defined, so that the client organization receives clear instructions about what must be delivered and when,
together with the consequences for project deadlines of failing to deliver the test data on the planned dates.
Use this task as an opportunity to ask for test data. Where existing systems are to be replaced, conversion planning should take into account the need, in the Testing
process, for real business data, in volumes that will support progressive volume testing appropriate to each stage of development. Real business data is a benefit
because users cannot relate to fake data in screens and reports. During early development iterations, you will probably have to manage with developer-created data.
There is little point in loading converted, real business data before the Database Design (DS.060) and the Implemented Database (IM.040) are stable.
However, consider the following regarding test data:
Can data be manually entered?
Can data be automatically generated using tools?
Can data be sourced from production or test systems?
Is the data of sufficient quality and quantity for testing?
Test Environments
Test environments should be developed in parallel with Configuration Management planning.
Tool Support
Testing tools can be of enormous benefit in improving testing coverage, reducing the time developers and users need to spend on tedious Testing tasks and developing
test scripts (that become test records). In an iterative approach to Testing, testing tools can be beneficial in enabling automated regression testing that can be performed
in batch runs overnight or during lunch breaks. Investigate what testing tools are available for the platforms, protocols and the user interface type used in the project, and
make an appropriate recommendation to the project sponsor. You may also want to test some different testing tools, produce some prototypes to see what tool is the
most effective in your project situation.
There are several things to consider when looking into tools for test support, such as:
Review functional testing capabilities.
Review performance testing capabilities (if no formal performance test is being performed).
Review Test Case Management capabilities.
Review capabilities to support defect management/configuration management.
Does the tool reduce the effort needed to develop and manage test scripts?
Does the tool improve the effectiveness of testing?
Does the tool automate test execution?
How does the tool make tests more repeatable?
Be prepared to cope with some difficulties in using testing tools when the components and the Database Design change during development. Flexibility of the testing
tools, and if possible integration with version control and document management tools, will help to make testing go smoothly. Also take into account any training needs
associated with testing tools. Training in the use of testing tools can provide, as a side benefit, training in testing techniques.
Testing tools supply some or all of the following features:
test case management
test results and reporting
test defects management
regression testing
stress testing
Test Case Management
This is one of the most important tools available to support the lifecycle of Testing. Features of a good tool will allow you to create a test case repository for reuse in the
development of specific testing scripts. There are numerous tools that will allow the testing manager to determine the state of each test script and whether the scripts are
currently under development or are ready to be executed.
Test Results and Reporting
Determine the reports required for your project and whether you need to develop additional reports. Standardize the test result classifications (for example, pass, fail,
skipped, or not executed). Verify whether the test tools have result compilation and reporting capabilities, and how users access this information.
Test Defects Management
Determine your test defect workflow. Many tools support standard workflow states but also allow customizations. The Testing Requirements and Strategy must clarify and
standardize the defect workflow in the tool (for example, open, assigned, fixed, verified, or closed).
Regression Testing
Determine your level of regression testing automation. Regression test automation is now a very realistic option. Current tools feature the ability to record user actions and
learn GUI objects, capturing this information into test scripts. You can then generalize the scripts to use variable data, enabling the scripts execution to be data-driven.
If your organization is considering automating its regression testing, clearly define your automation goals and plan extra time for script development and generalization.
Place test scripts under configuration control and update the scripts each time the application is updated.
Relationship to Performance Testing
The Testing process does not address volume and stress testing; these are the subjects of the Performance Management (PT) process. Coordinate with the
Performance Management team on your project so that you can share resources, business processes, and automation tools. Depending on how many configurations the
Performance Management team plans to evaluate, you may be able to schedule one of the tests on the same configuration on which you are planning to run the system
test.
Reuse
Try to reuse testing components where possible, both within and between iterations. Reusable components might include:
Test scenarios (threads) and sequences
Test scripts and scripted data for automated testing
Test drivers (harnesses)
Validation Strategy
An essential element of the OUM approach is the continuous involvement of ambassador users and adviser users, who progressively validate both the application system
and the defined requirements. In contrast to a waterfall approach, in which requirements are all defined at the start of the project and validated at its end, the OUM
approach is designed to allow the requirements to be refined during collaborative development. Ideally there is only a short delay between the user participants defining a
requirement and the developers presenting pages/screens and other user-visible parts of the system.
User Validation During Development
For each type of test, document to what extend is it expected that client resources should be involved. However, if you do involve client resources in the Testing activities,
keep in mind that the developer organization still is responsible, with the exceptions of the Acceptance Test. The users participation does not change that.
Also, consider a testing approach where you pair the tester with an Ambassador User having the appropriate functional knowledge. This often results in better
understanding for both the tester and the user, and will often result in better error detection, but may also result in improved requirements (that may be implemented in a
later iteration if prioritized so). In this way you deliver a system that better complies to the actual business and system requirements. Less surprises and corrections will
be needed during the full system test or acceptance test.
You need to document a commitment to user participation and availability. A certain amount of negotiation is usually needed to obtain the necessary levels. Creative
compromise might be required. For example, you might agree that:
All ambassador users will be available for reviews on certain days of the week during certain hours, except during scheduled busy periods.
All ambassador users will be available to answer questions or to make appointments by telephone during office hours.
Ambassador users will be contacted before 09.00 if they are needed on the same day.
One of the ambassador users will always be present in the project room during specified hours on working days.
A named user will be assigned from each site or office, to participate in requirements workshops and during later stages of testing and validation.
Review comments will be logged in a tracking system or sent to a dedicated email account.
A limited number of reviews or workshops will be arranged during weekends.
Developers and ambassador users will meet for a working lunch on certain days of the week.
Testing Metrics and Measures
A part of the testing process is to determine what testing metrics should be collected and measured against. This may be different for the various tests, and may even
differ per iteration, depending on what is the objective of the test in question, and how the measure should be used.
By collecting these kind of figures you may get an idea of how well the testing is performed (too few in the beginning of the project often indicates that it is not sufficiently
tested, or not well enough), how the application evolves (if the number of successfully completed test scenarios increases significantly this seems like a healthy
progress), and so on. Also often the acceptance criteria, or end criteria for a test is based on such figures.
Determine what kind of testing metrics you will use in the project, and how they should be measured, used and collected.
Back to Top
Technique Guidance for Service-Oriented Architecture Implementations
If your project involves SOA implementation, the Service Testing technique provides important guidance for testing services.
Back to Top
Tester Develop Testing Strategy. For some projects, this may be a lead tester. 100
Back to Top
PREREQUISITES
Prerequisite Usage
(PJM.CM.010)
The environments that will be used for testing should be synchronized with the promotion levels defined in the
Configuration Management Plan and Processes.
Business and System Objectives (RD.001) The Business and System Objectives states the objectives to be met by the new system.
Use Case Specification (RA.024.1) The Use Case Specification provides use case scenarios that lead to test scenarios that need to be tested in the
various tests, and therefore is an input to the Testing Strategy.
Testing Requirements (TE.005.2) The Testing Strategy must be in line with the Testing Requirements as the strategy describes how the
requirements will be satisfied.
Data Acquisition and Conversion Requirements
(CV.010)
The Data Acquisition and Conversion Requirements indicate which business objects will be converted, and
where data may be used during testing.
Back to Top
TECHNIQUES
Technique Comments
Service Testing Use this technique to help you define the testing strategy for services.
Back to Top
TEMPLATES AND TOOLS
TE-010_TESTING_STRATEGY.DOC MS WORD
Back to Top
The Testing Strategy is used in the following ways:
by the client organization to increase confidence in the OUM approach
by the developers, testers and users on the project team to understand the approach for testing the solution components, and to explain to developers and users
what is expected of them in an OUM project with regards to testing
by the project manager to understand the approach and impact of this on dependent tasks
Distribute the Testing Strategy as follows:
to the project sponsor
to other stakeholders
to all team members
Back to Top
QUALITY CRITERIA
Have the Clients IT systems quality policies been discussed before arriving at the testing approach?
Does the document make clear what is expected from the client organization in relation to validation and testing?
Are the consequences of failure to deliver adequate test data at the time it is needed, clearly stated?
Is the project team able and willing to perform and document testing as described in this document?
Are the testing scope and objectives clearly identified?
Are the testing types clearly communicated in this deliverable?
Are specific critical success factors and risks to testing documented?
Are all resource and tool requirements that could impact the testing process stated and understood?
Are the metrics and measures defined in a way they can be collected?
Are the problem management workflow tool details covered and is the resolution process detailed out?
Is it clear from this deliverable what is expected from the Testing process?
Will test script development be based on key project work products?
Will the testing be objective and performed by an independent test team where feasible and appropriate (other than the programmers responsible for the
component)?
Will the problem management process be functional as soon as testing begins, and will it ensure that only valid and non-duplicated defects are processed?
Has there been planned for multiple iterations for each testing task to allow for a higher density of testing for the current test iteration and scheduled fixes for the
next iteration?
Will planning for the systems integration test start early, as it will involve multiple projects, systems, and organizations?
Has the scope of the regression test been clearly defined?
Has an automated tool been considered to perform regression testing?
Will locking, response time, and stress testing use process-based testing scripts?
Will testing components be categorized by their relative importance to the business for defect prioritization and testing?
Back to Top
TE.015 - DEVELOP INTEGRATION TEST PLAN
In this task, you develop the Integration Test Plan, which you use as a guide to perform the integration tests that are performed during the iterations in the Elaboration and
Construction phases. The Integration Test Plan is produced iteratively along with the development iterations to ensure that the plan reflects what is actually developed in
the iterations.
Define the approach to the integration of solution components. This includes information about tester roles and responsibilities, test types, test data and test estimates
and scheduling.
The test plan evolves into high-level test cases that evolve into more detailed test cases. It is common to have multiple iterations of testing (unit test, integration test,
system test, systems integration test) before the final user acceptance test. There could be one or more test results documents depending on whether or not the test
plans are integrated.
and/or integrate the COTS system with other COTS or legacy systems. An integration test verifies that application extension components are properly linked and no
coding errors are generated when related components are linked together.
ACTIVITY
TE.015.1
TE.015.2
Back to Top
WORK PRODUCT
Integration Test Plan - The Integration Test Plan contains information necessary to plan, prepare for and conduct the integration tests.
Back to Top
TASK STEPS
1 Review the Baseline Project Workplan
(WM.010) to see how integration
testing activities have been planned,
and the Quality Management Plan
(QM.010) to review how quality will be
ensured.
Introduction The Introduction include a reference to these documents and document any specifics related to the
documents.
2 Review the Testing Strategy (TE.010)
document. The Integration Test plan
should be within the boundaries
provided by the Testing Strategy.
Introduction Document any specifics related to this document. Also include a reference.
3 Determine the scope of integration
testing.
Integration
Test Scope
The Integration Test Scope describes the scope of the integration test for the iterations in both the
Elaboration and Construction phases. The scope describes Test Types that should be performed during the
integration tests. It also lists the Test Items that should be tested, the features that should be tested, and the
features that for some reason should not be tested.
4 Determine the approach of integration
testing.
Approach The Approach section includes the approach that you will use for the integration tests. This should have
been documented earlier in the Testing Strategy document for integration testing. If additional information is
required, include it in this section. Do not repeat the approach as described in the Testing Strategy, but
include a reference.
5 Determine pass and fail criteria for test
items.
Item
Pass/Fail
Criteria
The Item Pass/Fail Criteria documents the criteria when a test has passed.
6 Determine the work products for
integration testing.
Integration
Test Work
Products
The Integration Test Work Products component describes what will be delivered as a result from the
integration test. This should reflect the work product as described for the Integration Test (TE.040).
7 Determine the testing tasks and
schedule.
Integration
Test
Schedule
The Integration Test Schedule component lists all the Testing tasks that should be performed as part of the
integration test. It also includes a schedule for when the tasks should be performed. This should be inline
with the overall project plan. If the project plan has sufficient details, do not repeat the content of the project
plan. Instead refer to it.
8 Determine detailed Integration Test
Environment requirements.
Resources The Environment Requirements section of the Resources component describes in detail the hardware and
software requirements to the environment, including other kind of physical requirements needed to perform
a proper integration test. The Testing Strategy (TE.010) includes details for the required testing
environments. If it contains sufficient level of detail, do not repeat the content, but include a reference.
9 Determine integration test
responsibilities.
Resources The responsibilities part of the Resources component describes the roles that should be involved in the
integration test, what their responsibilities are. It also lists one or more persons that are responsible for the
various test types.
10 Determine staffing and training needs. Resources The staffing and training need part of the Resources component describe the required skills for integration
testing, and what the training need are for those that should be involved in system testing. The Project
Team Learning Plan (TR.020) should include this kind of information. If this is sufficient, do not repeat the
content, but include a reference.
11 Identify risks and related risk
management.
Risk
Management
The Risk Management component contains high-risk assumptions that relate to a successful completion of
integration testing. It also contains contingency plans for each. The Baseline Risk Assessment
(PJM.RKM.040) includes identified risks. If any relate to the integration tests, include a reference to the work
product, rather than duplicating the content. The Risk Management component also contains suspension
criteria and resumption requirements. Specify the criteria to suspend some or all of the tests, and the
requirements to resume these tests.
Back to Top
APPROACH
When a unit test is completed with success, the component is integrated with other components developed during the iteration. These components are then tested as part
of an integration test (TE.040). In OUM, integration testing is twofold:
1. use case testing
2. additional integration testing
Scenarios (TE.035) and use to execute an integration test to verify the use case. Second, you may decide to perform additional integration testing on a group of
interrelated components. In this way you allow for early discovery of integration problems. This test is preferably performed as a continuous process throughout the
iteration. As soon as a component is ready for test, and has passed the unit test, it goes into the integration test. This presents a challenge in that you always have to
have the Integration Test Environment (TE.038) up to date and consistent with the developed components. Also, keep in mind that use cases and other components can
be developed iteratively within the iteration and therefore, you may need to test a use case or an interrelated group of components more than once during the iteration.
In OUM, the goal of integration testing is to verify that the components (and use cases) can be executed in a way that is consistent with what the users expect, and that
the integration between those components works together as a whole. Integration testing is performed in order to detect possible problems, inconsistencies and
omissions.
Integration testing should also include scenarios to test specific error handling, and other non-functional requirements specific to a use case or between components.
Integration testing must make sure that:
the requirements that are agreed upon are met
data used in the flow is used and handled as expected by the various components included in the test
communication between components works as required
there is consistency of look and feel
Test plans and scenarios should be reused in subsequent iterations whenever possible.
Scope of Testing
The scope of testing is described through a number of test types that are performed during the various integration tests, the test items that should be tested, and the
features that should be tested. You should also list possible features that should not be tested. Include the reason why they should not be tested.
All implemented components (and use cases) are delivered into integration testing, and should be properly tested before they can be delivered into system testing. The
integration test should be seen as an integral part of the development, so components are not delivered into system test before they have passed integration testing.
Therefore, it is important that the Testing process also uses priorities to ensure that the most important components and scenarios are tested first.
Test Types
You should identify the test types that are relevant for the various integration tests. The test types could be all the possible types of tests to which use cases or integrated
components can be subjected (functional and non-functional). Use cases and components evolve through iterations, including the use case scenarios, therefore the test
types may also evolve with the iterations. In the early iterations, the test types should focus on the basics and foundations of the components. The test types you identify
should reflect the requirements that have been defined for the components. Keep in mind that performance testing is included in the Performance Management (PT)
process.
Test Items
Identify the test items that should be included in the various integration tests. You should do this to a level that is relevant for your project. As the actual test items (the
actual implemented components) vary during the iterations, it might be too much to document them all as part of the testing plan. Therefore, it might be better to
document the test items on another higher level, for example, functional/non-functional area, application, subsystem, module. A detailed list of the components included
in the test could be produced from configuration control.
Features to be Tested
You should list all the features that should be tested as part of the integration tests for use cases. As there are many integration tests for use cases as well as multiple
iterations of integration tests for any given use case, and because of the nature of OUM, you may not know all the scenarios that should be tested in each iteration up
front. The plan should be updated at the beginning of each new iteration at the same time as the iteration content is determined. When you first prepare the Integration
Test Plan, reflect what is intended to be implemented as part each iteration. Then at the start of each new iteration, update the the plan with the appropriate Integration
Test Scenarios (TE.035) that will be tested as part of the features to be tested in that iteration.
Keep in mind that many use case scenarios may have many common aspects that may be covered by a single Integration Test Scenario. Do not produce an unnecessary
amount of Integration Test Scenarios when less will do.
If there is a need to visualize in the Integration Test Plan what specific use cases will be tested in future iterations and phases, include the actual Integration Test
Scenarios that you have developed from the use case scenarios (RA.024), or if the use case scenarios are not yet available, include the listing based on business use
cases (RA.015).
Features Not to be Tested
During the project, conditions may occur that impact which features should not be tested. If there are specific features or combination of features that under certain
conditions should not be tested, but otherwise would be tested, include a list and document the reason or conditions under which they should not be tested.
Test Pass/Fail Criteria
For each test item determine the criteria that determines whether an item has passed or failed the integration test. You should document this for each integration test that
should be performed. The criteria might vary depending on the iteration level of the component, as in an early iteration it is likely, and acceptable, that there are more
errors than there should be at the end of the last iteration.
Test Roles and Responsibilities
You should allocate test roles and responsibilities to team members as appropriate. Where white-box (structural) testing is relevant, it should be performed by persons
with developer skills. Try to involve the users in black-box (functional) testing. This allows for early feedback where the users expectations are inconsistent with what is
produced for integration testing. Plan to deliver training in test techniques to those participants who have not tested computer systems before.
Integration Testing
The importance and complexity of integration testing increases geometrically with the size of the project (as measured, for example, by the number of detailed
requirements, or in terms of use case points). On larger projects, you should consider assigning a specialized team to integration tasks. You need to make sure that the
integration of newly completed components does not destabilize previously released and integrated components. Testing use cases is a low level Integration test.
Therefore, you might decide to include some specialists to ensure that the integration between components works correctly throughout the iterations when new released
components are integrated with previously released components, or new versions of previously released components are released.
Estimating and Scheduling
As early as possible, the project manager and lead tester should estimate and schedule the integration testing tasks. Unit and use case testing is performed within each
development timebox as part of low-level integration testing.
Test Environment
An environment must be established for integration testing. You should establish this environment as soon as development begins so that it is ready immediately when
sufficient components are completed to start the first integration test. If you have resources available, there is no reason to hold off on integration testing until all
components and use cases for that iteration have been completed. Therefore, it is important that you have an environment ready as early as possible. Install appropriate
test tools in the environment. For each iteration, the environment must be updated to reflect the content delivered to that point in time. Describe the required
environments in the Environment Needs part of the Resources component.
Risk Management
Identify, in particular, in what situations the integration test or parts of the integration test should be suspended, and what criteria should be met to restart the test if it has
been suspended. This should put focus on important matters that must be in place to keep the integration test going.
There might also be other kind of risks related to the preparation and execution of the integration test. Document risks that relate to a successful completion of an
integration test. Review the Baseline Risk Assessment (PJM.RKM.040) with identified risks. If it contains risks related to integration testing, include a reference to the
document.
Project Learning
As the integration tests are performed through a number of iterations, both in the Elaboration phase, and the Construction phase, you will gain experience on which
aspects of the test work well and those that do not work well. This may depend on a number of aspects, such as, the experience of the project members, user dedication
and the type of application. At the end of each iteration, plan to conduct a lessons learned workshop involving all test participants, preferably also including participants
from development and configuration control.
Adjust the testing approach based on the cumulative experience, and update the plan accordingly.
Back to Top
Back to Top
Tester Develop the Integration Test Plan. For some projects, this may be a lead tester. 100
Back to Top
PREREQUISITES
TE.015.1
Prerequisite Usage
(PJM.WM.010)
Quality Management Plan
(PJM.QM.010)
The Baseline Project Workplan should be used to see how integration testing activities have been planned, and the Quality
Management Plan to see how quality will be ensured, and how that is related to testing.
Baseline Risk Assessment
(PJM.RKM.040)
The Baseline Risk Assessment may include risks specific to integration testing.
The Testing Requirements and Testing Strategy should be used as input for how the integration tests should be performed.
Project Team Learning Plan (TR.020) The Project Team Learning Plan should include any needs for education related to testing. This should be used as input to
see whether any needs have not been identified specific to integration testing.
Behavior Design (DS.100)
Use these work products to identify and define test types, test items and features to be tested.
Conversion Component Designs
(Initial Load) (CV.040.1)
Use the Conversion Component Designs (Initial Load) (CV.040) to identify and define test types, test items and features to be
tested.
TE.015.2
Prerequisite Usage
Testing Strategy (TE.010) The Testing Strategy should be used as input for how the integration tests should be performed.
Conversion Component Designs
(Initial Load) (CV.040.2)
System Management Guide (TA.100)
Use the Conversion Component Designs (Initial Load) (CV.040) as well as the System Management Guide (TA.100) to
identify and define test types, test items and features to be tested.
Back to Top
TECHNIQUES
Technique Comments
Service Testing Use this technique to to understand how to perform integration testing for SOA services.
Back to Top
TEMPLATES AND TOOLS
TE-015_INTEGRATION_TEST_PLAN.DOC MS Word
Back to Top
The Integration Test Plan is used in the following ways:
The lead tester uses the Integration Test Scope as the starting point for planning.
Testing members use the Integration Test Roles to understand their responsibilities.
Operations uses the Environment Requirements section for providing hardware and software.
Facilities uses the Environment Requirements section for space planning.
The project leader uses the Environment Requirements section for budgeting.
The project leader uses the scheduling results for overall planning and critical path analysis.
Testing members use the scheduling results as their detailed schedule.
The lead tester uses the schedule results for sequence and script development and testing status.
Distribute the Integration Test Plan as follows:
to the project leader for review and inclusion in the appropriate phase end report
to the projects quality manager for judging the quality of the test plan
to the client project manager to accept the components and agree on scope, detail, and quality of the integration test
to any ambassador users, identified by the client project manager or line managers, to accept the work product
Back to Top
QUALITY CRITERIA
Is the Integration Test Plan within the requirements and expectations of the Testing Strategy?
Has sufficient time been scheduled for integration testing?
Have roles and responsibilities been clearly identified for testing?
Are test data requirements clearly stated?
Is the level of testing appropriate for the criticality of the system?
Are adequate resources (staff and time) estimated for testing the system?
Have all the scenarios specified in the requirement both explicit and implicit, been converted into test conditions?
Has the test data set, if required been generated appropriately?
Have the required negative scenarios been identified in the test conditions?
Have the steps been correctly given in appropriate sequence for each test scenario?
Have the Pass/Fail Criteria been identified correctly?
Back to Top
TE.018 - PREPARE STATIC TEST DATA
In this task, you prepare required test data you will need throughout the project. This data supports prototyping and testing activities. It is test data that is generally more
static in nature and is used as a basis or starting point for specific testing activities. This data could be produced from converted business objects, but may also be
produced manually. It might consist of reference data and codes (such as list of values (LOV) codes) and master data (such as, Account, Name and Address, and
Vendor records, etc.). It may contain transactional data, but generally does not as that data is more dynamic.
Additional test data may be required for specific tests during the project. This task does NOT address that type of test data. Test-specific test data is determined and set
up during the planning and preparation activities for each specific test. The Static Test Data, in addition to the test-specific data, make up the complete test data for a
specific test.
In a commercial-off-the-shelf (COTS) application implementation, much if not all of the Static Test Data is identified in Define Applications Setup task (MC.050) and pre-
positioned for testing when the various testing environments are configured. In such projects, this task may not be required.
ACTIVITY
TE.018.1
TE.018.2
Back to Top
WORK PRODUCT
Static Test Data - The Static Test Data consists of actual physical data that remains consistent and is used as the starting basis for testing activities.
Back to Top
TASK STEPS
1 Review the Testing Strategy (TE.010), and
the appropriate test plans to see what data
will be required.
None
2 Determine required test data baselines. Test Data
Baselines
The Test Data Baselines describe all the sets of test data that are required for all the types of tests
performed during the project.
3 Identify for each required test data how it
should be produced. This could be manual,
converted, or automated.
Approach The Approach describes for each data object how the data should be produced.
4 Identify test data for each baseline. Baseline
Test Data
The Baseline Test Data describes which data objects will take part of each test data baseline. The
content might increase during the iterations.
5 Produce test data for baselines. Physical
Test Data
The Physical Test Data is the actual test data included in the test data baselines. This could be
manually created, converted or otherwise created. The content might increase during the iterations.
6 Quality check baseline test data. Quality
Checked
Test Data
The Quality Checked Test Data is the actual test data that has been quality checked to prevent test
errors to occur related to irrelevant/faulty test data. If new data is included the quality check needs to
be repeated.
7 Produce specific test data for test. Data for
Specific
Test
The Data for Specific Test is the actual test data prepared for a single test. This is data that will be
required on top of any of the baseline test data. It would typically be built using one or more test data
baselines with specific test data produced on top.
Back to Top
APPROACH
Producing good Static Test Data that can be used repeatedly during a number of tests should increase the productivity in producing required test data as well as
preventing unnecessary defects related to test data.
Because of the iterative nature of an OUM project, it will not be possible to produce one set of Static Test Data containing all required data for all tests performed during
the project. Also, each individual test may require different kind of data.
However, it is recommended that a Static Test Data baselines can be used as a the starting basis for test data production during the project. Data related to business
objects that have not yet stabilized should not be included in such a baseline.
It is important to ensure all conditions are tested. This may require altering "live" data that may not contain all test conditions. It is also critical to test failure and restart
functionality.
Core Test Data Baseline
It is recommended that you define a set with core test data that very unlikely will change during the project. This is typically reference data and codes, but may also
include more complex data. Transactional data is more dynamic and will more likely change during the project. Therefore such a core test data baseline would normally
not contain a lot of transactional data, if any.
Identify the data objects that should be included, and build a master database with appropriate content. This baseline might increase during the iterations, as more and
more of the data model stabilize. When other baselines should be built, use this core test data baseline as a starting point.
Other Test Data Baselines
Identify how many other types of baselines you will need during the project. You might want to have just one other baseline including transactional data, or you might
decide to produce baselines related to specific functional areas. This type of baseline will more likely change throughout the project. Attempt however only to include data
objects that seem to have stabilized enough to prevent rebuilding of the baseline.
Test Data for a Specific Test
When test data is needed for a specific test, review the need for test data specific for that test. If you have built baselines you should be able to use one of these as a
starting point. For some tests the baseline in itself might be sufficient, but for others you might need to add content specific for that test. When the production of test data
is complete, make a baseline so that if you need to re-start the test, you will have a database with consistent content.
Test Data Production
Whenever possible, use converted data as test data, but especially in the early phases of the project this might be difficult. Attempt however to produce as realistic
possible data even when it is not converted. Ask for lists with examples for each data object you have identified. If you need a larger volume of data, consider automating
the process of building test data. Some manually entered records may be copied, or made with some variations.
Quality Check Test Data
It is important that the quality of the produced data is verified before used in a test. If this is skipped there is a risk that errors will occur during test caused by faulty data.
Good quality data will reduce frustration for the tester, as well as unnecessary defect analysis. Whenever new data is added, this must be verified as well. The verification
should be done partly by a client representative to verify on a functional level, but must also be verified on a technical level to ensure that the data is consistent, that all
references are correct, and that specific system related data is appropriate.
You should put the test data under configuration control to ensure that you know exactly what kind of test data is used for a specific test.
Back to Top
Back to Top
System Architect
Participate in determining what kind of data is required to execute the tests. Preferably, this should be done by a system
50
Database Designer Participate in determining what kind of data is required to execute the tests and participate in quality checking of the test data. 50
Client Data Administrator Assist in providing appropriate test data to execute the tests and participate in quality checking the test data. *
Ambassador User Assist in providing appropriate test data to execute the tests and participate in quality checking the test data. *
Back to Top
PREREQUISITES
Prerequisite Usage
Testing Strategy (TE.010) The Testing Strategy contains information about what test data will be needed.
Integration Test Plan (TE.015) The Integration Test Plan contains detailed information about what test data will be required for the integration test.
System Test Plan (TE.050) The System Test Plan contains detailed information about what test data will be required for the system test.
Systems Integration Test Plan
(TE.080)
The Systems Integration Test Plan contains detailed information about what test data will be required for the systems
integration test.
Acceptance Test Plan (TE.082) The Acceptance Test Plan contains detailed information about what test data will be required for the user acceptance test.
Clean Legacy Data (CV.068) The Clean Legacy Data can be used to produce actual test data
Back to Top
TEMPLATES AND TOOLS
TE-018_STATIC_TEST_DATA.DOC MS Word
Back to Top
The Static Test Data is used in the following ways:
To populate test environments
To populate development environments
Distribute the Static Test Data as follows:
to the persons responsible for setting up test environments and other environments
to configuration management to ensure that the test data is put under configuration control
Back to Top
QUALITY CRITERIA
Is there a core Static Test Data baseline that can easily be used as a basis for other test data?
Has the Static Test Data been quality assured by at least one functional resource?
Has the Static Test Data been quality assured by at least one technical resource?
Has the Static Test Data baseline(s) been used to produce one or more test environments?
Back to Top
TE.019 - COLLECT, ASSESS AND REFINE KPI MEASUREMENTS
In this task, you measure the progress towards meeting the key business objectives set forth for the implementation. Each business solution will have certain key
performance indicators (KPIs) associated with its implementation. At the beginning of the implementation, these KPIs are reviewed with the customer and agreement is
obtained on how the implementation will be measured against these KPIs. Through each prototyping and system testing cycle, the progress towards meeting the
business performance objectives is measured. This allows the customer to see real progress against the key business issues or "pain points" early in the implementation.
ACTIVITY
TE.019.1
TE.019.2
Back to Top
WORK PRODUCT
Key Business Strategies and Objectives - Update the Key Business Strategies and Objectives (RD.015) to reflect any changes in the project's objectives or Key
Performance Indicators (KPIs). Assess progress toward achieving KPI targets and refine strategies for measuring and tracking improvement throughout the remainder of
the project. The refined Key Business Strategies and Objectives, when compared to the Current Business Baseline Metrics (RD.034), measure and document progress
towards these strategies and objectives. Update the KPI measurement criteria as necessary based upon issue identification and resolution through the iterative process.
Back to Top
TASK STEPS
1 Review the Key Business Strategies and Objectives, Key Business Strategies component
(RD.015), and update as necessary.
Key Business
Strategies
The Key Business Strategies describes
management's key strategic vision and project
direction.
2 Review the Key Business Objectives component and update as necessary. Key Business
Objectives
The Key Business Objectives highlights the
implementation engagement objectives, projects
the estimated benefits on a year-by-year basis,
and documents associated assumptions.
3 Measure progress towards achieving Key Performance Indicator (KPI) targets as described in
the Key Business Strategies and Objectives (RD.015) and Current Business Baseline Metrics
(RD.034).
Key
Performance
Indicators
(KPI)
Measurements
This component describes the Key Performance
Indicators to be tracked, baseline metrics,
targets and associated calculations.
4 Assess KPI collection and reporting strategy and determine refinements required In KPIs tracked
and/or measurement and reporting strategies
None
5 If a Metrics Collection and Reporting Strategy (ENV.BA.017) is available and it is relevant for the
project, assess the measures collection and reporting strategy to determine whether there
should be any changes or refinements. If so, document the required changes and the reasoning
behind them and provide it to the responsible person(s) in the enterprise.
Metrics
Collection and
Reporting
Strategy
Change
Request
The Metrics Collection and Reporting Strategy
Change Request documents proposed changes,
including the reason for the change.
6 Refine KPI Collection and Reporting Strategy, as necessary. KPI Collection
and Reporting
Strategy
The KPI Collection and Reporting Strategy
describes the method and means for tracking
progress toward the KPI targets, data sources
required, and reporting format.
Back to Top
APPROACH
This task is the last in a series of tasks aimed at aligning the project to the business objectives and key benefits that the implementing organization is hoping to achieve
throughout the implementation.
In this task, you measure progress toward achieving the target benefits and Return On Investment (ROI) goals originally established in Key Business Strategies and
Objectives (RD.015). In subsequent iterations you measure progress toward achieving the target benefits and Return On Investment (ROI) goals, as captured during the
previous iterations of this task. Key Performance Indicators (KPIs) associated with the business solution being implemented are reassessed, and target values at the
completion of the project are refined. The KPI monitoring strategy and means of measuring improvement are also reviewed for potential improvement/refinement.
Back to Top
Business Analyst 90
System Architect 10
Back to Top
PREREQUISITES
Prerequisite Usage
Reporting Strategy
(ENV.BA.017)
Use this Envision work product, if available. If the Metrics Collection and Reporting Strategy was used as an input to determine whether
there were any requirements relevant for the project for KPI collection, make sure any refinements are provided to the responsible
person(s) in the enterprise.
Key Business Strategies
and Objectives (RD.015)
The Key Business Strategies and Objectives provides a statement of the business benefits to be derived from the project and the KPIs that
will be used for measuring progress against these strategies and objectives
Current Business
Baseline Metrics
(RD.034)
The Current Business Baseline Metrics provides baseline performance metrics for selected business processes.
Back to Top
TEMPLATES AND TOOLS
Key Business Strategies and
Objectives
MS Word - Update the Key Business Strategies and Objectives work product from RD.015 to prepare the work product for this
task.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
TE.020 - DEVELOP UNIT TEST SCRIPTS
In this task, you develop the script to test individual components. The tests validate that the components inputs, outputs, and processing logic function as required. The
task is mainly performed in parallel with the actual development of the components. Thinking through how the component should be tested increases the understanding
of what the component should do or produce. Also, the component can be immediately tested when developed. As part of the task, you also prepare common checklists
that are used in performing unit testing for each type of primary or supporting component. This is done prior to developing individual unit test scripts for each unit test. In
addition, the Unit Test Scripts are registered in the Enterprise Repository and linked to the assets to which they apply.
This task occurs in both the Elaboration and Construction phases.
For projects that involve the upgrade of Oracle products, this task is used to review the clients existing Unit Test Scripts that will be used to test migrated custom
extensions.
ACTIVITY
ACT.DCCTS - Develop Custom Component Test Scripts
Back to Top
WORK PRODUCT
Unit Test Scripts - The Unit Test Scripts identify what needs to be unit tested, as well as the steps that are required to complete the test. Unit Test Scripts are used to
verify that each component does not include coding errors. A component is the smallest unit that the application consists of. What the smallest components would be
dependent on the languages used for development. Examples may be a table, a method, a database trigger, a screen, or a report. Automated scripts are used as much
as possible.
When a physical Enterprise Repository has been established, this information is updated in the Enterprise Repository creating new Unit Test Scripts or Unit Test Script
versions.
Back to Top
TASK STEPS
1 Review the projects design and build
standards.
None None
2 Incorporate the design and build
standards into the Unit Test Checklist.
Unit Test
Checklist
This section defines the categories of tests to validate the execution features of the each type of component
(for example, item validation, help test, error handling, and appearance). Design standards drive many of
these categories, and they are common for all components of the same type.
3 Review the Business Rules Design
(DS.110) and the Reviewed Design
Model (DS.160) for use case, class
and business rules design.
None None
4 Review the Reviewed Requirements
Specification (RD.150).
None None
5 Develop Unit Test Scenarios. Unit Test
Specifications
This section details the test steps necessary to test the unique logic of the component. To evaluate all of
the logic combinations, numerous test scenarios can be created. The goal is to exercise all logic, so the
tests do not need to reflect real business situations. In fact, the tests may be very artificial so that they test
the maximum amount of functionality in the fewest possible passes.
6 Develop the Data Profile. Data Profile This component specifies the test data required to execute the unit test scenario. Typically, multiple data
profiles are developed for execution with each test scenario. By defining a unit test scenario for each logic
path and a data profile for each data combination, the reusability of the tests and the coverage they
provide is maximized.
7 Develop Unit Test Scripts. Unit Test
Scripts
The Unit Test Scripts are coded scripts used to test the components. For some components it might be
difficult with automated scripts, and the test will be manual. If this is the case, the Unit Test Scenarios
should be sufficient. For other components the scripts execute the developed code following the Unit Test
Scenarios, and report any errors.
8 Update Enterprise Repository. Test Case
Assets
If an Enterprise Repository is being used, the Test Case Asset is created or updated in the Enterprise
Repository. This includes meta data regarding the contents of the Unit Test Scripts.
Back to Top
APPROACH
Use the Unit Test Script to document the steps needed to test a single component. A component is the smallest unit that the application consists of. What the smallest
components would be dependent on the languages used for development. Examples may be a table, a method, a database trigger, a screen, or a report. Automated
scripts should be used as much as possible.
The Unit Test Scripts are produced by the same developer that develops the code that should be unit tested. Preferably the developer starts thinking about how the code
should be tested before starting to develop the actual code. This forces the developer to think better through what the code should actually do. The Test Driven
Development approach might be used as well.
Produce a Unit Test Checklist for all kind of components in the application. This is not a checklist for an actual component, but a general checklist that can be used by the
developer as a starting point to determine the Unit Test Scenarios for a specific component.
Unit Testing Scope
The unit test is the narrowest scope of testing you will perform. Each unit test script exercises a single component, a method, program, screen, report, database trigger,
or other type of components. When performed thoroughly, unit testing is one of the biggest contributors to a stable application system and will significantly reduce all
downstream testing efforts. Unit testing is a repetitive task; testers execute each unit test numerous times using different combinations of test data as specified in the data
profile.
Unit Test Scenarios, Data Profiles and Unit Test Scripts
The development of unit test scenarios, data profiles and unit test scripts should not be a very time consuming effort. It is recommended that it is performed in parallel with
the actual development of the component, where the developer starts with this task, before starting developing. Reviewing the requirements and the design to determine
what kind of test situations will be required, also helps the developer in understanding how the component should be developed. Therefore, the startup effort for
developing the component and the effort to think through unit test cases can be combined.
For each component list the Unit Test Scenarios to test the unique logic of the component. Think through all kind of situations that may occur related to the component,
and make a list of all required unit test cases. The goal is to exercise all logic, so the tests do not need to reflect real business situations. In fact, the tests may be very
artificial so that they test the maximum amount of functionality in the fewest possible passes.
For each Unit Test Scenario, determine what kind of data is required. This, together with the Unit Test Scenarios, will lead to a number of required test cases. Test all
possible type of input and output values against the unit under test. Especially if you use automated test scripts, this should be easy and fast to do at this test level.
For all components that can be executed using automated tests, write Unit Test Scripts executing all the test cases described in the Unit Test Scenarios, and the data
described in the Data Profile. Ensure that the script is easily expandable so that new test cases can be included if required. Make certain that the script provides feedback
as to which test case has failed.
Consider using a tracker tool to enter the unit test scripts and to prepare the defect log. This makes it easier when the unit tester discovers errors, and makes it easier to
keep track on reported defects.
If automated test scripts are used, there is usually a possibility to generate test scripts documentation (specification and reports) automatically as well. The documentation
is created according to comments made in the source code of the test scripts.
Cosmetic and User Interface Standards
When defining tests for a screen or a report, provide a checklist to validate conformance with cosmetic standards, including informative messages for error conditions. The
Design and Build Standards define general cosmetic standards.
Coding Standards
Think about checking the code under test against the projects coding standards. If possible, use test tools to execute such tests.
Basic Functionality
Your test must verify that everything works as the designer intended. Examine the Use Case Realization (design) (DS.020), Designed Classes (DS.090) and Business
Rules Design (DS.110) to identify specific business rules and conditional logic. Construct data profiles and test scenarios to exercise all possible logic combinations. Use
this as an input to determine the Unit Test Scenarios.
Boundary Conditions
Organize your tests to evaluate normal execution flows first, and then test exception or out-of-range cases and boundary conditions. Defects are very often detected
related to such boundary condition. A boundary condition is a condition that is at or just outside the boundary that your component should accept. This may the largest
and smallest values permitted, invalid or unrealistic input data, empty or missing values, invalid ranges, invalid duplicates, lists out of order, and so on.
It is much easier to diagnose problems during unit testing, rather than later when many different programs are interacting. Therefore, also use this as an input to
determine the Unit Test Scenarios.
Interface Programs
Interface programs transfer or integrate data from one business application to another. Interface programs often extract data from the source and place them in a
temporary state (tables or files), before placing them in the destination environment. The temporary state allows data validation, collection (batch), and other
transformations to occur. Therefore, unit-testing interface programs must consider the discrete components that extract, validate, or transform the data. Define unit tests
for each component of an interface separately. Depending on the design, you may need to test interface components for error correction and feedback.
Performance
If the design identifies performance as a possible issue, or the application component is part of a business process with high volumes or transaction rates, you should
include information in your test scripts so that the tester can monitor performance during the tests. Make sure you define prerequisites for sufficient data volume in the
test environment to exercise the component adequately. Coordinate your tests with the team performing Performance Management (PT) tasks.
Restart and Recovery
If the application component is a concurrent program or other batch job, include tests to confirm that you can rerun the component in the event of failure. Look at the
design to determine the restart strategy. Some programs keep track of their progress and complete processing where they left off. Other programs simply roll back all
changes when an error occurs and start from the beginning when the program is rerun.
You may need to provide instructions for artificially simulating a database error by renaming a synonym or resizing tables to a smaller size (to trigger out of extent errors),
before executing the test. The size and number of rollback segments relative to the processing volume and run duration can influence both System Testing and the
program design. Long-running, high-volume batch programs may need to commit data at periodic checkpoints to avoid rollback segment to old errors and to prevent
running out of rollback segments. Coordinate with the developer and the people who are planning the physical database design of the production system to structure an
appropriate test case.
Database triggers that fire when other components insert or update data can also leave data in an invalid state if they do not handle errors properly. Any error in a
database trigger must raise an exception that propagates to the program that initiated the transaction, so that it can roll all changes back and display (or print) an
appropriate message. The component that performs the initial update or insert operation should process exceptions generated by a database trigger like any other
database error. Construct test cases that will cause the error logic to execute.
Destructive Testing
The most extreme form of testing is when you try to break the application component by providing bad input data or extreme test conditions. For screens, this can include
keying invalid fields, and invalid field sequences. Components having input parameters should handle invalid parameter values. Include test cases for these extreme
conditions or suggest general techniques that allow the testers to be creative.
Unit Test Data
Unit test data is generally created since converted data is either not available or is in an unstable state. You may want to use sample documents and data from the legacy
application, or have the technical analyst or business analyst help you design the unit test data. The specific data you need depends on the type of application
component you are testing. For example, if you are designing a test for a screen that users employ for entering information, you only need the data required to serve as
lookup values. On the other hand, if you are testing a complex report or a batch program that operates on existing data, you need enough data to test all possible logic
combinations.
If an Enterprise Repository is being used, for each new Unit Test Script or update of an existing one, update the Enterprise Repository with the meta data regarding this
script. It is very important to make Unit Test Scripts discoverable, supporting reuse of Unit Test Scripts in which a considerable amount of time has been invested. A Unit
Test Script is captured as a Test Case asset type.
Refer to the IT Asset Management technique Test Case Meta Data Description for a suggestions and descriptions of properties.
Back to Top
Back to Top
Developer Create Unit Test Scripts. 80
Business Analyst Assist in creating the Unit Test Scripts. 10
System Analyst Assist in creating the Unit Test Scripts. 10
Back to Top
PREREQUISITES
TE.020.1
Prerequisite Usage
(ENV.GV.100)
govern the proposed assets (test cases) and their relationships to other IT assets. In addition, ensure that the final proposed
assets and their relationships are added/updated in the repository.
(DS.160.1)
(DS.110.1)
The Reviewed Design Model contains the use case realization - design and the designed classes. the Business Rules Design
describes the functionality and business rules that should be implemented. They are used as your primary guide in developing unit
test scripts.
The Reviewed Requirements Specification captures the original requirements and helps you understand how the component to
test fits into the larger business process.
Testing Requirements (TE.005.1) The Testing Requirements provides the testing requirements for Testing.
Testing Strategy (TE.010) The Testing Strategy provides the testing approach and strategy for Testing.
Functional Prototype (IM.010)
TE.020.2
Prerequisite Usage
(ENV.GV.100)
govern the proposed assets (test cases) and their relationships to other IT assets. In addition, ensure that the final proposed
assets and their relationships are added/updated in the repository.
(DS.160.2)
(DS.110.2)
The Reviewed Design Model contains the use case realization - design and the designed classes. the Business Rules Design
describes the functionality and business rules that should be implemented. They are used as your primary guide in developing unit
test scripts.
The Reviewed Requirements Specification captures the original requirements and helps you understand how the component to
test fits into the larger business process.
Testing Requirements (TE.005.2) The Testing Requirements provides the testing requirements for Testing.
Unit Test Scripts (TE.020.1) Revise the Unit Test Scripts, as necessary.
Back to Top
TECHNIQUES
Technique Comments
Service Testing Use this technique to understand how to perform unit testing for SOA services.
IT Asset Management Use this technique to understand what information can be stored in an Enterprise Repository regarding Unit Test Scripts.
Back to Top
TEMPLATES AND TOOLS
TE-
020_UNIT_TEST_CHECKLISTS.DOC
MS WORD
TE-
020_UNIT_TEST_SCENARIOS.DOC
MS WORD
Tool Comments
Getting Started with Unit Testing using JDeveloper JDeveloper-Unit-Testing using a framework like JUnit is only effective when
integrated in the development process itself.
This task has supplemental guidance for using using Oracle Application Test Suite
(OATS) Testing and Quality Management Tools. Use the following to access the
task-specific supplemental guidance. To access all Oracle Application Test Suite
(OATS) Testing and Quality Management Tools supplemental information, use the
OUM Testing and Quality Management Tools Supplemental Guide.
Oracle Application Test Suite (OATS) Testing and Quality Management
Tools is a complementary Oracle suite of tools that is used to manage
software testing for a project as well as to develop test automation and
performance testing, when used together these tools can be used to
maximize system performance and ensure the quality and success of a
project.
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
The Unit Test Scripts are used in the following ways:
to be able to unit test application components
Distribute the Unit Test Scripts as follows:
to the person that should perform the unit test
Back to Top
QUALITY CRITERIA
Have unit test scripts been coded where automated unit testing would be beneficial?
Have test scenarios been defined for components that must be manually unit tested?
Do the unit test scenarios cover boundary conditions sufficiently?
Do the unit test scenarios cover basic functionality?
For interfaces, are there separate unit test scripts/scenarios for all components that take part of the interface?
Back to Top
TE.025 - CREATE SYSTEM TEST SCENARIOS
In this task, you develop the System Test Scenarios that you use during the iteration system tests in the Elaboration and Construction phases, as well as for the final full
system test at the end of the Construction phase. In addition, the System Test Scenarios are registered in the Enterprise Repository and linked to the assets to which
they apply.
The System Test Scenarios that should be created have been defined as part of the System Test Plan (TE.050). If the System Test Scenario relates to a use case, use
the use case scenarios in the Use Case Model as a starting point. The Context Process Model can also be used to prepare System Test Scenarios at higher-levels, but
details are based on the use case scenarios.
The System Test Scenarios should be used to validate that the functional requirements, the integration of all components, the technical infrastructure and the
supplemental requirements (excluding performance) have been met.
In a commercial off-the-shelf (COTS) application implementation, you develop the System Test Scenarios to test the operation and integration of business system flows
within the (COTS) application system, including the integration of application extensions. A system test scenario contains detailed steps which testers follow to verify the
system setup and the integrity of custom application extensions for supporting business processes.
In a commercial-off-the-shelf (COTS) application implementation employing a solution-driven approach that leverages pre-defined system test scenarios or demo scripts,
the scope of this task may be limited to minor updates, or additions, to the pre-defined test scenarios. However, updated Test Data identified in TE.018, Prepare Static
Test Data to "personalize" the environment, and entirely new test scenarios associated with custom extensions, may also need to be incorporated in the pre-defined test
scenarios as part of this task.
ACTIVITY
TE.025.1
TE.025.2 and TE.025.3
ACT.DSTS Develop System Test Scenarios
Back to Top
WORK PRODUCT
System Test Scenarios - The System Test Scenarios work product consists of the set of test scenarios that each include a number of test steps that should be
performed as part of the System Test.
When a physical Enterprise Repository has been established, this information is updated in the Enterprise Repository creating new Test Scenarios or Test Scenario
versions.
Back to Top
TASK STEPS
1 Review the System Test Plan (TE.050) to see what test types should be
performed and what features should be tested, as well as other aspects to take
into consideration when producing the System Test Scenarios.
None None
2 Review requirements related to the System Test Scenarios that should be
described.
None None
3 Determine System Test Scenarios for each feature that should be tested. System Test
Scenario
The System Test Scenario includes the following information:
ID and name
Reference to system use case scenario, if applicable
Other reference, if applicable
Revision history
Objectives for the test
Setup requirements for the test
Pre-conditions for the test
Required test-data
Steps that are included in the scenarios
Expected result
Preferably use some testing tool to record the System Test
Scenarios.
4 Review and revise System Test Scenario. None None
5 Update Enterprise Repository. Test
Scenario
Assets
If an Enterprise Repository is being used, the Test Scenario Asset is
created or updated in the Enterprise Repository. This includes meta
data regarding the contents of the System Test Scenarios.
Back to Top
APPROACH
In OUM, the goal of system testing is to verify that the system works as a whole, in a way that is consistent with what the users expect, and to detect inconsistencies and
omissions between the partitions (including any from previous iterations). At this level, you should be able to concentrate on testing aspects of the application system that
could not be tested earlier. System testing is not concerned with detailed exception handling and data testing, since these areas should have been adequately covered in
component testing. System testing must make sure that:
data entered using some components is as expected by other components that use the same data
other links (e.g., between custom built components and commercial off-the-shelf application products) work as required
there is consistency of look and feel throughout
Scope of Testing
The scope of testing is described through a number of test types that are performed during the various system tests, the test items that should be tested, and the features
that should be tested. Test types, items and features that should be tested are described in the System Test Plan. The System Test Plan is updated for each iteration,
and identifies all required scenarios for that particular system test. This task, to create the system test scenarios, should be completely inline with the System Test Plan,
and should provide detail to the scenarios that have been listed as part of the System Test Plan. Having said that, while detailing the system test scenarios, you might
discover missing features, or discrepancies between the test scenarios. If this should occur, update the System Test Plan to reflect the additions or corrections. You also
might discover reasons that certain features could not (yet) be tested, that also should be reflected in the plan.
You should provide System Test Scenarios to cover for all Must Have and Should Have requirements at a minimum.
System Test Scenarios
For each System Test Scenario that has been listed in the System Test Plan, review the requirements that are related to the System Test Scenario. This might be
functional requirements documented in the Use Case Model (RA.023/RA.024/AN.110) or the Future Process Model (RD.011), but it might also be supplemental
requirements documented as supplemental requirements (RD.055). Supplemental requirements related to the use cases can normally be found as part of the Use Case
Model.
Use case scenarios often provide a good starting point for many scenarios. Keep in mind that many use case scenarios may have many common aspects that easily
could be covered by a single System Test Scenario. These use cases typically are implemented by the same components, or set of components. Do not produce an
unnecessary amount of System Test Scenarios when multiple use case scenarios can be tested by a single or a few System Test Scenarios.
Based on the requirements, determine the objectives for the test scenario, the setup requirements for the test, what the pre-conditions are to be able to perform the test,
and the required test data on a detailed level.
Determine detailed steps that are needed to perform to complete the scenario. Include for each step the expected result. Ensure that the sequencing of the scenarios is
well understood.
Documenting the Test Scenarios
OUM recommends using a tool to track defects or enhancement requests as a result of testing. Preferably, the tool should also have the capability to enter test scenarios,
so that whenever a defect is detected, the tester can easily link the test scenario and the actual step to the defect. In this way, expected result can be linked with actual
result.
If you use such a tool, record the test scenarios in the tool, rather than using documents. Choose a tool that allows printing of the scenarios in a readable format, so that
the test steps can be easily reviewed.
If an Enterprise Repository is being used, for each new System Test Scenario or update of an existing one, update the Enterprise Repository with the meta data regarding
this scenario. It is very important to make System Test Scenarios discoverable, supporting reuse of System Test Scenarios in which a considerable amount of time has
been invested. A System Test Scenario is captured as a Test Scenario asset type.
Refer to the IT Asset Management technique Test Scenario Meta Data Description for a suggestions and descriptions of properties.
Back to Top
Back to Top
System Analyst Oversee, review and approve the development of the System Test Scenarios. 20
Tester Develop the System Test Scenarios. For some projects, this may be a lead tester. 80
Ambassador User Review the System Test Scenarios to verify relevance relative to business. *
Back to Top
PREREQUISITES
TE.025.1
Prerequisite Usage
(ENV.GV.100)
how to govern the proposed assets (test scenarios) and their relationships to other IT assets. In addition, ensure that the final
proposed assets and their relationships are added/updated in the repository.
System Test Plan (TE.050.1) This work product provides which scenarios should be created.
Future Process Model (RD.011) The Future Process Model can be used to prepare System Test Scenarios at a higher-level, but the use case scenarios are
used for the details. It also includes process flow diagrams of the events and business processes that the system supports.
The use case scenarios are translated into System Test Scenarios. Also the priorities given for the use cases must be taken
into account, in order to create System Test Scenarios for all the Must Have and Should Have use cases, at a minimum.
(RD.055)
The Supplemental Requirements may provide input to supplemental aspects of the System Test.
TE.025.2
Prerequisite Usage
(ENV.GV.100)
how to govern the proposed assets (test scenarios) and their relationships to other IT assets. In addition, ensure that the final
proposed assets and their relationships are added/updated in the repository.
System Test Plan (TE.050.2) This work product provides which scenarios should be created.
Future Process Model (RD.011) The Future Process Model can be used to prepare System Test Scenarios at a higher-level, but the use case scenarios are
used for the details. It also includes process flow diagrams of the events and business processes that the system supports.
The use case scenarios are translated into System Test Scenarios. Also the priorities given for the use cases must be taken
into account, in order to create System Test Scenarios for all the Must Have and Should Have use cases, at a minimum.
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique to understand what information can be stored in an Enterprise Repository regarding System Test Scenarios.
Back to Top
TEMPLATES AND TOOLS
TE-025_SYSTEM_TEST_SCENARIOS.DOC MS WORD
Tool Comments
project.
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
The System Test Scenarios are used in the following ways:
Testing members use the System Test Scenarios as a step-by-step guide on how to perform the test
The test leader uses the required test data component to ensure that required test data will be in place prior to the test
The test leader uses the pre-conditions component to ensure that all pre-conditions are met prior to the test
The developer uses the System Test Scenarios, in particular the steps and expected outcome, as an input when defects are reported
Distribute the System Test Scenarios as follows:
to the system analyst and ambassador users for review
to the testing members to indicate what should be tested and how
to the developers
Back to Top
QUALITY CRITERIA
Have all System Test Scenarios described in the System Test Plan been detailed, or has there been explained why there is a discrepancy?
Are the System Test Scenarios related to specific use case scenarios or other type of requirements?
Are the test steps for each scenario described in sufficient detail so that a tester can understand without consulting others?
Is there for each scenario step described an understandable expected outcome?
Have the pre-conditions for the execution of the scenarios been described?
Has the required test data been described for each test scenarios?
Back to Top
TE.030 - PERFORM UNIT TEST
In this task, you test application components on an individual basis to verify that the inputs, outputs, and processing logic of each application component functions without
errors. Unit testing is most often performed in the development environment but it is also possible to use a separate testing environment. The task is performed in parallel
with the actual development of the components.
The goal is to find errors in the smallest unit of software before you logically integrate it into larger units. Only by finding and correcting defects can the team build user
confidence in the system. If successful, subsequent integration testing should only reveal errors related to the integration between components.
The developer performs the unit test as per the unit test scripts and checklists prepared earlier to make sure that the developed components meet the user requirements
and are fit for their business purpose.
Tests must be repeatable. Therefore it is necessary to document what has been tested. There might also be a requirement to retain a record of each test for audit
purposes.
This task occurs in both the Elaboration and Construction phases.
In an application implementation project, unit testing is generally performed in the Construction phase. However, it may be performed in the Elaboration phase for
complex, higher risk custom extensions that have been identified during the pre-sales cycle and/or during the Inception phase, and where the prototypes that have been
developed during the Elaboration phase continue to be enhanced during the Construction phase.
ACTIVITY
ACT.PCCT Perform Custom Component Testing
Back to Top
WORK PRODUCT
Unit-Tested Components - Unit-Tested Components include source code that has been tested to verify that the inputs, outputs, and processing logic of each application
component functions without errors. It also includes the Unit Test Results containing test reports, metrics, bug reports, and so on.
Back to Top
TASK STEPS
1 Enter or confirm the required setup data. None None
2 Review the Unit Test Script (TE.020) and
complete the form information.
Completed
Component
Information
This component lists specific information about the component being unit tested (such as the name
of the application, component short name, component title, testers name, and date tested).
3 Using the Unit Test Script, identify what
and how the component should be tested.
None None
4 Perform the unit test and document the
unit test results.
Unit Test Results This component records the results of each unit test.
5 Fix errors identified in the testing process. None
6 Repeat the test if required. Unit Test Results
7 Place the tested component under
configuration control.
None
8 Update the design documentation if
required.
None
9 Record the completed unit test script result
for evidence of testing.
Unit Test Results
Back to Top
APPROACH
The Unit-Tested Components are the result of performing unit testing on custom built application components. Each application component is unit tested separately.
Iterative Testing
Unit testing is an iterative process tightly integrated with coding. The developer who codes an application component does this in an iterative way, where the component is
immediately unit tested to identify any errors, where these again are immediately corrected, until the unit test runs without errors. This is especially effective when
automated test scripts can be used. A developer codes an application component or parts of it and unit tests it, performs bug fixes, and retests it until the program is free
of errors. More functionality is then added and the process is repeated.
If there are more complex and time consuming unit test cases, the developer who codes the application may not perform all unit test cases, but would typically perform the
main stream unit test cases, while another developer or dedicated tester (with developer skills) completes the unit test.
Once the developer is comfortable with the completed component, it is turned over to another developer or tester for final unit testing. This is especially useful for complex
components as another developer might see new aspects that the original developer has overlooked. If that is the case, it might also be that the unit test cases are not
sufficient for the component under test. In each round of unit testing, the tester must communicate defects back to the developer, who fixes the problems and then
releases a new version for retesting. Therefore, even though the two tasks (development and unit testing) are separate, consider them to be one integrated activity.
Test Results Documentation
Use the Unit Test Scenarios component from the Unit Test Script (TE.020) to document the actual unit test results. If the test is automated, use the output as
documentation for the test result. If the component is unit tested by another developer, or if there are for some reason still (acceptable) defects that remain after unit test
they should be logged using some tracking tool to keep track of open issues.
Test Coverage
Test coverage is about how much of the developed code has actually been tested (executed as part of tests). Proper unit testing improves the quality of the code. There
will be less serious and complicated errors reported during later tests for properly unit tested programs than for programs where the developer has skipped, or not been
thorough enough with unit testing.
Therefore, good test coverage during unit testing is important. That means that all components should be tested thoroughly before being released to the next test level.
There are tools available on the market to determine the test coverage.
Sometimes it is very simple to gather proper metrics because all types of test coverage (i.e., statement, branch, branch condition coverage etc.) might be collected
automatically. In other cases, we might use instance coverage metrics for use cases. While gathering code coverage metrics, remember not to focus only on achieving
100% code coverage as that does not mean that all requirements are implemented and that all paths through the code are tested. Therefore, it can create a false sense
of security.
The exit criteria for unit testing might be based on a pre-defined test coverage required. If it is too little, expand test suites and iterate until satisfactory coverage is
achieved.
Test Data
Unit test data is generally created since converted data is either not available or is in an unstable state. You may want to use sample documents and data from the feeder
systems, or have the technical analyst or business analyst help you design the unit test data. The specific data you need depends on the type of application extension
you are testing. For example, if you are designing a test for a form that users employ for entering information, you only need the data required to serve as lookup values.
On the other hand, if you are testing a complex report or a batch program that operates on existing data, you need enough data to test all possible logic combinations.
Back to Top
Back to Top
Developer Perform the unit test. 80
System Analyst Assist in performing the unit test. 20
Back to Top
PREREQUISITES
Prerequisite Usage
Implemented Database (IM.040)
You must have the coded components with the corresponding executables before you can unit test them. However, the
components may not yet be complete, as you for example see in the Test Driven Approach.
Unit Test Scripts (TE.020) The Unit Test Scripts provides the prerequisite seed data, the detailed steps, and the expected results of the test.
Testing Requirements (TE.005) The Testing Requirements provides the testing requirements for Testing.
System Management Guide (TA.100)
Back to Top
TECHNIQUES
Technique Comments
Service Testing If your project involves SOA implementation, this technique provides important guidance for testing services.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
JDeveloper
itself.
Back to Top
The Unit-Tested Components are used in the following ways:
by configuration management to place under configuration control
by the system administrator for preparation of integration testing
Back to Top
QUALITY CRITERIA
Have all unit test scripts been executed on the tested components?
Have all errors been fixed or have these been documented as open issues?
Has required test coverage been achieved?
Has the the check list for the type of component in the Unit Test Script been followed?
Are defects, if any identified fixed and the component tested again?
Are design documents updated where required?
Have the tested components been placed under configuration control?
Back to Top
TE.035 - CREATE INTEGRATION TEST SCENARIOS
In this task, you develop the Integration Test Scenarios that you use during the integration tests in the Elaboration and Construction phases. In addition, the Integration
Test Scenarios are registered in the Enterprise Repository and linked to the assets to which they apply.
Most of the Integration Test Scenarios are created to test use cases and should have been defined as part of the Integration Test Plan (TE.015). For these Integration
Test Scenarios, you should be able to use the use case scenarios as a starting point.
coding errors are generated when related components are linked together. In this task, you develop scripts to test interaction, or linkage, between related application
extension modules. This uncovers any integration problems with other application extension components that provide or use the data manipulated by the target modules.
ACTIVITY
ACT.DCCTS - Develop Custom Component Test Scripts
Back to Top
WORK PRODUCT
Integration Test Scenarios - The Integration Test Scenarios consists of the set of Integration Test Scenarios for each use case to be tested as well as the Integration
Test Specifications and the corresponding Data Profiles for any additional integration tests that are to be performed.
Back to Top
TASK STEPS
1 Review the Integration Test Plan (TE.015) to see what test types should be
performed and what features should be tested, as well as other aspects to
take into consideration when producing the Integration Test Scenarios.
None None
2 Review the Reviewed Analysis Model (AN.110) and Reviewed Design Model
(DS.160) as a starting point for the Integration Test Scenarios that should be
described.
None None
3 For each use case to be tested, define Integration Test Scenarios for each
feature that should be tested.
Use Case
Integration
Test
Scenario
The Use Case Integration Test Scenario includes the following
information:
ID and name
Reference to system use case scenario
Revision history
Setup requirements for the test
Required test-data
Steps that is included in the scenarios
Expected result
Preferably use some testing tool to record the Use Case Test
Scenarios.
4 For other additional integration tests that have been determined, develop the
Integration Test Specifications.
Integration
Test
Specifications
This component defines the step-by-step integration test script for
the integration test. It includes the following:
Step
Role
Action
Expected Result
Actual Result
5 In addition, for other additional integration tests that have been determined, Data Profile This component describes the business conditions or seeded data
develop the corresponding Data Profile. you need to perform the integration test.
6 Update Enterprise Repository. Test Scenario
Assets
If an Enterprise Repository is being used, the Test Scenario Asset is
created or updated in the Enterprise Repository. This includes meta
data regarding the contents of the Integration Test Scenarios.
Back to Top
APPROACH
When a unit test is completed with success, the component is integrated with other components developed during the iteration. These components are then tested as part
of an integration test (TE.040). In OUM, integration testing is twofold:
1. use case testing
2. additional integration testing (for example, test the interaction, or linkage, between related application extension modules)
Scenarios (TE.035) and used to execute an integration test to verify the use case. Second, you may decide to perform additional integration testing on a group of
interrelated components (for example, test the interaction, or linkage, between related application extension modules). In this way, you allow for early discovery of
integration problems. These tests are performed as a continuous process throughout the iteration. As soon as a component is ready for test, and has passed the unit test,
it goes on to the integration test. This presents a challenge in that you always have to have the Integration Test Environment (TE.038) up-to-date and consistent with the
developed components. Also, keep in mind that use cases are also developed iteratively and therefore, you may need to test a use case more than once during the
iteration.
omissions.
During the iteration, separate integration tests are performed on each use case. In addition, separate integration tests are performed for any group of two or more
interrelated components that you identify a need on which to conduct an integration test. Because use cases and components are developed iteratively, integration tests
may be performed multiple times on the same use case or group of components as well.
Integration testing should also include scenarios to test specific error handling, and other non-functional requirements specific to a use case or between components.
Integration testing must make sure that:
the requirements that are agreed upon are met
data used in the flow is used and handled as expected by the various components included in the test
communication between components works as required
there is consistency of look and feel
Scope of Testing
The scope of testing is described through a number of test types that are performed during the various integration tests, the test items that should be tested, and the
features that should be tested. Test types, items and features to be tested are documented in the Integration Test Plan (TE.015). The Integration Test Plan is updated for
each iteration and identifies all required Integration Test Scenarios for each use case to be tested. This task, to create the Integration Test Scenarios, should be
completely in parallel with the Integration Test Plan, and should provide detail to the scenarios that have been listed as part of the plan. Having said that, while detailing
the Integration Test Scenarios, you might discover missing features, or discrepancies between the test scenarios. If this should occur, update the Integration Test Plan to
reflect the additions or corrections. You also might discover reasons that certain features could not (yet) be tested, that should also be reflected in the plan.
At a minimum, you should create Integration Test Scenarios for all Must Have and Should Have requirements.
Integration Test Scenarios
USE CASE TESTING
For each use case that is to be tested, a corresponding Integration Test Scenario should be listed in the Integration Test Plan. Review the requirements for the use case
on which the the Integration Test Scenario is based. Often, the use case scenarios documented in the use case can be reused to build the test scenario .
Keep in mind, that many use case scenarios may have common aspects that may be covered by a single Integration Test Scenario. This should have been considered
when determining the required Integration Test Scenarios in the Integration Test Plan, but as you go into more detail now, you may discover other use cases or scenarios
that share the same components and are used in a similar way, so you may want to merge some Integration Test Scenarios (fully or partly). Update the Integration Test
Plan. Do not create duplicate Integration Test Scenarios.
Integration Test Scenarios are step-by-step descriptions of how each integration test to validate a use case should be performed. The level of detail that is required for
each scenario depends on the complexity of the use case, the complexity of the use case scenario, and the skills of the tester(s). Document the scenarios to an
appropriate level of detail. Documenting on too low a level of detail decreases flexibility for reusing the test scenario and is extremely time consuming for the tester.
An experienced tester will understand how to test with lesser instructions than a novice tester. However, you should not keep a specific tester in mind when documenting
the scenarios, each tester should be able to use and understand the Integration Test Scenarios.
Determine detailed steps that are needed to perform to complete the scenario. Include for each step the expected result.
ADDITIONAL INTEGRATION TESTING
For other additional integration tests that have been determined, use the Integration Test Scenarios to check the integration between two or more components that are
part of the same business process. Create one Integration Test Scenario for each integration test to be performed. For these integration tests, each Integration Test
Scenario consists of an Integration Test Specification and a Data Profile. The Integration Test Specification component details the test steps necessary to thoroughly
perform the test. The Data Profile specifies the test data required to execute the Integration Test Specification.
Documenting the Integration Test Scenarios
result.
If an Enterprise Repository is being used, for each new Integration Test Scenario or update of an existing one, update the Enterprise Repository with the meta data
regarding this scenario. It is very important to make Integration Test Scenarios discoverable, supporting reuse of Integration Test Scenarios in which a considerable
amount of time has been invested. A Integration Test Scenario is captured as a Test Scenario asset type.
Refer to the IT Asset Management technique Test Scenario Meta Data Description for a suggestions and descriptions of properties.
Back to Top
Back to Top
Tester Create the Integration Test Scenarios. For some projects, this may be a lead tester. 100
Back to Top
PREREQUISITES
TE.035.1
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
proposed assets (test scenarios) and their relationships to other IT assets. In addition, ensure that the final proposed assets and their relationships
are added/updated in the repository.
Integration Test
Plan (TE.015.1)
The Integration Test Plan outlines the Integration Test Scenarios that should be built.
Reviewed
Analysis Model
(AN.110.1)
The use case scenarios can be used to determine Integration Test Scenarios for each use case to be tested.
Reviewed Design
Model (DS.160.1)
The Reviewed Design Model contains the designed components for which Integration Test Scenarios should be created.
Unit-Tested
Components
(TE.030.1)
Unit-Tested Components include source code that has been tested to verify that the inputs, outputs, and processing logic of each application
component functions without errors.
TE.035.2
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
proposed assets (test scenarios) and their relationships to other IT assets. In addition, ensure that the final proposed assets and their relationships
are added/updated in the repository.
Integration Test
Plan (TE.015.2)
The Integration Test Plan outlines the Integration Test Scenarios that should be built.
Reviewed
Analysis Model
(AN.110.2)
The use case scenarios can be used to determine Integration Test Scenarios for each use case to be tested.
Reviewed Design
Model (DS.160.2)
The Reviewed Design Model contains the designed components for which Integration Test Scenarios should be created.
Unit-Tested
Components
(TE.030.1)
Unit-Tested Components include source code that has been tested to verify that the inputs, outputs, and processing logic of each application
component functions without errors.
Back to Top
TECHNIQUES
Technique Comments
IT Asset Management Use this technique to understand what information can be stored in an Enterprise Repository regarding Integration Test Scenarios.
Back to Top
TEMPLATES AND TOOLS
TE-035_INTEGRATION_TEST_SCENARIOS.DOC MS Word
Tool Comments
Oracle Enterprise
Repository
Repository.
Back to Top
The Integration Test Scenarios are used in the following ways:
Testing team members use the Integration Test Scenarios as a step-by-step guide on how to perform the test.
The test leader uses the Integration Test Scenarios to ensure that required test data will be in place prior to the test.
The developer uses the Integration Test Scenarios, in particular the steps and expected outcome, as an input when defects are reported.
Distribute the Integration Test Scenarios as follows:
to the testing team members
to the test leader
to the developers
Back to Top
QUALITY CRITERIA
Have all Integration Test Scenarios described in the Integration Test Plan been detailed, or has an explanation been given why there is a discrepancy?
Are the Integration Test Scenarios related to specific unit test scripts or other type of requirements?
Are the test steps for each scenario described in sufficient detail so that the tester can understand them without consulting others?
Is there an understandable expected outcome for each scenario step described?
Have the required test data been described for each test scenario?
Back to Top
TE.038 - PREPARE INTEGRATION TEST ENVIRONMENT
In this task, you prepare the Integration Test Environment.
coding errors are generated when related components are linked together.
ACTIVITY
TE.038.1
TE.038.2
Back to Top
WORK PRODUCT
Integration Test Environment - The Integration Test Environment consists of the integration test database, manual data, possibly converted data, and components.
When this task is completed, the work product is the actual environment including a setup report that reflects how the Integration Test Environment actually has been set
up.
Back to Top
TASK STEPS
1 Review the Testing Strategy (TE.010) to see what kind of testing
environments should be used, and Integration Test Plan
(TE.015) for more detailed requirements for the Integration Test
Environment.
None None
2 Determine the exact configurations required for the Integration
Test Environment.
Integration Test
Environment
Setup Report
The Integration Test Environment Setup Report documents the exact
configurations that is used for the Integration Test Environment. This includes
the hardware, software, set up and network configurations.
3 Determine required test data for integration tests. Test Data
Baseline
Manual Data
Load
Scripted Data
Load
Converted
Data Load
The Test Data Baseline describes which test data baseline (from Prepared Static
Test Data (TE.018)) will be used for integration testing.
The Manual Data Load describes any additional data that should be manually
entered in the Integration Test Environment on top of the test data baseline.
The Scripted Data Load describes any additional data that should be loaded into
the Integration Test Environment on top of the test data baseline using scripts.
The Converted Data Load describes any additional data that should be loaded
into the Integration Test Environment on top of the test data baseline using
conversion programs or scripts.
4 Determine which components should be included in the
integration tests.
Application
Object Load
for Integration
Test
The Application Object Load for Integration Test component describes all the
source components that should be contained in the Integration Test
Environment.
5 Set up physical Integration Test Environment. Update of all
components
The components listed above are updated along with the physical creation of the
Integration Test Environment. The work product as a whole should be seen as a
listed above in
this table
setup report that reflects how the Integration Test Environment actually has
been set up.
6 Quality check Integration Test Environment. Update of all
components
listed above in
this table
When the Integration Test Environment is ready to be used, it must be quality
checked to see whether it works as expected. It might result in some
changes/corrections, and the final work product must be updated to reflect any
changes.
Back to Top
APPROACH
The Integration Test Environment should preferably be separate from that used for development. The Development Environment will be in a constant state of change. The
Integration Test Environment should be more controlled to ensure that the test is performed with the appropriate versions of the needed components. An integration test
uses a set of custom built components and/or application(s) features that should work together as a whole, therefore it must be certain that the needed components are
available in the versions that should work together as an integrated set.
The creation of the first Integration Test Environment must start early in the Elaboration phase, as this initial environment must be ready for integration testing during the
first development iteration in the Elaboration phase. This is early in the project, and the environment needs to be updated (evolved) for each iteration to ensure that it
reflects the situation required for that iteration.
Test data baselines are produced in the task Prepare Static Test Data (TE.018) and should be used as a starting point for data production to the Integration Test
Environment. The Statoc Test Data also evolves throughout the iterations, as the data model becomes more stable, and conversion data becomes available.
Install appropriate testing tools in the test environment(s). Allow time for training and familiarization. Make sure that support is available, if possible on-site, during the
busiest test periods.
The Integration Test Environment includes the following:
required configurations (database, application, workstations, servers, networks, etc)
data load (manual, scripted, converted)
implemented components and/or application(s) set ups
Back to Top
Back to Top
System Architect
Participate in the preparation of the Information Architecture for the Integration Test Environment to support integration testing.
20
System Architect Participate in the preparation of the Technical Architecture for the Integration Test Environment to support integration testing. 20
System Administrator Install application software. Provide support for the integration testing. 40
Tester Provide support for the creation of the Integration Test Environment. Perform quality check of the environment. For some
projects, this may be a lead tester.
20
IS Operations Staff Set up hardware and system software configuration. *
IS Support Staff Provide support for the creation of the Integration Test Environment. *
Back to Top
PREREQUISITES
TE.038.1
Prerequisite Usage
Functional Prototype (IM.010) The Functional Prototype contains all the components that should be system tested during the Elaboration Phase.
Implemented Database
(IM.040.1)
The Implemented Database provides the data you need to create database objects in the Integration Test Environment. Adjust the
storage parameters before creating the Integration Test Environment if disk space is limited.
Integration Test Plan
(TE.015.1)
The preparation of the Integration Test Environment should occur according to the Integration Test Plan.
Static Test Data (TE.018.1) Baseline Static Test Data is used as a starting point to create test data for the integration testing.
TE.038.2
Prerequisite Usage
(IM.040.2)
The Implemented Database provides the data you need to create database objects in the Integration Test Environment. Adjust the
storage parameters before creating the Integration Test Environment if disk space is limited.
Assembled Components
(IM.070)
The Assembled Components are the actual components that should be system tested.
Integration Test Plan
(TE.015.2)
The preparation of the Integration Test Environment should occur according to the Integration Test Plan.
Static Test Data (TE.018.2) Baseline Static Test Data is used as a starting point to create test data for the integration testing.
Back to Top
TECHNIQUES
Technique Comments
Service Packaging and Deployment Use this technique for guidance while applying the deployment configuration for the test environment.
Back to Top
TEMPLATES AND TOOLS
TE-038_INTEGRATION_TEST_ENVIRONMENT.DOC MS Word
Back to Top
The Integration Test Environment is used in the following ways:
by operations to standardize requests for access to application, databases or networks
by the lead tester who uses the end reports (setup report) as tangible evidence that the test environment is ready
by testers to determine what components are available for testing
Back to Top
QUALITY CRITERIA
Have all application components been correctly installed in the Integration Test Environment?
Is the Integration Test Environment set-up consistent with the scope of the integration test planning requirements?
Has the Integration Test Environment been quality checked?
Back to Top
TE.040 - PERFORM INTEGRATION TEST
In this task, you perform the appropriate integration tests during each development iteration, both in the Elaboration and Construction phases. Test the components based
on the plan outlined in the Integration Test Plan using the scenarios described in the Integration Test Scenarios.
coding errors are generated when related components are linked together. In this task, you test several application extension components together as part of a business
flow, or use case, to uncover any integration problems with other application extension components that provide or use the data manipulated by the target component.
The scope of each integration test typically includes the set of components that support or are affected by a single application extension.
In an application implementation project, integration testing is generally performed in the Construction phase. However, it may be performed in the Elaboration phase for
complex, higher risk custom extensions that have been identified during the pre-sales cycle and/or during the Inception phase, and where the prototypes of those
complex custom extensions that have been developed during the Elaboration phase, will continue to be enhanced during the Construction phase.
ACTIVITY
ACT.PCCT Perform Custom Component Testing
Back to Top
WORK PRODUCT
Integration-Tested Components - Integration-Tested Components include components (and use cases) that have been tested and can be executed in a way that is
consistent with what the users expect, and that the integration between those components works together as a whole.
Back to Top
TASK STEPS
1 Review the Integration Test Plan (TE.015)
to see how the integration test is planned
for each iteration.
None None
2 Review the Integration Test Scenarios
(TE.035) to see how they best can be
distributed among the Testing team.
None None
3 Perform each integration test. Integration
Test Detail
Defects
The Integration Test Detail describes per Integration Test Scenario whether it has failed or passed (or
skipped).
The defects are actual errors that have been discovered during the integration test. Preferably, these
should be logged in a defect tracker tool.
4 Conclude integration test. Integration
Test
Summary by
Test Type
Integration
Test
Summary by
Iteration
The Integration Test Summary by Test Type summarizes how many test have passed, failed and have
been skipped. It also summarizes how many tests have been completed, how many should have
been completed, and the completion and passed percentage.
The Integration Test Summary by Iteration provides a similar summary as above, but this time
organized as a summary for each integration test iteration.
Back to Top
APPROACH
This task is mandatory and is performed many times during each development iteration during the Elaboration and Construction phases. In OUM, integration testing is
twofold:
1. use case testing
2. additional integration testing
omissions.
During the iteration, separate integration tests are performed on each use case. In addition, separate integration tests are performed for any group of two or more
interrelated components that you identify a need on which to conduct an integration test. Because use cases and components are developed iteratively, integration tests
may be performed multiple times on the same use case or group of components as well.
In this way, the integration test is executed several times. The integration tests do not have to all happen all at the very end of the iteration, but should be performed as
soon as a use case is completed or all components used as part of an integration test are available for test. In most situations, which approach you choose depends on
available testing resources. The benefit of starting integration testing as early as possible is that errors are detected early and thereby can be corrected almost
immediately if time allows.
To allow for this approach it is important that you keep a track of the progress of the developed components, and that you know which scenarios use the various
components.
Be aware that the focus in the integration test should differ depending on the iteration in which the test is performed. During early iterations, the requirements are not yet
stabilized, and the test may be more focused on detecting gaps, misunderstandings, usability, and deficiencies rather than detecting all errors. However, if errors are
detected, they should be reported, but they might not be corrected as they may become obsolete because of changed requirements.
In later the iterations, the focus changes more towards error detection or gap closure, however, if other type of issues are detected, they should still be reported. These
issues may not be resolved in the current release, but at least they are documented for a possible subsequent release.
Individual Integration Test Scenarios may be performed several times, depending on the results.
The Incremental and Iterative Approach to a Tested System
The OUM approach has been designed to avoid disaster scenarios where major problems become visible late in the project. In this approach, requirements are
formulated by the project team working together. The continuous involvement of empowered users contributes to a common understanding of testable requirements. The
test as you go approach to testing also contributes to preventing unpleasant surprises at the end of the project. Ambassador users and adviser users, with their
knowledge of business processes and needs, and developers, with their technical skills, participate as much as possible in testing. Tasks are allocated by agreement
within the team, in order to achieve their common objectives within each timebox.
In OUM, the goal of integration testing is to verify that the components can be executed as described in the Integration Test Scenarios, as far as they have been
developed and/or the application(s) have been set up when the integration test is performed, in a way that is consistent with what the users expect.
Integration to System
System integration is performed in three stages:
1. Low-level integration is performed in integration testing (TE.040).
2. Upper-level integration of partitions and other components is part of the system test (TE.070), and final full system test (TE.070)
3. Integration with external systems is part of the systems integration test (TE.100).
Execute Script for each System Test Scenario
An important part of integration testing for use cases is scenario-based testing. Some of this testing must be performed manually, but parts of it could be performed by
executing automated scripts using scripted data that has been developed during component testing. You might find it useful to track the status of each scenario
separately. It is usual for some scenarios to be tested only once or twice before the results are satisfactory, whereas other scenarios require many iterations.
Record actual results, specific data entered, and other comments in the Integration Test Scenarios (TE.035). You can also include screen shots and sample report output
to support your results.
Although the already developed Integration Test Scenarios primarily dictate your integration testing process, you may think of other variations and scenarios that you
should test. Test these new scenarios and document each one in a new Integration Test Scenarios (TE.035).
Defect Registration and Test Scenarios
so that whenever a defect is detected, the tester can easily link the test scenario and the actual step to the defect. In this way, the expected result can be linked with
actual result. In addition, the Integration Test Summary components can easily be collected.
If you use such a tool, ensure that every defect that is a result of a scenario not giving the expected result refers back to the actual test scenario and test step.
Back to Top
Back to Top
Tester Develop test details and perform test. Review test details and monitor test results. For some projects, a lead tester may review
the test details and monitor test results. Provide support for integration tests by reconciling differences between design
requirements and the application and represent the project team.
If a Testing (or other) team leader has been designated, 20% of this time would be allocated to this individual, leaving 80%
allocated to the tester. The team leader would then provide support for integration tests by reconciling differences between
design requirements and the application and represent the project team.
100
Ambassador User Participate in the integration test. Allowing the users to participate in the integration test provides early feedback on
misunderstandings or incorrect interpretations of requirements.
*
Back to Top
PREREQUISITES
TE.040.1
Prerequisite Usage
Integration Test Plan (TE.015.1) This work product provides the plan of how to perform integration tests.
Integration Test Scenarios (TE.035.1) This work product provides the scenarios that should be tested.
Integration Test Environment (TE.038.1) This work product contains all components that should be tested as part of integration testing.
TE.040.2
Prerequisite Usage
Integration Test Plan (TE.015.2) This work product provides the plan of how to perform integration tests.
Integration Test Scenarios (TE.035.2) This work product provides the scenarios that should be tested.
Integration Test Environment (TE.038.2) The work product contains all components that should be tested as part of integration testing.
Back to Top
TECHNIQUES
Technique Comments
Service Testing If your project involves SOA implementation, this technique provides important guidance for testing services.
Back to Top
TEMPLATES AND TOOLS
TE-040_INTEGRATION_TEST_RESULTS.DOC MS Word
Back to Top
The Integration Test Results template is used to document the actual results from the various integration tests. The Integration Test Results is used in the following ways:
by the project manager to assist in reporting to the lead application developer(s) and developers or business flow/application specialist(s) to correct functional
defects
by the lead system developer or business flow/application specialist to correct defects related to supplemental requirements
Distribute the Integration Test Results as follows:
to all team members
Back to Top
QUALITY CRITERIA
Has integration testing been performed as described in the Integration Test Plan (TE.015) ?
Is there evidence of adequate code coverage, such that it is unlikely that serious errors remain undetected?
Can the business be confident that testing has reduced the risk of undetected errors to an acceptable level?
Is there evidence that all the essential requirements (functional and supplemental) have been tested and, where necessary, demonstrated to the users?
Back to Top
TE.050 - DEVELOP SYSTEM TEST PLAN
In this task, you develop the System Test Plan, which you use as a guide to perform the system tests at the end of each iteration, as well as the full system test when all
the iterations have been completed. This includes information about tester roles and responsibilities, test types, test data and test estimates and scheduling.
The System Test Plan is produced iteratively along with the development iterations to ensure that the plan reflects what is actually developed through the iterations.
In a commercial off-the-shelf (COTS) application implementation, you develop the System Test Plan to use as a guide for testing the operation and integration of business
system flows within the (COTS) application system, including the integration of application extensions.
ACTIVITY
TE.050.1
TE.050.2
Back to Top
WORK PRODUCT
System Test Plan - The System Test Plan includes all information necessary to plan, prepare for and conduct the system test.
Back to Top
TASK STEPS
(PJM.WM.010) to see how system testing
activities have been planned, and the
Quality Management Plan (PJM.QM.010)
to review how quality will be ensured.
Introduction Document any specifics related to these documents. Also include a reference to these documents.
2 Review Testing Requirements (TE.005)
and the Testing Strategy (TE.010)
documents. The System Test plan should
be within the boundaries provided by
these documents.
3 Review the Domain Model (RD.065), the
Use Case Model (RA.023), the Use Case
Realization Analysis and Design
documents (AN.110/DS.160) and the
Conversion Components Designs (Initial
Load) (CV.040).
None Use these documents as a basis to identify and define logical test scripts as well as and test data
requirements for each aspect.
4 Determine System Test Scope. System Test
Scope
The System Test Scope describes the scope of the System test for the iterations and the Full System
Test. The scope describes Test Types that should be performed during the various System Tests. It also
lists the Test Items that should be tested as part of the System Tests, the Features that should be
tested, and the Features that for some reason should not be tested .
5 Determine System Test Approach. Approach The Approach section includes the approach that you will use for the system tests. This should have
been documented earlier in the Testing Strategy (TE.010). If you need to further detail the described
approach do that in this section. Do not repeat the strategy as described in the Testing Strategy, but
include a reference.
6 Determine pass and fail criteria for test
items.
Item
Pass/Fail
Criteria
The Item Pass/Fail Criteria provides the pass/fail criteria for a test.
7 Determine System Test Work Products. System Test
Work
Products
The System Test Work Products component describes what will be delivered as a result from the System
Test. This should reflect the work product as described for the System Test (TE.050).
8 Determine Testing Tasks and Schedule. System Test
Schedule
The System Test Schedule component lists all the Testing tasks that should be performed as part of the
System Test. It also includes a schedule for when the tasks should be performed. This should be inline
with the overall project plan. If the project plan has sufficient details, do not repeat the content of the
project plan. Instead refer to it.
9 Determine detailed System Test
Resources The Environment Requirements section of the Resources component describes in detail the hardware
and software requirements for the environment, including other kind of physical requirements needed to
perform a proper system test. The Testing Strategy (TE.010) includes details for the required testing
environments. If it contains sufficient level of detail, do not repeat the content, but include a reference.
10 Determine System Test Responsibilities. Resources The Responsibilities section of the Resources component describes the roles that should be involved in
the (Full) system test and their associated responsibilities. It also lists one or more persons that are
responsible for the various test types.
11 Determine staffing and training needs. Resources The Staffing and Training Needs section of the Resources component describes the required skills for
system testing, and what the training needs are for those that should be involved in system testing. The
Project Team Learning Plan (TR.020) should include this kind of information. If this is sufficient, do not
repeat the content, but include a reference.
12 Identify risks and related risk management. Risk
Management
The Risk Management component contains high-risk assumptions that relate to a successful completion
of the system test. It also contains contingency plans for each. The Baseline Risk Assessment
(PJM.RKM.040) includes identified risks. If any relate to the system tests, include a reference to the work
product, rather than duplicating the content. The Risk Management component also contains suspension
criteria and resumption requirements. Specify the criteria to suspend some or all of the tests, and the
requirements to resume these tests.
Back to Top
APPROACH
In OUM, the goal of system testing is to verify that the system works as a whole, in a way that is consistent with what the users expect, and to detect inconsistencies and
omissions between the partitions (including any from previous iterations). At this level, you should be able to concentrate on testing aspects of the application system that
could not be tested earlier. System testing is not concerned with detailed exception handling and data testing, since these areas should have been adequately covered in
component testing. System testing must make sure that:
data entered using some components is as expected by other components that use the same data
other links (e.g., between custom built components and commercial off-the-shelf application products) work as required
there is consistency of look and feel throughout
Test plans and scripts should be reused in subsequent iterations whenever possible.
Scope of Testing
The scope of testing is described through a number of test types that will be performed during the various system tests, the test items that should be tested, and the
features that should be tested. You should also list possible features that should not be tested, if they are expected to be tested. Include the reason why they should not
be tested.
All implemented requirements will be delivered into testing, and should be properly tested before it can be delivered as part of a new application. However, as both
development and testing in most OUM projects will be timeboxed, it is important that also the testing process uses priorities to ensure that the most important
components and scenarios are tested first. Therefore the test items should be prioritized. The priorities will in most situations be the same as for the implementation.
System Testing should, at a minimum, cover all of the Must have and Should have requirements in the MoSCoW List. You should also plan to test and validate the Could
have requirements if such requirements have been implemented. However, testing of the Could have requirements should be given a lower priority, but it must be
ascertained that the implementation of any such requirements do not compromise data integrity or application stability. If there is insufficient time to test any of the Could
have requirements, then the related components will not be delivered.
Test Types
You should identify the test types that are relevant for the various system tests. The test types could be all the possible types of tests to which the system will be subjected
(functional and non-functional). They might vary dependent on in which phase and iteration the system test is performed. The test types you identify should reflect the
requirements that have been defined for the project.
Each system test type covers a class of technical, functional or non-functional requirements. Typical test types include the following:
business functionality tested using scenarios derived from business use case and business process models
usability consistency, ease of use, user efficiency
performance response times (batch and online), volume, stress (load-testing) (part of Performance Testing process)
security and control access permissions, data security, communications security
operability tested using scenarios derived from operational procedures (part of Technical Architecture process)
conversion and data quality
coexistence testing
locking
job scheduling
middleware and connectivity
data load - manual, initial, simulated using scripted data
documentation (including help text)
At the system level, some non-functional testing is performed. Performance testing is performed in the Performance Management process, operational testing, backup
and recovery testing, and disaster recovery tests are preformed in the Technical Architecture process, but non-functional testing also includes other aspects such as for
example maintenance testing and portability tests.
Test Items
Identify the test items that should be included in the various system tests. You should do this to a level that is relevant for your project. As the actual test items (the actual
implemented components and/or application(s) features) will vary during the iterations, it might be too much to document them all as part of the testing plan. Therefore, it
might be better suitable to document the test items on another higher level, for example, functional/non-functional area, application, subsystem, module. A detailed list of
the components included in the test could be produced from configuration control.
You should list all the features that should be tested as part of the system tests. Before a specific system test starts this should be a list of System Test Scenarios that
should be performed. For system tests that will be performed during later iterations or phases, including the full system test, this is rather a listing of relevant Business
Processes or Business Use Cases as it will not be necessary (or feasible) to list System Test Scenarios for later iterations. This means that for example, in the first
version of the plan, you produce a list of system test scenarios that will be performed as part of the first iteration system test, but for the subsequent system tests, you will
list the Business Processes/Business Use Cases that will be relevant for those iterations, phases and for the full system test as far as this is known. For each new version
of the plan, new listings of System Test Scenarios will be included so that the listing is complete prior to the System Test for that specific iteration.
Use case scenarios may often provide a good starting point to determine System Test Scenarios. Keep in mind that many use case scenarios may have many common
aspects that easily could be covered by a single System Test Scenario. These use cases typically are implemented by the same components, or set of components. Do
not describe an unnecessary amount of System Test Scenarios when one System Test Scenario can be used.
You should also focus attention on system features that support the following:
labor intensive or complex business tasks
human-computer interaction
Do not include features related to performance testing, as this is covered by the Performance Testing process.
During the project, situations may occur that impacts which features should not be tested. If there are specific features or combination of features that should not be
tested, but where it is expected that they should be tested, include a list. Also document the reason to why they should not be tested, so that it is easy to determine when
the features may be tested.
For each test item determine the criteria that determines whether an item has passed or failed the system test. You should document this for each system test that should
be performed. The criteria might vary depending on the iterations, as in an early iteration it is likely, and acceptable, that there are more errors than there should be at the
end of the last iteration.
You should allocate test roles and responsibilities to team members as appropriate. Where white-box (structural) testing is relevant, it should be performed by developers.
During system testing and systems integration testing, however, most testing is black-box (functional), and this kind of testing can also be performed by user participants.
Where testing is to be performed by anyone who is not a member of the core team, you need to make sure that they first receive an introduction to the project and to the
system. You should also plan to deliver training in test techniques to those participants who have not tested computer systems before.
Integration of Partitions and Components
requirements, or in terms of use case points). On larger projects, you should consider assigning a specialist team to integration tasks. You need to make sure that the
integration of newly completed components does not destabilize previously released and integrated components.
2. Upper-level integration of partitions and other components is part of the system test (TE.070).
As early as possible, the project manager and lead tester should estimate and schedule the integration and testing tasks. Lower-level integration testing is performed
within each implementation timebox as part of the integration tests. At levels above this task, system testing is usually performed in a timebox immediately following the
implementation iteration. As the number of components increases, and as the components mature towards their final versions, integration testing shifts in focus from low-
level interfaces to system testing (TE.070) and external interfaces (TE.100). Appropriate resources need to be deployed at each stage.
Also keep in mind that testing is an iterative process. Usually plan for two iterations, with the first iteration requiring 65% of the total effort estimated, and the second 35%.
For each test scenario, you should indicate the complexity to develop the test scenario (for example, Simple, Average and Complex) and use this as a basis for test
scenario development. You should also estimate the duration it will take to perform each test scenario. Again, use the indication of Simple, Average and Complex.
Test Environment
You should establish this environment so that it is ready before the first system test during the Elaboration phase. Install appropriate test tools in the environment. For
each iteration, the environment must be updated to reflect the content delivered up to that point of time. Make sure that support will be available, if possible on-site, during
the busiest test periods. Describe the required environments in the Environment Needs part of the Resources component.
You should detail the hardware/software requirements for the system test. Also consider the physical environment such as whiteboards, printers, and filing cabinets. You
should specify this for each test source, staging and data warehouse environments. Also, consider the following:
Environment and data backup and restore
Security considerations if access to production data is required
Supporting software such as MS Office
Risk Management
Identify in what situations the system test or parts of a system test should be suspended, and what criteria should be met to restart the test if it has been suspended. This
should put focus on important matters that must be in place to keep the system test going.
There might also be other kind of risks related to the preparation and execution of the system test. Document risk that relate to a successful completion of the system test.
Review the Baseline Risk Assessment (PJM.RKM.040) with identified risks. If it contains risks related to System Testing, include a reference to the document.
Project Learning
As the system tests are performed through a number of iterations, both in the Elaboration phase, and the Construction phase, you will gain experience on which aspects
of the test work well and those that do not work well. This may depend on a number of aspects, such as, the experience of the project members, user dedication and the
type of application. At the end of each iteration, plan to conduct a lessons learned workshop involving all test participants, preferably also including participants from
development and configuration control.
Adjust the testing approach based on the cumulative experience, and update the plan accordingly.
Back to Top
Back to Top
Tester Develop System Test Plan. For some projects, this may be a lead tester. 100
Back to Top
PREREQUISITES
TE.050.1
Prerequisite Usage
Baseline Project Workplan The Baseline Project Workplan should be used to see how system testing activities have been planned, and the Quality Management
(PJM.WM.010)
(PJM.QM.010)
Plan to see how quality will be ensured, and how that is related to testing.
Baseline Risk Assessment
(PJM.RKM.040)
The Baseline Risk Assessment may include risks specific to system testing.
Testing Strategy (TE.010) The Testing Strategy should be used as input for how the system test should be performed.
Project Team Learning Plan
(TR.020)
The Project Team Learning Plan should include any needs for education related to testing. This should be used as input to see
whether any needs have not been identified specific to system testing.
Cutover Strategy (TS.020.1) The initial Cutover Strategy provides a strategy that describes how the organization goes from the present system to the new
application system. This should be taken into consideration when developing the System Test Plan.
(DS.160.1)
Conversion Component
Designs (CV.040.1)
Use the Conversion Component Designs (CV.040) to identify and define test types, test items and features to be tested.
TE.050.2
Prerequisite Usage
Testing Strategy (TE.010) The Testing Strategy should be used as input for how the system test should be performed.
Cutover Strategy (TS.020.1) The Cutover Strategy provides a strategy that describes how the organization goes from the present system to the new application
system. This should be taken into consideration when developing the System Test Plan.
(DS.160.2)
Conversion Component
Designs (CV.040.2)
System Management Guide
(TA.100)
Use the Conversion Component Designs (CV.040) as well as the System Management Guide (TA.100) to identify and define test
types, test items and features to be tested.
Back to Top
TECHNIQUES
Technique Comments
Service Testing Use this technique to help you plan testing for services.
Back to Top
TEMPLATES AND TOOLS
TE-050_SYSTEM_TEST_PLAN.DOC MS WORD
Back to Top
The System Test Plan is used in the following ways:
The lead tester uses the System Test Scope as the starting point for planning.
Testing members use the System Test Roles to understand their responsibilities.
Operations uses the Environment Requirements section for providing hardware and software.
The project leader uses the Environment Requirements section for budgeting.
The lead tester uses the schedule results for sequence and script development and testing status.
Distribute the System Test Plan as follows:
to the quality manager for judging the quality of the test plan
to the client project manager to accept the components and agree on scope, detail, and quality of the system test
Back to Top
QUALITY CRITERIA
Is the System Test Plan within the requirements and expectations of the Testing Strategy?
Has sufficient time been scheduled for system testing?
Has the test data set, if required, been generated appropriately?
Have the steps been correctly given in appropriate sequence for each test scenario?
Back to Top
TE.060 - PREPARE SYSTEM TEST ENVIRONMENT
In this task, you prepare the System Test Environment.
In a commercial off-the-shelf (COTS) application implementation, this task is used during the Construction phase to establish the System Test Environment to test the
operation and integration of business system flows within the (COTS) application system, including the integration of application extensions.
For projects that involve the upgrade of Oracle products, the System Test Environment is typically used to iteratively test the migration of custom objects to the new
release. Therefore, depending on the project phase and specific iteration, this task is used to create or refresh the System Test Environment.
ACTIVITY
TE.060.1
TE.060.2
C.ACT.PST Prepare for System Test
Back to Top
WORK PRODUCT
System Test Environment - The System Test Environment consists of all the required system components that are needed to perform a proper system test, such as the
system test database, manual data, converted data, components, application server, external tools, and online help text. When the task has completed, the work product
will be the actual environment including a setup report that reflects how the System Test Environment actually has been set up.
Back to Top
TASK STEPS
1 Review the Testing Strategy (TE.010) to see what kind of
testing environments should be used, and System Test Plan
(TE.050) for more detailed requirements for the System Test
Environment.
None None
2 Determine the exact configurations required for the System
Test Environment.
System Test
Environment
Setup Report
The System Test Environment Setup Report documents the exact configurations
that will be/are used for the System Test Environment. This includes the
hardware, software, set up and network configurations.
3 Determine required test data for System Test. Test Data
Baseline
Manual Data
Load
Scripted Data
Load
Converted
Data Load
Test Data (TE.018)) will be used for the system test.
entered in the system test environment on top of the test data baseline.
the system test environment on top of the test data baseline using scripts.
into the system test environment on top of the test data baseline using conversion
programs or scripts.
4 Determine required help data for the System Test
Environment.
Help Text Data
Load
The Help Text Data Load component describes all help text scripts or files must be
included in the system test environment.
5 Determine default application setup for the System Test
Environment
Application
Setup
The Application Setup component describes how the application should be set up
as an initial setup as required by the developed application. This could be values
of system parameters and other type of setup information, such as application
user roles.
#TOP #TOP
system test.
Application
Object Load
for System
Test
The Application Object Load for System Test component describes all the sources
that should be contained in the system test environment.
7 Set up physical System Test Environment. Update of all
components
listed in this
table above
The components listed above will be updated along with the physical creation of
the System Test Environment. The work product as a whole should be seen as a
setup report that reflects how the System Test Environment actually has been set
up.
8 Quality check System Test Environment. Update of all
components
listed in this
table above
When the System Test Environment is ready to be used, it must be quality
changes.
Back to Top
APPROACH
The System Test Environment should be controlled to ensure that the test is performed with the appropriate versions of the System as developed thus far. The system
test uses a range of components that should work together as a whole, therefore, it must be certain that the needed components as well as application(s) set ups and
patches are available in the versions that should work together as an integrated set.
The System Test Environment is first created at the end of the first iteration in the Elaboration phase. This is fairly early in the project, and the environment needs to be
updated (evolved) for each iteration to be ready for the system tests at the end of the iterations. Test data baselines are produced in the task Prepare Static Test Data
(TE.018) and should be used as a starting point for data production to the System Test Environment.
Install appropriate test tools in the test environment(s). Allow time for training and familiarization. Make sure that support is available, if possible on-site, during the busiest
test periods.
The System Test Environment includes the following:
required configurations (database, application, workstations, etc)
data baseline
manual data load
scripted data load
converted data load
online help text
application setup
implemented components
Back to Top
System Architect
Participate in the preparation of the Information Architecture for the System Test Environment to support system testing.
20
System Architect Participate in the preparation of the Technical Architecture for the System Test Environment to support system testing. 20
System Administrator Install application software. Provide support for the system testing. 40
Tester Provide support for the creation of the System Test Environment, and prepare testing tools. Perform quality check of the
environment. For some projects, this may be a lead tester.
20
IS Support Staff Provide support for the creation of the System Test Environment. *
Back to Top
PREREQUISITES
TE.060.1
Prerequisite Usage
Testing Strategy (TE.010) The Testing Strategy is reviewed to determine what kind of strategy has been chosen in regards to the System Test Environment.
(IM.040.1)
The Implemented Database provides the data you need to create database objects in the System Test Environment. Adjust the storage
parameters before creating the System Test Environment if disk space is limited.
Static Test Data (TE.018.1) Baseline Static Test Data is used as a starting point to create test data for the system test.
Functional Prototype
(IM.010)
The Functional Prototype contains all the components and services that should be system tested during the Elaboration phase.
System Test Plan (TE.050.1) The preparation of the System Test Environment should occur according to the System Test Plan.
TE.060.2
Prerequisite Usage
(IM.040.2)
The Implemented Database provides the data you need to create database objects in the System Test Environment. Adjust the storage
parameters before creating the System Test Environment if disk space is limited.
Integrated Services (IM.080) The Integrated Services is the actual components and services that should be system tested.
System Test Plan (TE.050.2) The preparation of the System Test Environment should occur according to the System Test Plan.
Static Test Data (TE.018.2) Baseline Static Test Data is used as a starting point to create test data for the system test.
Back to Top
TECHNIQUES
Technique Comments
Service Packaging and Deployment Use this technique for guidance while applying the deployment configuration for the test environment.
Back to Top
TEMPLATES AND TOOLS
TE-060_SYSTEM_TEST_ENVIRONMENT.DOC MS WORD
Back to Top
The System Test Environment is used in the following ways:
by the lead tester who uses the end reports (setup report) as tangible evidence that the test environment is ready
Back to Top
QUALITY CRITERIA
Have all application components been correctly installed in the System Test Environment?
Is the System Test Environment set-up consistent with the scope of the system test planning requirements?
Has the System Test Environment been quality checked?
Back to Top
TE.065 - PERFORM INSTALLATION TEST
In this task, you install all application components in the System Test Environment to test the installation routines and refine them for the eventual Production
Environment. This task is done in parallel with setting up the testing environments.
In a commercial off-the-shelf (COTS) application implementation, this task is performed only for custom-built component that extend the functionality of the COTS system
and/or integrate the COTS system with other COTS or legacy systems. In this task, you install application extensions in the System Test Environment to test the
installation routines and refine them for future use in preparing the Production Environment.
ACTIVITY
Back to Top
WORK PRODUCT
Tested Installation Routines - The Tested Installation Routines provide evidence that the application can be installed into an environment, usually the System Test
Environment, by following the installation steps found in the Installation Plan (TS.030). The Tested Installation Routines should address the adequacy of the Installation
Plan. The work product also contains the Installation Results that document the actual results from the installation.
Back to Top
TASK STEPS
1 Review the Installation
Plan (TS.030).
None None
2 Follow instructions and
execute the Installation
Plan.
Installation
Plan
This is produced during Develop Installation Plan (TS.030). Any difficulties noted during the installation of applications
extensions or patches in the testing environments should be noted directly on the Installation Plan to reflect the corrected
instructions.
3 Document actual results. Installation
Results
This component documents the actual results from the installation.
4 Review the results with
the developer.
None None
5 Fix errors in the
installation routines and
instructions.
(Corrected)
Installation
Plan
The Installation Plan produced during Develop Installation Plan (TS.030) is updated based on the reviewed installation
results.
Back to Top
APPROACH
This task serves as a dry run of the installation steps in preparation for configuring the production system.
Use the Tested Installation Routines to prove that the Installation Plan (TS.030) in a System Test Environment works properly. The task is done in parallel with setting up
the System Test Environment. Setting up the System Test Environment is done iteratively, and there might not be a full setup for each iteration, so a full test of the
installation may not be possible as a copy of the previous installation environment probably might be used as a starting point.
Since there are no formal test scripts for this task, use the Installation Plan (TS.030) as a reference to record your test results. Make comments directly on the various
sections in the Installation Plan. Review and update the Installation Plan accordingly. At the completion of your testing, you should have an accurate Installation Plan.
Where there are specific instructions in installing a component or a set of components, it is the responsibility of the developer to create and unit test installation routines
and procedures to support this. A common mistake is to have the developer who coded the components also install this in the System Test Environment. This creates a
potential problem because the original developer may have transitioned off the project and the system administrator, or someone else, must reinstall the component(s)
without accurate installation instructions.
During testing, you should plan to follow the installation instructions without help from the developer unless you run into a problem you cannot resolve. The goal is to be
able to install all applications components by following only the Installation Instructions provided. This may take several attempts.
Environment Preparation
Some aspects of the installation might be difficult to undo, for example some extensions to standard applications. If you need to retest the installation process or if one of
the steps results in an incorrect configuration, you can restore the target environment from a backup and start over.
Back to Top
Back to Top
System Administrator Perform the installation test. 80
Developer Walk through problems from the installation test with the system administrator, and provide other required assistance. 20
Back to Top
PREREQUISITES
Prerequisite Usage
Installation Plan (TS.030) The Installation Plan are your guides to the installation process.
(TE.005.2)
The Testing Requirements and Testing Strategy provide the testing approach and testing requirements and strategy for testing.
System Test
Environment (TE.060.2)
Systems Integration Test
Environment (TE.085)
The Installation Test is performed in parallel with setting up the System Test Environment. Prior to the test, the environment consists of the
physical hardware, the database, and initial setup that is required prior to installing the application components.
Installation Routines
(IM.090)
These routines include documented instructions for installing all of the custom modules in the testing and production environments. Not all
customizations can be installed with an automated script, so the instructions may include manual steps as well.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Tested Installation Routines are used in the following ways:
to show that you have an Installation Plan that can be relied upon when installing the application components in the production environment
Back to Top
QUALITY CRITERIA
Has the installation test been performed on an actual environment, such as the System Test Environment?
Have all problems, inconsistencies or unclear steps been improved upon?
Does the installation guide include information about all installation steps?
Is the description of all installation steps correct?
Is the description of all installation steps sufficient (there is no missing information)?
Back to Top
TE.070 - PERFORM SYSTEM TEST
In this task, you perform the system test that is performed at the end of each iteration, both in the Elaboration and Construction phases. Test the application system based
on the plan outlined in the System Test Plan using the scenarios described in the System Test Scenarios. The last iteration of the system test is performed at the end of
all iterations, at the end of the Construction phase. It should be concerned with the behavior of the system as a whole.
In a commercial off-the-shelf (COTS) application implementation, you perform the system test to test the operation and integration of all business system flows within the
(COTS) application system, including the integration of application extensions. This task is equivalent to a full conference room pilot (CRP) where the environment
simulates the future production environment. The system test is performed in a test environment.
In an application implementation project, system testing is generally performed in the Construction phase. However, for application projects employing a requirements-
driven approach, it may be performed in the Elaboration phase for complex, higher risk custom extensions that have been identified during the pre-sales cycle and/or
during the Inception phase, and where the prototypes of those complex custom extensions that have been developed during the Elaboration phase, continues to be
enhanced during the Construction phase.
ACTIVITY
TE.070.1
B.ACT.PSTE Perform System Test - Elaboration
TE.070.2
Back to Top
WORK PRODUCT
System-Tested Applications - The System-Tested Applications are applications that have been tested to verify that the applications work as a whole (final full system
test) or as far as they have been developed (iteration system tests), in a way that is consistent with what the users expect, and that there are no inconsistencies and
omissions between the partitions.
Back to Top
TASK STEPS
1 Review the System Test Plan (TE.050) to
see how the system test is planned for
each iteration.
None None
2 Review the System Test Scenarios
(TE.025) to see how they best can be
distributed among the testing team.
None None
3 Prepare test scripts. Test Scripts The Test Scripts are small programs that are used to automate as much as possible of the test. This
could be to test parts of, or complete scenarios.
4 Perform System Test. System Test
Detail
Defects
The System Test Detail describes per System Test Scenario whether it has failed or passed (or
skipped).
The Defects are actual errors that have been discovered during the system test. These should
preferably be logged in a defect tracker tool.
5 Conclude System Test. System Test
Summary by
Test Type
System Test
Summary by
Iteration
The System Test Summary by Test Type summarizes how many test have passed, failed and have
been skipped. It also summarizes how many tests have been completed, how many should have been
completed, and the completion and passed percentage.
The System Test Summary by Iteration provides a similar summary as above, but this time organized
as a summary for each system test iteration.
Back to Top
APPROACH
This task is mandatory and is performed at the end of each development iteration during the Elaboration and Construction phase. In this way, the system test is executed
several times, but there might also be executed a number of system test iterations at the end of a development iteration. Fewer system test iterations will be expected at
the end of early development iterations as the feedback from the system test easily can be incorporated into the next development iteration. Probably none of the
development iterations in the Elaboration phase will require multiple system test iterations at the end.
The system test that is performed at the end of each iteration may have a different character than the final system test. The final system test should cover all System Test
Scenarios, but the project situation may not allow that such a full test can be done at the end of each iteration.
Individual System Test Scenarios may be performed a number of times, depending on the results during the various system tests, and system test iterations.
The Iterative Approach to a Tested System
In Classic or Waterfall approaches to system development, the system test is the moment of truth. Using those approaches, the system test is executed at the end of the
project, similar to OUM's final System Test, but in OUM we also perform the system test multiple times before we come to the final full system test. When following those
other approaches, it is not unusual for major problems to become visible during system testing, and it has been known for such projects to enter system testing and never
emerge from it before the project has been canceled because of schedule and budget overruns. Often this situation has arisen as a result of developers not
understanding requirements, and of designs not having been adequately reviewed by users, who were only involved at the beginning and end of the project.
The OUM, approach has been designed to avoid this kind of disaster scenario. In this approach, requirements are formulated by the project team working together. The
continuous involvement of empowered users contributes to a common understanding of testable requirements. The test as you go approach to testing also contributes
to preventing unpleasant surprises at the end of the project. Ambassador users and advisor users, with their knowledge of business processes and needs, and
developers, with their technical skills, participate in testing. Tasks are allocated by agreement within the team, in order to achieve their common objectives within each
timebox.
In OUM, the goal of system testing is to verify that the system works as a whole, as far as it has been developed when the system test is performed, in a way that is
consistent with what the users expect, and to detect inconsistencies and omissions between the partitions. The system test (TE.070) is performed at the end of each
iteration for early detection of integration issues. A final full system test is performed at the end of Construction phase. This system test is performed after the final
iteration and covers all loose ends or System Test Scenarios that have not been completed successfully during earlier system tests.
The goal is to provide a system with the agreed functionality and which meets all the agreed supplemental requirements. At the end of the full system test, there should be
a working, useable system that safely can be placed in the users business environment.
Test, Fix and Conduct Retests
Typically, the system test is executed more than once. Each test execution is referred to as a test iteration. These test iterations should not be confused with application
development (build) iterations. This means that after one development iteration, the system test belonging to that iteration, may be executed more than once. The early
system tests performed during the Elaboration phase are more likely to be executed only once since the defects found can been fixed in the next development iteration.
Integration to System
2. Upper-level integration of partitions and other components is part of the system test and final full system test (TE.070)
Execute Script for each System Test Scenario
An important part of integration and system testing is scenario-based testing. Some of this testing must be performed manually, but parts of it could be performed by
executing automated scripts using scripted data that has been developed during component testing. Prepare scripts where possible, and where the benefit will outweigh
the cost. You might find it useful to track the status of each scenario separately. It is usual for some scenarios to be tested only once or twice before the results are
satisfactory, whereas other scenarios require many iterations.
Execute Script for each Architecture Test
The supplemental requirements tests are executed in order to confirm the system and technical architecture, and to verify that the architecture has been implemented to
meet the agreed supplemental requirements. Typically, these tests include:
middleware and connectivity tests
security, safety and control tests
performance, stress, storage, volume and load tests
coexistence testing (at each level of a multi-tier architecture)
user interface, usability and operability testing
reliability, installability, and recovery testing
portability and compatibility testing
maintainability and configuration testing
Keep in mind that some supplemental requirements testing is performed in the Performance Management and Technical Architecture process.
actual result. In addition, the System Test Summary components can easily be collected.
Back to Top
Back to Top
Tester Perform the system test. This person should also be able to design tests. Manage the system test. Answer questions and
resolve potential issues. Represent the project team. Monitor test execution and results.
allocated to the tester. The team leader would then manage the system test, answer questions and resolve potential issues,
represent the project team, and monitor test execution and results.
100
Ambassador User Participate in the system test. Allowing the users to participate in the system test provides earlier feedback on
misunderstandings/incorrect interpretations of requirements.
*
Back to Top
PREREQUISITES
TE.070.1
Prerequisite Usage
System Test Scenarios (TE.025.1) The System Test Scenarios are used when performing the system test.
System Test Plan (TE.050.1) The System Test Plan describes the plan for system testing, including which scenarios should be used in what order.
System Test Environment (TE.060.1) Before the system test can start, the System Test Environment must be ready.
TE.070.2
Prerequisite Usage
System Test Scenarios (TE.025.2) The System Test Scenarios are used when performing the system test.
System Test Plan (TE.050.2) The System Test Plan describes the plan for system testing, including which scenarios should be used in what order.
System Test Environment (TE.060.2) Before the system test can start, the System Test Environment must be ready.
Back to Top
TEMPLATES AND TOOLS
TE-070_SYSTEM_TEST_RESULTS.DOC MS WORD
Back to Top
The System Test Results template is used to document the actual results from the various system tests. The System Test Results are used in the following ways:
by the project manager to assist in reporting of status by the lead application developer(s) and developers to correct functional defects
by the lead system developer to correct defects related to supplemental requirements
Distribute the System Test Results as follows:
to all team members
Back to Top
QUALITY CRITERIA
Has integration and system testing been performed as described in the System Test Plan (TE.050) ?
Is there evidence of adequate coverage, such that it is unlikely that serious errors remain undetected?
Is there evidence that all the essential requirements (functional and supplemental) have been tested and, where necessary, demonstrated to the users?
Have any and all safety-related and product liability aspects of the system been properly validated?
Has all functionality that has been provided to support transition to production been adequately tested?
Back to Top
TE.072 - TEST PRE-UPGRADE STEPS
In this task, you perform the pre-upgrade steps in your test environment. Follow the steps documented by Oracle upgrade instructions for your specific application plus
any custom upgrade steps you require for migrating custom extensions and data.
ACTIVITY
TE.072.1
TE.072.2
Back to Top
WORK PRODUCT
Pre-Upgrade Checklist - The Pre-Upgrade Checklist is a checklist for performing the pre-upgrade steps. Continue to assess and enhance this document during the
packaged software upgrade test (TE.073) and the post-upgrade steps test (TE.074). The final checklist will contain all steps identified by these three tasks. During
Production Migration this checklist will be used to document the test results of pre-upgrade steps (TS.054), the Production Environment upgrade (TS.055), and the post
upgrade steps (TS.056).
Back to Top
TASK STEPS
1 Perform each pre-upgrade step as described in the Oracle
Application-Specific Upgrade Instructions.
Application-Specific
Upgrade Instructions
Use the Application-Specific Upgrade Instructions to record
information related to the pre-upgrade steps.
2 Record the results for each step in the Issue Log. Issue Log The Issue Log provides a table to track issue resolution activities
associated with testing pre-upgrade steps.
3 Update the Pre-Upgrade Checklist, as necessary. Pre-Upgrade Checklist
Back to Top
APPROACH
In your initial iteration, you perform the standard steps and record them in your upgrade checklist document / application. When you identify places where you need to
perform special steps for custom extensions, migrating custom data, or architecture changes, add these steps to your checklist document / application (even if you do not
yet have all the custom migration scripts you need at this point).
Not all delivered steps for an upgrade outlined for your application may apply. Update your upgrade checklist document / application as appropriate as these are identified
to help accelerate subsequent iterations. Keep in mind that the cycle of an upgrade through go live might result in some tasks becoming active due to changes in
production over time.
In subsequent iterations and the final production upgrade, you will execute the pre-upgrade steps using the new checklist that you have developed.
Back to Top
System Architect Execute and evaluate the pre-upgrade steps. 100
Back to Top
PREREQUISITES
Prerequisite Usage
(MC.050)

Back to Top
TEMPLATES AND TOOLS
The following tool guidance is available to assist with this task:
Tool Comments
PeopleSoft Upgrade Guidance Refer to the PeopleSoft Upgrade Instructions Document provided for Pillar/Path through Oracle My Oracle Support.30 Please note
that the Change Assistant Tool is required at this point to create a job based on the application to filter the critical tasks necessary
to execute relevant steps prior to executing the upgrade. Details on Change Assistant setup exist on the Upgrade Home page and
further details are on the Upgrade Instructions document.
Back to Top
The Pre-Upgrade Checklist is used in the following ways:
to formally describe each step within the pre-upgrade preparation process
to formally capture the expected and actual results of each pre-upgrade step test
Distribute the Pre-Upgrade Checklist as follows:
to the technical team leader
Back to Top
QUALITY CRITERIA
Does the Pre-Upgrade Checklist describe all of the steps involved in the pre-upgrade process?
Does the Pre-Upgrade Checklist include a complete list of expected and actual results for each iteration?
Have lessons learned from earlier iterations of the pre-upgrade testing process been included?
Back to Top
TE.073 - TEST PACKAGED SOFTWARE UPGRADE
In this task, you run the standard software upgrade process against your test environment as documented by Oracle upgrade instructions relevant to each application
pillar and upgrade path.
ACTIVITY
TE.073.1
TE.073.2
Back to Top
WORK PRODUCT
Packaged Software Upgrade Checklist - The Packaged Software Upgrade Checklist is a list of steps to be performed during the upgrade, along with expected and
actual results.
Back to Top
TASK STEPS
1 Execute delivered upgrade tasks as determined by the application pillar
and specific upgrade path as detailed in the related instruction
document.
Upgrade
Instructions

2 Determine any additional steps that need to be added to the Packaged
Software Upgrade Checklist.
Packaged Software
Upgrade Checklist
The Packaged Software Upgrade Checklist is a list of steps to be
performed during the upgrade, along with expected and actual
results.
Back to Top
APPROACH
Execute delivered upgrade tasks against the initial copy of production determined by the application pillar and specific upgrade path as detailed in the related instruction
document.
Your first iteration may be against a copy of production test environment, but the final iteration should be against a copy of the production instance.
During the initial iteration, performance should not be considered your priority. At this point, it is more important to ascertain a baseline of processes and tasks relevant to
your environment with a focus on data integrity and issue resolution. Subsequent iterations should focus on improving the overall timeline that will meet with an
acceptable window of opportunity for go-live
Back to Top
System Architect Execute and evaluate the upgrade steps. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Pre-Upgrade Checklist
(TE.072)
Use the Pre-Upgrade Checklist to verify that all the pre-upgrade steps have been completed, and to note any results that affect the
software upgrade process.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
PeopleSoft
Upgrade
Guidance
Execute the upgrade tasks utilizing the Change Assistant Application. At this point, Change Assistant will have been executed as an application to
generate a job based on the upgrade process as early as the execution of the task, Perform Custom Extension Impact Analysis (RD.136).
EBS Upgrade
Guidance
Run the standard software upgrade against your test environment as documented by Oracle. This typically involves running the AutoInstall utility.
Back to Top
The Packaged Software Upgrade Checklist is used in the following ways:
to formally describe each step within the upgrade process
to formally capture the expected and actual results of each upgrade step
Distribute the Packaged Software Upgrade Checklist as follows:
Back to Top
QUALITY CRITERIA
Does the Packaged Software Upgrade Checklist describe all of the steps involved in the upgrade process?
Does the Packaged Software Upgrade Checklist include a complete list of expected and actual results for each iteration?
Have lessons learned from earlier iterations of the upgrade testing process been included?
Back to Top
TE.074 - TEST POST-UPGRADE STEPS
In this task, you perform the post-upgrade steps in your test environment. Follow the steps documented by Oracle upgrade instructions for your specific application plus
any custom upgrade steps you require for migrating custom extensions and data.
ACTIVITY
TE.074.1
TE.074.2
Back to Top
WORK PRODUCT
Post-Upgrade Checklist - The Post-Upgrade Checklist is a checklist for performing the post-upgrade steps.
Back to Top
TASK STEPS
1 Perform each post-upgrade step as described in the Oracle
Application-Specific Upgrade Instructions.
Upgrade Instructions
Use the Application-Specific Upgrade Instructions to record
information related to the post-upgrade steps.
2 Record the results for each step in the Issue Log. Issue Log The Issue Log provides a table to track issue resolution activities
associated with testing post-upgrade steps.
3 Update the Post-Upgrade Checklist, as necessary. Post-Upgrade Checklist
Back to Top
APPROACH
In your initial iteration, you perform the standard steps and record them in your upgrade checklist document / application. When you identify places where you need to
perform special steps for custom extensions, migrating custom data, or architecture changes, add these steps to your checklist document / application (even if you do not
yet have all the custom migration scripts you need at this point).
Not all delivered steps for an upgrade outlined for your application may apply. Update your upgrade checklist document / application as appropriate as these are identified
to help accelerate subsequent iterations. Keep in mind that the cycle of an upgrade through go live might result in some tasks becoming active due to changes in
production over time.
In subsequent iterations and the final production upgrade, you will execute the post-upgrade steps using the new checklist that you have developed.
Back to Top
System Architect Execute and evaluate the post-upgrade steps. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Packaged Software Upgrade Checklist (TE.073) Use the Packaged Software Upgrade Checklist to verify the results of the software upgrade.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
PeopleSoft
Upgrade
Guidance
Refer to the PeopleSoft Upgrade Instructions Document provided for Pillar/Path through Oracle My Oracle Support.30 Please note that the Change
Assistant Tool is required at this point to create a job based on the application to filter the critical tasks necessary to execute relevant steps prior to
executing the upgrade. Details on Change Assistant setup exist on the Upgrade Home page and further details are on the Upgrade Instructions Document.
Back to Top
The Post-Upgrade Checklist is used in the following ways:
to formally describe each step within the post-upgrade preparation process
to formally capture the expected and actual results of each post-upgrade step test
Distribute the Post-Upgrade Checklist as follows:
Back to Top
QUALITY CRITERIA
Does the Post-Upgrade Checklist describe all of the steps involved in the post-upgrade process?
Does the Post-Upgrade Checklist include a complete list of expected and actual results for each iteration?
Have lessons learned from earlier iterations of the post-upgrade testing process been included?
Back to Top
TE.075 - PERFORM POST-UPGRADE RECONCILIATION
TESTING
Use this task to run reconciliation reports and audits to verify that the results between the upgraded system and the original system match. This testing does not include
full testing of business processes, but may include spot testing of specific functionality to verify that the upgrade completed successfully.
ACTIVITY
TE.075.1
TE.075.2
Back to Top
WORK PRODUCT
Reconciliation Test Report - The Reconciliation Test Report is typically created using system generated reports to reconcile the original and upgraded systems.
Back to Top
TASK STEPS
1 Generate system reports for the upgraded system. System-Generated Reports
2 Reconcile upgraded system reports to original system reports.
Back to Top
APPROACH
Use system generated reports to reconcile the original and upgraded systems.
Back to Top
System Architect Generate reports and reconcile the original and upgraded systems. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Packaged Software Upgrade Checklist (TE.073) Use the Packaged Software Upgrade Checklist to verify the results of the software upgrade.
Post-Upgrade Checklist (TE.074) Use the Post-Upgrade Checklist to verify the status and results from the post-upgrade steps test.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
PeopleSoft
Upgrade
Guidance
The validation process within PeopleSoft is limited in scope to audit validation reports, baseline functional testing and access as outlined in the
Upgrade Instructions Document for the application Pillar/Path on Oracle My Oracle Support.30
Back to Top
The Reconciliation Test Report is used in the following ways:
to identify anomalies between the existing and target software release
to provide input and incremental improvements to the next iteration of the upgrade process
Distribute the Reconciliation Test Report as follows:
Back to Top
QUALITY CRITERIA
Does the report cover all the areas of software being upgraded?
Where there are legitimate differences between the existing and target releases (i.e., additional data fields), does the report identify these?
If there are any instances where specific pieces of data are no longer required in the new software release, are these items documented within the report?
Back to Top
TE.076 - REVIEW UPGRADE TEST RESULTS
Use this task to review the results of the current iteration of your upgrade tests [pre-upgrade steps test (TE.072), packaged software upgrade test (TE.073), post-upgrade
steps test (TE.074), and post-upgrade reconciliation testing (TE.075)] to identify corrections and refinements and determine if additional iterations are required.
ACTIVITY
TE.076.1
TE.076.2
Back to Top
WORK PRODUCT
Upgrade Test Analysis - The Upgrade Test Analysis is used to record key information regarding the review of the various upgrade test results.
Back to Top
TASK STEPS
1 Update the Executive
Overview.
Executive
Overview
The Executive Overview documents the upgrade test results purpose, approach, results, and recommended
actions.
2 Update the Issue Log. Issue Log The Issue Log records information about each issue identified during the test results review to facilitate follow-up
activities.
Back to Top
APPROACH
At this point, the key considerations for review that will flow back into subsequent iterations are data validation, process run times and process conversion issues during
execution of the upgrade tasks. These elements will determine the comfort point for executing the move to production.
Back to Top
System Architect Complete the Upgrade Test Analysis and review the various upgrade test results. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Post-Upgrade Steps Checklist
(TE.074)
The Post-Upgrade Steps Checklist is used to verify the results of the post-upgrade steps test.
Reconciliation Test Report
(TE.075)
The Reconciliation Test Report is used to verify the results of the reconciliation between existing and target software release that were
captured during upgrade process
Back to Top
TEMPLATES AND TOOLS
TE-076_UPGRADE_TEST_ANALYSIS.DOC MS WORD
Tool Comments
PeopleSoft
Upgrade
Guidance
Use the Change Assistant job to determine the upgrade issues and overall performance times executed during the upgrade process. The Change
Assistant job process can be exported to an Microsoft Excel file for review and validation of all executed tasks.
Back to Top
The Upgrade Test Analysis is used in the following ways:
to provide an overall analysis of the pre-upgrade steps, packaged software upgrade, post-upgrade steps and reconciliation results
to identify corrections and refinements and determine if additional iterations are required
Distribute the Upgrade Test Analysis as follows:
Back to Top
QUALITY CRITERIA
Does the Upgrade Test Analysis fully describe the approach, results, and recommended actions?
Back to Top
TE.080 - DEVELOP SYSTEMS INTEGRATION TEST PLAN
In this task, you develop the Systems Integration Test Plan, which you use as a guide when you perform the systems integration test at the end of the Construction phase.
A systems integration test is a test between two or more application systems, the interfacing to external systems. If the project team has developed these systems in
parallel, the integration test can be fully or partly a part of the systems integration test. However, when different teams -- perhaps for different user organizations -- are
involved, or delivery dates are different, you must plan for a separate integration test. The plan includes information about tester roles and responsibilities, test types, test
data and test estimates and scheduling.
The Systems Integration Test Plan is completed at the end of the Elaboration phase, when the requirements for systems integration should have stabilized. If there are
any changes to these requirements, or any additional requirements are identified at a later point in time, then the Systems Integration Test Plan should be updated to
reflect these changes.
ACTIVITY
Back to Top
WORK PRODUCT
Systems Integration Test Plan - The Systems Integration Test Plan is very similar to the System Test Plan. It contains all information necessary to plan, prepare for and
conduct the Systems Integration Test.
Back to Top
TASK STEPS
(PJM.WM.010) to see how systems integration
testing activities have been planned, and the
Quality Management Plan (PJM.QM.010) to
review how quality will be ensured.
Introduction Document any specifics related to the these documents. Also include a reference to these
documents.
2 Review Testing Requirements (TE.005) and the
Testing Strategy (TE.010) documents. The
Systems Integration Test plan should be within
the boundaries provided by these documents.
Introduction Document any specifics related to these documents. Also include a reference to these
documents. Use this as a source to determine the types of integration tests that are to be
performed.
3 Determine Systems Integration Test Scope. Systems
Integration
Test Scope
The Systems Integration Test Scope describes the scope of the systems integration test. The
scope describes Test Types that should be performed during the various Systems Integration
Tests. It also lists the Test Items that should be tested as part of the systems integration test, the
features that should be tested, and the features that for some reason should not be tested.
4 Determine Systems Integration Test Approach. Approach The Approach section includes the approach that you will use for the systems integration tests.
This should have been documented earlier in the Testing Strategy (TE.010). If you need to
further detail the described approach do that in this section. Do not repeat the strategy as
described in the Testing Strategy, but include a reference.
5 Determine pass and fail criteria for test items. Item
Pass/Fail
Criteria
The Item Pass/Fail Criteria provides the pass/fail criteria for the test.
6 Determine Systems Integration Test Work
Products.
Systems
Integration
Test Work
Products
The Systems Integration Test Work Products component describes what will be delivered as a
result from the Systems Integration Test. This should reflect the work product as described for
the Systems Integration Test (TE.120).
7 Determine Testing Tasks and Schedule. Systems
Integration
Test
Schedule
The Systems Integration Test Schedule component lists all the Testing tasks that should be
performed as part of the Systems Integration Test. It also includes a schedule for when the tasks
should be performed. This should be inline with the overall project plan. If the project plan has
sufficient details, do not repeat the content of the project plan. Instead, refer to it.
#TOP #TOP
8 Determine detailed Systems Integration Test
Resources The Environment Requirements section of the Resources component describes in detail the
hardware and software requirements to the environment, including other kind of physical
requirements needed to perform a proper systems integration test. The Testing Strategy
(TE.010) includes details for the required testing environments. If it contains sufficient level of
detail, do not repeat the content, but include a reference.
9 Determine Systems Integration Test
Responsibilities.
Resources The Responsibilities section of the Resources component describes the roles that should be
involved in the Systems Integration Test, what their responsibilities are. It also lists one or more
persons that are responsible for the various test types.
10 Determine staffing and training needs. Resources The Staffing and Training Needs section of the Resources component describes the required
skills for systems integration testing, and what the training needs are for those that should be
involved in systems integration testing. The Project Team Learning Plan (TR.020) should include
this kind of information. If this is sufficient, do not repeat the content, but include a reference.
11 Identify risks and related risk management. Risk
Management
The Risk Management component contains high-risk assumptions that relate to a successful
completion of systems integration test. It also contains contingency plans for each. The Baseline
Risk Assessment (PJM.RKM.040) includes identified risks. If any relate to the systems
integration tests, include a reference to the work product, rather than duplicating the content.
The Risk Management component also contains suspension criteria and resumption
requirements. Specify the criteria to suspend some or all of the tests, and the requirements to
resume these tests.
Back to Top
APPROACH
In OUM, the goal of systems integration testing is to verify that the system works as a whole together with all other systems the system communicates with or where there
are incoming or outgoing interfaces. This should be in a way that is consistent with what the users expect. At this level, you should be able to concentrate on testing
aspects related to two-ways communication between the implemented system and other application systems, and any outgoing and incoming interfaces.
Systems integration testing must make sure that:
Incoming interfaces perform the appropriate controls before the data is loaded into the actual system tables, and that any possible security controls work correctly.
Outgoing interfaces include all required data, possible encryption or other security mechanisms required either by the developed application or the receiving
system.
Two-way communications between the systems work as expected, including any required security mechanisms.
If you are going to test integration with applications outside the client's organization, ensure that mechanisms are put in place to prevent hold-ups in the systems
integration test due to delays external to your own control. Identify contact persons at the other end, agree on their involvement, agree on how defects should be handled
and agree on a schedule.
If possible, consider to cover the integration with other application systems within your application systems tests. However, the following situations may force you to plan
for a separate integration:
Project teams deliver the application systems involved at different moments in time.
Project teams have contractual obligations to different customer organizations.
The System Test Plan is very similar to the Systems Integration Test Plan. However, you may need an adapted project organization that suits the needed integration,
special change control procedures and network requirements during the integration test. Identify all external or internal interfaces. These can be of different levels of
complexity. If the system is only sending or receiving data, the test usually is not very complex. If the interface involves two-way data traffic, the integration test can be
very complex.
Scope of Testing
The scope of testing is described through a number of test types that will be performed during the systems integration test, the test items that should be tested, and the
features that should be tested. You should also list possible features that should not be tested, if they are expected to be tested. Include the reason why they should not
be tested.
Also, include a section to list all external systems that the system must integrate with, along with their key points of contact. Also identify alternate contact methods for key
points of contact.
In an OUM project, all requirements are prioritized. The systems integration testing should reflect these requirements. However, if an integration point to another system
has been decided to be developed, then it must be tested in detail before it can be released for production. Therefore, requirements that otherwise are Should Have
requirements, might become Must Have requirements when it comes to systems integration testing.
Test Types
You should identify the test types that are relevant for the systems integration test.
Each systems integration test type covers a class of technical, functional or supplemental requirements. Typical test types include the following:
business functionality tested using scenarios derived from business use case and business process models that crosses the system boundaries
performance response times (batch and online - including SQL and transaction response times), volume, stress (network stress, load-testing) (part of
Performance Testing process)
security access permissions, data security, communications security
operability tested using scenarios derived from operational procedures (part of Technical Architecture process)
network and gateway latency
locking
job scheduling
middleware and connectivity
data load - manual, initial, simulated using scripted data
documentation (including help text)
host system resource consumption
systems integration process sequence using historical or sample data
Test Items
Identify the test items that should be included in the various systems integration tests. You should do this to a level that is relevant for your project. It most situations it will
sufficient enough to document the various integration points as test items, rather than including a detailed list of the interfacing components.
List all the features that should be tested as part of the systems integration tests. This list will be used to develop the Systems Integration Test Scenarios (TE.090).
Do not include features related to performance testing, as this is covered by the Performance Testing process.
With regards to the test data:
Ensure there is a process to validate that the data generated is correct.
Ensure that the data is a representative sample.
During the project, situations may occur that impacts which features should not be tested. If there are specific features or combination of features that should not be
tested, but where it is expected that they should be tested, include a list. Also document the reason to why they should not be tested, so that it is easy to determine when
the features may be tested.
For each test item, determine the criteria that determines whether an item has passed or failed the systems integration test.
You should allocate test roles and responsibilities to team members as appropriate. Where white-box (structural) testing is relevant, it should be performed by developers.
During system testing and systems integration testing, however, most testing is black-box (functional), and this kind of testing can also be performed by user participants.
Where testing is to be performed by anyone who is not a member of the core team, you need to make sure that they first receive an introduction to the project and to the
system. You should also plan to deliver training in test techniques to those participants who have not tested computer systems before.
Integration of Partitions and Components
requirements, or in terms of use case points). On larger projects, you should consider assigning a specialist team to integration tasks. You need to make sure that the
integration of newly completed components does not destabilize previously released and integrated components.
2. Upper-level integration of partitions and other components is part of the systems integration test (TE.070).
As early as possible, the project manager and lead tester should estimate and schedule the integration and testing tasks. Lower-level integration testing is performed
within each implementation timebox as part of the integration tests. At levels above this task, system testing is usually performed in a timebox immediately following the
implementation iteration. As the number of components increases, and as the components mature towards their final versions, integration testing shifts in focus from low-
level interfaces to system testing (TE.070) and external interfaces (TE.100). Appropriate resources need to be deployed at each stage.
Also keep in mind that testing is an iterative process. Usually plan for two iterations, with the first iteration requiring 65% of the total effort estimated, and the second 35%.
For each test scenario you should indicate the complexity to develop the test case, for example as Simple, Average and Complex, and use this as a basis for test
scenario development. You should also estimate the duration it will take to perform each test scenario. Again, use the indication of Simple, Average and Complex for this.
Test Environment
The Systems Integration Test Environment should be established at the end of the last development iteration, so that the test can start as soon as possible after that.
You should detail the hardware/software requirements for the systems integration test. Also, consider the physical environment, such as, whiteboards, printers and filing
cabinets. You should specify this for each test source, staging environment and data warehouse environment. Also consider the following:
Environment and data backup and restore
Security considerations if access to production data is required
Supporting software such as MS Office
Install appropriate test tools in the test environment(s). Make sure that support, will be available, if possible on-site, during the busiest test periods. Describe the required
environments in the Environment Needs part of the Resources component.
Risk Management
Identify in particular in what situations the systems integration test or parts of a systems integration test should be suspended, and what criteria should be met to restart
the test if it has been suspended. This should put focus on important matters that must be in place to keep the systems integration test going.
There might also be other kind of risks related to the preparation and execution of the systems integration test. Document risks that relate to a successful completion of
the systems integration test. Review the Baseline Risk Assessment (PJM.RKM.040) with identified risks. If it contains risks related to Systems Integration Testing, include
only a reference to the document.
Back to Top
Back to Top
Tester Develop the Systems Integration Test Plan. For some projects, this may be a lead tester. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Baseline Project Workplan (PJM.WM.010)
Quality Management Plan (PJM.QM.010)
The Baseline Project Workplan should be used to see how systems integration testing activities have been planned,
and the Quality Management Plan to see how quality will be ensured, and how that is related to testing.
Baseline Risk Assessment (PJM.RKM.040) The Baseline Risk Assessment may include risks specific to systems integration testing.
Testing Strategy (TE.010) The Testing Strategy should be used as input for how the systems integration test should be performed.
Project Team Learning Plan (TR.020) The Project Team Learning Plan should include any needs for education related to testing. This should be used as input
to see whether any needs have not been identified specific to systems integration testing.
System Test Plan (TE.050.1) The System Test Plan provides the framework and starting point for the Systems Integration Test Plan.
System Test Results (TE.070.1) The System Test Results provide points of attention for integration testing.
Cutover Strategy (TS.020.1) The initial Cutover Strategy describes how the organization goes from the present system to the new application
system. This should be taken into consideration when developing the Systems Integration Test Plan.
Conversion Component Designs (CV.040) Use the Conversion Component Designs (CV.040) to identify and define test types, test items and features to be tested.
Back to Top
TEMPLATES AND TOOLS
TE-
080_SYSTEMS_INTEGRATION_TEST_PLAN.DOC
MS WORD
Back to Top
The Systems Integration Test Plan is used in the following ways:
Each lead tester uses the Systems Integration Test Scope as the starting point for their planning.
Testing members to understand their responsibilities.
Operations uses the Environment Requirements for providing hardware and software.
Facilities uses the Environment Requirements for space planning.
Each project leader uses it for overall planning and critical path analysis.
Distribute the Systems Integration Test Plan as follows:
to each project leader for review and inclusion in the appropriate phase end report
to each quality manager for judging the quality of the test plan
to each client project manager to accept the components and agree on scope, detail, and quality of the systems integration test
to any ambassador users, identified by each client project manager or line managers, to accept the work product
Back to Top
QUALITY CRITERIA
Is the Systems Integration Test Plan within the requirements and expectations of the Testing Strategy?
Has sufficient time been scheduled for systems integration testing?
Has the test data set, if required, been generated appropriately?
Have the steps been correctly given in appropriate sequence for each test case?
Back to Top
TE.082 - DEVELOP ACCEPTANCE TEST PLAN
In this task, you assist the user in developing the Acceptance Test Plan, which the client uses as a guide when they perform the user acceptance test during the
Transition phase.
The Acceptance Test Plan is completed at the end of the Elaboration phase, when the key requirements should have become relatively stable. However, if any
changed/additional requirements that impact the Acceptance Test Plan content are identified at a later point of time, then the Acceptance Test Plan should be updated to
reflect these changes.
ACTIVITY
Back to Top
WORK PRODUCT
Acceptance Test Plan - The Acceptance Test Plan work product includes all information necessary to plan, prepare for and conduct the user acceptance test.
Back to Top
TASK STEPS
You should assist the client in performing the following steps:
1 Review the Baseline Project
Workplan (PJM.WM.010)
to see how user
acceptance testing
activities have been
planned.
2 Review Testing
Requirements (TE.005).
The Acceptance Test plan
should be within the
boundaries provided by this
documents.
3 Determine the scope of
user acceptance testing.
Acceptance
Test Scope
The Acceptance Test Scope describes the scope of the Acceptance Test. The scope describes Test Types that should
be performed during the user acceptance tests. It also lists the Test Items and Features that should be tested, and the
Features that for some reason should not be tested.
4 Determine the approach for
user acceptance testing.
Approach The Approach section includes the approach that you will use for the user acceptance tests. This might have been
documented earlier in the Testing Strategy (TE.010). If so, do not repeat the strategy as described in the Testing
Strategy, but include a reference.
5 Determine pass and fail
criteria for test items.
Item
Pass/Fail
Criteria
The Item Pass/Fail Criteria provides the pass/fail criteria for a test.
6 Determine the work
products for the user
acceptance tests.
Acceptance
Test Work
Products
The Acceptance Test Work Products component describes what will be delivered as a result from the user acceptance
test. This should reflect the work product as described for the user acceptance test (TE.120).
7 Determine testing tasks and
schedule.
Acceptance
Test
Schedule
The Acceptance Test Schedule component lists all the Testing tasks that should be performed as part of the user
acceptance test. It also includes a schedule for when the tasks should be performed. This should be inline with the
overall project plan. If the project plan has sufficient details, do not repeat the content of the project plan. Instead, refer
to it.
8 Determine detailed
Acceptance Test
Resources The Environment Requirements section of the Resources component describes in detail the hardware and software
requirements for the environment, including other kind of physical requirements needed to perform a proper user
acceptance test. The Testing Strategy (TE.010) includes details for the required testing environments. If it contains
sufficient level of detail, do not repeat the content, but include a reference.
9 Determine Acceptance Test
responsibilities.
Resources The Responsibilities section of the Resources component describes the roles that should be involved in the user
acceptance test, what their responsibilities are. It also lists one or more persons that are responsible for the various test
types.
10 Determine staffing and
training needs.
Resources The Staffing and Training Needs section of the Resources component describe the required skills for user acceptance
testing, and what the training needs are for those that should be involved in acceptance testing. The Project Team
Learning Plan (TR.020) should include this kind of information. If this is sufficient, do not repeat the content, but include
a reference.
11 Identify risks and related
risk management.
Risk
Management
The Risk Management component contains high-risk assumptions that relate to a successful completion of the user
acceptance test. It also contains contingency plans for each. The Baseline Risk Assessment (PJM.RKM.040) includes
identified risks. If any relate to the acceptance tests, include a reference to the work product, rather than duplicating the
content. The Risk Management component also contains suspension criteria and resumption requirements. Specify the
criteria to suspend some or all of the tests, and the requirements to resume these tests.
Back to Top
APPROACH
The goal of user acceptance testing is to obtain acceptance for the developed system. It is the client that accepts the system, and therefore the client's goal for
acceptance testing is to verify that the system works as a whole, according to the agreed requirements, with all its internals and interfaces with other systems. It is the
client that determines what should be tested, and will therefore select the features that will give the best confidence in whether the system qualifies sufficiently for
production.
User acceptance testing can be everything from a full test, covering all type of tests, to a minor test just verifying a few features at the end. The level of user acceptance
testing is decided by the client, and is dependent on the level of confidence the client has to the developed system at the moment it is delivered for acceptance testing.
The more the client has been involved during testing and validation activities along the way, the better they will know the system, and the more confident they will be in
the solution.
In a commercial off-the-shelf (COTS) application implementation, at this stage of the testing, it is advised to have the user access and responsibilities set up as if it were a
production system. This can be a considerable effort in complex multinational projects (for example, multi org setup). Also you should have the proper scheduling of
concurrent requests/programs implemented. This is especially true when using batch interfaces as opposed to online interfaces.
Scope of Testing
The scope of testing is described through a number of test types that will be performed during the user acceptance tests, the test items, and the features that should be
tested. It is also recommended that you list possible features that should not be tested, if they are expected to be tested. Include the reason why they should not be
tested, so that if this is questioned at a later point of time it will be clear as to why it was not included in the test.
In determining the scope of user acceptance testing, the client needs to consider where testing needs to be done to provide the confidence they need to accept the new
system. The areas that are the most critical to the client, and/or would give the most business benefit should naturally fall into scope. However, if the client has been
heavily involved in other test activities, these are probably the areas they most likely already have tested the most. If that is the case, there might be other areas they
want to put focus on during user acceptance testing. The test results from the other tests would also provide a good input to determine possible areas where they want to
put focus on.
The client should however keep in mind that the system must be accepted before it can go into production. Therefore, the features that should get the highest priority for
user acceptance testing are the parts that must be in place and work properly before it can be released for production. These are not the acceptance criteria; these have
been documented earlier.
Test Types
Identify the test types that are relevant for the user acceptance test. The test types could be all the possible types of tests to which the system will be subjected (following
the functional and supplemental requirements). The test types should reflect the requirements defined during project.
Each test type could cover a class of technical, functional or supplemental requirements. Typical test types include the following:
business functionality tested using scenarios derived from business use case and business process models
performance response times, volume, stress (load-testing)
security access permissions, data security, communications security
operability tested using scenarios derived from operational procedures
conversion and data quality
Performance testing is performed in the Performance Management process, but the client may want to add some performance testing as part of the user acceptance test.
Operational testing, backup and recovery testing, and disaster recovery tests are performed in the Technical Architecture process, but again, the client might want to
include test types covering this as part of the acceptance test.
As these test can be quite complicated, time consuming, and sometimes require additional (costly) environments, try to involve the client during these tests, or distribute
test results for each testing iteration, so that the client will feel confident in these areas and therefore will not feel a need for retest.
Other test types may include other supplemental aspects such as maintenance testing and portability tests.
Test Items
Identify the test items that should be included. Do this to a level that is relevant to the project. Instead of documenting each and every component that should be in the
test, it might be more suitable to document the test items on another higher level, for example, functional/non-functional area, application, subsystem, module. A detailed
list of the components included in the test could be produced from configuration control.
You should list all the features that should be tested. Consider to reuse scenarios from other tests, or use the scenario list to determine scenarios that have not yet been
tested. The test results from the tests might also provide useful input to determining user acceptance test scenarios.
If there are specific features or combination of features that should not be tested, but where it is expected that they should be tested, include a list. Also document the
reason to why they should not be tested.
For each test item determine the criteria that determines whether an item has passed or failed the acceptance test. The overall acceptance criteria have already been
defined as part of the contract. The pass/fail criteria documented here is on a lower level of detail.
The client should allocate test roles and responsibilities to team members as appropriate. Also consider any training needs. Plan to deliver training in test techniques to
those participants who have not tested computer systems before.
Test Environment
The Acceptance Test Environment must be established. If the Data Acquisition and Conversion and user acceptance test tasks need to occur concurrently, then the
Acceptance Test Environment and the Production Installation must be different instances. Otherwise, it is preferable that the Acceptance Test Environment should be the
Production Installation. This gives both the development team and the users the confidence that the user acceptance test represents acceptance of the Production
Installation. Make sure that support, will be available, if possible on-site, during the busiest test periods. Describe the required environments in the Environment
Requirements section of the Resources component.
Back to Top
Tester Assist the client in developing the Acceptance Test Plan. For some projects, this may be a lead tester. 75
System Analyst Assist the client in developing the Acceptance Test Plan. 25
Validation Coordinator Develop the Acceptance Test Plan. *
Back to Top
PREREQUISITES
TE.082
Prerequisite Usage
Baseline Project Workplan (PJM.WM.010) The Baseline Project Workplan should be used to see how user acceptance testing activities have been planned.
Testing Requirements (TE.005) Testing
Strategy (TE.010)
The Testing Requirements contains requirements related to user acceptance testing, and the Testing Strategy might
include a strategy for user acceptance testing.
Project Team Learning Plan (TR.020) The Project Team Learning Plan should include any needs for education related to testing. This should be used as
input to see whether any needs have not been identified specific to user acceptance testing.
Integration Test Results (TE.040.1)
System Test Results (TE.070.1)
The test results may be useful to identify areas that require special attention during user acceptance testing.
Conversion Component Designs (CV.040.1) Use the Conversion Component Designs to identify and define test types, test items and features to be tested.
Back to Top
TECHNIQUES
Technique Comments
Service Testing Use this technique to help you plan for testing services.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Acceptance Test Plan is used in the following ways:
The validation coordinator uses the Acceptance Test Scope as the starting point for planning.
Testing members use the Acceptance Test Roles to understand their responsibilities.
Operations use the Environment Requirements section for providing hardware and software.
The client project leader uses the Environment Requirements section for budgeting.
Distribute the Acceptance Test Plan as follows:
to the quality manager for judging the quality of the test plan
to the client project manager to accept the components and agree on scope, detail, and quality of the user acceptance test
Back to Top
QUALITY CRITERIA
Is the Acceptance Test Plan within the requirements and expectations of the Testing Strategy?
Does the Acceptance Test Plan reflect the acceptance criteria set for the project?
Does the Acceptance Test Plan include sufficient test types and test features to ensure that the client will be confident with the solution of the tests pass within the
given criteria?
Has sufficient time been scheduled for user acceptance testing?
Back to Top
TE.085 - PREPARE SYSTEMS INTEGRATION TEST
ENVIRONMENT
In this task, you prepare the Systems Integration Test Environment.
In a commercial off-the-shelf (COTS) application implementation, the Systems Integration Test Environment includes the following:
configured servers with multiple application systems
configured workstations with multiple application systems
installed customizations (including interfaces)
configured databases
loaded manual data
loaded converted data
ACTIVITY
Back to Top
WORK PRODUCT
Systems Integration Test Environment - The Systems Integration Test Environment consists of the systems integration test database, manual data, converted data,
components (including interfaces to other systems), and online help text.
In a commercial off-the-shelf (COTS) application implementation, setting up an environment includes the configuration, or parameter setting, of the environment as well. In
addition, patching may also be required. It is important that all project environments be kept in sync both from a set up point of view as well as from a patching level point
of view.
Back to Top
TASK STEPS
1 Review the Testing Strategy (TE.010) to see what kind of
testing environments should be used, and Systems Integration
Test Plan (TE.080) for more detailed requirements for the
Systems Integration Test Environment.
None None
2 Determine the exact configurations required for the Systems
Integration Test Environment.
Systems
Integration
Test
Environment
Setup Report
The Systems Integration Test Environment Setup Report documents the exact
configurations that will be/are used for the Systems Integration Test Environment.
This includes the hardware, software, setups and network configurations.
3 Determine required test data for Systems Integration Test. Test Data
Baseline
Manual Data
Load
Scripted Data
Load
Converted
Data Load
Test Data (TE.018)) will be used for the systems integration test.
entered in the systems integration test environment on top of the test data
baseline.
the systems integration test environment on top of the test data baseline using
scripts.
The Converted Data Load describes any additional data that should be loaded into
the systems integration test environment on top of the test data baseline using
4 Determine required help data for the Systems Integration Test Help Text The Help Text Data Load component describes all help text scripts or files must be
#TOP #TOP
Environment. Data Load included in the systems integration test environment.
systems integration test.
Application
Object Load
for Systems
Integration
Test
The Application Object Load for Systems Integration Test component describes
how the application should be set up as an initial setup as required by the
developed application. This could be values of system parameters and other type
of setup information, such as application user roles.
6 Set up physical Systems Integration Test Environment. Update of all
components
listed above
The components listed above will be updated along with the physical creation of the
Systems Integration Test Environment. The work product as a whole should be
seen as a setup report that reflects how the Systems Integration Test Environment
actually has been set up.
7 Quality check Systems Integration Test Environment. Update of all
components
listed above
When the Systems Integration Test Environment is ready to be used, it must be
quality checked to see whether it works as expected. It might result in some
changes.
Back to Top
APPROACH
The Systems Integration Test Environment must be ready towards the end of the Construction phase, so that it is available when the Systems Integration Test starts. You
must ensure that all other systems the application should communicate with during the Systems Integration Test will be available for the test. If you need to test towards
systems outside your own control, ensure that you have mechanisms in place so that the receiving end can verify your output, and produce required input for you to test.
Test data baselines are produced in the task Prepare Static Test Data (TE.018) and should be used as a starting point for data production to the Systems Integration Test
Environment.
Install appropriate test tools in the test environment. Allow time for training and familiarization. Make sure that support, will be available, if possible on-site, during the
busiest test periods.
The Systems Integration Test Environment includes the following:
required configurations (database, application, workstations, etc)
manual data load
scripted data load
converted data load
online help text
implemented components (including interface components)
Back to Top
Back to Top
System Architect
Participate in the preparation of the Information Architecture for the Systems Integration Testing Environment to support
systems integration testing. Preferably, this should be done by a system architect that specializes in Information Architecture.
20
System Architect Participate in the preparation of the technical architecture environment to support systems integration testing. You may want to
use a system architect that specializes in system integration.
20
System Administrator Install application software. Provide support for the systems integration testing. You may want to use a system administrator
that specializes in system integration.
40
Tester Provide support for the creation of the Systems Integration Test Environment. Perform quality check of the environment. For
some projects, this may be a lead tester.
20
IS Support Staff Provide support for the creation of the Systems Integration Test Environment. *
Back to Top
PREREQUISITES
Prerequisite Usage
Testing Strategy (TE.010) The Testing Strategy is reviewed to determine what kind of strategy has been chosen in regards to the Systems Integration Test
Environment.
Implemented Database (IM.040.2) The Implemented Database provides the data you need to create database objects in the Systems Integration Test Environment.
Adjust the storage parameters before creating the Systems Integration Test Environment if disk space is limited.
Integrated Services (IM.080) The Integrated Services is the actual components and services that should be system tested.
Systems Integration Test Plan
(TE.080)
The preparation of the Systems Integration Test Environment should occur according to the Systems Integration Test Plan.
Static Test Data (TE.018.2) Baseline Static Test Data is used as a starting point to create test data for the systems integration testing.
Back to Top
TEMPLATES AND TOOLS
TE-085_SYSTEMS_INTEGRATION_TEST_ENVIRONMENT.DOC MS Word
Back to Top
The Systems Integration Test Environment is used in the following ways:
by the lead tester uses the end reports (setup report) as tangible evidence that the test environment is ready
Back to Top
QUALITY CRITERIA
Have all components been correctly installed in the Systems Integration Test Environment?
Is the Systems Integration Test Environment set-up consistent with the scope of the systems integration test planning requirements?
Have mechanisms for verification of outgoing interfaces to external parties been identified?
Has the Systems Integration Test Environment been quality checked?
Back to Top
TE.090 - DEVELOP SYSTEMS INTEGRATION TEST SCENARIOS
In this task, you develop the Systems Integration Test Scenarios that you use during the systems integration test at the end of the Construction phase. The Systems
Integration Test verifies how the system integrates with other application systems in a production-like environment.
The Systems Integration Test Scenarios have been defined as part of the Systems Integration Test Plan (TE.080). If the Systems Integration Test Scenario relates to a
use case, you can use the use case scenarios in the Use Case Model as a starting point. The Context Process Model can also be used to prepare Systems Integration
Test Scenarios as this visualizes the systems boarders and communications with other systems.
For projects that involve the upgrade of Oracle products, this task is used to review the clients existing System Integration Test Scenarios. New integration scenarios
should only need to be created to cover new features or processes that are being introduced as part of the new software release.
ACTIVITY
C.ACT.DSITS Develop Systems Integration Test Scenarios
Back to Top
WORK PRODUCT
Systems Integration Test Scenarios - The Systems Integration Test Scenarios work product consists of the set of test scenarios that each include a number of test
steps that should be performed as part of the Systems Integration Test.
Back to Top
TASK STEPS
1 Review the Systems Integration Test Plan (TE.080) to see what test types should be performed and what
features should be tested, as well as other aspects to take into consideration when producing the Systems
Integration Test Scenarios.
None None
2 Review requirements related to the System Test Scenarios that should be described. None None
3 Determine Systems Integration Test Scenarios for each feature that should be tested. System Test
Scenario
The Systems Integration Test
Scenario includes the following
information:
ID and name
Reference to system use
case scenario, if applicable
Other reference, if applicable
Revision history
Setup requirements for the
test
Required test data
Steps that are included in
the scenarios
Expected result
Preferably use some testing tool to
record the Systems Integration
Test Scenarios.
4 Review and revise Systems Integration Test Scenario. None None
Back to Top
APPROACH
#TOP #TOP
This task is mandatory if there are external system interfaces. In subsequent iterations, some of the results of this task might be reused. For each external system to be
integrated, identify and group the interfaces.
In OUM, the goal of systems integration testing is to verify that the system works as a whole together with all other systems the system communicates with or where there
are incoming or outgoing interfaces. This should be in a way that is consistent with what the users expect. At this level, you should be able to concentrate on testing
aspects related to two-ways communication between the implemented system and other application systems, and any outgoing and incoming interfaces.
Systems integration testing must make sure that:
incoming interfaces perform the appropriate controls before the data is loaded into the actual system tables, and that any possible security controls work correctly
outgoing interfaces include all required data, possible encryptions or other security mechanisms required either by the developed application or the receiving
system.
two-ways communications between the systems work as expected, including any required security mechanisms
Scope of Testing
The scope of testing is described through a number of test types that are performed during the systems integration test, the test items that should be tested, and the
features that should be tested. Test types, items and features that should be tested are described in the Systems Integration Test Plan. This task, to create the system
test scenarios, should be completely inline with the Systems Integration Test Plan, and should provide detail to the scenarios that have been listed there. Having said
that, while detailing the systems integration test scenarios, you might discover missing features, or discrepancies between the test scenarios. If this should occur, update
the Systems Integration Test Plan to reflect the additions or corrections. You also might discover reasons that certain features could not (yet) be tested, that also should
be reflected in the plan.
Systems Integration Test Scenarios
For each Systems Integration Test Scenario that has been listed in the Systems Integration Test Plan, review the requirements that are related to the Systems Integration
Test Scenario. This might be functional requirements documented in the Use Case Model (RA.023/RA.024/AN.110) or the process models (RD.011), but it might also be
supplemental requirements (RD.055). Supplemental requirements related to the use cases can normally be found as part of the Use Case Model.
Use case scenarios may provide a good starting point for many scenarios. Keep in mind that many use case scenarios may have many common aspects that easily could
be covered by a single Systems Integration Test Scenario. These use cases typically are implemented by the same set of components. Do not produce an unnecessary
amount of Systems Integration Test Scenarios when on Systems Integration Test Scenarios can be used.
result.
Back to Top
Back to Top
Tester Develop the Systems Integration Test Scenarios. Oversee, review and approve the development of the Systems Integration
Test Scenarios. For some projects, you may want to use a lead tester to oversee, review and approve the development of the
Systems Integration Test Scenarios.
100
Ambassador User Review the System Integration Test Scenarios to verify relevance relative to business. Typically the ambassador user knows
the surrounding systems better than the members of Oracle Consulting.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Systems Integration Test Plan (TE.080) This work product provides which scenarios should be created.
Future Process Model (RD.011) The Future Process Model can be used to prepare Systems Integration Test Scenarios.
Use Case Details (RA.024.1)
The use case scenarios are translated into Systems Integration Test Scenarios.
Supplemental Requirements (RD.055) The Supplemental Requirements may provide input to supplemental aspects of the Systems Integration Test.
Cutover Strategy (TS.020) The Cutover Strategy describes how the organization goes from the present system to the new application system.
Back to Top
TEMPLATES AND TOOLS
TE-090_SYSTEMS_INTEGRATION_TEST_SCENARIOS.DOC MS Word
Depending on the nature of the interfaces to be implemented and tested, appropriate testing tools may be useful. Usually these will be tools developed for load testing
and stress testing that will be relevant.
Where network connections are involved, various network analysis tools can be helpful.
Back to Top
The Systems Integration Test Scenarios are used in the following ways:
Testing members use the Systems Integration Test Scenarios as a step-by-step guide on how to perform the test
The test leader uses the required test data component to ensure that required test data will be in place prior to the test
The test leader uses the pre-conditions component to ensure that all pre-conditions are met prior to the test
The developer and/or business flow/application specialist use the Systems Integration Test Scenarios, in particular the steps and expected outcome, as an input
when defects are reported
Distribute the Systems Integration Test Scenarios as follows:
to the system analyst and ambassador users for review
to the testing members to indicate what should be tested and how
to the developers and/or business flow/application specialists
Back to Top
QUALITY CRITERIA
Have all Systems Integration Test Scenarios described in the Systems Integration Test Plan been detailed, or has there been explained why there is a
discrepancies?
Are the Systems Integration Test Scenarios related to specific use case scenarios or other type of requirements?
Are the test steps for each scenario described in sufficient detail so that a tester can understand without consulting others?
Is there for each scenario step described an understandable expected outcome?
Has the required test data been described for each test scenarios?
Back to Top
TE.100 - PERFORM SYSTEMS INTEGRATION TEST
In this task, you perform the systems integration test. Test the system's integration with other application systems in the Systems Integration Test Environment (TE.085)
based on the Systems Integration Test Plan (TE.080) and Systems Integration Test Scenarios (TE.090).
In a commercial off-the-shelf (COTS) application implementation, this task validates the integration between the target application system and other systems and verifies
that the new system meets defined interface requirements and supports execution of business processes that cross system boundaries.
ACTIVITY
Back to Top
WORK PRODUCT
Integration-Tested System - The Integration-Tested System is a system that has tested whether all integration points work as they should, and that the business flows
that cover more than a single system (or application) perform as expected.
Back to Top
TASK STEPS
1 Review the Systems Integration Test Plan
(TE.080) to see how the systems integration
test is planned.
None None
2 Review the Systems Integration Test
Scenarios (TE.090) to see how they best
can be distributed among the testing team.
None None
3 Prepare test scripts. Test Scripts The Test Scripts are small programs that are used to automate as much as possible of the test.
This could be to test parts of, or complete scenarios.
4 Perform Systems Integration Test. Systems
Integration Test
Detail
Defects
The Systems Integration Test Detail describes per Systems Integration Test Scenario whether it
has failed or passed (or skipped).
The defects are actual errors that have been discovered during the systems integration test.
These should preferably be logged in a defect tracker tool.
5 Conclude Systems Integration Test. Systems
Integration Test
Summary by
Test Type
Systems
Integration Test
Summary by
Iteration
The System Test Summary by Test Type summarizes how many test have passed, failed and
have been skipped. It also summarizes how many tests have been completed, how many should
have been completed, and the completion and passed percentage.
The System Test Summary by Iteration provides a similar summary as above, but this time
organized as a summary for each systems integration test iteration.
Back to Top
APPROACH
The systems integration test is performed at the very end of the last development iteration. However, when the components required in a Systems Integration Test
Scenario are ready for test, there is no reason to postpone this test. The earlier these components are systems integration tested, the better, so that problems are
detected as early as possible. It does however require that the Systems Integration Test Environment is available.
Individual Test Scenarios may be performed a different number of times each, depending on the results during the systems integration test iterations.
Test, Fix and Conduct Retests
Typically, the systems integration test is executed more than once. Each test execution is referred to as a test iteration. These test iterations should not be confused
with application development (build) and/or implementation iterations.
Execute the test scenarios for each group of interfaces as soon as the relevant interface components and other elements of the solution are in place. Correct any defects
identified and repeat as necessary.
After a test iteration is completed, detail and summary test results are produced. Defects found during testing are corrected and prepared for the next testing iteration.
When the next iteration is completed, results from each iteration can be compared to measure quality gains or losses. This information is used to manage quality. Plan for
additional test iterations, if necessary.
Individual Test Scenarios may be performed a different number of times each, depending on the results during the various system tests, and system test iterations.
Execute Script for each Systems Integration Test Scenario
An important part of integration and system testing is scenario-based testing. Some of this testing must be performed manually, but parts of it could be performed by
executing automated scripts using scripted data that may have been developed during component testing. Prepare scripts where possible, and where the benefit will
outweigh the cost. You might find it useful to track the status of each scenario separately. It is usual for some scenarios to be tested only once or twice before the results
are satisfactory, whereas other scenarios require many iterations.
The Systems Integration Test Results include both detailed and summary results from the system integration test. Detailed results should be logged for each step of the
test scenario. Defects are logged for each step where there was a discrepancy between the actual and expected step results. Summary results use detailed test results
to produce summaries by test type and by test iteration.
actual result. In addition, the Systems Integration Test Summary components can easily be collected.
Back to Top
Back to Top
Tester Perform the systems integration test. Manage the systems integration test. For some projects, a lead tester may manage the
systems integration test. Provide support for systems integration test by answering questions and helping resolve potential
issues and represent the project team.
allocated to the tester. The team leader would then provide support for systems integration test by answering questions and
helping resolve potential issues and represent the project team.
100
Ambassador User Participate in the systems integration test. Allowing the users to participate in the system test provides earlier feedback. *
Back to Top
PREREQUISITES
Prerequisite Usage
Systems Integration Test Environment
(TE.085)
The Systems Integration Test Environment is the environment in which you need to perform the test.
Systems Integration Test Plan (TE.080) This work product describes how to perform the test.
Systems Integration Test Scenarios
(TE.090)
This work product provides a set of test sequences and a scenario that describes how to apply these specifications. The
specific items that you test with these scenarios have to be included as well.
Back to Top
TEMPLATES AND TOOLS
TE-100_SYSTEMS_INTEGRATION_TEST_RESULTS.DOC MS WORD
Depending on the nature of the interfaces to be implemented and tested, appropriate testing tools may be useful. Usually these will be tools developed for load testing
and stress testing that will be relevant.
Where network connections are involved, various network analysis tools can be helpful.
Back to Top
The Systems Integration Test Results template is used to document the actual results from the systems integration test(s). The Systems Integration Test Results are
used in the following ways:
by the project manager to assist in reporting of status
by the lead system developer and/or business flow/application specialist to correct interface defects
Distribute the Systems Integration Test Results as follows:
to the integration team
Back to Top
QUALITY CRITERIA
Has systems integration testing been performed as described in the Testing Strategy (TE.010)?
Has systems integration testing been performed as described in the Systems Integration Test Plan (TE.080) ?
Can the business be confident that testing has reduced the risk of undetected errors to an acceptable level?
Is there evidence of adequate code coverage, such that it is unlikely that serious errors remain undetected?
Back to Top
TE.105 - PREPARE USERS FOR TESTING
In this task, you provide basic training to users participating in acceptance testing. These users may be other users than those that participated in the testing activities
during the Elaboration and Construction phase.
Users that participate earlier should be trained early in the project with the Conduct Project Team Learning Events (TR.050).
Use one of the test environments (for example, System Test Environment) to prepare users for acceptance testing.
ACTIVITY
Back to Top
WORK PRODUCT
Prepared Users for Testing - Prepared Users for Testing have been trained on the new system and are able to perform the acceptance test for their business process
area. They are knowledgeable about the new systems features and are ready to perform the acceptance test (TE.120). This work product should address the following:
the training necessary for users to perform their testing tasks
instructions on when to use online documentation
instructions on how to read a test scenarios and how to perform acceptance testing
Back to Top
TASK STEPS
1 Identify users for the acceptance test. None None
2 Review the Testing Requirements (TE.005)
and Testing Strategy (TE.010) for the
approach, and techniques.
None None
3 Review the Acceptance Test Plan (TE.105). None None
4 Produce and provide users with preparation
material.
Preparation
Material
The Preparation Material is material that the users can read prior to the test instruction class so that they
can prepare any questions. This is typically consist of the following type of information:
Acceptance Testing objectives, and how it relates to other project activities
Orientation Guide (PJM.STM.040)
Relevant sections from the Testing Requirements (TE.005) and the Testing Strategy (TE.010)
Relevant sections from the Acceptance Test Plan (TE.105)
Overview of specific business processes (from RD.011)
Overview of organization changes (from RD.012)
Location/reference to User Reference Manual (DO.060) and User Guide (DO.070) and how these
should be used.
Project decisions. This part provides an overview of important decisions that were made during
the project that impacts the way the application supports their business, and their way of working.
This should include a reason as to why these decisions were made.
5 Prepare test instruction class. Class
Material
The Class Material component is all additional material to the Preparation Material component you will
need to fully prepare the users for the acceptance test. This typically consist of (in addition to the
Preparation Material from the previous step):
Testing Technique presentation, including how to read testing scenarios, how to log defects and
so on.
Application specific features. This are features built in to the application that the users should be
aware of.
Testing example. This is an actual testing example with which you can walk users through all the
steps used in acceptance testing.
#TOP #TOP
Operation procedures. This includes information about who to contact in case of problems.
Support procedures. This include information on who to contact for support.
6 Conduct test instruction class. Prepared
Users
The Prepared Users are the actual users that have followed the test instruction class for acceptance test.
Back to Top
APPROACH
This task should communicate any necessary background information and introduce materials that would be helpful for performing the acceptance testing.
Familiarize users with the project activities so they understand the context of Acceptance Testing.
Discuss the acceptance testing in terms of the following major sections:
acceptance test objectives
main business processes (normal transactions carried across organizational boundaries)
exceptions (like error correction)
volume testing (simulating live operation with multiple users active on the same and conflicting programs)
The objective of this task is to equip users with enough information so they can take a primary role in testing the overall business solution during the acceptance test. This
audience must come away from this task with a clear understanding of:
testing objectives
testing techniques
use of testing tools
system login
steps to perform the tests
navigation through the applications
analysis of results
definition of terms (for example, test cycles, business system)
Formal Test Instruction Class
Discuss the objectives of the test, the test scenarios, and the techniques to validate the business system. Communicate the following testing guidelines:
Test the main scenarios first, i.e., the scenarios that will be the most used.
Validate interim steps as much as possible, for example using reports and inquiries.
Perform new setup entries if applicable (super users only).
Perform reversing transactions (undo).
Perform transactions and record results.
Perform adjustments and modifications that update the transactions or entries.
Perform cancellations (if possible).
Review test analysis techniques (how to interpret the results).
Incorporate real data (current system documents such as purchase orders, and so on) within test scenarios.
Back to Top
Back to Top
Tester Assist the Validation Coordinator in preparing material and the test instruction class. For some projects, this may be a lead
tester.
70
Business Analyst Provide input to preparation material. 30
Validation Coordinator Lead the production of the preparation material, prepares and conduct the test instruction class. *
User Read preparation material and attends test instruction class. *
Business Line Manager Provide input to preparation and class material. *
Ambassador User Provide input to preparation and class material. *
Back to Top
PREREQUISITES
Prerequisite Usage
User Reference Manual (DO.060) Use the User Reference Manual to obtain specific information about the functionality of the application.
User Guide (DO.070) A User Guide is prepared and given to users to help prepare them for acceptance testing.
These prerequisites provide the testing approach and strategy for Testing.
System Test Environment (TE.060.2) Prior to executing the acceptance test, familiarize users with the application using the System Test Environment.
Orientation Guide (PJM.STM.040) Users should review the project orientation guide so that they get familiar with the project prior to acceptance testing.
Business and System Objectives (RD.001) Users should review the Business and System Objectives to understand what is important and what is less important.
Future Process Model (RD.011) Users should review the High-Level Business Process Model to get an understanding of what business processes
are supported by the application system.
(RD.012)
Users should review the Present and Future Organization Structures to get an understanding on how the
organization should be when the application is set into production.
Acceptance Test Plan (TE.082) The Acceptance Test Plan provides input on how the acceptance test is planned.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Prepared Users for Testing are used in the following ways:
The Preparation Material component is used by the users that should take part of acceptance test to better learn how to perform the acceptance test
The Class Material component is used by the class leader to instruct users how to perform acceptance test, and by the users to learn how to perform the
acceptance test
The Prepared Users component are the users that actually perform the acceptance test.
Back to Top
QUALITY CRITERIA
Has preparation material been produced and made generally available so that it can be revisited at any point of time, by anyone who will take part of acceptance
testing?
Has every user that takes part of the acceptance test been properly prepared for this?
Have the objectives of the acceptance test been properly communicated to the acceptance testers?
Have the business and systems objectives been properly communicated to the acceptance testers?
Have important project decisions been communicated to the acceptance testers?
Back to Top
TE.110 - PREPARE ACCEPTANCE TEST ENVIRONMENT
In this task, you prepare the Acceptance Test Environment that is to be used to perform user acceptance testing. The task allows the acceptance test team to perform
acceptance tests on an installation that mirrors the Production Installation and does not hamper the creation of the Production Installation. This ensures that it will not be
hampered with the creation of the Production Installation.
ACTIVITY
Back to Top
WORK PRODUCT
Acceptance Test Environment - The Acceptance Test Environment consists of the final system documentation, acceptance test database, manual data, converted data,
components, and help text.
Back to Top
TASK STEPS
1 Review the Testing Strategy (TE.010) to see what kind of testing
environments should be used, and Acceptance Test Plan
(TE.082) for more detailed requirements for the Acceptance
Test Environment.
None None
2 Determine the exact configurations required for the Acceptance
Test Environment.
Acceptance
Test
Environment
Setup
Report
The Acceptance Test Environment Setup Report documents the exact
configurations that will be/are used for the Acceptance Test Environment.
3 Determine required test data for the user acceptance test. Test Data
Baseline
Manual Data
Load
Scripted
Data Load
Converted
Data Load
Test Data (TE.018) will be used for the user acceptance test.
entered in the Acceptance Test Environment on top of the test data baseline.
the Acceptance Test Environment on top of the test data baseline using scripts.
into the Acceptance Test Environment on top of the test data baseline using
4 Determine required help data for the Acceptance Test
Environment.
Help Text
Data Load
The Help Text Data Load component describes all help text scripts or files must be
included in the Acceptance Test Environment.
5 Determine which components should be included in the user
acceptance test.
Application
Object Load
for
Acceptance
Test
The Application Object Load for Acceptance Test component describes all the
sources that should be contained in the Acceptance Test Environment.
6 Set up physical Acceptance Test Environment. Update of all
components
listed above
The components listed above will be updated along with the physical creation of
the Acceptance Test Environment. The work product as a whole should be seen
as a setup report that reflects how the Acceptance Test Environment actually has
been set up.
7 Quality check Acceptance Test Environment. Update of all
components
listed above
When the Acceptance Test Environment is ready to be used, it must be quality
changes.
Back to Top
APPROACH
The purpose of this task is to install all the necessary components to provide an environment for user acceptance testing. If the Data Acquisition and Conversion and user
acceptance testing tasks need to occur concurrently, then the Acceptance Test Environment and the Production Installation must be different instances. Otherwise, it is
preferred that the Acceptance Test Environment should be the Production Installation. This gives both the development team and the users the confidence that the user
acceptance test represents acceptance of the Production Installation. After the user acceptance test, the Production Installation must be refreshed with production data.
The chosen approach should have been documented in the Testing Strategy (TE.010).
Test data population is included in this task. It is recommended that you use use production installation data, as this is the most accurate. If this is not yet available, you
should use one of the following sources of data:
baseline test data (TE.018)
training database data
data created manually by the users
Back to Top
Back to Top
System Administrator Install and configure hardware and operating system. Install and configure application code. Ensure that login IDs exist
for the user acceptance testers.
45
Database Administrator Install and configure the user acceptance test database. Ensure all user acceptance testers have access to the
database.
45
Tester Ensure facilities, hardware, and software are configured and installed properly. Ensure availability of facilities
coordinator, system administrator, and database administrator. For some projects, this may be a lead tester.
10
IS Operations Staff Provide support for the Acceptance Test Environment. *
IS Support Staff Provide support for the Acceptance Test Environment. *
User Ensure the application functions properly so that user acceptance testing can begin. *
Client Project Manager Ensure availability and commitment of users. Ensure availability of hardware, software and facilities. *
Back to Top
PREREQUISITES
Prerequisite Usage
The Testing Requirements and Testing Strategy are reviewed to determine what kind of requirements there are and what strategy
has been chosen in regards to the Acceptance Test Environment.
Acceptance Test Plan (TE.105) The preparation of the Acceptance Test Environment should occur according to the Acceptance Test Plan.
(IM.040.2)
The Implemented Database provides the data you need to create database objects in the Acceptance Test Environment.
Integrated Services (IM.080) The Integrated System provides the actual components and subsystems that should be tested.
Static Test Data (TE.018.1) Baseline Static Test Data may be used as a starting point to create test data for the user acceptance test.
Installation Plan (TS.030) This plan specifies in detail everything that needs to be done to create any installation.
Back to Top
TEMPLATES AND TOOLS
TE-110_ACCEPTANCE_TEST_ENVIRONMENT.DOC MS WORD
Back to Top
The Acceptance Test Environment is used in the following ways:
Operations uses to standardize requests for access to databases or networks.
The lead tester uses the set up reports as tangible evidence that the test environment is ready.
Testers use the set up reports to determine that the Acceptance Test Environment is ready to use for user acceptance testing.
The project manager uses to decide whether the system is ready for user acceptance testing by end users.
Back to Top
QUALITY CRITERIA
Have all application components been correctly installed in the Acceptance Test Environment?
Has the Acceptance Test Environment been quality checked?
Back to Top
TE.120 - SUPPORT ACCEPTANCE TEST
In this task, you support the users in performing the user acceptance test.
Perform the user acceptance test as specified in the Acceptance Test Plan. The Prepared Users for Testing (TE.105) perform the user acceptance test. You should
support the users in performing the acceptance test as much as possible to prevent holdups and explain areas that are unclear or misunderstood.
The user acceptance test may include any aspect of the system from business scenarios to individual screens to recovery and fallback procedures. This also involves
scheduling the acceptance test team, support staff and user facilities.
As a minimum, users should validate the solution against the critical business requirements to confirm that the system is ready to go into production. For example, these
requirements could be the Must Have items identified on the MoSCoW List.
ACTIVITY
Back to Top
WORK PRODUCT
Acceptance Test Results - The Acceptance Test Results includes both detailed and summary results from the user acceptance test. Detailed results are logged for each
step of the test scenarios. Defects are logged for each step where there was a discrepancy between the actual and expected step results. Summary results use detailed
test results to produce summaries by test type.
Back to Top
TASK STEPS
1 Review the Acceptance Test Plan
(TE.082) to see how the
acceptance test is planned.
None None
2 Detail the scenarios for the user
acceptance test.
Acceptance
Test Scenarios
The Acceptance Test Scenarios include step-by-step descriptions on how the scenarios should be tested.
3 Perform user acceptance test. Acceptance
Test Detail
Defects
The Acceptance Test Detail describes per Acceptance Test Scenario whether it has failed or passed (or
skipped).
The Defects are actual errors that have been discovered during the user acceptance test. These should
preferably be logged in a defect tracker tool.
4 Conclude the user acceptance test. Acceptance
Test Summary
by Test Type
Acceptance
Test Summary
by Iteration
The Acceptance Test Summary by Test Type summarizes how many test have passed, failed and have been
skipped. It also summarizes how many tests have been completed, how many should have been completed,
and the completion and passed percentage.
The Acceptance Test Summary by Iteration provides a similar summary as above, but this time organized as
a summary for each user acceptance test iteration (if it is performed through multiple iterations).
Back to Top
APPROACH
The user acceptance test is intended to verify that all of the required functionality is in the new application system. This verification was already performed by the project
team, but is a basic requirement for the user to accept the new system.
Staffing for Testing
The system administrators provide support for the Acceptance Test Environment while the users perform the tests. The staff who use the system most heavily should
participate in the user acceptance test because they gain better familiarity with the new system and they better understand the functionality that is being tested. The user
acceptance test team members must be dedicated to the testing, not split between testing and other work. Component designers from the project team should be on
hand to resolve technical and functional issues and questions but not to participate directly in the user acceptance test.
Acceptance Test Scenarios
Each Acceptance Test Scenario that has been listed in the Acceptance Test Plan should be detailed. You should be able to reuse many testing scenarios from earlier
tests, otherwise you might be able to use case scenarios from the Use Case Model (RA.024) as a starting point. Keep in mind that many use case scenarios may have
many common aspects that easily could be covered by a single Acceptance Test Scenario. These use cases typically are implemented by the same components, or set
of components. Do not produce an unnecessary amount of Acceptance Test Scenarios when one Acceptance Test Scenario is sufficient.
Keep in mind that at a minimum all the Must Have and Should Have requirements must be validated. For each requirement, indicate within its associated scenario, the
MoSCoW priority. This should help the user acceptance tester to determine which scenarios to test first.
result.
Using Acceptance Criteria
User acceptance testing consists of performing the tests and verifying the results against the acceptance criteria. The user acceptance test may cover any aspect of the
new system, including administrative procedures such as backup and recovery. All QA testing and validation should have already been performed. The user acceptance
test is a verification. It is not an opportunity for the users to indicate what they might like the system to do.
The tests are successful if they meet the acceptance criteria. The results of all tests are recorded and reviewed as part of the user acceptance testing process. Logging of
all tests allows management to assess the completeness of the user acceptance test as well as the results.
Resolving Issues
Preferably, a central help desk should be set up to provide support for the testers and review any issues raised during testing. The help desk is staffed by transition team
members. The transition team should verify problems before they are accepted as problems. Log and handle verified problems according to the established procedures.
Establishing a Testing Facility
The test should be conducted in a facility that is separate from the users normal work area so that daily work does not interfere with the test. Having everyone in an
isolated facility also allows for easier communication of problems and their resolutions.
Scheduling Testing
A successful user acceptance test requires the commitment of the business management to dedicate the resources for conducting the test. Schedule around the
business critical business hours and schedule the test far in advance so that the users can make adjustments to cover the testers normal work duties.
Back to Top
Back to Top
Developer Provide support for user acceptance tests by answering questions and helping resolve potential issues. Represent the project
team. Conduct user acceptance tests and log results.
10
System Administrator Support user acceptance tests. 20
Tester Ensure facilities, hardware, and software are configured and installed properly. Ensure availability of facilities. Review and
resolve any issues that arise. For some projects, this may be a lead tester.
20
System Analyst Support user acceptance testing by providing assistance about business requirements. 20
System Architect Support user acceptance testing by providing assistance about system architecture. 20
System Architect
Support user acceptance testing by providing assistance about Information Architecture. Preferably, this should be done by a
system architect that specializes in Information Architecture.
10
IS Support Staff Provide support for the user acceptance tests. *
Client Project Manager Ensure availability and commitment of users. Ensure availability of hardware, software and facilities. Develop sense of
teamwork and ownership of the new application. Review and resolve any issues that arise.
*
Validation Coordinator Lead and coordinate the user acceptance test from the client side. *
User Conduct user acceptance tests and log results. *
Back to Top
PREREQUISITES
Prerequisite Usage
(PJM.QM.010)
Testing Requirements (TE.005.2)
The Quality Management Plan provides the approach to performing QA functions during the project. The Testing Requirements
contains sign-off requirements for user acceptance testing are defined. Together they provide:
user acceptance approach and criteria - an overall approach to performing the user acceptance test
user acceptance procedure - an outline of how to handle acceptance on the project
Acceptance Test Plan (TE.082) The Acceptance Test Plan describes the plan for user acceptance testing, including which scenarios should be used in what order.
Prepared Users for Testing
(TE.105)
The Prepared Users for Testing are the actual users that should perform the user acceptance test.
Acceptance Test Environment
(TE.110)
This work product represents that the system is ready for the testers to begin the user acceptance test. This includes hardware,
software, test data, setups and documentation.
In a BI Custom implementation, this also includes final data validation and data access results.
MoSCoW List (RD.045) The MoSCoW List is a help to determine the most critical business elements that should be included in the user acceptance test
Back to Top
TEMPLATES AND TOOLS
TE-120_ACCEPTANCE_TEST_RESULTS.DOC MS WORD
Back to Top
The Acceptance Test Results is used in the following ways:
The lead tester and validation coordinator uses the Acceptance Test Summary to report status, and determine the rate of testing.
The lead tester, quality manager, and project manager use the Acceptance Test Summary by Test Type to measure quality problems specific to a type of test, and
re-deploy effort as necessary.
Testers use the Acceptance Test Detail to document their testing results and progress.
The project management team uses the Reported Defects to prioritize and schedule fixes.
The project leader uses the Signoff form to get system acceptance from the project sponsor.
Distribute the Acceptance Test Results as follows:
to the quality manager for judging the quality of the application system, procedures, and documentation
to the client project manager to accept the components and agree on scope, detail, and quality of the user acceptance test
Back to Top
QUALITY CRITERIA
Are the Acceptance Test Results within the requirements of the acceptance test scenarios?
Have all of the acceptance test types and scenarios been tested and included in the results?
Have all Must Have and Should Have requirements been met by the solution and validated by the user tester?
Back to Top
[PT] PERFORMANCE MANAGEMENT
project implementation lifecycle in order to validate that the performance of the system or system components is aligned with the user's requirements and expectations
when the system is implemented. Performance Management is not limited to conducting a performance test or an isolated tuning exercise, although both those activities
may be part of the overall Performance Management strategy.
It should be noted that where Performance Management process is going to be performed in a holistic manner (majority of tasks within process), a separate performance
management project is typically performed versus attempting to perform all the tasks within the same project where component design, test, and build is occurring.
To succeed, Performance Management must be oriented around the user view of performance. Traditional approaches to Performance Management use a top-down
approach that evaluates overall system health and then drills down into any issues apparent at a system level. DBAs and Performance tuners evaluate the wide variety
of system statistics and try to find evidence of problems that should be remediated. In some cases where there is a system wide constraint, this approach can succeed,
but if the performance "problem" is related to a failure of a particular transaction to meet its performance objective, considerable time can be spent without effectively
addressing the actual problem the users are experiencing. When the problem is poor performance with important business transactions but a top-down approach is used,
time may be spent on unrelated transactions or system wide configuration, resulting in no discernible improvement from a user perspective. Effective performance
management must begin with identifying the key business transactions and associated performance expectations and requirements early in the Inception and Elaboration
phases and implementing the appropriate standards, controls, monitoring checkpoints, testing and metrics to ensure that transactions meet the performance expectations
as the project progresses through elaboration, construction, transition and production. Field experience has repeatedly shown that attempting to manage performance
from a system perspective without a clear view of the user expectations does not produce the desired result.
Failure to begin the Performance Management process in the project's early phases or to identify the key business transactions and their performance requirements can
lead to a significant amount of reactive, unplanned work in the later phases of Construction, Transition or after Production. In some cases, this approach has led to a lack
of user acceptance and in the worst cases, project cancellation. Time spent developing a Performance Management strategy and establishing the appropriate controls
and checkpoints to validate that performance has been sufficiently considered during the design, build and implementation will save valuable time spent in reactive
tuning at the end of the project while raising user satisfaction. The Performance Management process should not end with the production implementation, but should
continue after the system is implemented to monitor performance of the implemented system and to provide the appropriate corrective actions in the event performance
begins to degrade.
If the project scope includes formal performance testing, the performance test objectives, scope and strategy will be defined in the Performance Testing Strategy
(PT.030). Performance Testing uses a top down approach, and it can be used to either validate a model of the entire solution or focus on a particular component of a
solution. Performance testing can establish the expected the solution or component under test and can be used to validate that the production performance will
acceptable for the business or if changes are required to meet the performance objectives. Performance Testing should represent the final validation, not the first
evaluation of performance. If Performance Testing is the only Performance Management technique used, there is considerable risk that:
Significant code rework may be identified.
Issues identified cannot be resolved without impacting the project timelines.
Performance issues may still occur in Production that were not identified during the testing process.
The requirements that drive Performance Management also impact Technical Architecture (TA) and the two processes are closely related.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Depending on your project (e.g., large, complex, etc.), the project manager may designate a Performance Management team leader. In some projects the performance
management effort is a "sub-project" to the overall software implementation effort. If the project manager designates a Performance Management team leader, they are
responsible for leading the Performance Management process and reviewing the work products. The team leader plans, directs, and monitors the day-to-day work of the
team. The team leader assigns work packages to the team members and makes sure they understand the requirements. The team leader is responsible for building team
cohesion, motivating the teams, and providing assistance and encouragement to the team members. Each team leader performs the final quality control and quality
assurance for the team by reviewing all work products. The team leader also signs off on team work completion and quality. Work that is not up to quality standards is
returned. Team leaders review work products from other teams when these work products may impact aspects of the system. The team leader reports the team's
progress to the project manager. Refer to Project Management in OUM for additional information on team leaders.
The Conduct Performance Management Workshop (PT.010) task is the first step in the Performance Management process. The Performance Management Workshop
familiarizes the client with the concepts of proactive Performance Management, the need to define performance requirements for business critical transactions,
establishment of metrics and monitoring related to performance management, Service-Level Agreements (SLA) and the appropriate use of Performance Testing. The
workshop also provides a mechanism to gather information on performance needs and expectations that should be used to develop the Performance Management
Requirements and Strategy (PT.020 ).
In projects that delegate the bulk of responsibility for Performance Management and Performance Testing to the client, a Performance Management workshop must be
conducted to make the client aware of the expectations and requirements associated with their responsibility as well as to share best practice approaches and
experiences of other clients.
After the Performance Management Workshop, the Performance Management process continues with the definition of the Performance Management Requirements and
Strategy (PT.020 ). The PT.020 documents the business critical transactions and their performance requirements, what metrics will be established and reported, what
monitoring or instrumentation will be implemented and what control processes will be put in place. If the project will conduct formal performance testing, a Performance
Testing Strategy (PT.030) should be created which defines the scope and objectives of Performance Testing for the project and outlines the strategy that will be used to
execute the Performance Test. The specific transaction scenarios and models are defined in the Performance Test Transaction Models and Scenarios (PT.040), design
of test scripts and programs is documented in the Performance Test Scripts and Programs Design (PT.050), and any test data or load programs required are
documented in the Performance Test Data and Load Programs Design (PT.060).
The Performance Management team defines the scope of testing and relates it to point-in-time snapshots of the transactions expected in the real production system.
Technical analysts create or set up transaction programs to simulate system processing within the scope of the test and populate a volume test database against which
to execute the transactions. Once the system and database administrators have created the test environment, the project team executes the test and the final results are
documented.
The general requirements for Performance Management are similar for all projects, although the details may vary considerably. Performance requirements should be
tied to the user's expectations and the most important transactions should receive priority. Most projects have a subset of business transactions that are considered
more critical than others, either because they have high execution rates, or because there is an impact to business processing if the transactions fail to complete within a
particular window of time.
A project implementing an application suite with limited customization or extensions, may require a fairly simple performance management strategy that identifies and
prioritizes the business critical transactions, establishes the techniques and metrics that will be used to monitoring actual performance and defines the process to identify,
track and resolve problems. On the opposite end of the spectrum, a new software engineering effort will require the above activities and should implement additional
measures such as code reviews for performance, proactive scanning for sub optimal components, detailed performance testing of individual components and automated
performance testing in order to validate that the solution meets the performance objectives. In many cases the system and database level statistics may not provide a
complete view of performance at a user transaction level. Instrumentation at the technical level or at the application level may be necessary to collect the appropriate
information and allow meaningful reporting of performance metrics.
Performance Management in Production
The need for Performance Management does not end after the project has implemented. Metrics and monitoring established to measure system performance are critical
post implementation processes in order to validate that system performance remains within acceptable parameters. Changes to workload, user volumes or other factors
can introduce performance issues. Failure to proactively monitor and measure production performance may lead to situations where although performance is degrading
over time, nothing is noticed until there is a highly visible production "crisis". Clients who invest in automated testing tools may be able to take advantage of that
investment to validate changes planned in the production environment.
Back to Top
TOOLS
Tool Guidance Application/Note
Oracle
Application
Test Suite
(OATS)
Testing and
Quality
Management
Tools
This process has supplemental guidance for using using Oracle Application
Test Suite (OATS) Testing and Quality Management Tools. Use the following
to access the process-specific supplemental guidance. To access all Oracle
Application Test Suite (OATS) Testing and Quality Management Tools
supplemental information, use the OUM Testing and Quality Management
Tools Supplemental Guide.
Oracle Application Test Suite (OATS) Testing and Quality
Management Tools is a complementary Oracle suite of tools that is
used to manage software testing for a project as well as to develop
test automation and performance testing, when used together these
tools can be used to maximize system performance and ensure the
quality and success of a project.
Back to Top
Inception Phase
PT.010 Conduct Performance Management Workshop Performance Management Workshop Results
Elaboration Phase
PT.020 Define Performance Management Requirements and Strategy Performance Management Requirements and Strategy
PT.030 Define Performance Testing Strategy Performance Testing Strategy
PT.040 Identify Performance Testing Models and Scenarios Performance Testing Models and Scenarios
PT.050 Design Performance Test Scripts and Programs Performance Test Scripts and Programs Design
PT.060 Design Performance Test Data and Load Programs Performance Test Data and Load Programs Design
Construction Phase
PT.070 Build Performance Test Scripts and Programs Performance Test Scripts and Programs
PT.080 Construct Performance Test Environment and Database Performance Test Environment and Database
PT.090 Conduct Performance Test Dress Rehearsal Validated Performance Test Environment and Environment
Transition Phase
PT.100 Execute Performance Test Performance Test Results
PT.110 Create Performance Test Report Performance Test Report
Production Phase
PT.120 Conduct Production Performance Management Managed Production Environment
Back to Top
OBJECTIVES
The objectives of Performance Management are:
Identify the set of critical business transactions and document their performance requirements.
Identify and document any system wide or overall performance expectations or Service-Level Agreements.
Determine scope, objectives and strategy of the Performance Testing effort and describe the process to interpret test results.
Identify specific performance metrics and the methods to monitor, collect and report them.
Establish specific quality controls relating to performance.
Establish processes and procedures to identify, track and resolve performance problems.
increase user satisfaction and system acceptance by minimizing performance related issues.
Reduce effort required for reactive performance remediation.
Define a method to evaluate the performance impact of a change to software or hardware.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
BA Business Analyst Assist in identification of key business transactions and performance expectations.
DBA Database
Administrator
Participate in the preparation of the Information Architecture for the environment to support performance testing. Provide support for the
execution of the performance testing dress rehearsal. Provide support for the data base environment used in Performance Testing. Monitor
database and application, resolve performance issues, report DB and application metrics.
DV Developer Participate in the process of performance requirement analysis. Define specific performance requirements for the application.
NE Network Engineer Monitor network activity during the test.
SAD System
Administrator
Install application software. Provide support for the performance testing. Provide support for Performance Management activities such as
running standard application reports on transaction performance, applying and testing patches and upgrades.
SAN System Analyst Provide input on projected volumes and scenarios, review and approve the development of the Performance Testing Models and Scenarios.
Provide support for the test scenarios used in Performance Testing.
SA System Architect Conduct the interviews, prepare workshop presentation and recommendations, facilitate workshop session. You may wish to include an
additional System Architect that specializes in system integration to participate in the process of performance requirement analysis.
Familiarize the client with the goals and objectives of the workshop, assist in gathering performance requirements. Provide information on
technical architecture design and performance implications. Develop the Performance Management Requirements and Strategy. Develop
Performance Testing Strategy. Develop the Performance Testing Models and Scenarios. Oversee, review and approve the design of of the
Performance Test Scripts and Programs. Design test components with regard to the technical architecture of the application. Review and
approve the Performance Test Data and Load Programs Design. Oversee, review and approve the Performance Test Transaction Programs.
Code the most complex components. Participate in the preparation of the technical architecture environment to support performance testing.
Review and approve the Performance Test Environment and Database. Supervise and oversee the Performance Test Dress Rehearsal.
Oversee the execution of the performance test. Assist tester in the execution of the performance test by addressing issues and question
related to the technical architecture. Review and approve Performance Testing Results.
SA
(IA)
System Architect
(Information
Architect)
Assist test team in designing test components with regard to the data architecture of the application. Preferably, this should be done by a
TE Tester Design the Performance Test Scripts and Programs. Design the performance test data and load programs. Create Performance Test
Transaction Programs. Executes performance test. Execute the performance test. Compile test results and prepare report.
Client (User)
KEY Ambassador User Identify key business transactions and performance expectations. Defines business performance objectives and requirements. Review and
approve the Performance Testing Strategy. Assist test team with identification of test data requirements.
CDA Client Data
Administrator
Identify existing performance management process, procedures, standards, SLAs. Participate in the process of requirement analysis.
CPM Client Project
Manager
Coordinate the interview schedule for the workshop, assist in gathering performance requirements.
CSM Client Staff
Member
Participate in the process of performance requirement analysis.
OS IS Operations Staff Identify existing Performance Management process, procedures, standards, SLAs. Participate in the process of performance requirement
analysis. Set up hardware and system software configuration. Set up hardware and system software configuration. Monitor hardware and
system software configuration, resolve performance issues, report system metrics.
SS IS Support Staff Participate in the process of performance requirement analysis. Provide support for the creation of the Performance Testing environment.
Provide support for the creation of the Performance Testing Environment. Log performance issues, track resolution and notify users.
Back to Top
An understanding that system performance is measured from the user perspective, regardless of what operating or system statistics show
User participation in identification of the critical transaction set and the associated performance requirements
Proactive establishment of standards, code reviews and other processes so that performance issues can be found quickly and resolved promptly
Establishment of appropriate metrics so that performance can be evaluated and reported in a way meaningful to the system users in addition to the technical
system administrators
Implementation of automated monitoring
Establishment of the appropriate process to identify, track and resolve performance issues that do arise. Resolving a performance issue may involve parties that
work in a variety of organizations (users, DBA staff, Unix administrators, network administrators, developers, vendors). Establishment of a Performance
Management "owner" who has the responsibility to manage this virtual team will greatly increase the success of a performance management effort.
Back to Top
PT.010 - CONDUCT PERFORMANCE MANAGEMENT
WORKSHOP
The Performance Management Workshop is the initial task in the Performance Management process. The Performance Management Workshop familiarizes the client
with the concepts of proactive Performance Management, the need to define performance requirements for business critical transactions, establishment of metrics and
monitoring related to Performance Management, Service-Level Agreements (SLA) and the appropriate use of Performance Testing. The workshop also provides a
mechanism to gather information on performance needs and expectations that should be used to develop the Performance Management Requirements and Strategy
(PT.020).
The Performance Management Workshop is a core activity and is particularly important for projects that have contractually delegated the bulk of responsibility for
Performance Management and Performance Testing to the client or third-party provider. If that is the case, the workshop should be conducted as early in the project
lifecycle as possible to make the client aware of the expectations and requirements associated with their responsibility as well as to share best practice approaches and
experiences of other clients.
If Performance Testing is planned or specified in the contract, the workshop should discuss the various options, objectives and approach. This Information will be an
input to the Performance Testing Strategy (PT.030).
For projects that involve the upgrade of Oracle products, this task includes the identification of any new risks to the performance of the information systems as a result of
the upgrade, and defines appropriate risk mitigation strategies.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Management Workshop Results
Back to Top
TASK STEPS
1 Schedule
workshop and
identify
participants.
Workshop
Schedule,
Participant List
The project manager should familiarize the client with the objectives of the workshop and identify the participants. It is
critical the key functional users participate in the interview cycle and that the workshop is not a purely "technical" exercise.
Participants should include IT leadership, key functional users or sponsors, representatives from operations, network,
technical architects, help desk, DBA staff, change management and development staff.
2 Conduct
interviews.
Interview Form Conduct interviews with all participants.
3 Gather Findings
and Develop
Recommendations.
Recommendations Address the specific expectations and requirements that were identified in the workshop interviews with recommendations
that are aligned with best practice.
4 Prepare Workshop
Presentation.
Workshop
Presentation
Workshop lead prepares a presentation to communication the findings and recommendations to workshop participants as a
group.
5 Conduct
Workshop.
Performance
Management
Workshop
Results
Workshop lead presents the findings and recommendations to workshop participants as a group. Conversation should be
structured as interactive with opportunity for discussion.
Back to Top
APPROACH
Performance Management Workshop Objectives
#TOP #TOP
The objective of the Performance Management Workshop is to familiarize the client with the concepts of proactive Performance Management, the need to define
performance requirements for business critical transactions, establishment of metrics and monitoring related to performance management, Service-Level Agreements
(SLA) and the appropriate use of Performance Testing and to gather information on performance needs and expectations that should be used to develop the
Performance Management Requirements and Strategy.
The workshop leader and the project manager should meet with the client project manager and explain the purpose and the approach for the workshop. The client project
manager should schedule the interviews and arrange for the appropriate parties on the client staff to participate. Providing sample interview questions can be helpful in
identifying which persons from the client organization should be invited to participate. Interviews should be scheduled with representatives from both the functional teams
and the technical teams and every effort should be made to complete the interview process in a 2-3 day window. Effective Performance Management depends on
developing an understanding of key transactions and performance expectations from the perspective of the business, so participation of key ambassador users is a
critical success factor. Representatives of the client's technical staff are also important, as they can provide the details on processes and procedures already in place that
impact Performance Management, such as monitoring, problem identification, existing SLAs, etc.
The workshop is conducted by the workshop leader. Interviews should begin with the client project sponsor to gain an understanding of the business objectives and
continue with the remainder of the interviewees. Ideally, interviews should be individual to allow a complete view of performance requirements across as broad a
spectrum as possible, but small groups can be schedule if time is a constraint. After the interviews are completed, the workshop leader will review the findings and
prepare a final presentation highlighting the key findings and recommendations. The results should be presented back to the workshop participants in an interactive
session allowing sufficient time for questions and answers.
Identification of "Key Transactions"
In some cases, client users may not be able to easily present a list of key business transactions or articulate their detailed performance requirements initially. The
workshop leader should guide this process by focusing on the business transactions that are mostly closely related to the business objectives of the system being
implemented. Key business transactions are typically ones that fall into one of the following categories:
transactions that are part of a business critical process, such as the month end close or the payroll run
transactions that run for a long time and delay a downstream process. A long running transaction that does not impact a downstream process may not be a
candidate for performance management, but rather one that is a candidate for off hours scheduling
transactions that are run most frequently
transactions that consume significant amount of system resources
transactions that have a timed based dependency on an external system or an existing legacy system - This type of requirement should be explored to validate that
it represents a legitimate business need and is not a holdover from legacy practice due to restrictions on the old system.
It is often sufficient to define the performance expectations somewhat generally. Examples include:
online transactions should complete within 3-5 seconds
the nightly batch process should finish within an "X" hour window
a particular business process, such as booking an order, should complete within "X" minutes
the system should be able to process "X" invoices per hour
Not all performance requirements have to be defined in exacting detail, but the intent is to translate the implicit expectation (which always exists) to an explicit one,
information that should be used in the the design and development process.
Back to Top
Back to Top
System Architect Conduct the interviews, prepare workshop presentation and recommendations, facilitate workshop session. You may wish to
include an additional System Architect that specializes in system integration to participate in the process of performance
requirement analysis. Familiarize the client with the goals and objectives of the workshop, assist in gathering performance
requirements.
If a Performance Management team leader has been designated, 15% of this time would be allocated to this individual, leaving
75% allocated to the system architect. The team leader would then familiarize the client with the goals and objectives of the
workshop, assist in gathering performance requirements.
90
Business Analyst Assist in identification of key business transactions and performance expectations. 5
Developer Participate in the process of performance requirement analysis. 5
Ambassador User Identify key business transactions and performance expectations. *
Client Project Manager Coordinate the interview schedule for the workshop, assist in gathering performance requirements. *
Client Data Administrator Identify existing performance management process, procedures, standards, SLAs. Participate in the process of requirement
analysis.
*
Client Staff Member Participate in the process of performance requirement analysis. *
IS Operations Staff Identify existing Performance Management process, procedures, standards, SLAs. Participate in the process of performance
requirement analysis.
*
IS Support Staff Participate in the process of performance requirement analysis. *
The following additional roles may participate in this task:
Database Administrator (DBA) - Participate in the process of performance requirement analysis.
Database Designer (DD) - Participate in the process of performance requirement analysis.
Quality Manager (QM) - Participate in the process of performance requirement analysis.
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.ER.100)
(ENV.EA.110)
Future State Transition Plan (ENV.ER.170)
Use these Envision work products or similar enterprise-level documents, if available. You may need this information
before you can begin this task. Therefore, if they are not available, you should obtain this information prior to beginning
this task.
Project Management Plan (PJM) The Project Management Plan should contain the high level scope and requirements that will drive the Performance
Management process. The business requirements and objectives of the project should be defined, and the roles and
responsibilities of those participating in the Performance Management process should be identified.
(RD.034)
The Performance Management Workshop (PT.010) includes an identification of current business levels of volume, driven
by current process steps. As you define the future business processes, you translate current volumes into projected
future levels, which you then use to estimate information storage needs.
Supplemental Requirements (RD.055) The Supplemental Requirements contains additional requirements that may impact performance.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
PT.020 - DEFINE PERFORMANCE MANAGEMENT
REQUIREMENTS AND STRATEGY
Effective Performance Management requires a holistic view over the life of the project. Management of performance should not be limited to reactive tuning exercises or
isolated to Performance Testing. Performance Management should begin as soon as requirements are identified, continue through development and testing and
continue after production implementation has occurred.
This task defines and documents the Performance Management Requirements and Strategy that will be used on the project. The Performance Management
Requirements and Strategy should document:
project organization, roles and responsibilities related to Performance Management
business critical transactions and their associated performance expectations
any Service Level Agreements (SLAs) established
any software tools that will be used to monitor environments, evaluate code, diagnose and resolve performance issues and track problems
processes to identify, track and resolve performance issues
type of Performance Testing that will be conducted
metrics that will be used to track the effectiveness of the Performance Management process
dependencies and interaction with other project activities, particularly development and conversion activities
ACTIVITY
Back to Top
WORK PRODUCT
Performance Management Requirements and Strategy
Back to Top
TASK STEPS
1 Review the output of the
Project Management
Workshop (PT.010).
None None
2 Review related project
documentation which
may discuss
performance
management issues or
requirements.
Summarized
List of
Performance
Requirements
There are a variety of project documents that may identify or address performance requirements either implicitly or
explicitly including:
Project Management Plan (PJM)
Use Case Specification (RA.024)
Supplemental Requirements (Non-Functional) (RD.055)
Architecture Requirements and Strategy (TA.020)
Reporting and Information Access Strategy (TA.040)
An informal summarized list should be created, to validate inclusion in the Performance Management Strategy.
3 Define the context for
Performance
Management
Requirements and
Strategy.
Introduction The Introduction details the purpose of the work product, provides background information on the project, and includes
references to related documents.
4 Define the Performance
Management Scope
Scope The Scope describes the scope of Performance Management for the project in as much detail as possible. Scope
statements should address both solution elements in and out of scope for the project. Examples of elements that can
define the scope include:
Establishment of the Performance Management Virtual Team
#TOP #TOP
Roles and Responsibilities of the Performance Management Team
Business Critical Transactions and response time requirements, throughput requirements or established SLAs
Known or Anticipated Performance Risks
Scope of Performance Testing
Performance Management relating to Business Processes and Applications out of scope for the Performance Test
Technical Architecture Implications
Interfaces, Data Acquisition and Conversion, Reporting and Databases
Performance Management Monitoring and Metrics
Performance Management Issue Tracking and Problem Resolution Process
Capacity Planning
5 Define the Performance
Management
Objectives.
Objectives The Objectives describes the rationale for Performance Management and the goals of the process.
6 Identify Performance
Management Approach
and critical success
factors.
Approach The Approach describes the process, policies and procedures, project dependencies, and the technical requirements
related to Performance Management. The approach should include a high level discussion of the tasks and work
products. If there is specific terminology associated with the process or selected tools, a glossary of terms related to
Performance Management (PT) should also be included. The subproject policies and procedures should be related to the
corresponding policies and procedures adopted for the main project. If the subproject will use different polices,
procedures or standards from the main project in any key control and reporting areas, the work product should document
the differences in detail, explaining why they differ. Examples of areas where the subproject will typically inherit standards
and procedures from the main project are listed below:
Issue Management and Resolution
Change Management
Reporting Format
Reporting Relationship to the Main Project
Acceptance
Project Policies and Procedures
Subproject Team Meetings
Logistics and Administrative Support
The project dependencies section of the component should describe the dependencies between Performance
Management and other processes or subprojects taking place within the overall implementation project. The technical
background should describe the technical circumstances affecting the approach to the project. Examples of the points
that may be included are:
Implementation sites
Technical Architecture Direction
Computing Platforms and Technical Infrastructure
Major System or Application Requirements
Innovative or Unusual Technical Requirements
The Approach should also include a description of the key process milestones, the constraints that this process will be
subject to and any assumptions made, the risks inherent in Performance Management, and the relationship of the
process to other systems projects and initiatives already underway.
7 Identify the mechanisms
used for executing
Performance
Management. .
Performance
Management
Strategy
The Performance Management Strategy describes the strategy for Performance Management, including the methods
used to collect user performance requirements, ensure performance requirements are considered and documented
during design, review of code for compliance with performance standards, monitoring and early identification of potential
performance problems in development and test environments, and the process to track and resolve performance defects
and any specific techniques that will be used to management performance of key transactions that are not included in the
performance testing scope.
8 Document the test
technical architecture
implications.
Technical
Architecture
Performance Management is closely related to the Technical Architecture process and performance requirements may
have a direct implication on the Technical Architecture designed and implemented.
9 Describe the resource
requirements needed to
support the
Performance
Management process
and document how the
virtual Performance
Management team will
be organized.
Resource
Requirements
The Resource Requirements component describes the specific resources needed for Performance Management. A
virtual team should be established which may require effort from resources primarily associated with:
Functional Team Leads and Ambassador Users
Development
Conversion, Integration and Reporting
Systems Operation and Network
Database Design and Administration
Help Desk
Business System Testing
10 Document specific tool
testing process.
Tool
Requirements
The Tool Requirements component describes the specific tool requirements identified for monitoring, tracking and
reporting on the Performance Management process. Include the tools relevant to each of following areas:
Application Development Tools
Automated Performance Testing
Problem Tracking and/or Trouble Ticket Tools
Performance Monitoring and Other System Management Tools
11 Identify risks in the
strategy.
Risks The Risks component describes the risks in the Performance Management Strategy. Examples of risks areas are:
lack of a centralized Performance Management team or Performance Management owner
lack of availability of expert resources
lack of an automated monitoring tools to collect and report performance measurements needed to meet the scope
and objectives of the project
lack of performance coding standards or an effective quality assurance process for custom code
Inappropriate performance expectations
12 Review the work product
with project and IS
managers. Secure
acceptance for the
Performance
Management and
Requirements Strategy.
None None
Back to Top
APPROACH
Effective Performance Management requires a holistic approach that begins in inception and continues not only through the project implementation but after the
application goes live. Performance Management must be oriented around the user view of performance to succeed. Traditional approaches to Performance
Management use a top-down approach that evaluates overall system health and then drills down into any issues apparent at a system level. DBAs and performance
tuners evaluate the wide variety of system statistics and try to find evidence of problems that should be remedied. In some cases where there is a system wide
constraint, this approach can succeed, but if the performance "problem" is related to a failure of a particular transaction to meet it's performance objective, considerable
time can be spent without effectively addressing the actual problem the users are experiencing. When the problem is actually poor performance of one important
business transaction, a top down approach can result in time and effort spent on unrelated transactions or system wide configuration, with the result that users receive no
discernible improvement from their perspective. Effective Performance Management must begin with identifying the key business transactions and associated
performance expectations and requirements early in the Inception and Elaboration phases and implementing the appropriate standards, controls, monitoring checkpoints,
testing and metrics to ensure that transactions meet the performance expectations as the project progresses through Elaboration, Construction, Transition and
Production. Field experience has repeatedly shown that attempting to manage performance from a system perspective without a clear view of the user expectations risks
failure to produce the desired result.
The Performance Management process should not end with the production implementation, but should continue after the system is implemented to monitor performance
of the implemented system and to provide the appropriate corrective actions in the event performance begins to degrade.
This task documents the Performance Management Requirements and Strategy. It establishes the organizational responsibilities for Performance Management within the
project and documents the strategies, processes, procedures and policies for Performance Management. The information needed to prepare the strategy and document
the requirements should be initially developed during the Performance Management Workshop (PT.010) and supplemented by existing business information systems
strategy or documents, or discussions with senior project and IS organization management. Once you define and document the Performance Management Requirements
and Strategy, it should be reviewed and accepted by management before progressing with the remainder of the tasks in this process.
One of the key issues related to Performance Management is the large number of organizational areas that can be involvement in "performance". A performance problem
in a complex system may be related to one or more of the following:
Poor Technical Design
Poorly optimized code
System Level Constraints such as CPU, memory, IO subsystem performance
Database configuration
Network Issues
Application configuration
Bugs or Defects in vendor code
User Training Issues
Lack of appropriate capacity planning
Failure to implement appropriate patches or required maintenance procedures such as transactional table purges
In most projects, ownership of these areas is spread across a number of teams and a organizational areas. This can create difficulty when addressing Performance
Management issues, as there is no single party responsible for tracking and resolving any particular issue as it moves among the various parties that may be involved in
detection and resolution. The Performance Management process requires the establishment of a Performance Management virtual team, with one owner assigned that
has the overall responsibility to work with the various project and organizational teams to implement, track and control Performance Management. Depending on the
client structure and maturity, the role of Performance Management lead may initially come from within the project team, but it must eventually transition to a client or client
representative in preparation for the transition of the application into production.
Performance Management Objective
The objective of Performance Management is to create the processes, procedures, controls and organizational structure to implement proactive performance
management techniques and to minimize the amount of unplanned, reactive performance remediation work that is identified in the later stages of the project. It is
important to note that Performance Management may not fully eliminate performance remediation efforts but it should provide the structure, process and procedures to
quickly identify, track and resolve issues that are identified.
User Orientation
The Performance Management process should be oriented around the user view of performance. System level performance factors relating to technical architecture,
database and application configuration and other factors cannot be ignored, but performance of the business critical transactions is key to establishing a well performing
system from a user perspective. The transactions that are considered business critical are the ones that should receive priority throughout the implementation. Functional
and technical designs should be evaluated for performance implications and risks, any code developed should be reviewed for potential optimization, response times in
development and testing should be evaluated, and as many as possible should be included in formal performance testing. Although specific numbers vary, it is
commonly believed that the majority of performance problems are directly related to application code as opposed to system level constraints. Identification of the
business critical transactions early allows the appropriate focus on performance from requirements development forward, which is key to minimizing expensive, time
consuming remediation work during the late stages of the project.
Throughput and Response Times
The requirements related to the business critical transactions should be specified in the form of throughput or response time. Throughput is the number of functional
transactions that can be performed within a given time interval, for example, the number of orders that must be processed within a particular window of time, such as
100,000 orders a day. Response time is specifically related to the user experience with the online portion of the system and is typically measured as the total period of
time from when the user initiates a transaction by clicking or pressing a button, until he gets a system response such a screen refresh or an update message on the
screen. Throughput and response-time targets have been identified during the Performance Management Workshop or in the MoSCoW List, and if so, these non-
functional requirements will begin to define your set of Performance Metrics. It is likely that additional metrics will be identified during the course of the implementation.
The List of Throughput metrics should specify:
the exact type or types of functional transactions to be measured
the time periods during the day, week, month and business cycle when the measurements are to be made
the minimum acceptable transaction volume in a given time interval
the anticipated method of measurement
The List of Response-Time metrics should specify:
the exact type of types of functional transactions to be measured
the start and end points of each measurement
the time periods during the day, week, month and business cycle when the measurements are to be made
the expected numbers of logged-in and simultaneously active users, respectively
the maximum acceptable response time for each type of transaction
the anticipated method of measurement
Business users need systems that meet their business needs at all times. Frequently the demands for system performance are greatest during peak workload, and users
have difficulty accepting systems that meet the throughput or response time requirements under light or normal load conditions, but fail to meet the objectives in a peak
load scenario. Typically there are daily, weekly, monthly, seasonal and annual peak periods. These should be identified during Use Case requirements definitions and
considered when creating the Performance Test Strategy as well as the Technical Architecture Strategy.
Technical Architecture Capacity
There is often a strong relationship between performance metrics and technical architecture capacity, including both space capacity and processing capacity. For
example, the statement, "The forecast transaction volume will require 10 GB of disk space," relates to storage capacity based on transaction volumes, while the
statement, "The forecast transaction volume will require twenty disks to maintain acceptable i/o response times," relates to processing capacity. Specify state any
capacity assumptions when defining performance measurements.
Inappropriate Performance Expectations
If the application being implemented is a browser based multi-tier application that is replacing a single tier mainframe system, the user community may have performance
expectations that are very difficult or impossible to achieve using the technology planned. While the Performance Management process cannot adjust the laws of
physics, early identification of unrealistic performance expectations is actually an advantage, as it highlights the issue to the project sponsor, the project management and
the change management team, giving them the opportunity to recalibrate the expectations and set achievable goals. Projects that fail to explore performance
expectations early can be at risk of discovering a mismatch very late in the project, leaving little or no item to make necessary adjustments which puts acceptance and
user satisfaction at risk.
Performance Management and Performance Testing
If the project scope includes formal Performance Testing, the performance test objectives, scope and strategy will be defined in the Performance Testing Strategy
(PT.030). Performance Testing uses a top down approach, and it can used to validate a model of the entire solution or focus exclusively on a particular component of a
solution. Performance testing can establish the expected performance of the solution or component under test. It can be used to validate that the production
performance will acceptable for the business or determine if changes are required to meet the performance objectives. Performance Testing should represent the final
validation, not the first evaluation of performance. If Performance Testing is the only Performance Management technique used, there is considerable risk that:
Significant code rework may be identified.
Issues identified cannot be resolved without impacting the project timelines.
Performance issues may still occur in production that were not identified during the testing process.
Even when properly scoped and defined, Performance Testing is unlikely to simulate a complete view of the production workload, transaction that could introduce a
performance risk. The Performance Management Requirements and Strategy should establish the appropriate processes to minimize production performance problems
that arise from workload not included within formal Performance Testing scope. Processes to handle performance issues related to custom development (for purposes of
packaged software Configuration, Extension, Modifications, Localization) and Interfaces as well as processes to handle performance issues related to vendor supplied
code need to be established. If the project has elected not to conduct formal Performance Testing, strategies for performance management become even more critical.
Metrics and Monitoring
The Performance Management process requires the establishment of monitoring events that identify potential performance issues and the establishment of metrics that
facilitate reporting on the effectiveness of the process. Monitoring of the system from a top-down perspective is defined in the Define Systems Operation and
Management Strategy task (TA.060) and it is not necessary to completely duplicate that effort here. Consideration does need be given to monitoring transactional
performance or response time for the business critical transactions. Depending on the application being implemented, the approach may vary. Some applications are
instrumented and provide relatively simple ways to monitor and report transaction performance. If the critical transaction set is composed of primarily batch processes
executed through the Concurrent Manager facility provided with Oracle Applications, then submission times, wait times, execution times and total elapsed time by
process is already captured in the FND schema tables, and reports can be constructed using data automatically available through standard application functionality. If
the application processes are online transactions using the Oracle Application Framework, then the Page Access Tracker facility (Metalink note 278881.1) can be be
implemented and transaction response times can be collected and reported using standard features of the tool. Not all application response time metrics are as easily
collected however, so the approach used depends on the specific application requirements. Some businesses who have invested in automated testing tools may chose
to create "active monitoring" of transaction performance using the tools. In this strategy, scripts are build and run on a periodic basis to provide a stream of data that
records simulated user response times. Although there may not be a single common approach to collecting the information, there is a clear advantage in identifying
these requirements early so that if the application requires additional instrumentation to facilitate effective monitoring, if additional tools need to be purchased or if custom
reports or scripts need to be created, the requirements can be identified and included during the implementation process and time consuming application rework can be
avoided. The key to success in monitoring performance is to monitor statistics that can be related to the actual user experience, rather than relying strictly on system level
statistics. Nothing is more frustrating to a user with a performance issue than a conversation about the Buffer Cache Hit Ratio or a chart showing CPU utilization within
acceptable ranges, as they understandably cannot relate the information to the actual problem at hand.
Additional metrics designed to monitor and measure the Performance Management process itself should be established. The particular metrics should be determined
based on the specific project requirement, but the following lists some examples that may be appropriate:
number of code reviews conducted
number of performance related defects identified
number of SQL statements with performance defects
number of system change requests related to performance issues
number of performance issues reported
time to resolve performance issues
number of performance TARs opened
number of performance patches applied
statistics on batch program performance by category
etc.
Metrics can be further categorized based on the project requirements and should be reported regularly to the project management. Trends in the metrics are a useful tool
in identification of areas that are working well, as well as areas that may require process improvement.
The Performance Management process should attempt to leverage the existing project Issue and Problem Management process and tools. A consideration specific to
Performance Management is that performance issues and problems should be easily identifiable using the standard tools. This may require the creation of grouping or
category data in the tool that allow performance issues to be specifically identified across other groups such as functional silos or ticket assignment. Time from
identification to resolution is a common Performance Management metric, so the Issue and Problem Management processes should capture and permit reporting of this
data without extensive manual manipulation. In addition, the process to manage performance issues and problems will be required after the application is implemented,
so if the project processes in place are for the implementation project only, an alternative, more permanent process may be required.
Back to Top
System Architect Provide information on technical architecture design and performance implications. Develop the Performance Management
Requirements and Strategy.
If a Performance Management team leader has been designated, 10% of this time would be allocated to this individual, leaving
80% allocated to the system architect. The team leader would then review and approve the Performance Management
Requirements and Strategy.
90
Developer Define specific performance requirements for the application. 10
Ambassador User Defines business performance objectives and requirements. *
Back to Top
PREREQUISITES
Prerequisite Usage
Project Management Plan (PJM) The Project Management Plan provides a high level discussion of the scope of the testing, what performance
concerns, risks or questions it should address, and how the project should be organized and run.
Performance Management Workshop Results
(PT.010)
These results provide information on performance needs and expectations.
Business Use Case Model (RA.015) The Business Use Case Model may highlight the set of critical business processes that should receive particular
attention in Performance Management.
Supplemental Requirements (Non-Functional)
(RD.055)
Any generic performance requirements are described as part of the Supplemental Requirements. The strategy for
Performance Testing will be dependent on what kind of performance requirements there are, how strict they are, and
what type of components will be performance critical.
Use Case Specification (RA.024.1) Specific performance requirements for a use case are provided as part of the Use Case Specification.
(TA.020)
The Performance Management Requirements and Strategy can impact the architecture options outlined in the
Architecture Requirements and Strategy and vice versa.
Back to Top
TEMPLATES AND TOOLS
PT-020_PERFORMANCE_MANAGEMENT_REQUIREMENTS_AND_STRATEGY.DOC MS WORD
Back to Top
The Performance Management Requirements and Strategy is used in the following ways:
to establish consensus on the project's approach to Performance Management
to document key business transactions and their performance requirements
to establish the Performance Management virtual team and increase understanding of the roles and responsibilities
to identify monitoring and metrics that will be used to measure both transaction performance and the Performance Management process.
to obtain sign-off approval for the requirements and resources needed
Distribute the Performance Management Requirements and Strategy as follows:
to project manager and client who should sign off the performance management requirements and resources needed
to IS managers who should sign off the Performance Management Strategy
to Performance Management virtual team members including system, database, and network administrators who are responsible for configuring and managing the
project environments
to lead developer and system architect
Back to Top
QUALITY CRITERIA
Use the following criteria to help check the quality of this work product:
Are the performance management scope and objectives clearly identified?
Are specific critical success factors and risks documented?
Have dependency and interaction with other processes been identified?
Are the key business transactions and their performance requirements clearly defined?
Has the strategy been reviewed and agreed to by the project team and related organizations?
Are all resource and tool requirements that could affect Performance Management stated and understood?
Back to Top
PT.030 - DEFINE PERFORMANCE TESTING STRATEGY
This task defines the scope and objectives of Performance Testing for the project and outlines the strategy that will be used to conduct the performance test. The
approach to performance testing is top down in nature and attempts to tie the transaction model and database used for performance testing back to actual or predicted
scenarios (point-in-time processing snapshots) in the production system. Although other approaches to the problem exist, they tend to be more bottom-up in nature, with
the result that relating the results back to the actual system being modeled is difficult and unclear. Performance tests typically are a simulation of complex systems and
require resources with the appropriate skills to interpret the results, approximate the impact to the planned production system and develop recommendations to improve
performance.
If your project includes Performance Testing, you should perform this task.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Testing Strategy - The Performance Testing Strategy documents the scope, objectives, strategy and requirements for the project Performance Testing
effort. It outlines the Performance Testing approach that is to be followed, and the strategy for achieving the stated objectives.
Back to Top
TASK STEPS
1 Review the Project Management Plan (PJM) and
other relevant project library documents for
requirements related to Performance Testing.
None See Prerequisites below.
2 Document the context for the Performance
Testing.
Introduction The Introduction details the purpose of the work product, provides background information on the
project, and includes references to related documents.
3 Identify Performance Testing scope and
objectives
Scope and
Objectives
The Scope statement describes the scope of Performance Testing for the project in as much
detail as possible. Scope statements define which solution elements are in or out of scope for the
project. Examples of elements that can define the scope include:
Specific Business Processes or Functions within to be Performance Tested
Applications to be tested
Technical Architecture Configurations to be tested
Interfaces, Data Conversion Programs, and Databases included in Performance Testing
Scope
It is equally important to clearly articulate which project elements are out of scope for the formal
Performance Test effort. Elements that are out of scope should be covered by the Performance
Management processes put in place in the Performance Management Requirements and
Strategy (PT.020)
The Objectives describe the specific goals and objectives of the Performance Test. It is critical
that the objective be clearly defined and agreed to by key project stakeholders, particularly the
business representatives. The test objectives will drive much of the test design and planning.
For example, if one of the objectives is to test alternative architectures selected to host the
application, it may be necessary to coordinate with the hardware vendor to arrange for testing at
a test site where a variety of servers can be made available. If the objective is to validate the
select production architecture has sufficient capacity to handle a series of phased rollouts, then
the performance test models must be designed to simulate the user volumes over time.
4 Identify Performance Testing approach and
strategy and critical success factors. Define
policies and procedures unique to Performance
Testing. Identify Performance Testing
dependencies to the main project and other
Approach The Approach describes the process, policies and procedures, project dependencies, and the
technical background for Performance Testing. The description of the process should include a
high-level discussion of the tasks and work products, including any variations from the
methodology standard Performance Testing process that have been adopted for the project. A
glossary of terms defining specific terminology associated with the process or selected tools
#TOP #TOP
subprojects. should be included. Key process milestones, the constraints that affect the Performance Testing
Process, any assumptions made, and the relationship of the process to other systems projects
and initiatives already underway should be documented.
The subproject policies and procedures should be related to the corresponding policies and
procedures adopted for the main project. If the subproject is to use different polices, procedures
or standards from the main project in any of the key control and reporting areas, the work product
should document the differences in detail, explaining why they differ. Examples of areas where
the subproject will typically inherit standards and procedures from the main project are listed
below:
Project Management Plan (PJM)
Issue Management and Resolution
Change Management
Reporting Format
Reporting Relationship to the Main Project
Acceptance
Project Policies and Procedures
Subproject Team Meetings
Logistics and Administrative Support
The project dependencies section of the component should describe the dependencies between
Performance Testing and other processes or subprojects taking place within the overall
implementation project. The technical background should describe the technical circumstances
affecting the approach to the project. Examples of the points that may be included are:
Dependency on the Conversion subproject for production quality data
Dependency on the development effort for completion of custom components (including
packaged software Extensions, Modifications, Localizations and Interfaces) included in the
Performance Test scope
Implementation sites, particularly testing to simulate geographically distributed users
Major System or Application Requirements
Innovative or Unusual Technical Requirements
In relation to the statements about the technical circumstances for the project, the work product
should define the requirements for the environments that will be necessary to support the
subproject. Typically, at least one separate environment will be needed for controlled
performance test measurements.
5 Identify the mechanism for executing the
performance tests. Establish the Performance
Test environment requirements and define the
strategy for obtaining a test database. Establish
high-level test execution procedures. Establish
the procedures for backing up the test
environment and refreshing the test environment
after an execution cycle.
Technical
Strategy
The Technical Strategy describes the technical strategy for Performance Testing, including the
means for executing the tests, the database and environment preparation and maintenance, and
the tools that are to be used. Specific areas that you should highlight include:
Transaction Models - specific scenarios or models of system processing that should be
included in the tests in order to meet the test objectives
Transaction Execution - how transactions are to be executed in the tests; a key decision is
whether an automated load testing tool is to be used
Database Construction - the strategy to be used for constructing the test database, loading
or maintaining setup data, planned reuse of other project data or programs
Performance Monitoring - how monitoring of performance is to be done during the tests
and the specific measurements to be taken
Test Execution and Refresh - specific techniques for execution of the tests and refresh of
the test environment after completion of a test cycle
6 Document the test technical architecture. Technical
Architecture
The Technical Architecture describes the technical architecture of the Performance Test
environment. It should include both the technical architecture of the system under test, as well as
support and boundary systems. For example, if automated testing is planned, the test technical
architecture should include any special servers that act as test driver machines processing the
automated test tool software. Include a diagram of the technical architecture of the test
environment.
7 Describe the resource requirements needed to
support the testing process. Document the
technical test infrastructure requirements.
Document the staffing requirements for the tests.
Resource
Requirements
The Resource Requirements component describes the specific resources needed for
Performance Testing which may include resources in the areas of:
Software
Hardware and Networks
Hardware and Software Delivery Schedule
Staff
8 Document specific tool requirements for the
testing process.
Tool
Requirements
The Tool Requirements component describes the specific tool requirements identified for building,
executing, and monitoring the performance tests. Include the following areas:
Application Development
Automated Performance Testing
Performance Monitoring and Other System Management Tools
9 Reporting Results Reporting
Requirements
The Reporting Requirement component should define what type of information will be collected
during the test execution and what results will be reported. A mechanism to collect and report
results that will demonstrate that the test has met the objectives defined is required. Although the
Oracle technology stack is well instrumented, thought must be given to which metrics are most
appropriate to report and if objective include testing of components that are not easily
instrumented, such as network performance, end-to-end business process execution times, etc.
then a method to collect the information will be required.
10 Identify risks in the strategy. Risks Performance Testing has a number of inherent risks. The Risks component describes the risks
related to the Performance Testing effort. Examples of risks areas are:
Timeline constraints related to Performance Test dependencies such as the completion of
Conversion or Development
Lack of an automated testing tool needed for performance measurements to meet the
scope and objectives of the project
Lack of availability of expert resources
Lack of an environment that can fully simulate the planned production environment to
conduct the testing
inability to construct sufficiently detailed system models due to time or cost constraints
11 Critical Success Factors Critical
Success
Factors
The Critical Success Factors for Performance Testing include:
Clearly defined scope and objectives
Business and Development involvement
Appropriate skills on the Testing team
Appropriate infrastructure and tool support
Early identification of test data requirements
Inclusion of Performance Testing within an overall Performance Management process to
provide the final validation of performance, not the initial review
12 Review the work product with project, IT
managers and key functional representatives.
Secure acceptance for the Performance Testing
Strategy.
None None
Back to Top
APPROACH
Performance Test Objectives
Performance Testing is a method for assessing the performance characteristics of specific application transactions at a point in time, using measurements of resource
consumption and transaction response times. The primary objective of a performance test is to understand how workload characteristics affect performance within a
given hardware, software and database environment. If the test results fail to meet the performance requirements or expectations, there are typically two options; tune the
application and the environment until the necessary results are achieved, or adjust the architecture being used to process the workload.
Performance Testing is not the same thing as benchmark testing or stress testing, although before the Performance Management workshop (PT.010) clients may not
grasp the distinctions between the types of tests. A performance test is designed to simulate a realistic production workload running on the planned production hardware
and software. Benchmarks and stress tests typically do not attempt to simulate realistic user workloads and may be not be constrained by architectural limitations.
Benchmark tests are designed to provide pure comparisons between a variety of hardware or software configurations. They are typically constructed with a somewhat
simplistic, limited transaction mix and may use highly optimized hardware configurations to achieve their goals. Stress tests tend to focus on determining the upper limits
of architecture capacity or transaction throughput, and are usually designed to execute a limited sets of transactions run at very high volumes.
Performance Testing can be used to validate individual transaction performance, validate that the production hardware selected can accommodate the anticipated
workload or may provide input to the capacity planning process. Performance Testing can also be used to validate ongoing capacity for a phased implementation with a
number of additional users added to the system over a period of time or to establish a baseline for regression testing of workload or architectural changes. Performance
Testing is not an appropriate method to provide functional recommendations, or validate processing gaps. the test may provide information about the processing speed of
certain business processes, which can be useful in suggesting process improvement options and the relative timing of interdependent tasks. However, unless
categorically stated as an objective, the processing speed of specific end to end business processes is not usually the central goal and including that as an objective can
significantly increase the complexity of the test. Determining the specific objectives is a critical component of Performance Testing, as the objectives will drive the
selection of scenarios and models including in the test process.
Once the the Performance Testing Strategy is defined and documented, it should be reviewed and accepted by key project stakeholders, including both IT and Business
representatives before progressing with the rest of the performance testing.
Performance Test Scope
A performance test is a simulation of workload, and like all simulations it is subject to a number of risks. It is common for users to expect that Performance Testing will
cover "all" the workload, while in reality, the effort to construct a test that exercised every possible transaction within even a relatively small application would be a highly
complex and resource intensive effort that can not be justified in terms of benefit received. Performance Testing must focus on a subset of key transactions that have
been identified as critical to the implementation effort. Due to constraints related to environment support or other reasons, integration with boundary systems may have to
be limited within formal performance testing, as often these systems may not be able to provide an isolated environment strictly for performance testing. It is most
appropriate for the business to drive the selection of transactions to be included within the performance test scenarios and equally important for them to understand and
agree to the exclusion of some transactions from the performance test scope. Performance Testing is only one aspect of the overall performance management process
in a project and the alternative methods for identification of transaction performance issues as documented in the Performance Management Requirements and Strategy
(PT.020) should be used for application workload that is considered out of scope for formal Performance Testing.
Performance Testing Strategy
The strategy used to conduct performance testing depends on the size and complexity of the implementation, as well as the resources available. Performance Testing
can be a complex process and may require a significant investment in resources. If automating testing is used, there may also be a requirement to purchase testing tools
and to staff the project with resources who know the tool. The Performance Testing Strategy should consider the level of risk associated with poor performance in the
implemented system and the probability of issue occurring. The effort, complexity and cost of Performance Testing must be related to the effort to mitigate these risks.
Automated or Manual Performance Testing
If the scope of the transactions included in Performance Testing is limited to key batch programs only, it may not be necessary to conduct an automated performance
test. Test scenarios that include heavy online transaction process typically will require automation and potentially a testing tool to manage and execute the process. It is
possible to conduct manual Performance Testing of online transactions, but this approach is not recommended due to the problems associated with acquiring sufficient
resources to product the desired volumes and the difficulty in accurately producing the same workload in the various iterations of the test execution. The process of
testing is typically a cycle of execution, determining what changes should be made and retesting to validate the changes produce the desired impact. An automated test
is much more effective and predictive than a series of manually executed tested. If use of testing tools are planned, the customer may have to purchase the tool or
potentially increase the amount of licenses they have available to meet the objectives of the test. If a purchase will be required, be that the project manager has a clear
understanding of the procurement requirement and validate that the process can be completed within the timeline of the testing plan.
Testing Risks
While Performance Testing is a valuable process that can help to identify any performance issues prior to the implementation of a production system, the process is an
artificial construct and cannot exactly simulate all the complex interactions and processing that will take place in a production system. As such there are some inherent
risks in the process, such as the risk of interpreting of results obtained from a relatively subset of processes and the risk that transactions not identified as included within
the performance test scope could potentially cause performance issues in the production system.
If the scope includes multiple simultaneous online processes, an automated testing tool is likely to be required to help manage the processing. Use of these tools can
require additional tasks and or expertise, resulting in an extra layer of complexity to all phases of a performance test. An automated test should be thought of as a mini-
implementation project, and be subject to controls and testing similar to any other implementation effort. Common errors are to use the tools to inadvertently drive more
workload than actual production users would really generate by failing to properly space transactions or account for "think time" or to introduce an artificial constraint that
affects performance that might never occur in a live system, such as 1000 users all accessing the same item number simultaneously. The subsequent tasks in the
Performance Management process, Identify Performance Testing Models and Scenarios (PT.040), Design Performance Test Scripts and Programs (PT.050), Design
Performance Test Data and Load Programs (PT.060), Build Performance Test Scripts and Programs (PT.070) and Conduct Performance Test Dress Rehearsal (PT.090)
have been designed to reduce testing risks that could be introduced by the Testing process.
The alternative to using automated tools is to conduct the tests manually. This approach reduces the the need for additional tools and expertise, but puts greater demand
on the time of users and limits the scope of what you can achieve, while raising the risk that the results of the testing may not as complete or comprehensive. In smaller
projects with limited resources and time, it is possible to merge the Performance Testing of the system with the Testing and employ the users performing the system test
to manually evaluate performance at the same time. In this approach, the Performance Testing goals and objectives risk being overcome by those of the Testing,
resulting in a Performance Test that cannot be successfully extrapolated to production performance. Typically this approach cannot simulate expected production
transaction rates and volumes related to specific periods of peak demand in the real system, thus it has a lower probability of uncovering performance risks related to
system load constraints. A performance test conducted manually using newly trained system users may lead to lower than expected performance results due to lack of
unfamiliarity with the system processes and inefficient data entry. If forced to conduct a manual project, it is critical to manage the expectations of results so that they do
not overstate what such an approach can hope to accomplish.
In a large and complex implementation project, Performance Testing may need to be a separate subproject because of its size and complexity, with resources fully
devoted to the Performance testing effort.
Hardware Vendor Coordination
Hardware vendors should have up-to-date metrics for the capacity and performance of their servers. The vendor may also offer technical consulting services with
consultants that are familiar with the type of applications you are attempting to implement and Performance Testing methods. Discuss your Performance Testing and
capacity planning requirements with your hardware vendor representative and establish the levels of assistance they can provide for this task. In some cases, the
execution of the performance test itself will occur at a hardware vendor testing facility in order to provide a variety of servers or processing options. If that is the case,
scheduling of the test execution becomes critical as the testing facilities typically have limited availability.
Resources
Applications that use formal Performance Testing tend to be highly complex and since the test cannot completely simulate the expected production workload, there is
often a need to extrapolate or interpret the results. Additionally, the test effort is often run as a sub-project and has numerous dependencies to other project streams,
particularly development and conversion. A performance test lead with the appropriate technical and project management skills is required. Typically staffing also
includes a DBA and tuning support. If the testing is automated, you need technical analysts who are experienced in the automated testing tool chosen, or you need to
arrange learning events for the identified technical analysts on the project. If the testing is manual, you need to arrange for enough coordinated user resources to
manually enter the transactions at test execution time.
Performance Test Environment
The Performance Testing team should have access to an environment for development of any special transaction programs or scripts. The test should be executed in a
separate controlled environment that is as similar as possible to (or is) the real Production Environment. The team needs access to a fully functioning installation of the
application and any third party applications or boundary systems. Setup data that mimics the Production Environment as closely as possible should be used. If the
project realities make it impossible to fully simulate the production environment and compromises are necessary, the testing must still be conducted in a controlled
environment, insulated from the miscellaneous transactions and processing of other project users on the system.
It is possible to conduct some level of performance testing using a server or an environment shared with the wider project team, but this approach can significantly
increase the complexity of performance testing. The testing may scheduled for times outside normal working hours, which can introduce resource constraints. Often
performance tests require specific data related to the test scripts or programs to operate as designed and if other users share the environment, a strategy to manage the
test data will be required.
Performance Test Data
The performance of applications running on the Oracle database can be significantly affected by both the quantity and quality of the data. Ideally, Performance Testing
should be run on an environment populated with a full complement of production quality data. In reality, this is a goal that can be difficult to achieve. If the project has a
conversion effort, then conversion may be able to provide at least a subset of production quality data that can be used for testing. If the transactions being tested are
driven by transactional data that is not included in conversion, such as open orders, open POs, etc., it may be necessary to design a method to pre-populate such data in
order to improve the accuracy of the performance test results. Constructing data that can not be obtained from other project sources can significant increase both the
effort and complexity of Performance Testing.
When determining the test data requirement, consider whether the intention is for the test to be a "one time only" event or a reusable test that the client intends to use to
validate future system enhancements or changes. If the test is intended to be reuseable, the test data to drive and support the testing must also be available, so relying
on specific conversion data, for example, is not a workable strategy for a test that may be rerun months after the application as gone into production. In such a situation,
consider developing data selection scripts, that can be reused to find appropriate data that meets the test requirements from either the current or future database. This
type of requirement may add additional effort to the test plan.
Reporting Results
The results of performance testing should be designed to demonstrate that the test has achieved the agreed upon test objectives. The specific data and metrics that will
be collected during the test should be determined ahead of time. Some automated testing tools provide fairly robust reporting capabilities that can be leveraged. Some
test objectives may require additional data collection, or perhaps even instrumentation built into the application under test. If the testing will be conducted on a platform
that differs from the proposed production platform, such as a smaller lab environment the results will be less precise and may require extrapolation. The Performance
Testing Strategy should discuss any assumptions or estimating techniques planned and the potential for a margin of error.
Back to Top
Back to Top
System Architect Develop Performance Testing Strategy.
If a Performance Management team leader has been designated, 10% of this time would be allocated to
this individual, leaving 90% allocated to the system architect. The team leader would then review and
approve the Performance Testing Strategy.
100
Ambassador User Review and approve the Performance Testing Strategy. *
Network Engineer (NE) - Assist the test team with network testing and identification of network demands outside of the project scope.
Back to Top
PREREQUISITES
Prerequisite Usage
Project Management Plan (Manage) The Project Management Plan provides a high-level discussion of the scope of the testing, what performance
concerns, risks or questions it should address, and how the project should be organized and run.
Performance Management Workshop
Results (PT.010)
These results provide information on performance needs and expectations.
Performance Management Requirements
and Strategy (PT.020)
The Performance Management Requirements and Strategy provides information about the the overall project
Performance Management and which project elements are out of scope for the formal Performance Test effort.
Physical Resource Plan (PJM.IFM.030) The Physical Resource Plan provides information about the environment strategy for the overall project and may
include information about the environment resources for performance testing.
Supplemental Requirements (RD.055) Any generic performance requirements are described as part of the Supplemental Requirements. The strategy for
performance testing will be dependent on what kind of performance requirements there are, how strict they are, and
what type of components will be performance critical.
Use Case Specification (RA.024) Specific performance requirements for a use case are provided as part of the Use Case Specification. The
Performance Testing Strategy will be dependent on what kind of use cases are performance critical.
Technical Architecture Workshop Results
(TA.010)
(TA.020)
These work products should contain early capacity and system requirements.
Back to Top
TECHNIQUES
Technique Comments
Service Testing Use this technique to help you define the testing strategy for services.
Back to Top
TEMPLATES AND TOOLS
PT-
030_PERFORMANCE_TESTING_STRATEGY.DOC
MS WORD
Back to Top
The Performance Testing Strategy is used in the following ways:
to establish the Performance Testing scope and objective and approach
to obtain agreement from key project stakeholders
to raise awareness of dependencies between the Performance Testing subproject and other project teams
to increase the understanding about the requirements for the Performance Test Environment
Distribute the Performance Testing Strategy as follows:
to project manager who should sign off the Performance Testing requirements and resources needed
to key ambassador users who should sign off on the scope of applications to be tested
to IS manager who should sign off the Performance Testing Strategy
to Performance Testing team members
to system, database, and network administrators who are responsible for configuring and managing the Performance Test Environment and Database (PT.080)
Back to Top
QUALITY CRITERIA
Are the project scope and objectives clearly identified?
Has the impact of dependent tasks from other processes been taken into account?
Are the Performance Testing requirements clearly defined?
Is the strategy understood by those on the distribution list for this work product?
Are all resource and tool requirements that could affect Performance Testing stated and understood?
Back to Top
PT.040 - IDENTIFY PERFORMANCE TESTING MODELS AND
SCENARIOS
In this task, you define the Performance Testing Models and Scenarios that will be included in Performance Testing. A scenario is a point-in-time snapshot of processing
that occurs or is projected to occur on the production system. In other words, a scenario is the combination of online transactions, reports, inquiries and other processing
that will be included in a performance test execution. Depending on the complexity of the implementation and the objectives defined for the performance test, multiple
scenarios may be required. For example, one common scenario is the "peak daytime workload" scenario. Another common scenario is the end of month closing
scenario. Typically there will be a different mix of programs and processes that are included in each scenario. A model is a definition of the transaction volumes and
architecture that will be used in conjunction with one or more scenarios. As an example, one model might represent user volumes anticipated at the time of initial
implementation and a second model might be volumes anticipated after some period of time and growth. Other examples of models could include executions of the
same scenarios using different architectural models.
The models and scenarios defined should be directly linked to the objectives of the Performance Testing Strategy that was defined in PT.030.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Testing Models and Scenarios - The Performance Testing Models and Scenarios describe the processing situations (point-in-time processing snapshots)
in the future production system that will be included in Performance Testing. The scenarios describe the sets of transaction processing that will occur and the models
define the various user volumes, architecture configuration or other where there will be critical performance requirements. The Performance Testing Models and
Scenarios form the basis for models of the system transactions in future tasks.
Back to Top
TASK STEPS
1 Review prior work products from PT process including the
output of the Performance Management Workshop, the
Performance Management Requirements and Strategy
and the Performance Testing Strategy.
None None
2 Review business volumes documentation and work
products.
None None
3 Prepare an introduction for the document giving the context
for the work product.
Introduction The Introduction details the purpose of the work product, provides background
information on the project, and includes references to related documents.
4 Create an initial list of Performance Test Scenarios. If
available, review the Future Process Model (RD.011.1)
and/or the Use Case Model (RA.023) to assist in business
use case decomposition of scenarios. Review the list of
Performance Test Scenarios with user management and
functional teams.
Test
Scenario
Descriptions
The Test Scenario Descriptions describe the system processing scenarios that you will
include in the performance test. For each test scenario identified, the business use case
considered to be active on the system at that time, the actors, and the number of users
representing those actors are identified. If you are attempting to model an end-to-end
business process, you need to identify each individual use case that could apply.
5 Identify the number of users and transaction volumes for
each Performance Test Scenario.
Users and
Transaction
volumes
The Users and Transaction Volumes specify the transaction rates and user volumes for
the performance testing of each scenario. The key metrics for each performance test
scenario are:
transaction rates for the constituent business use cases (either current or
projected for a certain date)
number of users executing each business use case (either current or projected
for a certain date)
6 Identify and document the list of Performance Test Models Performance The Performance Test Models represent the various mix of Test Scenarios or
#TOP #TOP
that will be tested. Test Models architectures that will be independently tested. If one of the test objectives is to test
expected performance both a go-live and after six months of growth, two models would
be created. They might both use the same set of scenarios, but at varying user volume
or transaction rates. If testing a Real Application Cluster (RAC) system, test models
that include node down scenarios should be included.
7 Document the assumptions made in defining the
Performance Test Models and Scenarios and their
decomposition.
Assumptions The Assumptions component describes the assumptions made in detailing the test
models, test scenarios and corresponding metrics. It is critical that the assumptions be
detailed and that they be reviewed with the project and IS managers prior to proceeding
with test definition. Examples of assumptions include:
assumptions about projected volumes
assumptions about archive or purge
assumptions about the future business operations model
8 Document the risks in the Performance Test Model and
Scenario analysis.
Risks The Risks component describes the risks in the test scenarios. Examples of risks
include:
limited number of business use cases included for a scenario
ignoring online processing effects for simplicity of models
ignoring batch processing load for simplicity of models
some processing scenarios in the real system may not be simulated due to
insufficient time or resources
Back to Top
APPROACH
A Performance Test Scenario is a point-in-time snapshot of the total production system processing environment that you model in your performance test. There may be
more than one performance test scenario that must be tested, each with a different set of active business use cases and transactions. There may be one or more
Performance Testing Scenarios included in a particular performance test. A Performance Test Transaction Model defines the precise mix of transactions, user volumes
and architecture that will be tested.
Types of Scenarios
Performance Test Scenarios are designed to simulate an actual production workload at a particular point in time. At a high level, scenarios are generally divided into two
types: those that have significant online activity and those that are primarily or totally batch processing in nature. Each scenario includes users or simulated user
transactions that represent in business use cases. The list of scenarios provides the context for the test transactions and scripts that are identified and documented in
subsequent tasks. Examples of scenarios might include a scenario that simulates peak day time workload and includes a mixture of online transactions and some limited
batch activity. Another, more batch oriented scenario, might simulate a nightly batch process and contain very limited or no online transactions.
Types of Models
Performance Test Transaction Models are the sets of transactions, including the transaction rates, user volumes and target architecture that simulate the Performance
Test Scenarios during test executions. Each Performance Test Scenario will have at least one Test Transaction Model, and some may have multiple models. A common
performance test objective is to test and tune the system to meet the requirements at initial production implementation and in addition, compare the performance to the
performance after some period of time, adjusting for growth in business volumes and users. In this case there would be two transaction models, both executing the same
Performance Test Scenarios. The production implementation model would use the estimated transaction rate and user volume anticipated at initial implementation and
the future period model would use the same transactions at the same relative mix, but with an increased transaction rate and increased number of users. The scenario is
the same in both cases, as are the transactions executed in the scenario, but the transaction rates and user counts vary.
If the system under test includes a RAC or Grid cluster, at least one model should be included that tests the system performance under diminished capacity, such as the
artificial failure of one or more nodes. This will allow validation of the high availability capacity of the system and test the transaction performance achievable under a
specified set of failure conditions.
Models with Architecture Variation
Some Performance Test Models require a variety of architecture designs. This may be true when the primary objective of the Performance Test is to validate an
architecture design or to perform capacity planning. It can be difficult to obtain the necessary equipment to conduct such a test at a client site due to resource limitations.
If the Performance Test requires testing a variety of architectural models, such as comparing performance between a design using a single SMP database server and a
design using a Grid of smaller commodity servers, it may be necessary to conduct the test at a vendor testing center. Tests with these type of model requirements are
complex to execute and require additional planning. It will be necessary to reserve the vendor testing center and the required hardware, and to develop a method to
transport the test from one architecture to another.
Distinguish Performance Testing Scenarios and Business Scenarios
Distinguish between the business requirements identified in the Business Requirements (RD) process and Performance Test Scenarios. The RD Process defines the
specifics of a single business process, with a single input and set of decisions. A business scenario does not refer to a point in time. Performance Testing Scenarios are
point-in-time snapshots of system processing, consisting of multiple separate business processes or portions of those processes. and use cases that are all concurrently
active. In general, a Performance Testing Scenario has multiple business process scenarios active concurrently as it is an attempt to model actual production workload.
Set of Scenarios Creation
Create the list of Performance Testing Scenarios by understanding the performance concerns of the user management and functional teams, analyzing the performance
test scope and objectives, and then factoring in the projected business volumes for the new system. Usually the scenario is a list of processing situations that constitute
the greatest performance risk in the implemented system. The definition of the set of Performance Testing Scenarios is also directly affected by the scope of Performance
Testing as detailed in the Performance Testing Strategy (PT.030).
Review Management Performance Concerns
You may have identified definite concerns on the part of business management regarding the performance of the implemented system during the early Performance
Testing scope and strategy work. Take care to review the prior specification of the project at this point, because the scenario analysis sets the context for the tests you
perform and directly affects the effort needed to design and execute the performance test.
Include a Comparative Scenario
As a comparison for the periods when the system is under extraordinary load, consider including a regular weekday scenario that baselines how the system performs
under ordinary conditions. This permits comparison of the performance of the system under regular processing conditions with the periods of peak system usage.
Factor in Cost and Complexity
When determining the list of scenarios to be tested, weigh the extra cost in resources and time each scenario requires. If the scenarios contain essentially the same
business use cases, but only vary in the relative mix of the use cases, the design and build work in the test are much less than if scenarios include different sets of
business use cases. Even if the decomposition of the Performance Testing Scenario results in the same set of business use cases for two scenarios, there is still
significant work to be done to re-execute the tests and take measurements for the different relative mixes and detailed transaction models.
Performance Testing Scenarios Characterization
Although approximations are required when designing performance tests because of the complex nature of the processing environment of a production system,
Performance Testing Scenarios are defined to be exact in nature. For example, it is possible to specify a particular scenario as being the morning of the last day of
external sales order processing in a business financial quarter. It is only when modeling the scenario in terms of the business processing and transaction flows that
approximations are required to focus on the most important transactions that occur in the system. By defining the Performance Testing Scenarios as exact snapshots of
the total processing on a system, the approximations are contained within the design of the performance tests while allowing discussion of the analysis of the business
volumes and the test processing environment in exact terms.
Scenario Decomposition Reflects Scope
As mentioned above, the Performance Testing scope in the project affects the list of Performance Test Scenarios that can be considered for including in the test. The
decomposition of the scenarios into constituent business use cases will also reflect the scope. For example, performance testing may be limited to only the batch
processing in the system, but conducted at business volumes and rates that are appropriate for a daytime scenario that also has online activity in the real production
system. The scenario still reflects a daytime processing situation, but artificially ignores the online processing and thereby introducing an approximation as a result. The
Performance Testing Scenario design should enable assessment of the approximations made when defining the performance test in relation to the situation in the real
production system.
Artificial Performance Testing Scenarios
A performance test executed early in an implementation project may not include, or may not be able to include, a reasonable simulation of the future system processing.
Such a test might be intended to gain information about some basic system parameters (for example, those that are relevant to system capacity planning such as
memory or CPU usage and I/O metrics). Under these circumstances, select a few sample transactions and define the single test scenario as being the sum total of the
business use cases corresponding to these transactions. This type of Performance Testing Scenario is not a realistic simulation of the actual future system and is artificial
in nature, although its results can be useful if interpreted and used with the understanding of the limitations of the test they were derived from. Such a scenario is similar
to a benchmark test, which usually has a highly simplified and artificial scenario model and accompanying transaction set.
Back to Top
Back to Top
System Architect Develop the Performance Testing Models and Scenarios. 80
System Analyst Provide input on projected volumes and scenarios, review and approve the development of the Performance Testing Models
and Scenarios.
20
Back to Top
PREREQUISITES
Prerequisite Usage
Project Management Plan (Manage) The Project Management Plan provides a high-level discussion of the scope of testing, performance concerns, risks or
questions it should address, and how the project should be organized and run.
Future Process Model (RD.011.1) Review the model to get an initial overview of how the business use cases using the new system.
Reviewed Analysis Model (AN.110.1) The use case scenarios for the performance critical use cases are translated into Performance Test Scenarios.
Test Scenarios (TE.025.1)
Systems Integration Test Scenario
(TE.035.1)
Parts of the scenarios from the Testing process may be reused for the Performance Testing Scenarios.
Performance Testing Strategy (PT.030) The Performance Testing Strategy provides information about the detailed strategy to be used for Performance Testing,
including an analysis of how the performance test objectives are addressed and the tools and techniques to be used.
Back to Top
TEMPLATES AND TOOLS
PT-040_PERFORMANCE_TESTING_MODELS_AND_SCENARIOS.DOC MS WORD
Back to Top
The Performance Testing Models and Scenarios are used in the following ways:
to accomplish the Performance Test
Distribute the Performance Testing Models and Scenarios as follows:
to the Performance Testing team members
to project manager
to IS manager
to ambassador users
Back to Top
QUALITY CRITERIA
Are the test models fully described with appropriate user and transaction volumes?
Are the test scenarios fully described and decomposed into their active business use cases?
Are the metrics included for each test scenario?
Does the work product include the assumptions and risks for the selected test scenarios and models?
Back to Top
PT.050 - DESIGN PERFORMANCE TEST SCRIPTS AND
PROGRAMS
In this task, you define the detailed Performance Test Scripts and Programs that will be created for the Performance Test effort. Scripts may be used for creating
transactional data, performing online transactions, inquiries, and or submit reports that model the processing occurring during a test scenario. Special programs for
Performance Testing may be needed to automate the simulation of multiple users or to drive transactions execution.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Test Scripts and Programs Design - The Performance Test Scripts and Programs Design define and documents the way in which each scenario
transaction model executes during the performance test. It should include the test data requirements and the response measurement you make as part of each scripted
transaction flow.
Back to Top
TASK STEPS
1 Prepare an introduction for the document giving the context for
the work product.
2 Identify transaction scripts or programs for each test use case
in each test scenario. Review the Performance Test Scripts
and Programs with business analysts. Revise the Performance
Test Scripts and Programs.
Test Scripts
and Programs
The Test Scripts and Programs describe the scripts for the test transactions of
each test scenario. For each test scenario, describe the scripts for the test
transactions that are included in the transaction models for that scenario. Identify
the data requirements related to each script and program.
3 Identify the test response measurements to make during the
execution of the Performance Test Scripts and Programs.
Test Script
Response
Measurements
The Test Script and Programs Response Measurements component describes the
measurements for the test transactions flows. Each test scenario should have
defined, detail measurements.
4 Document assumptions applied to create the Performance Test
Scripts and Programs.
Assumptions The Assumptions document the assumptions made in the course of identifying the
scripts, programs and measurements.
Back to Top
APPROACH
This task defines the detailed system navigation, steps and events that a user would go through in order to perform the transactions detailed in the Performance Testing
Models and Scenarios (PT.040). Whereas the transaction model is defined at the business object level (for example, create a sales order ), this task describes how the
business object is transacted in the application in detail.
User Workflow Patterns
When designing the Performance Test Scripts, it is critical to mimic realistic user behavior. Keep in mind the workflows that occur in the real production system. Work with
business analysts in the project team that are experts in the business use cases to understand how the transactions are or will be performed, what responsibilities will be
used, and what the navigation patterns and data requirements are. Working directly with system users will provide the best insight into their detailed work patterns. Keep
in mind that when implementing new systems, information about work patterns in the legacy system may provide limited value. If that is the case, review the functional
testing scripts for CRP or integration test as input to the test scripts that should be used in performance testing.
Performance Test Scripts and Programs Data Requirements
A Performance Test Script or Program typically requires test data to operate successfully. If script in question is an item inquiry, and the model will simulate many users
executing the same script, then it will be necessary to identify an appropriate number of items that meet the requirements of the scenario. A common testing error is to
work with a small subset of data rather than a realistic sampling. If the production workload pattern is for each user to query a different item number, a test where 50,000
users look up the same item number will not provide realistic results, and in fact could either artificially improve or artificially degrade performance. If the users commonly
use a portion of a particular key field to do their inquiry, a test script using a wild card search may not be accurate. When working with the business analysts and system
users, identify the test data needs as well as the navigation and workflow.
Performance Test Scripts Review
Business analysts on the project team should review the design of the Performance Test Scripts and Programs and the associated data requirements to validate that they
constitute a reasonable model of the real system transactions.
Test Script Response Measurements
Test Script Response Measurements are timing measurements made during the execution of the test scripts within each test execution cycle. Depending on the exact
scope and objectives of project performance testing, it may not be worthwhile to make such measurements. For example, if the Performance Test Models and Scenarios
(PT.040) are highly simplified, the test response measurements made in the test environment may not be useful as metrics for the real system. In more sophisticated and
complex simulations, however, timings of particular transactions or system event points will be required. Most automated testing tools will allow collection of the response
times for system events such as:
time to commit a transaction
time to display a list of values
time to open a form or a graphical window
The design and construction of a performance test can be a lengthy process and the desire to capture as many timings or measurements as possible is understandable.
However, beware of information overload. Too many timing event points in the scripted transaction flows can create a great deal of information to process and interpret
after the testing has finished. It is helpful to set a standard for which event points should be captured that focuses on the most meaningful data, rather than capturing the
response for every single event point possible. Any data captured should be evaluated in terms of it's usefulness in reporting on the results of the testing, rather than just
captured because it is possible to do so.
Instrumentation provided in the application can prove to be useful, without adding overhead to the testing process. As an example, batch processing running through the
Concurrent Manager already records information about each job submitted, including wait time, processing and elapse time. Application response times for application
using the Oracle Application Framework are already instrumented to use Page Access tracker, which captures response time measurements and provides a set of
standard reports. Evaluate all the mechanisms available, and utilize the ones most closely aligned to your test objectives.
Back to Top
Back to Top
System Architect Oversee, review and approve the design of of the Performance Test Scripts and Programs. 20
Tester Design the Performance Test Scripts and Programs. 80
Back to Top
PREREQUISITES
Prerequisite Usage
Performance Testing Strategy (PT.030) The Performance Testing Strategy identifies the overall objectives of the Performance Test.
Performance Test Models and
Scenarios (PT.040)
The Performance Test Models and Scenarios provide information about the sets of transactions that compose the scenarios
that will be modeled during Performance Testing. This task defines the individual transactions mentioned in each model in
detail, identifies the test data requirements and the response time measurement method.
Back to Top
TEMPLATES AND TOOLS
PT-050_PERFORMANCE_TEST_SCRIPTS_AND_PROGRAMS_DESIGN.DOC MS WORD
Tool Comments
project.
Back to Top
The Performance Test Scripts and Programs Design is used:
to document the workflows that each test user should follow to execute the transactions for each scenario
to record the detailed response measurements that are taken as a particular test user executes the script
to identify the test data requirements
Distribute the Performance Test Scripts and Programs Design as follows:
Business analysts for review
Performance Testing team members
Back to Top
QUALITY CRITERIA
Are the Test Scripts and programs fully described and decomposed into their individual business events and actions?
Are test user responsibilities and navigation paths identified?
Are the Test Script Response Measurements included for each test script or program?
Does the definition of each Test Script or Program include test data requirements?
Does the work product include the assumptions used?
Back to Top
PT.060 - DESIGN PERFORMANCE TEST DATA AND LOAD
PROGRAMS
In this task, you perform the detailed data (component) design work for Performance Testing on the target environment. Specific test data needs, including volumes and
sources the test database, the source of the data, and the proposed mechanism for getting the data into the test database.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Test Data and Load Programs Design - The Performance Test Data and Load Programs Design is a set of design documents that identify what test data
will be used to populate the Performance Test Environment and the requirements for any special test programs needed to either create test data or identify appropriate
test data required to execute transactions during the performance tests.
Back to Top
TASK STEPS
1 Review the test data strategy in the Performance Testing Strategy
(PT.030) and the data requirements documented in the Performance
Test Scripts and Programs Design (PT.050). Calculate volumes of
test data objects needed to satisfy the performance test scope and
strategy using the Performance Test Models and Scenarios (PT.040).
Review progress by the Data Acquisition and Conversion team and
application setup teams (if applicable).
None None
2 Prepare an introduction for the document giving the context for the
work product.
3 Identify the high-level strategy for the construction of the test
database. Identify gaps in the existing application setup data.
Establish mechanisms for filling gaps in the setup data. Establish
values of keys for missing setup data.
Test Data
Strategy
The Test Data Strategy describes the strategy to be used to identify and
assemble the test data required to support Performance Testing. Ideally the
bulk of data and programs will already available in the project environments,
but in some cases missing data may need to be generated. The
Performance Testing Strategy (PT.030) should contain a high level a
discussion of the Test Data Strategy, in which case this component can
either reference the component in the Performance Testing Strategy
(PT.030) or reproduce that text here.
4 Document setup data analysis. Identify gaps in the existing
transaction data. Establish mechanisms for filling gaps in the
transaction data. Establish values of keys for missing transaction
data.
Application
Setup Data
Analysis
The Application Setup Data Analysis component describes the setup data
required for the Performance Test Database. For each business object that
needs to be present in the test database, indicate the volume of data needed,
the source of the data, how existing data will be identified and the
specifications for any new data you need to create artificially.
5 Document transaction data analysis. Application
Transaction
Data
Analysis
The Application Transaction Data Analysis component describes the
transaction data required for the Performance Test Database. For each
business object that needs to be present in the test database, indicate the
volume of data needed, the source of the data, how existing data will be
identified and the specifications of any new data that must be created
artificially.
6 Identify risks in the test database strategy. Risks The Risks component describes the risks in the strategy and analysis of the
test data presented in the Performance Test Data Design.
Back to Top
APPROACH
General Considerations
Appropriate test data is a critical success factor for a performance test. Test data that simulates both production quantity and production quality is key to uncovering
performance bottlenecks or system tuning problems. Business Testing in an implementation project is usually performed against databases that are populated with
relatively small and unrealistic volumes of data and as a result, Business Testing does not exercise the technical configuration and processing to a degree that would
uncover major performance issues (nor is it intended to). In order for the results of a performance test to be representative, it is important that the performance test is
executed against a database that simulates production and has a volume of data in it that is at least equal to, or a significant fraction of, the volume of data expected in
the real production database. This requirement introduces a dependency between Data Acquisition and Conversion and Performance Testing. If the Data Acquisition and
Conversion programs will not be available or fully tested in time to provide data to the Performance Test, or if the data conversion volumes will not be sufficient for
Performance Testing, test data may have to be generated by the Performance Test team. The work involved in artificially populating a database to the required volumes
is time consuming, and introduces significant risk to the performance test effort.
Supporting the Iterative Nature of Performance Testing
Many performance tests require iterative execution cycles. This implies a requirement that adequate test data will be available to support each iteration. The test data
design must accommodate the strategy to perform test iterations. If the strategy includes refreshing the database from a backup after each iteration, then the volume of
data required is typically constant. If the strategy requires multiple iterations without refreshing the test database, then sufficient data must be made available to support
the planned number of iterations. Particular attention should be paid to external files that support the test and to data that is "consumed" in the testing process.
Network Performance Testing
If the Performance Testing is focused exclusively on the network components of the system, rather than system performance or transaction performance, test data is less
critical. A test database sufficiently sized to execute transactions will still be required, but large volumes of data may not be needed if measurement of query or database
performance is not a test objective.
Most applications do not have exclusive use of shared network segments. They must share bandwidth with other applications on the corporate WAN or LAN. When
testing network performance, one must take the additional demands on the network from other applications into account.
Production Database Copy
If the system being tested is already in production, and Performance Testing is being used to assess the performance impact of a change or reconfiguration of the
production system, the effort involved in this task diminishes dramatically. A clone of the production database should be used as the source for the Performance Test
Database (assuming sufficient disk space is available).
Conversion Database Copy
If the system under test is not in production, but the project includes a conversion effort, a copy of the conversion database can be used to provide the bulk of the
necessary test data. While this reduces the effort associated with creating test data, it does introduce a dependency between Data Acquisition and Conversion and
Performance Testing that must be monitored and managed, because if the conversion effort slips, the Performance Testing execution may be delayed.
Test Database Volumes Calculation
To calculate the data volumes needed, review the scope and strategy for the Performance Testing, and in particular, the test transaction models that may simulate
different situations after the new system has gone into live production. Use the business volumes information and the transaction models to define the type and volume of
data needed. If the information is available, factor in decisions about the archive and purge cycles for different business objects. The volume of data in the database is a
critical factor affecting the test performance results, so make sure that the database properly represents the processing environment.
Test Database Strategy
If a direct copy of the live processing database is not available to clone into the test environment, the test database will have to be created. Setup data should be cloned
or copied from a "Gold" instance, and then volume transaction data loaded. .
Reuse Implementation Team Data and Programs
If Performance Testing, is part of an implementation project, reduce risk by reusing as much of the data and programs created within that project as possible. The
following sources of data and programs are useful to this task:
data in Prototyping or Testing (TE) databases
data in a dedicated application setups database
programs from Data Acquisition and Conversion (CV)
Even if the data does not yet exist or programs have not been written, component designs from Data Acquisition and Conversion (CV) may be reusable for this purpose.
Not all data in the test database may require the same integrity that the production system must have. If the data in a table is not accessed during a transaction and is not
part of a report or inquiry data set, it may be possible to populate the data with dummy data to fills out the table volume for the presence of table scans and index
searches. This approach does introduce risk of inadvertently affecting transaction integrity and so must be carefully analyzed for any potential impact.
When filling the gaps in the data, the database designer needs to decide whether to load data that accurately represents the data in the live processing environment or
whether to manufacture artificial data to fill out the database. The latter option is easier, but care needs to be taken to verify that a realistic distribution is chosen for the
data of the table keys, so that indexes perform as they would in the live environment.
Populate Only What Is Needed
It may not be necessary to populate all the tables in the test database to full production volume. If the performance test transactions, inquiries or reports do not access a
particular table, it may not need to be populated for the test. However, if scope of the Performance Testing includes operational timings (for example, backup and
recovery) it may be necessary to populate all tables to their approximate production volume.
Loading Data to Support a Business Process
If the scope of the performance test includes many or all steps within an overall business process, consider loading data in tables that are accessed during all the
individual steps embedded in the process. In such a situation, transactions must be executed through the business process to be able to populate the tables
corresponding to the business objects transacted within the middle steps of the process. In the order fulfillment business process, for example, a test of picking and
shipping of products requires sufficient sales orders in a state where they can be picked or shipped. Executing the linked transactions of a business process to populate a
database can be very time consuming, repetitive, and difficult to automate, but it may be the only reasonable way to populate the database to support this type of
complex business process.
Suggestion: In addition to the straightforward execution of business process flows to populate mid-process transaction tables, there may be other creative ways to use
application functionality to populate tables. The tight integration between ERP/Supply Chain applications can be problematic for database population; however, it can be
used to advantage. For example, if forecast or MPS data is available, MRP can be run to create volumes of purchase orders for testing -- even if MRP is not included in
the performance test scope.
Integration with External Systems
Data requirements relating to integration with external systems require careful analysis. Often the availability of legacy system environments is limited and there may not
be an environment that can be dedicated to supporting performance testing. There are a number of approaches to this problem including:
pre-loading data into interface tables and limiting the performance testing to processing only the interface table data
creating "stub files" on interface data that can be repeatedly processed with each performance test iteration
excluding interfaces from the formal performance test scope and monitoring and managing their performance as part of the overall project performance
management effort
dedicating additional system environments to support the Performance Testing requirements
If using an approach that relies on data that is staged and ready for processing, be sure the volume of data is realistic in the context of the test scenarios and models it will
be used in.
Data Multiplication
A very simple approach to populating a table to full volume is to multiply the number of rows already in the table with a script. This approach does not provide for
complete integrity of the data, but is a fast way to pad out a table to its full production volume. Develop a method of continuously changing the primary keys of the rows
so that the primary key integrity is not violated -- this is important for index searches to work correctly. One means of changing the primary key is to add a changing prefix
to a primary key field, for example:
Customer Name: Global Computers Inc.
AAA-Global Computers Inc.
AAB-Global Computers Inc.
The prefix is also a means of tracking where a particular record lies in the database blocks storing the table data and can be used to help make sure that you access a
wide distribution of records during a particular transaction or inquiry (if the business data processing model requires it).
If using this method to create test data, be aware that the data may not meet the necessary data integrity requirements. Test data populated in this manner should not be
directly accessed by test scripts or programs, unless you have done the complete analysis necessary to ensure that it will function correctly within the application.
Application Development Installation Access
A development environment can help with the data design task if it includes all the components within the Performance Testing scope. A development database should be
a be used to enter and prototype data creation.
Back to Top
Back to Top
System Architect Design test components with regard to the technical architecture of the application. Review and approve the
Performance Test Data and Load Programs Design.
30
Tester Design the performance test data and load programs. 60
System Architect (Information
Architect)
Assist test team in designing test components with regard to the Information Architecture of the application. Preferably,
this should be done by a system architect that specializes in Information Architecture.
10
Ambassador User Assist test team with identification of test data requirements. *
System Architect specializing in J2EE Architect (SA) - Assist test team in designing test components with regard to the J2EE application architecture.
Back to Top
PREREQUISITES
Prerequisite Usage
Performance Testing Strategy (PT.030) Describes the overall test objective and strategy and may define method and sources of test data
Performance Test Models and Scenarios (PT.040) The Performance Test Models and Scenarios provide information about the sets of transactions that model the
system in the test. Make sure that the test database setup data can enable the error free execution of these
transactions and that the database has the full volumes of setup and transaction data dictated by the
performance test objectives and strategy.
Strategy (CV.020)
The Data Acquisition, Conversion and Data Quality Strategy may be an aid to determine a source of the
required data, including a mechanism for getting the data into the test database.
Back to Top
TEMPLATES AND TOOLS
PT-060_DESIGNED_PERFORMANCE_TEST_DATA.DOC MS WORD
PT-060_DESIGNED_TEST_LOAD_PROGRAMS.DOC MS WORD
Back to Top
Distribute the Performance Test Data and Load Programs Design to the following:
project manager
technical analysts participating in Data Acquisition and Conversion (CV)
Back to Top
QUALITY CRITERIA
Are the setup and transaction data fully specified for the test database?
Is the process to manage changes to the setup Sand transaction data documented?
Is the new data (which may need to be created) specified?
Are methods to identify test data expected to be provided by conversion or other processes fully specified?
Are the data design risks documented?
Back to Top
PT.070 - BUILD PERFORMANCE TEST SCRIPTS AND
PROGRAMS
In this task, you create the special Performance Test Scripts and Programs (Components) that execute the transactions, reports and inquiries against the Performance
Test Database.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Test Scripts and Programs - The Performance Test Scripts and Programs are the actual component code (programs) for the components that were
designed in tasks Design Performance Test Scripts and Programs (PT.050) and Design Performance Test Data and Load Programs (PT.060).
Back to Top
TASK STEPS
1 Review the detailed Design Performance Test Scripts
and Programs (PT.050) and Create Performance Test
Data and Load Programs (PT.060)
None None
2 Code components (programs). Component Code (Programs) The Component Code (Programs) is the actual code or
programs that implement the Designed Performance Test
Programs.
3 Unit test components (programs). Tested Component Code (Programs) The Tested Component Code (Programs) is the actual code or
programs that implement the Designed Performance Test
Programs tested for errors and bugs.
4 Update the design documents as needed. Updated Designed Performance Test
Scripts and Programs, Performance Test
Data and Load Programs.
The Updated Designed Performance Test Data reflects any
corrections realized from creating the actual code (programs).
Back to Top
APPROACH
Testing Tool Programming Expertise
Some automated testing tools require C programs or advanced technical skills to manage the test transactions. Although the tools may generate some of the
programming automatically, they may still need some manual changes by skilled developers. The types of changes that need to be made may include:
establishing transaction checkpoints to record transaction timings
changing record primary keys to prevent clashes
setting transaction "think" times
setting delay times for the commencement of different test users
build test data parameter files
You should already know how your testing tool functions and what technical skills you need to build and make changes to the programs.
Non-Technical Resources Utilization
Some automated testing tools may permit the use of non-technical resources to build the test components. The generation of performance test character keystroke or
graphical event files may not require technical resources and the entry of the data according to the documented test plans can be done by business or functional
specialists, or even users. If an implementation project is proceeding in tandem with the performance test, the data entry required for the test components can be a useful
opportunity for users to gain experience on the new system.
Transaction Programs Testing
Like any other programs, the components of a performance test require unit testing to validate they are functioning correctly before introducing them to the performance
test. Test the new components by executing them against a database with appropriate test data. If possible, test the components against the performance test database
as it is being created for the project. If the performance test data base is not complete, test against a database with similar setup data loaded in it. Errors and bugs
discovered when building the component code mean less time spent coding corrections when testing the execution of the components in the Performance Test
Environment.
Back to Top
Back to Top
System Architect Oversee, review and approve the Performance Test Transaction Programs. Code the most complex components. 20
Tester Create Performance Test Transaction Programs. 80
Back to Top
PREREQUISITES
Prerequisite Usage
Performance Test Scripts and Programs Design (PT.050) These designs are used to build the actual test scripts and programs.
Performance Test Data and Load Programs Design (PT.060) These designs are used to build the actual load programs.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
project.
Back to Top
The Performance Test Transaction Programs are the tested program code that will be used to execute the Performance Test. If Performance Testing is part of a larger
implementation project, you may share the development environment with other technical work on the project. If that is the case, you will need to define procedures to
separate your code and testing from the other development work.
Back to Top
QUALITY CRITERIA
Back to Top
PT.080 - CONSTRUCT PERFORMANCE TEST ENVIRONMENT
AND DATABASE
In this task, you create the Performance Test Environment and populate the Performance Test Database up to the full desired volume of data in preparation for execution
of the Performance Test. If the test execution will occur in another location, such as a hardware vendor testing center, the environment and database will have to be
migrated to the test environment after it is created and validated.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Test Environment and Database - The Performance Test Environment and Database is an environment with a database fully populated with data for
Performance Testing purposes. It includes the application server, database and other software components required in the application.
Back to Top
TASK STEPS
Component
Description
1 Create a new database instance. Copy the database files from another project database into the
Performance Test Database (if applicable).
Initial Performance Test Database
Instance
None
2 Load the converted data into the test volume database. Test Database Converted Transaction
Data
None
3 Verify the converted data. Verified Converted Transaction Data None
4 Load the new generated test data into the test database. Test Database Generated Transaction
Data
None
5 Verify the new data. Verified Generated Data None
6 Verify the final test environment and application operation. Verified Test Database Operation
Against Application
None
7 Backup the database for migration to the Performance Test Environment. Backup Copy Of Database Operating
System Files
None
Back to Top
APPROACH
If the Performance Test Environment is not an exact replica of the production environment it is intended to simulate, the assumptions under which the test results will be
evaluated should be documented. Performance results are not necessarily linear, thus the method that will be used to extrapolate the results should be clearly
documented and explained.
If the test hardware is a subset of production, often the hardware vendor can assist in developing accurate extrapolation of results.
Back to Top
Back to Top
System Architect Participate in the preparation of the technical architecture for the environment to support performance testing. Review and
approve the Performance Test Environment and Database.
20
Database Administrator Participate in the preparation of the Information Architecture for the environment to support performance testing. 40
System Administrator Install application software. Provide support for the performance testing. 40
IS Support Staff Provide support for the creation of the Performance Testing environment. *
Back to Top
PREREQUISITES
Prerequisite Usage
Design (PT.060)
The Performance Test Data and Load Programs Design provides information about the strategy for constructing the
database and including manually entered data, data copied or imported from other databases, or data loaded
programmatically.
Performance Test Scripts and Programs
(PT.070)
You need the Performance Test Scripts and Programs if the Performance Testing Strategy requires the loading or
manufacture of data.
Back to Top
TEMPLATES AND TOOLS
PT-080_PERFORMANCE_TEST_ENVIRONMENT.DOC MS WORD
PT-110_PERFORMANCE_TEST_REPORT.DOC MS WORD
The Performance Test Report template contains a section for including information on the Performance Test Environment. Use the template that fits your project. You
may decide to use the Performance Test Environment template and provide more detail and use that report to complete the Performance Test Report with a summary of
the information from the Performance Test Environment Report or a reference to the report or you may elect to only use the Performance Test Report.
Tool Comments
project.
Back to Top
Load the Performance Test Database to the full planned volume. If you are unable to do so, update the data design to reflect the designed data volumes versus the
actual data loaded and specify any risks that may be faced. A shortfall in the amount of data you can load commonly results from technical difficulties and complexity in
building the database that could not be predicted when the estimates for resources and time were produced.
Back to Top
QUALITY CRITERIA
Back to Top
PT.090 - CONDUCT PERFORMANCE TEST DRESS REHEARSAL
In this task, the unit-tested Performance Test Scripts and Programs are tested using the defined Performance Testing Models and Scenarios. Monitoring, data collection
and the Performance Test Refresh Strategy should also be tested prior to the start of the formal test execution cycle.
ACTIVITY
Back to Top
WORK PRODUCT
Validated Performance Test and Environment - When this test is completed, the Performance Test should be ready to begin formal execution cycles. The
Performance Test Scripts and Programs should be validated. The Test Environment and Database should support the test requirements, and monitoring tools and data
collection mechanisms should be in place.
Back to Top
TASK STEPS
Component
Description
1 Load all data needed at the start of Performance Test Execution into the Performance Test Database,
including conversion data and any generated test data.
Loaded Performance Test
Database
None
2 Verify the data. Verified Converted and
Transactional Data
None
3 Take a backup of the test database to establish a recovery/refresh point. None
4 Verify the final test environment and application operation. Verified Test Database Operation
Against Application
None
5 Backup the database for migration to the Performance Test Environment (if necessary). None
6 Execute a dress rehearsal of some or all of the Performance Testing Models and Scenarios. None
7 Validate test results are appropriate with no artificially introduced constraints, and that data collection
mechanism are in place and working to collect test data results.
Validated Performance Test None
8 Refresh the environment or migrate to the Performance Test Environment. Environment Ready for Testing None
Back to Top
APPROACH
Effects of Automated Test Driver Machine
If you are executing a large-scale test using an automated testing tool that simulates multiple online user sessions, you need to verify that the server that is acting as the
driver for the automated tool is not a bottleneck to your test. The software that is automating the test should be running on a different server than your system under test
and the server that it runs on should have sufficient processing power so it does not limit the test transaction rates. If you have planned the capacity of the test driver
machine and the network that connects it carefully, you can ignore the effects of the test driver altogether. If, however, you have doubts about the effect of the test driver,
you may need to monitor it during the test execution to make sure it is not affecting the results. There are techniques you can employ to satisfy yourself that the effects of
the test driver machine can be ignored. For example, if you increment the user sessions, you should see little or no degradation of transaction response time. Executing
such tests on the driver machine is another reason why you may need to iterate through multiple test execution cycles.
Automated Load Testing Tool Program Design
It is at this point that flexibility and good design in the grouping of the test scripts into test programs pays dividends. Some automated testing tools require technical
programming to develop test scripts, and if the suite of test programs has been badly designed, you may need to reprogram to tune parameters such as transaction rates,
delay times, and "think" times.
Back to Top
Back to Top
System Architect Supervise and oversee the Performance Test Dress Rehearsal. 10
Database Administrator Provide support for the execution of the performance testing dress rehearsal. 20
Tester Executes performance test. 60
Systems Analyst Provide support for the test scenarios used in Performance Testing. 10
IS Support Staff Provide support for the creation of the Performance Testing Environment. *
System Administrator (SAD) - Provide support for the Performance Testing.
System Architect (SA) - Participate in the preparation of the technical architecture environment to support Performance Testing.
Back to Top
PREREQUISITES
Prerequisite Usage
Performance Test Scripts and Programs
(PT.070)
You need the unit-tested Performance Test Scripts and Programs to conduct the test dress rehearsal.
Performance Test Environment and Database
(PT.080)
The Performance Test Environment and Database is an environment fully populated with data for Performance
Testing purposes. It includes the application server, database and other software components required in the
application.
Design (PT.060)
The Performance Test Data provides information about the strategy for constructing the database and including
manually entered data, data copied or imported from other databases, or data loaded programmatically.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
PT.100 - EXECUTE PERFORMANCE TEST
Execute the Performance Testing components against the test environment and measure various performance metrics for individual transactions and system
components. Execute the test components for each transaction model within each test scenario and take the prescribed measurements of system performance. Repeat
for each model identified.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Test Results - The Performance Test Results record the test date and time, specific test or configuration parameters, as well as the individual
measurements made.
Back to Top
TASK STEPS
1 Prepare a Performance Test Log. Performance
Test Log
The Performance Test Log is used to record the time and date of each performance test execution. Specific
model and test scenarios executed should be recorded. Document any tuning or configuration changes made
since the last execution.
2 Conduct Test Execution Cycle. None None
3 Collect and Validate Results. None None
4 Analyze Results and implement
tuning changes.
None None
5 Refresh the Performance Test
Database and Environment.
Test Cycle The Test Cycle component Includes the following key items:
Test Cycle Objective - describes the objective of the test cycle
Test Cycle Parameters - describes the changes in parameter settings for the test cycle
General Observations - describes the general observations made during the test cycle execution
Specific Results and Measurements - describes the results and measurements during the performance test
execution of this cycle
6 Apply changes. None None
7 Establish and schedule the next
test cycle based on the results
analysis.
None None
Back to Top
APPROACH
Test Cycle Iterations
Performance test execution is by its nature an iterative process. Tuning and configuration changes may be necessary between iterations of a large-scale, multiple
transaction performance test. Collecting system measurements for a particular set of test parameters or a test configuration may require multiple cycles, before the
system and the test programs are properly tuned, to provide realistic or useful results.
Performance Test Log
Establishing a Performance Test Log is a good practice method to structure the gathering of test results. A team member should be assigned to record the details of each
test cycle, the measurements taken, and any changes made to the database or configuration and other unusual events or that occurred during the test.
System Stabilization
The more complex a performance test, the more time will be needed for all the transactions to begin processing and to reach a stable state where you can gather
meaningful performance metrics. Depending on how you have structured your test, there may be initial spurious variations in the system and transaction measurements
as particular transaction flows begin. Allow the various overall system performance and load metrics to stabilize before collecting detailed data.
Results and Review Scope Analysis
Analysis of the results is intended as a checkpoint for management to decide whether they wish to proceed with testing further configurations. The first configuration
tested may be the preferred configuration and once they have reviewed the preliminary results of the test, they may choose not to proceed with the other configurations.
You can present the results in the form of an Executive Summary by using a scaled down version of the full Performance Test Report (PT.110).
Test Execution Team
You need to assemble a test execution team. The precise makeup of the team depends on how the test is to be conducted; however, you need technical resources that
can address issues in any aspect of the infrastructure and technical analysts that understand how the transaction model is being implemented in the test environment. In
a testing project that is using an automated testing tool, the need for technical analysts that understand the tool is even more important. During the testing, the technical
analysts who created the test transaction may be required to tune the testing scripts and make slight program modifications. Database, network, and system
administrators need to be available to monitor the technical infrastructure and make recommendations. This is the case whether the test scenarios and transactions
models are batch only, or contain significant online processing.
Attention: The most successful performance tests are the ones in which detailed hands-on monitoring of the test environment is done while the test execution is in
process. The reason is that while it is possible to automate the collection of almost all of the measurements in the test, you inevitably miss dynamic effects or subtle
problems if you attempt to completely automate the testing. It is also easier to analyze performance problems as the test proceeds, rather than trying to recreate the test
conditions subsequently. Unfortunately this also means that resources need to be freed up to participate in the tests, either directly or by being on call to the test
execution team.
Back to Top
Back to Top
System Architect Oversee the execution of the performance test. Assist tester in the execution of the performance test by addressing issues and
question related to the technical architecture.
15
Tester Execute the performance test. 70
Database Administrator Provide support for the data base environment used in Performance Testing. 10
Network Engineer Monitor network activity during the test. 5
Data Architect (DAR) - Assist tester in the execution of the performance test by addressing issues and question related to the data architecture.
Systems Analyst (SAN) - Assist tester in the execution of the performance test by addressing issues and question related to the test scenarios.
Back to Top
PREREQUISITES
Prerequisite Usage
Performance Testing Models and Scenarios
(PT.040)
The test components for each Performance Test Scenario within each Performance Test Transaction Model are
executed to measure performance.
Performance Test Environment and Database
(PT.080)
The Performance Test Environment is the actual environment in which the performance test is performed.
Validated Performance Test and Environment Once the environment is fully configured, all of the hardware, software, monitoring tools, automated testing tools,
(PT.090) transaction programs, and test execution procedures should be in place and tested prior to the formal performance
test execution.
Back to Top
TEMPLATES AND TOOLS
PT-100_PERFORMANCE_TEST_RESULTS.DOC MS WORD
The Performance Test Report template contains a section for including information on the Performance Test Results. Use the template that fits your project. You may
decide to use the Performance Test Results template and provide more detail and use that report to complete the Performance Test Report with a summary of the
information from the Performance Test Results Report or a reference to the report or you may elect to only use the Performance Test Report.
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
PT.110 - CREATE PERFORMANCE TEST REPORT
In this task, you compile and produce the Performance Test Report.
Document the results and the description of Performance Testing in a format suitable for presentation to project managers, executive sponsors, and the project team.
ACTIVITY
Back to Top
WORK PRODUCT
Performance Test Report - The Performance Test Report details the approach used in the project, tests performed, results, conclusions, and recommendations.
Back to Top
TASK STEPS
1 Gather and
review outputs
from the
Performance
Test.
None None
2 Summarize the
original scope,
objectives, and
approach of the
Performance
Testing
subproject.
Project Scope,
Objectives and
Approach
The Project Scope, Objectives and Approach describes the scope of Performance Testing defined in the Performance
Testing Strategy (PT.030) . Identify any scope changes that may have occurred since the original scope was established.
The Objectives should list the high-level objectives for the project. The extent to which the report is able to fulfill the original
objectives for the project determines the relative success of the project.
The Approach should describe the methods and approaches used to accomplish the project, including any dependencies
between Performance Testing and other processes or subprojects taking place within the overall implementation project.
3 Summarize the
Performance
Testing strategy.
Performance
Testing Strategy
The Performance Testing Strategy describes the detailed approach used for Performance Testing and documents its
benefits. The description of the approach should include a high-level discussion of the work breakdown structure, the tasks
and work products, reasons for selection, and the benefits of the particular testing method adopted. It should describe the
unique concepts used in Performance Testing (in particular, Performance Test Models and Scenarios (PT.050). The
Performance Testing Strategy component should also discuss the strategy used for executing the tests, including
transactions execution methods (including whether an automated load testing tool was used), and specific techniques for
execution of the tests and refresh of the test environment after completion of a test cycle.
4 Summarize the
test scenarios,
transaction
models, and test
scripts.
Test Models and
Scenarios
The Test Models component describes the models of the system constructed for the performance tests. Generally these
models are approximations of the complex transaction environment of a real production system, so it is important to
document how the real production system was represented in the tests. It should include:
test scenarios
transaction models
test scripts
5 Describe how the
Performance
Test Database
was constructed
and populated.
Test Database The Test Database component describes the method for creating the Performance Test Database. It should describe the
strategy used for the construction of the database with reference to reuse of existing project data and data load programs,
and the volumes of data loaded for the key business objects accessed by the performance test transactions.
6 Summarize the
test system
configuration
System
Architecture and
Configuration
The System Architecture and Configuration component describes the system architecture and configurations implemented
for the performance test. It includes detailed specifications for the technical infrastructure of the test such as hardware,
operating system and network components, as well as the application configuration. A diagram of the performance test
including
hardware,
network,
database, and
applications.
environment technical architecture should be included.
7 Document the
test assumptions
in detail.
Assumptions The Assumptions component lists all of the key assumptions made during performance testing into a single integrated list.
The assumptions will pertain to different aspects of the test (business, functional, and technical) so you may wish to create a
separate section for each category of assumptions. An example of the categories you could create is:
business definition
application functionality and configuration
technical architecture
test execution
8 Document the
test risks in
detail.
Risks The Risks component summarizes the major risks of Performance Testing, either arising from the assumptions made, or
from some inherent source of risk in the implementation.
9 Analyze the
performance test
measurements
and results.
None None
10 Document the
performance test
measurements
and results in
detail.
Test Results The Test Results component documents the results obtained from the performance test execution. If you have collected a
great volume of detailed results from numerous performance test cycles, you need to find the best method of presenting the
results to the project team and project and business managers, without losing the impact of your results in volumes of
complex detailed data. If you wish to include the detailed data, you could include it in an appendix to the report. One way to
structure the component is to create separate subsections for the following categories:
Summary
Performance Measurements
Issues Identified and Resolution
Patches Applied
11 Formulate
conclusions and
recommendations
from the test
results.
Conclusions and
Recommendations
The Conclusions and Recommendations component describes the conclusions you have drawn from the results of the tests
and the recommendations based on the results and the conclusions. It is convenient to present these discussions in
separate sections:
Conclusions
Recommendations
This is the most important component of the work product and should address the original performance issues or concerns
that the performance test was intended to answer. The recommendations you document may include the following:
specific recommendations on technical infrastructure and application configuration
identification of areas that may constitute future risk and techniques that could be used to mitigate the risk
follow up on testing or performance monitoring projects or activities
escalation of internal project issues
escalation of issues that are relevant for vendor support, such as performance bugs
12 Create the report
executive
summary.
Executive
Summary
The Executive Summary summarizes Performance Testing for executive consumption. It should introduce the performance
testing effort and then describe its scope, objectives, results, and conclusions.
13 Review the
Performance
Test Report with
management,
business
analysts, and
technical
analysts.
None None
14 Secure
acceptance for
the Performance
Test Report and
the test project.
None None
Back to Top
APPROACH
Task Effort Depends on the Test Scope and Objectives
The effort that you need to put into this task depends on the nature of the performance test you have conducted and whether it is of strategic importance to the overall
implementation project and the business. If Performance Testing has been primarily focused on final validation and tuning of the business system, then the project
manager may not require you to create a separate and formal Performance Test Report. The results may be documented within other project Testing (TE) documents
that summarize and discuss all of the testing efforts on the project. At the other extreme, Performance Testing may have been organized as a separate subproject
providing critical capacity planning or architecture information that senior management will use to make business or project strategic decisions. In this situation, you may
need to create a formal report that is presentable to senior management.
Presentation of Results to Project Management
Distribute the final test report to the project sponsor and relevant senior project managers. Organize a meeting to present the results, conclusions, and recommendations
arising from the results of the test. Present answers to the specific performance concerns posed by the users and identify any project shortcomings. The presentation of
the results is an important element of the meeting, but also try to indicate how the results are of direct use to the business. Present suggestions for incorporating the test
methodology and reusable test programs into future work that the information systems administrators may perform. Encourage the future use of the results for
comparison against the production measured performance.
Back to Top
Back to Top
System Architect Review and approve Performance Testing Results. 30
Tester Compile test results and prepare report. 70
Back to Top
PREREQUISITES
Prerequisite Usage
Performance Test Results
(PT.100)
Analyze the results of the performance test and document your findings. You may also need to use work products from other
Performance Testing tasks to create the Performance Test Report.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Tailor the Performance Test Report to the intended audience and reflect the scope of the Performance Testing for your project in the style of work product you create.
Use the Performance Test Report as follows:
to document the work you have performed in Performance Testing
to communicate the results and conclusions to project managers and sponsors
This work product should address the following:
a summary of previous work products produced for Performance Testing
a summary of the analysis and design work products
detailed test results
how the test results answers posed in the original Performance Testing Strategy (PT.030)
specific recommendations
Distribute the Performance Test Report to the following:
project manager of the main project
IS manager and other senior business managers
IS operations staff and administrators
other process or subproject leaders who have an interest in the results of the performance tests
Back to Top
QUALITY CRITERIA
Is the Performance Test Report comprehensive?
Does the report discuss how the performance test was designed?
Does the Performance Test Report describe and interpret the test results in a method understandable to non-technical business people?
Are the assumptions and risks clearly documented to qualify the results and conclusions?
Are the original performance concerns and project objectives addressed in the Performance Test Report?
Are there actionable recommendations associated with each finding that requires one?
Back to Top
PT.120 - CONDUCT PRODUCTION PERFORMANCE
MANAGEMENT
This core task implements the Performance Management activities established during the project development to the production environment in conjunction with the
implementation of the application. Monitoring, metric collection and review is an ongoing process. If issues or problems are identified, they are tracked, assigned, worked
and resolved using the approach and strategy established in the Performance Management process. Optionally, the Performance Test Models and Scenarios may be
used to regression test any changes to infrastructure or application.
ACTIVITY
E.ACT.MPSP Manage Production System Performance
Back to Top
WORK PRODUCT
Managed Production Environment - Properly implemented, Performance Management is an ongoing process that continues after production implementation. As part of
that process, regular reporting of Performance Management Metrics should be distributed and a Performance Management Issue Log should be maintained and any
patching requirements related to performance should be provided to the change management review organization.
Back to Top
TASK STEPS
Component
Description
1 Review Performance Management Requirements and Strategy (PT.020). Validate that selected monitoring and metrics are in
place on production system.
Performance
Management
Monitoring
None
2 Review monitoring output and prepare performance reports for management, including reports of performance against the
performance metrics established in the PT.020 such as measures of throughput or response time.
Performance
Management
Reporting
None
3 Monitor performance issue list, track progress of identified issues or problems and follow up as required. Performance
Management Issue
Log
None
4 Monitor vendor web sites for recommended performance patches and application upgrades. Review, test and apply if
applicable.
Inputs to Patch and
Upgrade Plans
None
Back to Top
APPROACH
Production Performance Management is the extension of Performance Management techniques and approaches identified and implemented prior to production
implementation. Performance metrics should be regularly collected and reviewed for all components. Although the basic strategy may be in place, variations in both
requirements and performance are likely to be encountered. Particular scrutiny of performance metrics should occur any time a change is introduced to the system such
as a patch, new interface or module, a change in hardware, etc.) Proactive evaluation of variations to the baseline will help to identify potential performance issues before
the user community notices the impact.
OUM methodology assumes that the preliminary work to identify transactions and associated metrics, determine how the metrics will be collected and installation of any
tools, scripts or collection mechanisms to track and report the metrics was done as result of the decisions made during completion of Define Performance Management
and Requirements Strategy (PT.020). If for some reason these tasks did not occur during implementation, review the approach associated with the PT.020 task to
determine what task steps must be completed in order to establish the production performance management strategy.
If additional tools must be installed, or if the application has not been instrumented to capture the required throughput or response time statistics, remember that
monitoring tools can introduce overhead on a production system. Throughput related measurements can be gathered from various Oracle internal structures such as
v$sesstat,v$filestat, v$session fixed tables, the aud$ table or by using operating system accounting tools, commands similar to the UNIX ps command, and several
vendor specific tools. Response time measurements can be obtained from client-side transaction logs, if such logging has been implemented. The impact of additional
monitoring should always be tested prior to implementation on a production system, particularly one that is fully loaded or already experiencing performance issues.
Back to Top
Back to Top
System Administrator Provide support for Performance Management activities such as running standard application reports on
transaction performance, applying and testing patches and upgrades.
20
Database Administrator Monitor database and application, resolve performance issues, report DB and application metrics. 80
IS Operations Staff Monitor hardware and system software configuration, resolve performance issues, report system metrics. *
IS Support Staff Log performance issues, track resolution and notify users. *
Back to Top
PREREQUISITES
Prerequisite Usage
Strategy (PT.020)
The Performance Management Requirement and Strategy establish the roles and responsibilities for Performance
Management, the key business transactions and the monitoring and performance metrics that should be regularly
reviewed and reported.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Back to Top
QUALITY CRITERIA
Do the performance statistics available reflect the performance metrics related to the critical business transactions identified by the users?
Are the performance metrics in line with the user expectations?
Is regular reporting provided to the key ambassador users for review?
Are established SLAs being met?
Is the problem and issue resolution process effective in tracking the progress of needed corrections or enhancements?
Have future performance risks been identified?
Is a regular patch management process in place?
Back to Top
[TA] TECHNICAL ARCHITECTURE
The goal of the Technical Architecture process is to design an information systems architecture to support and realize the business vision. The process takes the
business and information systems requirements and develops a blueprint for deploying and configuring:
Oracle Products and EPM Solutions
Oracle, third party and custom applications
supporting application and web server environment integration and data distribution mechanisms between applications, servers, and sites hardware to support
computing requirements, including both servers and client desktop platforms, network and communication infrastructure
software, tools and processes to monitor and manage the technical architecture environment
The tasks in the Technical Architecture process identify and document the requirements related to the establishment and maintenance of the application and technical
infrastructure environment for the project. Processes and procedures required to implement, monitor and maintain the various environments are established and tested.
The Technical Architecture process specifies elements of the technical infrastructure of the development project. It assumes that the business already has an information
system strategy and that these elements fit within that strategy. There must be a sharp focus on the technical infrastructure in a OUM-based solution deployment project.
By exposing its business systems to the Web, a business is exposing itself to unpredictable load levels and, sometimes, a hostile security environment. Therefore, the
importance of the technical infrastructure cannot be overstated.
It is highly advisable to perform a benchmarking exercise as early as possible to make sure the capacity, workload, failover, and security requirements of the system are
fulfilled. Leaving this until later in the development significantly increases the risk level of the development. The process focuses on specifying the elements of the
infrastructure during Elaboration, and on iteratively refining and constructing those elements during Construction.
The Technical Architecture process is a critical project element, particularly for systems that have complex requirements. Examples of complex requirements include
systems that will be deployed as public facing on the Internet, systems with high transaction volumes, systems with aggressive performance targets, systems with high
availability requirements, or systems servicing user communities that are distributed geographically over large distances or a variety of time zones. If the project is
implementing using software or technology that is not commonly in use or has been very recently released, the level of complexity is also more significant due to
increased potential of encountering issues during the Implementation process.
The requirements that drive Technical Architecture also impact Performance Management (PT) and the two processes are closely related.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Depending on your project (e.g., large, complex, etc.), the project manager may designate a Technical Architecture team leader and/or team leaders for various other
reasons that the project manager deems necessary. If the project manager designates team leaders, they are responsible for leading their team and reviewing the work
products produced by their team. The team leader plans, directs, and monitors the day-to-day work of the team. The team leader assigns work packages to the team
members and makes sure they understand the requirements. The team leader is responsible for building team cohesion, motivating the teams, and providing assistance
and encouragement to the team members. Each team leader performs the final quality control and quality assurance for the team by reviewing all work products. The
team leader also signs off on team work completion and quality. Work that is not up to quality standards is returned. Team leaders review work products from other teams
Project Scale
The approach to the Technical Architecture may vary depending on the scale and scope of the project. If the Technical Architecture is part of a small, localized
implementation of packaged software or an upgrade or enhancement to an existing application already in place, the technical and application architecture required to
support the project may already be in place, or reference architectures may exist that simplify the work involved.
On the opposite end of the spectrum, a large, complex implementation project may need a semi-autonomous architecture subproject to provide effective focus and
control.
In some cases, even though the application implementation is relatively small and references architectures are available, a significant portion of the architecture
components may be unfamiliar to the client. An example would the first implementation of an application using RAC or GRID within the enterprise or the first
implementation of a Linux based system in an environment that was previously entirely mainframe. A technical architecture paradigm shift implies a significant change in
existing process and procedure, and requires additional Technical Architecture effort.
Project Scope
There are two broad categories of architecture projects that differ greatly in scope. An enterprise level architecture will encompass all, or a major portion of, the important
corporate information systems. This type of project may define the strategic direction for information systems and encompass multiple data centers, sites, or countries in
a series of phases and often includes a technology stack upgrade or strategic change of hardware or software. An enterprise-level architecture typically must
accommodate both new applications and existing legacy applications. This type of project covers the breadth of the enterprise and helps to set strategic IS Direction, but
it may not get into detailed design of every component of every application or system.
A site-level architecture project is narrower in scope than the enterprise-level architecture, but it may go into greater detail for the architecture components within scope. It
deals with a single installation of key applications, or a localized set of system. While architectural tasks are still required, typically they implement following standards
and strategies already been defined at the enterprise level.
Areas to Consider
A coherent and well designed information systems architecture is critical for the success of any implementation project. Typical issues to be considered include:
the best deployment strategy for the applications across servers, data centers, and business organizations
the high level configurations required to meet the various line of business requirements
interface requirements between applications and the most appropriate integration architecture to support them
selection, sizing and deployment of the hardware and network infrastructure
management tools, software and procedures that are needed to keep the system operating as intended
A project that involves a replacement of a significant portion of legacy systems requires an architecture comprehensive enough to define the framework for the information
systems vision and strategy of the the corporation.
Components of the Technical Architecture Process
Technical Architecture covers two major areas: Application Architecture, the deployment and configuration of applications across servers, hardware platforms and data
centers, and Technical Architecture, the deployment, configuration and management of the hardware platform and network infrastructure.
The Application Architecture portion of the process includes these key areas:
Application Deployment and Integration
Information Security and Control
Reporting and Information Access
Application Deployment and Integration - Defining the applications deployment across different data centers and servers, together with the supporting databases is an
important activity. The information flows between the deployed applications reveal the application integration points and interfaces that may be needed.
Information Security and Control - Information security and control is an increasingly critical topic that is often underestimated, particularly when deploying packaged
applications. Flawed assumptions may exist, such as the idea that all necessary security is "built in", or that an application that is not publicly facing on the Internet does
not have to be concerned about information security and controls. The security landscape is heavily influenced by government legislation, particularly in the areas of
privacy and compliance, and the standard application features can only address a subset of the overall information security requirements.
Reporting and Information Access - Reporting and information access addresses the different types of reporting and information needs for the business, such as the
operational reporting strategy, decision support strategy , ad hoc reporting, business intelligence, and analytical reporting. The strategy needs to take into account the
physical data distribution in the business and the databases and applications within which the data is stored.
Application Architecture - Application architecture addresses the specific database and infrastructure configurations required to support the applications business
requirements. Application requirements may have a direct effect on your application and technical architecture, influencing such items as application deployment, and
database configurations such as data partitioning or language support.
The Technical Architecture portion of the process includes the following key areas:
Server Configuration
Processing Configurations
Physical Database Design and use of Database Features
Platforms and Networks
System Availability Strategy
System Management Procedures and Tools
Integration Architecture Requirements
Server Configuration - This area covers the design of the optimal configuration of the company wide network of database and application servers. This also includes the
review and definition of scaling and fault tolerance.
Processing Configurations - This area covers the various N-tier configurations for the separation of presentation, business logic, and data management processing
within your applications. You have direct control over this for in-house developed applications, but packaged applications may require that you make choices regarding
how you partition your processing.
Physical Database Design and Use of Database Features - This area includes the detailed layout of a database across file systems and disks and the use of the
advanced database features such as multi-threaded server
Platforms and Networks - Platforms and networks constitute the technical infrastructure of the new system and must have the capacity to meet the technical
requirements, performance requirements, transaction and user volumes anticipated at cutover and for some predetermined future period of time.
System Availability Strategy - This is the strategy defined to address the different types of planned and unplanned outages. Many different detailed techniques and tools
exist to provide the system availability the business requires and to guard against the loss of critical data, but there are tradeoffs to consider when selecting the
mechanisms and systems to adopt.
Systems Management Procedures and Tools - There are a wide variety of software tools that allow for monitoring and managing of the software, server hardware, and
network aspects of the architecture. This strategy considers the selection of the appropriate tools from both Oracle and third party vendors and establishes the processes
and procedures necessary to use the tools effectively.
Integration Architecture Requirements - Integration architecture defines the subsystems used to pass data between applications while maintaining the integrity of data
and supporting delivery. Significant advances in technology have increased the capability of integration subsystems and many clients can benefit from the introduction of
more advanced techniques in conjunction with the replacement of their legacy systems.
Division of Responsibilities and "Out of Scope" Issues
Most projects delegate at least some portion of the Technical Architecture work to client staff or third parties. A common example is network architecture and
administration. Depending on how scope of responsibilities have been divided, it is possible that a significant portion of the Technical Architecture task may be the
responsibility of the client or be assigned to a third party to perform. Regardless of who has the responsibility, the substantive work described in the TA series of core
tasks must still be performed in order to establish a sound technical foundation for the implementation.
In projects that delegate the bulk of responsibility for technical architecture to the client, a Technical Architecture Workshop is the mechanism used to ensure the client is
aware of the expectations and requirements associated with Technical Architecture in the Oracle Unified Method as well as to share best practice approaches and
experiences of other clients with them. The Workshop should familiarize the client with the basic concepts, activities and tasks that make up the Technical Architecture
process, the reference architectures most appropriate to the specific project implementation requirements, the processes and procedures required to effective manage
and maintain the technical infrastructure, and the establishment of metrics and monitoring related to technical architecture and Service level Agreements (SLA). The
Workshop also provides a mechanism to gather information on existing architecture standards or requirements that can be used to develop the Technical Architecture
Requirements and Strategy document (TA.020 ).
Back to Top
Inception Phase
TA.004 Perform Technical Architecture Impact Analysis Technical Architecture Impact Analysis
TA.010 Conduct Technical Architecture Workshop Technical Architecture Workshop Results
Elaboration Phase
TA.006 Define Technical Prototype Subprojects Technical Prototype Approach
TA.020 Define Technical Architecture Requirements and Strategy Technical Architecture Requirements and Strategy
TA.030 Define Integration Requirements and Strategy Integration Architecture Strategy
TA.040 Define Reporting and Information Access Strategy Reporting and Information Access Strategy
TA.050 Define Disaster Recovery Strategy Disaster Recovery Strategy
TA.060 Define System Operations and Management Strategy System Operations and Management Strategy
TA.070 Define Initial Architecture and Application Mapping Initial Architecture and Application Mapping
TA.080 Define Backup and Recovery Strategy Backup and Recovery Strategy
TA.090 Develop Security and Control Strategy Security and Control Strategy
Construction Phase
TA.100 Define System Management Procedures System Management Guide
TA.110 Define Operational Testing Plan Operational Testing Plan
TA.120 Conduct Operational Testing Operational Test Results
TA.130 Conduct Backup and Recovery Test Backup and Recovery Test Results
TA.140 Conduct Disaster Recovery Test Disaster Recovery Test Results
TA.150 Define Final Platform and Network Architecture Final Platform and Network Architecture
TA.160 Define System Capacity Plan System Capacity Plan
Back to Top
OBJECTIVES
The objectives of the Technical Architecture process are:
Define the hardware, network and software components required for to support the application being implemented.
Provide an architecture that is consistent with the business strategic direction.
Provide an infrastructure that supports the system at deployment and will be extensible and scalable to support the customer's future requirements.
Provide an architecture that supports the interfaces required to other systems.
Define and implement the management processes and procedures required to operate the technical architecture components.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
Specialist
BA Business Analyst Participate in the Technical Architecture Workshop. Provide business requirements that could impact technical architecture. Review
Architecture Requirements and Strategy in terms of satisfaction of business requirements. Assist in the process of requirement analysis
and review them.
DBA Database
Administrator
Perform the activities of the operational test scenario, and gather and report results. Perform the activities of the backup and recovery test
scenario, and gather and report results. Perform the activities of the disaster recovery test scenario, and gather and report results. Provide
information relating to database processing and disk requirements.
DV Developer Participate in the Technical Architecture Workshop. Participate in the process of requirement analysis.
NE Network Engineer Provide the network requirements for the Architecture Requirements and Strategy.
SAN System Analyst Participate in the Technical Architecture Workshop. Document Technical Architecture Requirements. Analyze the business requirements.
Identify and document the Reporting and Information Access Strategy. Provide and assist in analyzing requirement related specifically to
the business requirements and applications. Assist the system architect in providing information about the non-functional business
requirements. Provide information regarding the structure of the new system. Provide information regarding the capacity planning
scenarios.
SA System Architect Lead the Technical Architecture Workshop. Familiarize the client with the goals and objectives of the workshop, assist in gathering
technical architecture requirements. Obtain client participation, set initial interview schedule, and get input from key users. Analyze, define
and document Architecture Requirements and Strategy. Responsible for obtaining input on client infrastructure, existing standards,
policies and procedures. Review the Architecture Requirements and Strategy. Assist with gaining client approval. Identify and document
the Integration Architecture Strategy. Prepare the functional Integration requirements. Obtain and document the special considerations
and technical assumptions. Review the Integration Architecture Strategy. Analyze the operational requirements. Produce the Disaster
Recovery Strategy. Determine the operational requirements. Produce the System Operations and Management Strategy work product.
Review the System Operations and Management Strategy and perform any negotiation required. Review architecture requirements and
strategy and validate conceptual architecture. Develop the initial technical architecture. Conduct design review sessions and prepare the
Initial Architecture and Application Mapping. Investigate the organization's backup strategy. Prepare the Backup and Recovery Strategy.
Interview technical personnel to find the currently implemented security and control strategy. Interview the users to identify any special
requirements. Interview the development team to ascertain more detail on the structure of the application. Prepare the Security and
Control Strategy. Identify and document the system management procedures. Ensure that all relevant areas have been addressed within
the operational scenario to be tested. Ensure that all necessary resources are available for operational testing. Ensure that all relevant
areas have been addressed within the backup and recovery scenario to be tested. Ensure that all necessary resources are available for
Backup and Recovery testing. Ensure that all relevant areas have been addressed within the disaster recovery scenario to be tested.
Ensure that all necessary resources are available for disaster recovery testing. Review prior architectural work and identify any technical
requirement updates required. Prepare the Final Platform and Network Architecture. Review previous capacity planning, architecture and
volume documents. Work with hardware vendor to perform or validate capacity planning strategy. Prepare System Capacity Plan.
Client (User)
KEY Ambassador User Participate in the Technical Architecture Workshop. Provide business expectations and requirements that may influence the Technical
Architecture. Provide the business requirements related to Disaster Recovery. Review and approve the Disaster Recovery Strategy.
CDA Client Data
Administrator
Participate in the Technical Architecture Workshop. Identify existing procedures, standards, SLAs. Participate in the process of
CPM Client Project
Manager
Coordinate the interview schedule for the workshop, assists in gathering technical requirements. Participate in the Technical Architecture
Workshop. Facilitate review by client IS staff. Approve Architecture Requirements and Strategy.
CPS Client Project Sponsor Review and approve the Disaster Recovery Strategy.
AU Internal Auditor Provide information about internal audit requirements.
ISM IS Manager Review the Final Platform and Network Architecture and provide comments and approval.
OS IS Operations Staff Participate in the Technical Architecture Workshop. Identify existing process, procedures, standards, SLAs. Participate in the process of
requirement analysis. Provide information on existing standards, processes and procedures related to Disaster Recovery. Review and
approve the Disaster Recovery Strategy. Provide and review the System Operations and Management Strategy. Indicate any aspects of
the System Operations and Management Strategy, which are unacceptable. Negotiate acceptable service levels. Answer queries and
provide information regarding the current user backup and recovery strategy. Review test results for completeness and success against
measurable success criteria. Review test results for completeness and success against measurable success criteria. Review test results
for completeness and success against measurable success criteria. Provide information regarding the current and future software and
hardware and review options for the new system.
SS IS Support Staff Participate in the Technical Architecture Workshop. Participate in the process of requirement analysis. Provide existing guidelines,
standards and technical architecture configuration. Review the Architecture Requirements and Strategy and provide feedback. Provide
information on the current integration strategy, special considerations and technical assumptions, existing systems and current enterprise
standards. Provide information on existing standards, processes and procedures related to Disaster Recovery. Review and approve the
Disaster Recovery Strategy. Answer queries and provide information regarding the current and proposed options for the new system.
Answer queries and provide information regarding operational requirements. Answer queries and provide information regarding the
current security and control strategy. Provide information on existing processes and tools, standards, policies and procedures. Review
and approve the procedure document and checklists. Review test results for completeness and success against measurable success
criteria. Review test results for completeness and success against measurable success criteria. Review test results for completeness and
success against measurable success criteria. Provide information regarding the current and future software and hardware and review
options for the new system.
NA Network Administrator Provide information relating to network configuration and capacity.
Back to Top
recognition of the importance of architecture as a key determinant of the success of the implemented applications and solution
alignment of the architecture design with the corporate business and information system vision and strategic direction
realistic evaluation of the capabilities and limitations of the technology to be used
experienced application and technical architects
balanced input of business and technical requirements driving the architecture design
knowledge and interaction with other processes and activities within or outside of the project that could impact the final production application or technical
architecture or impose architectural requirements
Balanced input of business and technical requirements driving the architecture is an especially important success factor. The Technical Architecture process should not
be considered to be a purely "technical exercise". This approach can may result in the business requirements becoming subservient to the technology. The Technical
Architecture process should use the business requirements and functional mappings as the drivers for the optimal configuration of the applications being implemented,
for the selection of hardware and network infrastructure supporting the application processing and for the tools, processes and procedures needed to manage the
complete system.
Back to Top
TA.004 - PERFORM TECHNICAL ARCHITECTURE IMPACT
ANALYSIS
In this task, you analyze and assess the application and technical architectural impact of upgrading to a new software release.
ACTIVITY
Back to Top
WORK PRODUCT
Technical Architecture Impact Analysis - The Technical Architecture Impact Analysis identifies all the changes required to the existing information systems architecture
to fit the requirements of the new software release. This analysis provides a clear assessment of the impact of additional new release changes on the overall system
architecture.
Back to Top
TASK STEPS
1 Review the
architecture of the
current software
version.
None The existing system architecture documents should be reviewed in order to fully understand the current system. This should
include the review of the initial implementation documents along with any intermediate changes to the overall information
system architecture.
2 Review the
architecture
new release.
None Review the new release features most likely to impact the overall system architecture from both the applications as well as
technical aspects. Any existing product documentation associated with the architectural requirements should be reviewed.
Any new mandatory or optional product feature that is part of the new release needs to be analyzed in terms of its impact
on the overall architecture.
3 Study and evaluate the
impact of new release
changes on the
architecture.
Architecture
Impact
Based on the preceding analysis of the existing information system architecture on the current application as well as new
release Architecture features, this component provides a classification of all changes with varying degrees of their impacts
is listed.
4 Prepare an approach
and strategy for the
architecture changes.
Architecture
Changes
Approach
and Strategy
In addition to the identification of the Architecture Impact, the Architecture Changes Approach and Strategy defines the
overall direction of the information system architecture solution addressing the impacts as assessed.
Back to Top
APPROACH
Architecture impact analysis intends to identify and quantify the impact of the new release changes to be accommodated to the existing information systems architecture.
This task is optional. In the case of an upgrade between two releases of software where there is little or no change in features or technology, there may not be a need for
any architecture migration work. Therefore, this task could be excluded from the scope of the project. On the other hand, if the upgrade is between two major software
releases and significant changes may have occurred in the enabling technology of the applications, their database architecture, and functionality, then this task becomes
mandatory, and a significant amount of work is necessary to prepare the information systems architecture for operation under the new release.
To assess whether or not an upgrade to a new release of software will affect the information systems technical architecture, the project team needs to review the current
technical architecture design as documented in the initial implementation. These would include:
Current Information Systems Architecture
Overall System Availability Plan
Database Architecture
Hardware and Network Architecture
System Capacity Plan
#TOP #TOP
Once the impact of the new software architectural changes is quantified, the approaches and strategies for incorporating these technical changes into the existing overall
architecture design are developed. The scope of the technical and architectural changes depends on the existing and target versions of the software. As a general
principle, the wider the disparity between software release numbers, the greater the technical changes involved.
The software impact analysis identifies all of the new release changes that affect application and technical architecture and assesses the impact of each change. Any
particular change between the software releases may result in one or more architecture impacts, and each impacted area will be classified. For example, a change in the
distributed processing architecture of applications from graphical client-server to web-deployed could lead to impacts in hardware architecture, system capacity planning,
systems management, IS training, and so on. In addition, to indicate the direct impact of the changes in the new software release, any work product should document
indirect impacts on the existing information systems architecture. An upgrade in applications software may trigger changes in other areas of the information systems
architecture, especially if the application software is integrated with a number of other applications and systems.
PeopleSoft Architecture Impact Analysis
In terms of PeopleSoft architecture impact analysis, the assessment would include the impact of third-party applications that are upgraded as part of the overall
PeopleTools upgrade. The assessment would evaluate the platform certification requirements from any target release perspective along with specific inputs on supported
operating systems and RDBMS versions.
Back to Top
System Architect Establish the future software architecture of the new system after migration. Meet with business analysts to identify the impact
of business process changes on the architecture. Translate the changes into a revised software and data architecture.
Coordinate and lead the development of an integrated software and technical conceptual architecture for the newly migrated
systems. The project team updates these detailed technical design efforts (for example, interfaces and custom components),
to provide compatibility with the overall future software architecture. Provide input to the architecture process about technical
designs for custom modules and functionality.
80
Database Administrator Provide input into logical database design and technical architecture. Review the database management and maintenance
procedures, database disk capacity requirements, and database level performance risks as appropriate for the scope of the
migration changes.
10
System Administrator Provide input into technical architecture planning and design. Review the design of the overall systems management and
maintenance procedures, hardware capacity requirements, and system performance risks as appropriate for the scope of the
migration changes.
10
Business Analyst Provide input about the key processes, mapping decisions, and functionality that will be used in the new release, gather and
communicate current and future business volumes, and review changes in the architecture.
minimal
Back to Top
PREREQUISITES
Prerequisite Usage
MoSCoW List (RD.045)
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Technical Architecture Impact Analysis is used in the following ways:
to identify and highlight the impact of the upgrade project on the existing information systems architecture
to enumerate strategies for dealing with these changes
Distribute the Technical Architecture Impact Analysis as follows:
to all technical team members
Back to Top
QUALITY CRITERIA
Back to Top
TA.006 - DEFINE TECHNICAL PROTOTYPE SUBPROJECTS
In this task, you identify any areas of the target software release architecture that are sufficiently new, complex or risk-prone and therefore, may require separate
investigation by prototyping.
ACTIVITY
Back to Top
WORK PRODUCT
Technical Prototype Approach - The Technical Prototype Approach describes the scope, objectives and approach that will be followed to deliver each prototype.
Note: This work product is not intended to be as detailed or comprehensive as the Project Management Plan for the parent migration project itself. It should justify the
creation of a separate subproject to prototype a particular aspect of the future technical environment, and give a brief description of the work needed to assess the
unknown area. If the architecture team has identified multiple areas that require prototyping in subprojects, a single physical version of this work product can describe all
prototyping subprojects in an integrated fashion.
Back to Top
TASK STEPS
1 Review the following work products:
Technical Architecture Impact
Analysis (TA.004)
Software Release Changes
Summary (RD.134)
None
2 Identify any areas of the target software
release architecture that are considered
sufficiently new, complex or risk-prone.
Potential
Areas to
Prototype
This component provides a list of any areas that may require separate investigation by prototyping.
3 Create an approach for each area to
prototype.
Approach Create an approach for each area to prototype. Include the following sections:
Introduction - This should introduce the architecture subproject and should identify the circumstances in
the architecture project that led to the identification of the need for an architecture subproject. It should
describe the sources that contributed to the definition of the prototype subproject.
Scope - This should describe the scope of the architecture subproject in as much detail as possible. It
should include a description of the key milestones and the assumptions underlying the subproject.
Objectives - This should describe what the subproject is attempting to achieve and how it will address
the problem statement. It should also identify the critical success factors for the architecture subproject.
Approach - This should describe the method to be used for the prototyping of the subsystem or
architectural component, the project deliverables, subproject application and technical environment, and
the organization of the subproject.
Back to Top
APPROACH
Prototyping work is not required for all upgrade projects. For example, a simple upgrade to a new application maintenance release or an upgrade without significant
change in the information systems architecture would not necessitate prototyping. Conversely, where there is significant change in the architecture, the IS organization
and migration project team may wish to test the characteristics of the future technical environment before beginning the migration. An example of this situation would be
the migration from a character mode application to a web deployed application, or migration through one or more major application releases with changes in database
architecture and application data partitioning.
Back to Top
System Architect Lead workshop sessions in order to qualify items to be considered for prototyping. 70
System Analyst Participate in the workshop. Provide system-level considerations that could necessitate the need to prototype. 15
Business Analyst Participate in the workshop. Provide business-level considerations that could necessitate the need to prototype. 15
Client Project Manager Coordinate the schedule for the workshop. Assist in gathering technical requirements and participate in the workshop. *
Back to Top
PREREQUISITES
Prerequisite Usage
Technical Architecture Impact
Analysis (TA.004)
Use the Technical Architecture Impact Analysis to help identify any areas of the target application release architecture that are
sufficiently new, complex, or risk-prone.
Future Process Model (RD.011) Use the Future Process Model to identify future process flows that are sufficiently new, complex, or risk-prone.
Software Release Changes
Summary (RD.134)
Use the Software Release Changes Summary to identify new functionality or technical features of the target release that are
sufficiently new, complex, or risk-prone.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Technical Prototype Approach is used in the following ways:
to identify any areas of the target software release architecture that are sufficiently new, complex or risk-prone to require separate investigation by prototyping
Distribute the Technical Prototype Approach as follows:
Back to Top
QUALITY CRITERIA
Back to Top
TA.010 - CONDUCT TECHNICAL ARCHITECTURE WORKSHOP
The Technical Architecture Workshop is the initial task in the Technical Architecture process. The workshop is intended to familiarize the client with the reference
architectures already established, options and features available and to gather high level architecture, availability, integration, reporting, backup and recovery, security
and disaster recovery requirements. The workshop also provides a mechanism to gather information on architecture in place and any strategic initiatives or enterprise
standards that the project architecture must fit within.
The Technical Architecture Workshop is a core activity and is particularly important for projects that have contractually delegated the bulk of responsibility for technical
architecture to the client or third party provider. If that is the case, the workshop should be conducted as early in the project lifecycle as possible to make the client aware
of the expectations and requirements associated with their responsibility as well as to share best practice approaches and experiences of other clients.
ACTIVITY
Back to Top
WORK PRODUCT
Technical Architecture Workshop Results - The Technical Architecture Workshop Results includes a presentation summarizing the information gathered during the
workshop. This information should be input for the Define Architecture Requirements and Strategy (TA.020) task.
Back to Top
TASK STEPS
1 Schedule
workshop and
identify
participants.
Workshop
Schedule,
Participant List
The project manager should familiarize the client with the objectives of the workshop and identify the participants. It is
critical the key functional users participate in the interview cycle and that the workshop is not a purely "technical" exercise.
Participants should include IT leadership, key functional users or sponsors, representatives from operations, network,
technical architects, help desk, DBA staff, change management and development.
2 Conduct
Interviews.
Interview Form Conduct interviews with all participants.
3 Gather Findings
and Develop
Recommendations
Recommendations Address the specific expectations and requirements that were identified in the workshop interviews with recommendations
that are aligned with best practice.
4 Prepare Workshop
Presentation.
Workshop
Presentation
Workshop lead prepares a presentation to communication the findings and recommendations to workshop participants as a
group.
5 Conduct
Workshop.
Technical
Architecture
Workshop
Results
Workshop lead presents the findings and recommendations to workshop participants as a group. Conversation should be
structured as interactive with opportunity for discussion.
Back to Top
APPROACH
Technical Architecture Workshop Objectives
The objective of the Technical Architecture Workshop is to familiarize the client with the reference architectures already established, architecture options and features
available and to gather high-level architecture, availability, integration, reporting, backup and recovery, security and disaster recovery requirements that will be used to
develop the Architecture Requirements and Strategy.
The workshop leader and the project manager should meet with the client project manager and explain the purpose and the approach for the workshop. The client project
manager should arrange for the appropriate parties on the client staff to participate and schedule the interviews. Providing sample interview questions can be helpful in
identifying which persons from the client organization should be invited to participate. Interviews should be scheduled with representatives from both the functional teams
and the technical teams and every effort should be made to complete the interview process in a 2-3 day window. Technical Architecture depends on developing an
understanding of requirements and expectations from the perspective of the business, so participation of key ambassador users is a critical success factor.
Representatives of the client's technical staff are also important, as they can provide the details on processes and procedures already in place that impact technical
architecture such as corporate standards or requirements, current architecture, existing system tools, processes and procedures, etc.
The workshop is conducted by the workshop leader. Interviews should begin with the client project sponsor to gain an understanding of the business objectives and
continue with the remainder of the interviewees. Ideally, interviews should be individual to allow a complete view of architecture requirements across as broad a
spectrum as possible, but small groups can be scheduled if time is a constraint. After the interviews are completed, the Workshop Leader will review the findings and
prepare a final presentation highlighting the key findings and recommendations. The results should be presented back to the workshop participants in an interactive
session allowing sufficient time for questions and answers.
Back to Top
Back to Top
System Architect Lead the Technical Architecture Workshop. Familiarize the client with the goals and objectives of the workshop, assist in
gathering technical architecture requirements. Obtain client participation, set initial interview schedule, and get input from key
users.
If a Technical Architecture team leader has been designated, 25% of this time would be allocated to this individual, leaving
60% allocated to the system architect. The team leader would then familiarize the client with the goals and objectives of the
workshop, assist in gathering technical architecture requirements, obtain client participation, set initial interview schedule, and
get input from key users.
85
System Analyst Participate in the Technical Architecture Workshop. Document Technical Architecture Requirements. 5
Business Analyst Participate in the Technical Architecture Workshop. Provide business requirements that could impact technical architecture. 5
Developer Participate in the Technical Architecture Workshop. Participate in the process of requirement analysis. Depending on the
project, you may want to use a lead application developer.
5
Client Project Manager Coordinate the interview schedule for the workshop, assists in gathering technical requirements. Participate in the Technical
Architecture Workshop.
*
Ambassador User Participate in the Technical Architecture Workshop. Provide business expectations and requirements that may influence the
Technical Architecture.
*
Client Data Administrator Participate in the Technical Architecture Workshop. Identify existing procedures, standards, SLAs. Participate in the process of
*
IS Operations Staff Participate in the Technical Architecture Workshop. Identify existing process, procedures, standards, SLAs. Participate in the
process of requirement analysis.
*
IS Support Staff Participate in the Technical Architecture Workshop. Participate in the process of requirement analysis. *
J2EE Architect - Participate in the Technical Architecture Workshop. Participate in the process of requirement analysis.
Network Engineer - Participate in the Technical Architecture Workshop. Participate in the process of requirement analysis.
Database Architect - Participate in the Technical Architecture Workshop. Participate in the process of requirement analysis.
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.ER.100)
(ENV.EA.110)
Technology Architecture (ENV.EA.130)
Future State Transition Plan (ENV.ER.170)
Use these Envision work products or similar enterprise-level documents, if available. You may need this information
before you can begin this task. Therefore, if they are not available, you should obtain this information prior to
beginning this task.
Project Management Plan (PMP) The Project Management Plan should contain the high level scope and requirements that will drive the Technical
Architecture process. The business requirements and objectives of the project should be defined, and the roles and
responsibilities of those participating in the Technical Architecture process should be identified.
Supplemental Requirements (RD.055) The Supplemental Requirements contains additional requirements that may impact the technical architecture.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
TA.020 - DEFINE TECHNICAL ARCHITECTURE REQUIREMENTS
AND STRATEGY
In this task, you identify the technical architecture requirements and document the strategy you will use for the design and development of the system you are
implementing. This task should address the requirements of the final production environment as well as the interim development, test and project support environments.
Requirements that could affect the architectural design including availability requirements, performance requirements, Service-Level Agreements, high-level security and
control requirements should be documented and considered.
ACTIVITY
Back to Top
WORK PRODUCT
Technical Architecture Requirements and Strategy - The Technical Architecture Requirements and Strategy documents the business and technical requirements of
the new system, describes the strategy for satisfying those requirements and produces a conceptual model that will be the basis for architecture design.
Back to Top
TASK STEPS
1 Produce an
architecture
overview,
describe
scope,
objective
and
approach.
Introduction
Scope
Objectives
Approach
The Introduction describes the purpose of the document and states why each member of the audience has received it.
TheScope describes the scope of the Technical Architecture process including its relationship to other project processes and
potentially other systems and projects. Scope statements should define what components are in or out of scope for the project
including:
data centers
business processes, sites or specific functions
applications
integration or interfaces
technical infrastructure
The Scope component should document the relationships between existing and new systems and identify any retrofitting of existing
systems within scope or any other ongoing projects that could impact scope of this effort.
The Objectives component lists the high-level objectives that the business and project managers have communicated during in the
Project Management Plan (Manage Focus Area) and the Technical Architecture Workshop (TA.010) and discuss factors critical to
achieving those objectives. Since this is a strategic document, the stated objectives should not be excessively detailed, but they
should be both specific and measurable.
The Approach component describes the process, policies and procedures, project dependencies and technical background for the
Technical Architecture process.
The description of the process should include a high-level discussion of the approach selected for the Technical Architecture work,
the tasks and work products, the reasons for selecting the approach and the benefits of the particular method adopted.
If the Technical Architecture process will use different policies, procedures, or standards than the main project, this document should
identify the specific differences, document them in detail and explain why they differ.
2 Document
the
information
systems
strategy.
Information
Systems
Strategy
The Information Systems Strategy documents the strategy that the organization as whole follows when selecting and implementing
new information systems. For some organizations and projects, an Information Systems Strategy may not yet exist and the
Technical Architecture process plays a key in establishing it. For other organizations, the strategy may already be in place, although
it may not be documented. If the strategy is already established, documented and supporting standards exist covering the required
elements, it is sufficient to refer to that documentation rather than reproducing it. The Information Systems Strategy should address:
a statement of issues with the existing information systems
#TOP #TOP
business vision
information systems vision
information systems policies
hardware and network standards
business application and enabling technology standards
office automation and desktop standards
development standards
systems management standards
3 Document
the
architecture
strategy.
Architecture
Strategy
The Architecture Strategy describes the strategy for addressing key areas in the architecture project. This should include the
evaluation of the current architecture, capacity planning and systems management issues. These areas are highlighted and
discussed because of their critical impact to the success of Technical Architecture process. Additional areas may also be included if
they represent inherent risk to the project, or will use an innovative or unusual approach, or for any other implementation-specific
reason. Depending on the project scope and complexity, integration requirements and strategy may be addressed by the Integration
Requirements and Strategy document (TA.030) and reporting and information access strategy may be documented in the Reporting
and Information Access Strategy (TA.040). If these documents will not be produced, relevant information should be included here.
4 Determine
and
document
architectural
requirements.
Architectural
Requirements
The Architectural Requirements component addresses the technical architecture requirements. The requirements summary should
summarize the detailed requirements gathered for the business and information systems and their likely impact on the architecture
and systems. Requirements that may be included are:
critical transactions the system must perform and any performance requirements or SLAs associated with them
availability requirements including the planned time periods the system will be available to users and any time periods when
the system can be unavailable for maintenance on a planned basis
information access requirements
high-level security or auditing requirements
For each requirement, a method of collecting metrics that can be used to evaluate the how well the system meets the requirement
should be determined.
5 Document
architectural
assumptions.
Architectural
Assumptions
The Architectural Assumptions component contains any assumptions that have been made that will affect the design of the technical
architecture.
6 Describe
current
system.
Current
System
Baseline
The Current System Baseline provides an inventory of systems, applications, software tools and networks that constitute the existing
technical infrastructure. The baseline identifies infrastructure, hardware or networks that may be redeployed or reused in the new
technical architecture. Existing systems targeted for replacement be should be identified and existing systems that will retained
should have integration points identified.
7 Describe
initial
capacity
requirements.
Initial Capacity
Requirements
The Initial Capacity Requirements should document the known or estimated user and transaction volumes. Information available on
critical workload, such as a timeboxed batch window or specific performance requirements should be listed. Describe the method
used to determine the initial sizing for the system. If a spreadsheet based sizer or hardware vendor tool was used to determine the
initial sizing, include the input and results of that exercise, perhaps as an attachment or appendix.
8 Create
Conceptual
Architectural
Model.
Conceptual
Architectural
Model
The Conceptual Model is a high-level design of the proposed architecture that blends the business, application, functional
operational and technical requirements. It is abstract in nature, and focuses on communicating the primary architectural
components to a non-technical audience.
9 Describe the
project
environment
requirements.
Project
Environment
Requirements
The Project Environment Requirements component describes specific resource needs for the architecture work, including software
versions, hardware platforms, network components, support and management resources.
Back to Top
APPROACH
Much of the information needed for the subsequent design activities may be strategic in nature, or at the very least, may require decisions by senior management or
project leaders. Often the strategic information is not documented. The Technical Architecture Workshop begins the collection of the information needed, but additional
face-to-face information gathering may still be required. The information systems manager or director will be an important source of information and decisions related to
the Technical Architecture Requirements and Strategy.
Level of Detail
The level of detail required for this task depends on the scope of the implementation project and the Technical Architecture process within it. If the architecture work
relates to a limited number of applications that need to fit into an existing enterprise architecture or information systems strategy, you may only need to document the
parts of the strategy that are relevant to the project scope. At the other extreme, if this is an enterprise level architecture for a large scale replacement of business
systems, or there is no clear enterprise architecture or information systems strategy already in place, you may need to provide considerable detail on the architecture
policies and expectations.
Business Vision
The vision for the new business systems is a key initial ingredient to the design of an architecture, particularly when the architecture process addresses the strategic
aspects of the new system as well as the tactical design.
Architecture Policies and Standards
At the heart of every architecture project are directives and policies fundamental to the project and the architecture design. Large projects that are replacing many of the
key business application of the company or the enterprise, may require defining the directives and policies for the first time. Projects with a more limited scope may be
required to conform to policies and principles that have already been established.
If a formal information systems strategy project has already occurred, a set of principles, directions and strategies may already be in place, and should be used as input to
the project Technical Architecture Requirements and Strategy. A common example of architecture standards is the selection of hardware, where preference is given to a
particular hardware vendor due to an existing strategic relationship.
Document Guidelines
Use the Technical Architecture Requirements and Strategy to expand on the high level architecture requirements defined in the Project Management Plan (PJM). It
should refer to the main project work products where appropriate, and indication objectives and approaches inherited from the main project. The following items should
be addressed:
The detailed requirements for the technical architectures
Scope of the architecture work
Approach to be taken within the process
Specific strategies to be used to achieve the requirements
Initial Capacity Estimate
The Technical Architecture Requirements and Strategy should document the strategy planned for initial sizing of the technical architecture. If the project is implementing
packaged application software, it is recommended that the initial sizing be done in conjunction with the hardware vendor. Most major vendors have partnerships with
Oracle and have developed very specific models related to the packaged application that can be used to size the architecture based on user counts and transaction
volumes. If this is the process used, document the input provided to the hardware vendor as well as the results.
When doing initial sizing for a custom application, hardware vendors may also be able to provide assistance as long as estimates on the number of users and type of
workload are available. If little is known about the planned workload early in the project, accurate sizing may be difficult to develop and the architecture approach should
emphasize an architecture that is easily scalable in the event that initial projections are inaccurate. Initial capacity estimates typically target both the processing
requirements to support both the anticipated workload at time of implementation and for some agreed upon period of time in the future.
Current System Baseline
Establishing the current system baseline requires information gathering, reading and reviewing documentation that exists on the components of the exiting system. Much
of this information may have been identified during the Technical Architecture Workshop (TA.010) and if current documentation exists, the system architect can review
the information independently. However, if documentation is sparse or out of date, additional interviews may be required to gather the information. IS personnel may not
have full details on the functions and processes of existing systems, thus it is advisable to talk directly to business analysts or users to gather some of the information.
For an enterprise level engagement, information may need to be gathered from multiple sites and organizational groups. If interviews and face-to-face time with local
personnel will be required, develop a checklist of basic information or a questionnaire and provide it prior to the interviews to increase the efficiency of the process.
Conceptual Architecture Model
Early in the project, there may not be a clear vision of the information systems architecture required to support the new applications system. This is more likely to be true
if the organization has not established a strategic vision or direction and or has relative few application directives or policies governing processing models or distribution
of processing and data. A variety of candidate models may need to be examined and evaluated in order to identify the appropriate Conceptual Architecture Model for the
project. Only those models that can meet the majority of the requirements need to be seriously considered, but if multiple models exist, the advantages and
disadvantages of each should be weighed when making the final recommendation. Conceptual architecture is a strategic task, and developing the final recommendation
may require a number of review sessions with project leadership and senior management. It is helpful to conduct review sessions to present the architectural alternative
under consideration and to gain both input and consensus from those who will be tasked with approving the selected approach.
Use of Advanced Technology Features
Each new release of technology introduces new features and functionality. When selecting the technology components for the architecture, include only those that are
needed to meet the requirements of the project. The simplest solution that meets the current requirement and aligns with strategic direction is often the best. Consider
the tradeoffs involved in adding more sophisticated software components including:
platform capacity and performance
scalability for future growth
reliability and fault tolerance
maintainability
hard costs, such as cost of hardware or licensing
soft costs, such as extra effort to implement and and the cost of expertise to maintain and manage the system.
If the architecture includes requires features that are very new or "bleeding edge", there is strong likelihood that problems will be encountered during implementation and
testing. If the customer will be an early adopter of a newly released technology or one of the first users of a newly certified combination of application and architectural
components, it is critical that expectations are set appropriately early in the architecture design process and that adequate time is allocated to deal with the issues as they
arise. Combining an early adopter effort with an aggressive implementation schedule without setting expectations properly is not a recipe for success. If there is a formal
early adopter program established, encourage the customer to enroll and participate, in order to gain the advantage of additional support provided by product
development.
Even if the technology to be implemented is mature and has been widely adopted elsewhere, a major architectural paradigm shift for your particular client could require
setting up of lab environments to validate the technical implementation and allow the client personnel to gain experience with it. Also consider whether established
operational and management procedures may need to modified or enhanced before the technology can be made available to the larger project team.
Environments that are targeting very high levels of availability will require a a higher level of operational testing in order to ensure that all associated processes are well
understood and working as expected. Project leadership and senior management need to be apprised of this effort so that they can have appropriate expectations.
Estimates for design and implementation activities may need to be adjusted upwards to accommodate all the required technical tasks. There is extensive, detailed
guidance relating to Maximum Availability Architectures (MAA) at http://www.oracle.com/technology/deploy/availability and this site should be consulted for the most
current guidance when designing a high availability architecture.
Back to Top
Back to Top
System Architect Analyze, define and document the Technical Architecture Requirements and Strategy. Responsible for obtaining input on client
infrastructure, existing standards, policies and procedures. Review the Technical Architecture Requirements and Strategy.
Assist with gaining client approval.
If a Technical Architecture team leader has been designated, 7% of this time would be allocated to this individual, leaving 83%
allocated to the system architect. The team leader would then review the Technical Architecture Requirements and Strategy
and assist with gaining client approval.
90
Business Analyst Review the Technical Architecture Requirements and Strategy in terms of satisfaction of business requirements. 5
Network Engineer Provide the network requirements for the Technical Architecture Requirements and Strategy. 5
IS Support Staff Provide existing guidelines, standards and technical architecture configuration. Review the Technical Architecture
Requirements and Strategy and provide feedback.
*
Client Project Manager Facilitate review by client IS staff. Approve the Technical Architecture Requirements and Strategy. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business and System Objectives (RD.001) The Business and System Objectives provides an understanding of the functional requirements, technical
requirements, budget, project schedule, system interfaces, existing systems, complexity, and significance of the
new system to the business.
Reviewed Requirements Specification (RD.150.2) These work products describe the business area to be computerized and hence the requirements for the new
system. The technical architecture must be sufficient to satisfy these requirements.
Business Use Case Model (RA.015) The objectives, expectations, processing and application requirements contained within this work product are
used to determine the initial technology and distributed requirements.
Technical Architecture Workshop Results (TA.010) The Technical Architecture Workshop gathers information on business and technical requirements as well as
the current system architecture and any existing Information System policies, procedures and standards.
Audit and Control Requirements (RD.070)
Application Extension Strategy (DS.020)
Strategy (PT.020)
The Performance Management Requirements and Strategy can impact the architecture options outlined in the
Technical Architecture Requirements and Strategy and vice versa.
Project Management Plan (PJM) The Project Management Plan documents the high-level business requirements and technical architecture
requirements.
Back to Top
TEMPLATES AND TOOLS
TA-020_TECHNICAL_ARCHITECTURE_REQUIREMENTS_AND_STRATEGY.DOC MS WORD
Back to Top
The Technical Architecture Requirements and Strategy is used in the following ways:
to communicate the requirements and strategy to non-technical project team members, including project leadership and functional leads
to obtain senior management agreement on the Conceptual Architecture model
to provide a reference for technical personnel and users tasked with designing the technical architecture for the proposed system
Distribute the Technical Architecture Requirements and Strategy as follows:
to project management for review and approval
to technical personnel and users for review and agreement
Back to Top
QUALITY CRITERIA
Are scope, objects and approach of the Technical Architecture Requirements and Strategy clearly identified?
Are the high-level business, operations, function and technical requirements clearly specified?
Are specific critical success factors listed?
Are risks identified? Are risk management or mitigation plans included?
Are there competing conceptual models, and if so, is there a clear recommendation for the preferred model?
Are all components of the conceptual model described in language that can be understood by non-technical team members?
Have diagrams been included to enhance understanding of strategy and proposed model?
Back to Top
TA.030 - DEFINE INTEGRATION REQUIREMENTS AND
STRATEGY
Effective integration strategy definition and clear documentation of the requirements will be the baseline for the Integration Architect upon which to build an effective
integration platform. This task will contain the high-level definition of the integration between the existing information systems, and the new information system.
It is important that each of the following inputs be leveraged to ensure a comprehensive approach:
Review the System Context Diagram and the Business Use Case Model to determine the integration points required, and to document the functional requirements,
including the data usage at a high-level for each Integration.
Analyze the functional system integration requirements concurrently with the other functional requirements necessary to meet the business objectives. The
separation of the work products is needed to emphasize the unique characteristics of the integration requirements.
Assign a complexity to these characteristics including the complexity in terms of data and transaction distribution, data transformation, special processing and
testing, since integration requirements often result in system functions that require further specialized detailed analysis and design.
If your project includes SOA, Web Services and BPEL requirements, you should perform this task.
ACTIVITY
Back to Top
WORK PRODUCT
Integration Architecture Strategy - The Integration Architecture Strategy documents the high-level requirements for each integration point. The report is broken down by
system, and within each system the functional Integration requirements are documented by information category. An information category is a set or group of data
elements that are logically related to represent a single integration.
Back to Top
TASK STEPS
1 Review the
prerequisite
work
products and
other
background
material.
None None
2 Document
the system
level
integration
requirements.
System Level
Integration
Requirements
The System Level Integration Requirements contains the requirements for each integration point in the system. It is a basis for
integration design and implementation. It is produced after the business models (Process, Domain and Business Use Case Models)
have been produced.
3 Prepare the
high-level
functional
requirements
for each
integration.
Functional
Overview
The Functional Overview should present a pictorial representation of a business overview of the integration design. It gives the non-
technical personnel an understanding of how the system links together. It should contain a diagram that shows, at a high level, the
information that is to be transferred between the systems. The diagram should contain short business descriptions of each of the
purpose of each integration point and how they operate.
4 Prepare
technical
requirements
and
implications
for each
Technical
Overview
Integration
Dependencies

The Technical Overview provides a technical overview of each integration stating the major software and hardware components of
the integration, the technical design of the integration and describe any data transformation or validation that will take place.
TheIntegration Dependencies provides a table that identifies dependencies between integration points and any sequencing required.
For example, you may need to load customer details before sales details in case the sales details relate to those new customers.
#TOP #TOP
Integration. System
Unavailability
Implications
Integration
Business
Rules
Detailed
Technical
Description
The System Unavailability Implications provides a table that describes what happens when the source or destination system
becomes unavailable.
The Integration Business Rules describes the business rules that apply to each integration point. Include list of valid values and
referential integrity requirements.
The Detailed Technical Description provides the necessary information to design the components that will implement the integration
point. It should state what attributes are to be transferred from the source system to the destination system or systems and
transformation will be required. It should contain a diagram showing the components that are to be used to implement the
component showing the data that passes between and how it is to be passed (for example, in flat files). For each component it
should state the type of component. Finally, it should contain a detailed technical description of how the complete Integration works,
stating what validation is to be performed on the incoming data and what is to be done with the records that fail validation.
Back to Top
APPROACH
Review the Prerequisite Work Products and Other Background Material
First, review the System Context Diagram, Future Process Model, and the Domain Model to identify the system, functional, and data integration requirements at a high-
level. Next, if you have any existing system reference material, existing system data models or documentation on existing system Integration, review these to gain an
additional understanding of the existing system, functional, and data Integration requirements. Lastly, review the the Business Use Case Model to verify that integration
requirements are clearly understood and documented.
Document the System Level Integration Requirements
Document the requirements for each integration point. The requirements for each system should include the following:
the name of the system
a brief description
the location of the system
the type of database (Oracle, non-Oracle, Flat Files, etc.)
the information categories to be integrated (the list or names of the Integration)
any supplemental information (references to sections of the existing material/work products that contain related system Integration information should be noted, for
example, the record descriptions and layouts contained in existing reference material, or the anticipated volume information contained in an existing capacity plan
or existing system data or domain model)
You should also interview or hold a workshop or meeting with the IS support staff and decision makers with knowledge of the existing systems to determine if there are
special considerations, a preferred Integration strategy, or any technical assumptions that need to be documented. An example follows:
System ABC System
Description Sales Order Entry System. Tracks Customers, Orders, and Shipments
Location VAX Cluster - GENCLUST1, Machine - MACH3
Database RDB - ID: 1234
Information to be Integrated from ABC system to XYZ system Customer
Order
Shipment
Information to be Integrated from XYZ system to ABC system Credit
Special Considerations None
References The database schema for ABC is located in ALL-IN-ONE shared drawer: ABC System
Functional Requirements
Document the functional requirements for each information category or Integration. These functional requirements should include the following:
a high-level functional description of the Integration
the type of Integration (input, output)
the Integration method
a high-level breakout of the data elements contained in the Integration
any potential Integration level strategies
special considerations
assumptions
An example follows:
Description Customer information relevant to XYZ system is passed from ABC system to XYZ system. The information is updated via a batch overnight process
whenever the data changes in the ABC system.
Type Input
Method Batch
Data Elements
The main data elements are listed below, the exact, full list is documented during detailed analysis:
Customer Name
Customer Address
Customer Type
Special
Considerations
None
Back to Top
Back to Top
System Architect Identify and document the Integration Architecture Strategy. Prepare the functional Integration requirements. Obtain and
document the special considerations and technical assumptions. You may want to use a system architect that specializes in
system integration. Review the Integration Architecture Strategy.
80% allocated to the system architect. The team leader would then review the Integration Architecture Strategy.
100
IS Support Staff Provide information on the current integration strategy, special considerations and technical assumptions. Provide information
on existing systems.
*
Business Analyst (BA) - Assist in defining business requirements for integration.
Systems Analyst (SAN) - Provide information on current system requirements.
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.EA.130)
Use this Envision work product or similar enterprise-level documents, if available. You may need this information before you can
begin this task. Therefore, if not available, you should obtain this information prior to beginning this task.
System Context Diagram
(RD.005)
The System Context Diagram helps to identify interfaces between the application to develop and external systems.
Future Process Model (RD.011.2) This model is used to determine the system interfaces required, and is a basis to document the functional requirements, including
the data usage at a high-level for each interface.
Domain Model (RD.065) The Domain Model is used to identify and gain an understanding of the existing data structures. This information is needed to map
the existing system data structures to the new system data structures in order to identify the data requirements of each interface.
(RA.015)
This model compliments the information provided in the context and high-level process model, and the domain model. This work
product may provide additional functional interface requirements.
Back to Top
TEMPLATES AND TOOLS
TA-030_INTEGRATION_ARCHITECTURE_STRATEGY.DOC MS Word
Back to Top
The Integration Architecture Strategy is used in the following ways:
by the project leader to confirm the appropriateness and to gather consensus on the project's approach to integration and gain the approval of the foreign system
owners
by the project team to act as the basis for the Integration design
Distribute the Integration Architecture Strategy as follows:
to the technical architects to confirm technical appropriateness and feasibility
to the foreign system owners to gain approval
to the clients business personnel to confirm business appropriateness
Back to Top
QUALITY CRITERIA
Have all known integration requirements been properly clearly identified and documented?
Within each Integration has the significant information been identified?
Is each integration technically feasible?
Does each integration provide the information in a timely manner for the business?
Have any existing system integration criteria or dependencies on new system been noted?
Have all stakeholders had an opportunity to review and agreed upon the strategy for the integration?
Back to Top
TA.040 - DEFINE REPORTING AND INFORMATION ACCESS
STRATEGY
In this task, you analyze the reporting and information access requirements required for the project and specify at a high level how you will meet these in the new
architecture. This is a systems view of how the reporting and information access requirements will be satisfied in the new architecture, and is designed to complement
and support the approach taken in Business Requirements (RD).
A reporting and information access strategy addresses the different types of reporting and information needs for the business. A strategy of this kind must provide for any
one or more of the following types of reporting:
Operational Reporting - This type of reporting solution meets business needs in cases where information is required for the regular operation of the business.
These are usually required periodically, say daily or at month-end. The level of information in this type of reporting would be very detailed to address the day-to-
day operational information requirements (such as inventory levels) of the business, as opposed to management decision-making. These include statutory reports,
reconciliation reports etc.
Decision Support Reporting - This type of reporting facilitates the management of a business through measurement and prediction of business performance.
The data supplied is of a longer time frame than that which is done in operational reporting, almost always involving trends. Ongoing analysis is conducted with
use of analytical tools and applications that typically involve key indicators that reflect an organization's success in maximizing revenue and minimizing expenses
and risks. Balance scorecards, multi-dimensional OLAP, and data mining applications are but a few examples of this kind of reporting.
Ad Hoc Reporting - Ad hoc reporting capabilities provide users with the ability to create their own reports, operational or decision support, by building and running
queries against pre-built business metadata to support the decision-making process. This kind of reporting capability provides users flexibility to modify pre-defined
reports by pivoting, drilling and changing the layout. Users could create their own version of reports and share them with other users in their business group.
While this task is primarily focused on the future production environment, it needs to address the testing of reporting and information access in interim environments.
If your project includes complex or significant custom reporting or information access requirements that cannot be satisfied by packaged application product features, you
should perform this task.
For projects that involve the upgrade of Oracle products, this task involves a review of the client's existing Reporting and Information Access Strategy; followed by a
review of the reporting and information access options available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Reporting and Information Access Strategy - The Reporting and Information Access Strategy documents the methods, approaches and guidelines for designing and
implementing the projects reporting and information access requirements.
Back to Top
TASK STEPS
1 Review prior
documentation.
Introduction The Introduction component should describe the purpose of the document and list the key Reporting and Information
Access requirements that the strategy has been designed to fulfill. Gather key reporting and information access
requirements collected in the Technical Architecture Requirements and Strategy (TA.020).
2 Analyze Information and
document requirements.
Summary of
Architecture
The Summary of Architecture component provides a summary of the various operational, ad-hoc and decision support
systems. A high-level architectural diagram is also provided.
3 Define the strategy. Reporting
and
Information
Access
Strategy
The Reporting and Information Access Strategy component defines the approach to Reporting and Information Access,
what approaches will be taken and what tools will be used.
4 Detail a strategy based on
Business Process.
Business
Process
Strategy
The Business Process Strategy component details processes, tools or approaches that are relevant to specific business
processes in a an OLTP system. Describe the business process requirements, include how information will be
deployed, what tools will be used, and what the long term strategy or vision is (if it differs from the tactical
#TOP #TOP
implementation approach).
5 Detail a strategy based on
Subject Area.
Subject Area
Strategy
The Subject Area Strategy component details processes, tools or approaches that are relevant to specific subject areas
in a decision support system. Describe the business process requirements, include how information will be deployed,
what tools will be used, and what the long term strategy or vision is (if it differs from the tactical implementation
approach).
6 Detail an alternate view of
the aforementioned
strategies, by Business
Unit.
Business Unit
Strategy
The Business Unit Strategy component details processes, tools or approaches that are relevant to specific business
users. Describe the business unit requirements, including how information will be deployed, what tools will be used,
and what the long term strategy or vision is (if it differs from the tactical implementation approach).
7 Define document retention
requirements.
Report
Distribution
and
Retention
Strategy
The Report Distribution and Retention Strategy defines the process for distribution and publishing of documents, and the
retention requirements and strategy.
8 Review the final strategy
with the individuals who
developed the initial
requirements.
None None
9 Revise the strategy as
required, and seek
approval
Acceptance
Certificate

Back to Top
APPROACH
Review the Prerequisite Work Products and Other Background Material
Document and define current reporting tools being used by the client. Work with business units to examine the value of current reports that are being delivered. With
asking the client why they use certain documents or reports, identification of "ease of use" requirements, functionality, use of parameters, and graphs is made easier.
Establish metrics to determine criticality of the reporting needs of the organization.
Determine the Different Types of Reports Required
The ability to easily obtain meaningful information from a system so that a business can make timely tactical and strategic decisions is a critical success factor for a newly
implemented system. There are many different styles of reports and techniques for manipulating data for reporting purposes, but they all fall into one of two major
categories:
operational reporting
decision support
ad hoc reporting
The dividing line between the three types of reporting is not hard and fast, but there are general characteristics that divide the three.
Operational Reporting
Operational Reporting is the routine transaction based reporting that needs to occur in a business to support general business operations. This type of reporting generally
involves relatively small volumes of data, presented in a detail format on a regular reporting schedule.
Decision Support Reporting
Decision Support is a type of reporting that is performed for decision making purposes in a business. The approach and periodicity of this type of reporting are less regular
than the operational reporting. Decision support is often interpreted as being synonymous with reporting against a data warehouse, but it is possible to perform decision
support type reporting within transaction systems. Data warehousing is the enabling technology for this type of operational reporting, not the reporting category. It is
usually more strategic in nature and can include:
structured reporting across large volumes of historical data
analytical (OLAP) style reporting to analyze and dissect business data to understand trends and relationships
data mining to discover hidden trends in large volumes of historical data
Decision Support includes the following types of reporting systems:
Classic Decision Support Systems (DSS)
Executive Information Systems (EIS)
Analytical Reporting Systems Including Online Analytical Processing (OLAP)
Ad Hoc Reporting
Ad hoc reporting may be executed to augment reporting in any one of the two aforementioned areas: operational or decision support. The key distinction here is the
empowerment of end user with tools, ideally metadata assisted, and access to many of the same data stores that support the other types of reporting. The end user in
this instance possesses a knowledge of the data, its architecture, and the tools with which access is made possible. The reporting applications crafted for operational
and decision support reporting often provide for a change in the data retrieved and to a limited degree the format of a report (i.e., rotation and drill); however, the tables
and columns in the underlying database are fixed. However, with using ad hoc tools the end user can alter the combination of table and column, and make wholesale
changes in report format and functionality to augment already existing reports in the other two reporting systems.
Determine Task Complexity and Project Scope
The potential complexity of this task and the reporting strategy you need to put in place depends on the scope and constraints of the project on which you are working.
Single Installation, Fast Track Implementations
If you are working on a fast track implementation with a single installation of a packaged application and intend to perform all reporting out of the operational (transaction)
environment, you may not need to perform the further requirements gathering and analysis in this task. Some custom reports may be required to meet some reporting
requirements that are not provided with the base application, but the data remains a single, consolidated operational database. You should always consider the effect on
performance of your reporting solution, but you may not need any special databases to support your reporting needs.
Attention: In the case of Oracle Applications, users typically execute all their batch reports using the Oracle Applications Concurrent Manager and their online inquiries
through forms or some other reporting tool.
Complex Enterprise Reporting Needs
Larger businesses typically have more challenging and complex reporting needs, spanning operational, strategic, and analytical reporting. For example, global reporting
or online query of operational data for:
sites, divisions, and business lines within a single application installation and database
sites, divisions, and business lines across multiple distributed applications and databases
different statutory and legal reporting requirements to satisfy local legislation and country laws
integrated reporting across heterogeneous applications and databases, relational and non-relational, legacy, and third party vendor packages
Senior management may require long-term trend analysis of data for strategic decision support of:
forecasting
financial modeling and budgeting
supply and distribution planning
sales and marketing
data mining
Data Warehouses: A simple definition of a data warehouse is a subject oriented corporate store of information source from one or more systems, applications, or
databases. A data warehouse can be an enabling technology for both general categories of reporting. Hence you could envision an operational data warehouse,
containing consolidated operational data and having a technical design, that supports the routine operational reporting needs of the business. More often than not, a data
warehouse contains a broad range and large volume of historical corporate data, and is the repository for decision support and analytical applications and systems. Data
warehouse-based systems are a good example of an architecture subsystem that would be singled out as a standalone component of the overall information systems
architecture.
You need to categorize the reporting requirements of different groups and business units within the enterprise, before you attempt to propose solutions.
Define the Components of the Reporting System
Reporting systems have four components:
a database of data from which to report usually a single physical database, but may be a logical database consisting of multiple physical databases
a way to load and transform data into the reporting database
a reporting engine that accepts input parameters or business rules to restrict and manipulate the data set that will appear in the report
a way to present the data in report format
In the simplest operational transaction systems that permit reporting, the data is generated directly in the transaction database, and a reporting tool performs the query
and manipulation, as well as the presentation of the data in the report. However, you should consider the different components depending on the exact function and
source of the reporting system. A separate reporting system is often classified as an architecture subsystem.
Consider Performance Implications
The effect of a reporting load on the performance of any transaction system is as important as the effect of the transaction, and it should not be (but often is) overlooked.
In an online transaction processing (OLTP) system environments in which significant reporting is permitted in an controlled fashion, the load can periodically be extremely
heavy. At critical times in the business cycle such as financial period end, the operational reporting load itself can consume many of the system resources of a database
server and can decimate the transaction performance. Conversely, if the reporting needs to be completed in a certain time window, the performance of the system for the
reporting is critical also. For more information about managing the performance quality of reporting systems, see Performance Management (PT).
Separate Reporting Systems as a System Capacity Management Technique
Traditionally, the approach used to alleviate some or much of the operational reporting load on an OLTP system was to offload the reporting functions onto a separate
reporting database on a separate server using a point-in-time copy of the transaction system for the purposes of reporting only. Reporting databases can be a valuable
technique for offloading processing from the transaction system.
Technology advances have introduced several options that should be considered prior to creating a duplicate database to support reporting requirements. Most
application logic in current packaged applications is resident in the application tier. In such applications, separate application servers can be dedicated to Concurrent
Manager processing, offloading some of the processing workload from the database server(s). This is an useful technique, particularly in the case of processes which
primarily compute intensive.
The introduction of Grid technology such as Real Application Clusters (RAC) allows the dedication of one or more nodes to support reporting, without requiring the
creation and maintenance of an entirely separate reporting database.
If reporting database will be created, consider the timeliness of the data. In order to be useful, there must be reporting groups within the enterprise that can perform their
reporting on aged data (for example, data that does not contain all transactions up to the immediate point-in-time). Increasing the refresh frequency for data in the
reporting database can circumvent some of these problems, but it is usually not feasible or cost effective to keep the data in a reporting database synchronized with the
OLTP system in real-time.
Design Operational Reporting and Information Access
The complexity of the operational reporting strategy depends on the conceptual architecture and business needs for reporting operational data across multiple application
installations or different OLTP application products. In a simple, single installation of a packaged application you may choose to perform all of your operational reporting
using standard product capabilities. With slightly more complexity, you could add a special ad hoc query environment within the same transaction database, perhaps
using a dedicated application tier.
Cross-Application or Cross-Installation Reporting
Generally the organizations within your business should be able to satisfy their reporting obligations using the operational system in which they record their particular
transactions, but some organizations may need access to data in multiple, physically separate operational systems.
If you need to provide consolidated operational reporting across multiple installations of the same applications suite or across heterogeneous application products, you
need to consider some special mechanism to enable such organizations to consolidate data from multiple operational environments. The data can be consolidated in one
of the applications or installations through the use of integration. You then perform consolidated reporting out of the consolidating application or instance.
Another approach is to design an operational data store, which is an independent standalone database, but which may reside in one of the database instances
corresponding to the separate application installations. The data store can be as comprehensive or complex as you wish.
Operational Reporting Database
If you have special security concerns for reporting users, or wish to offload report processing load to another server, you can use an operational reporting database. This
type of reporting database is different from a data warehouse, because it is a direct copy of the transaction database, without reorganization of the data. When it is copied
onto a separate database server, it also offloads processing capacity, but it does introduce additional architectural complexity.
Design Ad-Hoc Query Strategy for Operational Reporting System
Providing users with a means to easily locate, retrieve, format, and display online the information they need can empower users and alleviate some development
overhead needed to migrate existing reports from legacy systems to a newly implemented system. However, creating an ad hoc query environment in which users can be
productive requires investment of information systems resources. Do not assume that because you make a report or inquiry development tool accessible to the users that
this automatically constitutes an ad hoc query capability for users. The main problem is that a relational data model optimized for OLTP performance is not easily
understood or decipherable by users. In order to facilitate the use of an ad hoc query tool you may have to create an environment that translates the OLTP data model
into the form of business objects that a user understands.
Key-User Layer (Meta Layer)
This technique adds a layer on top of the relational OLTP data model to present the data in the operational transaction system in the form of easily understood and
familiar business objects, such as sales orders or purchase orders. You can build this layer on top of the OLTP database directly and allow ad hoc queries in the
transaction environment, or you can add the layer to a direct copy of the transaction database, that is mounted as a reporting database.
Operational Data Warehouse
Another type of system that you can use for ad hoc queries on operational data is an operational data warehouse. This type of data warehouse is different from the type
that supports strategic reporting or analysis because it supports operational reporting needs, it may only contain the most recent operational data, and it may not have the
summarized views of data that provide a long-term strategic business view. The data in the warehouse is incremented on a regular basis and may be completely
refreshed after a certain time period. The warehouse will usually have a report- or query-friendly data model, so programs need to be developed both to extract
operational data from OLTP systems and to load data into the data warehouse. An example of where this might be useful is in the consolidation of order entry and point-
of-sale information, where you might totally refresh the data every quarter or annually.
Attention: A data warehouse where operational reporting is performed and data is refreshed from time-to-time is sometimes referred to as an operational data store to
distinguish it from a true data warehouse, where data agglomeration is cumulative for historical analysis.
Design Decision Support Strategy
Decision support systems are specialized applications that enable users to summarize and organize transaction data into formats that are oriented towards reporting and
analysis. The data model for a decision support database may be very different than the data model for the transaction databases that provide the source data. Often the
database for a decision support system is a data warehouse that stores transaction data from multiple, different transaction systems over many financial periods. Raw
operational data may have been summarized or aggregated to some degree within the warehouse. A data warehouse or decision support system is a common
standalone architecture subsystem that might need custom development or custom integration work.
One benefit of a custom data warehouse system that is often overlooked is the fact that the data model is owned by the business. By performing as much of the reporting
from the data warehouse as possible, the business insulates itself from the effects of data model changes in new releases of packaged applications.
Online Analytical Processing (OLAP)
This technique is the manipulation and analysis of data in multiple dimensions to support business decisions. The manipulations performed include slicing and dicing data
across different dimensions, pivoting, selective data summary, consolidation, and drill-down.
OLAP systems are usually specialized in their internal architecture and are subsystems within their own right. OLAP system functions may be supported directly from a
transaction database; they may or may not have built-in persistent data caches (effectively a local database). A very powerful solution is to combine a backbend data
warehouse that contains structures appropriate for OLAP with an intuitive, user-friendly OLAP tool to perform the data manipulation. If an OLAP system is included, you
need to define exactly how it should interact with other reporting databases or warehouses and design the architecture accordingly. Of particular importance are the
requirements surrounding the aging and refresh of the data. These requirements are driven by how close to a real-time view of the business analysts need.
Data Marts
Data Marts are data warehouses that are smaller in scale than an enterprise data warehouse and are oriented more towards department-level decision support. They may
be organizational or functional slices of the complete data set in the enterprise data warehouse. Often they are installed on cheaper workgroup or functional departmental
server.
Data Warehouses
It is relatively straightforward to specify the systems with which a data warehouse will interact and how the data warehouse will be used in the overall reporting strategy,
but integrating a package corporate data warehouse solution or custom developing a corporate data warehouse is a major undertaking. An analysis of the requirements
and the very detailed technical and database design is beyond the scope of this process. An architecture subproject should be initiated to perform the design of this part
of the architecture solution. If it is apparent that a data warehouse system is required, generate the Architecture Subsystem Proposal.
Design Report Storage and Report Distribution Strategy
Report storage and report distribution are related issues that affect how reports should be handled and are concepts that are often discussed in the context of workflow. If
many users need to view a particular report, it is a waste of resources to have individual users creating their own copy of a report by executing the report program
multiple times. By providing systems to support sensible business practices in this area, the information systems organization can reduce waste of paper and precious
platform system resources. Include any special systems needed to support this in the architecture.
Types of systems you might consider include:
storage of reports or report images in a database or in a computer output to laser disk (COLD) system
automated or manual routing of electronic reports to users after execution, by email or fax
intranet web-based report publishing, where reports are converted into HTML format, and can be browsed by users across the internal corporate network
Review Reporting Tools
Oracle has products that can help you build the end-user layer (EUL) business views and ad hoc query environment. . You can use these tools to build a view-based EUL
on top of the transactional database schema which will help hide the underlying complexity of the database from ad-hoc report developers. You will also write reports or
allow browsing tools to access the Oracle Applications database through these layers. Many third-party vendors also have reporting and query products that you can
use for this task. Define with the client what data access tools will be used to solve each of the clients reporting requirements.
Back to Top
Back to Top
System Analyst Analyze the business requirements. Identify and document the Reporting and Information Access Strategy. 80
Business Analyst Assist in the process of requirement analysis and review them. 20
IS Support Staff Provide information on existing systems and current enterprise standards. *
Project Manager (PM) - Assist in the process of requirement identification, review and approve strategy.
Back to Top
PREREQUISITES
Prerequisite Usage
MoSCoW List (RD.045.2) The MoSCoW List provides information about the reporting requirements of the system. It helps specify the
reports needed by the various business organizations and sites.
Technical Architecture Requirements and Strategy
(TA.020)
The Technical Architecture Requirements and Strategy provides information on the scope, requirements, and
strategy for the architecture work
Initial Architecture and Application Mapping
(TA.070)
The Initial Architecture and Application Mapping document provides the initial framework for the applications
architecture.
Back to Top
TEMPLATES AND TOOLS
TA-040_REPORTING_AND_INFORMATION_ACCESS_STRATEGY.DOC MS WORD
Back to Top
Use the Reporting and Information Access Strategy in subsequent tasks to define the reporting systems that support the reporting needs of system users within your new
architecture.
The Reporting and Information Access Strategy is used in the following ways:
by the project leader to confirm the appropriateness of the reporting and information access solution and gain the approval of the business system owners
by the project team to act as the basis for the Reporting and Information Access design
Distribute the Reporting and Information Access Strategy document as follows:
to the business system owners to gain approval
to the clients business personnel to confirm business appropriateness
Back to Top
QUALITY CRITERIA
Have all known reporting requirements been properly addressed?
Have critical reports or those with Service-Level Agreement requirements been identified?
Within each reporting and access requirement, has the significant information been identified?
Is the strategy technically feasible?
Does each design strategy provide the reports in a timely manner for the business?
Have Service-Level Agreements or other metrics been developed to ensure the business is receiving information needs to meet business objectives?

Back to Top
TA.050 - DEFINE DISASTER RECOVERY STRATEGY
In this task, you define the methods, actions, and requirements needed to execute a recovery of technical system(s) from loss due to severe failures such as those that
results from fire, earthquake, tornado, or hurricane. This strategy also includes recovery of systems(s) due to other catastrophic loss not caused by an act of nature, such
as complete loss of networks, data center or other physical resources that necessitates restoration of production business systems due to their loss. Depending on the
business requirements, this recovery may take place at an alternative facility. The Disaster Recovery Strategy addresses the requirements of IT Service Continuity, a key
requirement of an overall business continuity plan.
The output of this task is not intended, nor should it be referred to as, a complete Business Continuity Plan. Business Continuity includes all the processes and
procedures that would be required in order for a business to maintain continuous operations in the event of a disaster or other catastrophic failure. This task is limited to
the technical strategy and requirements related to mission critical systems that must be recovered including availability requirements, performance requirements, Service-
Level Agreements, high-level security and control requirements.
If your project includes establishing disaster recovery capability, you should perform this task.
For projects that involve the upgrade of Oracle products, this task involves a review of the client's existing Disaster Recovery Strategy, combined with a review of any in-
built disaster recovery utilities available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Disaster Recovery Strategy - The Disaster Recovery Strategy defines the requirements for the following operational procedures:
declaration of a disaster or other catastrophic event
recovery from disaster events
availability requirements related to disaster recovery
activation of critical business functions involved in disaster recovery
validation of recovered systems
restoration of normal operations
The strategy should identify the process to determine that a disaster requiring recover has occurred, and detail start-up and shut-down procedures, recovery of mission
critical systems to an alternative facility, error notification and reporting, validation of recovered systems. Once the disaster has passed, the procedure for restoring
normal operations should be discussed.
Back to Top
TASK STEPS
1 Review prior
deliverables.
Introduction The Introduction describes the purpose of the Disaster Recovery Strategy, lists the service level requirements, operational
requirements and review requirements the strategy is based on provides a reference to other related project
documentation that define the high level business requirements that drove the strategy development.
The Service Level requirements should address service levels such as:
levels of acceptable downtime after disaster event
level of technical support for disaster recovery operations and hours of availability
level of availability from 3rd party disaster recovery partners based on contractual service levels
The Operational requirements should address such things as:
disaster loss notification and reporting
inventory of lost/remaining systems
activation of disaster recovery procedures
2 Define Scope. Scope The Scope component defines the mission critical systems included within the Disaster Recovery Strategy as well as the
elements of application architecture and technical architecture included. It documents key assumptions used in
#TOP #TOP
developing the strategy and lists any risks, along with their mitigation strategy.
3 Define the disasters to
be covered by the
Strategy.
Disaster
Definition
The Disaster Definition component lists the events or combination of events that are considered to be "disasters" within the
scope of the Disaster Recovery Strategy.
4 Identify the
participants and their
roles and
responsibilities.
Roles and
Responsibilities
The Roles and Responsibilities component documents what organizational roles have specific responsibilities in support of
the Disaster Recovery Strategy.
5 Define metrics to
measure the
effectiveness of the
strategy.
Metrics The Metrics component defines what statistics or measurements will be used to evaluate the effectiveness of the Disaster
Recovery strategy and what information will be collected to provide those measurements.
6 Define the processes
and procedures to be
used.
Disaster
Recovery
Strategy
The Disaster Recovery Strategy defines the specific processes and procedures that will be used to:
declare a disaster
complete the technical recovery of mission critical systems
validate that the systems have been successfully recovered
activate the systems and notify users of their availability
restore normal operations once the disaster has ended
7 Create Disaster
Recovery Test Plan.
Disaster
Recovery Test
Plan
The Disaster Recovery Test Plan component defines the requirements for testing the Disaster Recovery strategy. It
defines:
what systems will be tested
how the tests will be conducted
participants in the tests
roles and responsibilities of test participants
Back to Top
APPROACH
The approach for documenting disaster recovery strategies is as follows:
Identify the systems that are of critical value to the business.
Identify critical business functions.
Define the levels of service required to support any critical business area.
Identify the order in which the critical systems must be restored, from most to least critical.
Identify those aspects and functions of the system that require recovery/replacement in event of disaster.
Document requirements for operational procedures.
Back to Top
System Architect Analyze the operational requirements. Produce the Disaster Recovery Strategy. 90
System Analyst Provide and assist in analyzing requirement related specifically to the business requirements and applications. 10
Client Project Sponsor Review and approve the Disaster Recovery Strategy. *
IS Operations Staff Provide information on existing standards, processes and procedures related to Disaster Recovery. Review and approve the
Disaster Recovery Strategy.
*
IS Support Staff Provide information on existing standards, processes and procedures related to Disaster Recovery. Review and approve the
Disaster Recovery Strategy.
*
Ambassador User Provide the business requirements related to Disaster Recovery. Review and approve the Disaster Recovery Strategy. *
Project Manager - Review and approve the Disaster Recovery Strategy.
Back to Top
PREREQUISITES
Prerequisite Usage
Technology Architecture (ENV.EA.130) Use this Envision work product or similar enterprise-level documents, if available. You may need this information
before you can begin this task. Therefore, if not available, you should obtain this information prior to beginning this
task.
Technical Architecture Requirements and
Strategy (TA.020)
The Technical Architecture Requirements and Strategy provide the framework for systems around which to plan for
disaster recovery operations.
Back to Top
TEMPLATES AND TOOLS
TA-050_DISASTER_RECOVERY_STRATEGY.DOC MS WORD
Back to Top
The Disaster Recovery Strategy is used in the following ways:
by the IS staff to describe roles and responsibilities for disaster recovery activities
to determine requirements for 3rd party involvement in disaster recovery operations
Distribute the Disaster Recovery Strategy as follows:
to all team members
to IS management staff
to IS operations staff
to IS support staff
to the Purchase department
Back to Top
QUALITY CRITERIA
Do the disaster recovery requirements fit within the organization's business operations strategy?
Do the disaster recovery requirements fit within the organization's information systems strategy?
Do the requirements fulfill the requirements of the Service Level Agreements?
Back to Top
TA.060 - DEFINE SYSTEM OPERATIONS AND MANAGEMENT
STRATEGY
In this task, you define the requirements, strategy, approach and metrics required to provide the IT services needed to effectively manage the new system. Supporting
software or tools that are required to support the strategy should be identified and linked to requirements of the strategy they support. After the strategy is identified in this
task and the tools and procedures are established, the detailed processes and procedures will be defined in the System Management Guide (TA.100) and tested.
The primary focus of this task is the future production environment, but effective operations and management of interim project environments are also critical to ensure
that the project is able to meet it's objectives in a timely manner.
If your project includes complex architecture changes, you should perform this task.
For projects that involve the upgrade of Oracle products, this task involves a review of the client's existing System Operations and Management Strategy, combined with a
review of any in-built operations and management utilities available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
System Operations and Management Strategy - The System Operations and Management Strategy defines the operations and management approach that will be
used to achieve:
Performance against formally defined Service Level Agreements (SLAs)
System and application availability requirements
System and application operational requirements
System and application maintenance requirements
System and application monitoring
System and application performance management
User access control and security management
Problem identification and resolution
Levels and nature of technical support, help desk procedures, service level requirements and reporting
Batch processing control
Auditing and control procedures
Archiving and Purging
Collection of metrics and reporting
The basic requirements are established in by previous architecture design work such as the Technical Architecture Requirements and Strategy (TA.020), Integration
Architecture Strategy (TA.030), Reporting and Information Access Strategy (TA.040), Disaster Recovery Strategy (TA.050) and Backup and Recovery Strategy (TA.080).
The System Operations and Management Strategy focuses on identification of procedures and tools that will be used to implement, manage, monitor and maintenance
these requirements within the new system. This is a design document produced by the technical system management experts. It should not discuss each procedure in
detail; the detailed guidance, reference guide information and checklists will be documented in the System Management Guide (TA.100).
Back to Top
TASK STEPS
1 Review previous
work products
and any existing
reference
material.
None None
2 Provide an
introduction.
Introduction The Introduction component describes the purpose of the document, it's intended audience and use. It should discuss the scope
of the System Operations and Management Strategy.
3 Describe client's Overview of The Overview of Network and Server Operations Center component describes the client's existing systems operations and
#TOP #TOP
current
organization.
Network and
Server
Operations
Center
management capabilities, what services each organization provides and any pre-existing level of service established.
4 Document
existing
enterprise
standards.
Enterprise
Management
Standards
and Policies
The Enterprise Management Standards and Policies component describes any established enterprise standards and policies to
which the system operations and management strategy must conform. Document who owns the standards, policies and their
scope. If these standards have already been documented in a prior project documents, such as in the Technical Architecture
and Requirements Strategy (TA.020), it may be adequate to reference the prior documentation, or you may choose to reproduce
the relevant standards here for ease of use.
5 Document the
system
operational and
management
requirements.
System
Operational
and
Management
Requirements
The System Operational and Management Requirements documents the system operational and management requirements the
System Operational and Management Strategy will support. The bulk of the requirements should have been defined in prior
work products as noted above, but should be summarized here for ease of use. The requirements component should discuss
how the operational baseline will be established.
6 Document
maintenance
schedules.
Planned
Maintenance
Schedule
The Planned Maintenance Schedule component summarizes all planned maintenance activities across system management
areas.
7 Describe
operations,
management and
monitoring of the
database tier.
Database
Tier
The Database Tier component describes the procedures and tools needed to manage the database tier in the new system. It
covers both normal operations and maintenance, as well as possible failure scenarios. It defines the tools will be used to
operate, manage, maintain and monitor the servers and what metrics that will be regularly collected, reviewed and reported.
8 Describe
operations,
management and
monitoring of the
application tier.
Applications
Tier
The Applications Tier component describes the procedures and tools needed to manage the application and web servers in the
new system. It covers both normal operations and maintenance, as well as possible failure scenarios. It defines the tools will be
used to operate, manage, maintain and monitor the servers and what metrics that will be regularly collected, reviewed and
reported.
9 Describe
operations,
management and
monitoring of the
Desktop Client
tier.
Desktop
Client Tier
The Desktop Client Tier component describes the procedures and tools needed for managing any software in the desktop client
tier of the new system. I covers both normal operations and maintenance, as well as possible failure scenarios. It defines the
tools will be used to operate, manage, maintain and monitor the servers and what metrics that will be regularly collected,
10 Describe
operations,
management and
monitoring of the
database tie.
Security and
Accounts
Management
The Security and Accounts Management component describes the procedures and tools needed for managing access to
systems and accounts and for preventing and responding to security breaches and what metrics that will be regularly collected,
11 Describe
operations,
management and
monitoring of the
hardware and
network.
Hardware
and Network
The Hardware and Network component describes the procedures and tools needed for managing hardware and network
configuration of the new system and what metrics that will be regularly collected, reviewed and reported.
12 Describe
Software
Management
procedures.
Software
Management
The Software Management component describes the procedures and tools needed for managing software components of the
new system and what metrics that will be regularly collected, reviewed and reported.
13 Describe Capacity
Planning
procedures.
Capacity
Planning
The Capacity Planning component describes the procedures and tools needed for proactive Planning of System Capacity
Requirements. It identifies what metrics and measurements are needed to support Capacity planning.
14 Describe
Performance
Management
procedures.
Performance
Management
The Performance Management component describes the procedures and tools needed for proactive Planning of System
Capacity Requirements and what metrics that will be regularly collected, reviewed and reported.
15 Summarize tools. Tools
Summary
The Tools Summary component summarizes the tools needed to support the Systems Operations and Management Strategy
and identifies any that need to be acquired or built.
Back to Top
APPROACH
A common error that occurs when designing a Systems Operations and Management "strategy" is to move immediately to the selection, purchase and implementation of
software tools, before explicitly defining what support functions are needed, what metrics should be collected and what reporting and information access is required.
Tools facilitate the implementation of the strategy, but they should not define it, and tools alone, without the appropriate processes to collect and review the information,
will not provide effective system management.
When defining the system operational and management strategy, review the existing operations center, services and processes, the prior architecture design documents
and performance management documents and make a list of the business requirements, operational requirements, performance management requirements, service
level agreements and any existing standards or tools that are already in place. These requirements should drive the strategy and thus the selection of tools to facilitate
the achievement of the strategy.
Metrics and Reporting
Each requirement should have a method of measurement established, or a metric that can be used to determine the ability of the application or system to meet the
requirements. As an example, if the system is required to be available 20 hours a day/6 days a week, then a method of tracking planned and unplanned outages will be
required. If backups are to occur each evening, then a mechanism to validate that the backup process is working correctly will be needed. If a particular batch process is
required to be complete within a particular window of time each day, then a method of tracking and reporting on execution time of the program will be required.
The Oracle technology stack is heavily instrumented at a very low level of detail, and many third party software tools collect masses of detailed data as well, but the
process of determining what data can be used to track the specific requirements of the project may require some level of analysis. Performance of critical transactions
from a user perspective can be a significant challenge, as many most monitoring tools do not track transactions at a "business transaction" level. It may be necessary to
work with the development team, and potentially add instrumentation to the application in order to gather the information necessary.
A regular reporting mechanism should be established that allows project management to have visibility into system operations and management using the metrics that
are establish. A standard format covering key metrics can be developed, preferably in a dashboard format. This report can be distributed to project management and the
Steering Committee or perhaps posted on the project portal or website. Regular reporting helps to drive the effectiveness of the systems management process, raises
the visibility of the efforts of the technical team and also provides a basis for establishing an operational baseline. When evaluating tools that are used for workflow or
repositories of information, consider the eventual reporting requirement to ensure that in addition to handling individual work items such as a specific trouble tickets or
system statistics, the tool can generate meaningful reporting that can be used to identify trends, assist in capacity planning or identify areas that require process
improvement.
Establishing a Operational Baseline
A key technique to effectively identifying and resolving issues before they develop or as they arise is to be able to easily identify a deviation from the "normal" pattern.
Regular review of system metrics will establish an operational baseline that makes it possible to much more quickly identify a change that might turn into an issue or even
a crisis over time. If the normal batch window completes within 6 hours every night on average, but one night it takes over 9 hours, review of that deviation from normal
should trigger someone to look into the situation and identify the root cause. If there is not information collected or reviewed on the normal processing time required, the
window could stretch to 9 hours the first night, but potentially go unnoticed, and therefore unresolved, and then expand to 12 hours the following day, at which point it
interferes with the peak online workload, creating an escalation. If CPU utilization has been in the 75% range for several months during peak processing hours, but then
begins to move steadily upward, that should trigger an evaluation of root cause and potentially a corrective action. Without regular review of the system metrics the
upward increase may not be noticed until the CPU is significantly overloaded, jobs are queuing up due to lack of resources and users are complaining to the help desk.
As the architecture technology implements more and more advanced components, the need for a well understood baseline becomes increasingly critical. Responding to
a problem without a clear view of the "normal" baseline often requires researching a large number of areas, and eliminating them one by one. If the baselines are
understood, areas of the system that are performing within documented normal tolerances can be quickly eliminated, allowing a more efficient and focused approach to
quickly locating the source of the problem and then resolving it.
Proactive versus Reactive Operational Systems Management
Most IS workers today can articulate the theoretical value of "proactive" operational systems management, yet all too often they report being too busy to implement
proactive techniques. Resource and staffing constraints are real issues for IS departments, yet in reality a major obstacle is the limited understanding of how lack of
defined measurement, process and established baseline contribute to a constant stream of events that require reactive measures.
Organizational structure can also be impediment, as the parties responsible may work for a number of different organizations and lack a common management hierarchy
or reporting structure.
Gaining consensus and agreement on implementing an effective systems management strategy may required a series of reviews or meetings with IS decision makers in
which the approaches are discussed. Once the measurements are established and the data is collected, the approach will demonstrate it's own value, but until that time,
be prepared to conduct a number of information and review sessions in order to communicate the value of establishing meaningful metrics and an operational baseline.
Many proactive managers understand the value of "proactive" systems management, but many are too busy reacting to a series of issues to actually implement a
proactive approach.
Automation of Operational Systems Management
Most operational and systems management activities can be run manually. Custom scripts can be created, cron jobs can be scheduled, and statistics can be maintained
in excel spreadsheets. Managing a complex environment in this manner is possible, but tends to be both resource intensive and error prone. It is usually preferable to
automate these operations to the maximum extent possible to avoid issues with human error and to reduce labor. There are numerous software tools available to
support the automation of systems management, however remember that a tool can only be as useful as the process that it supports. In other words, if there is not a
clear process established to use the information the tool collects, return on investment may not be satisfactory and the tool may not fulfill the objective it was purchased to
achieve.
Documenting Critical Business Transactions and Service Levels
Identify hours of system availability required by the business. Determine the affect on business function and costs if the system is not available.
Identify specific business transactions that are critical to business process and their performance expectations.
Define types of services required to support the requirements of the applications and the users.
Define the levels of service needed to support any critical business area.
Define the levels and types of support needed during peak processing, nights, weekends and holidays.
For each service level, define an approach to capture performance against the requirement.
Any conflicts or inconsistencies in the requirements may require review with IS and business representatives. It is helpful to conduct a series of review sessions once the
service levels are established, and representatives from both the business and IS should attend.
Back to Top
Back to Top
System Architect Determine the operational requirements. Produce the System Operations and Management Strategy work product. Review the
System Operations and Management Strategy and perform any negotiation required.
85% allocated to the system architect. The team leader would then review the System Operations and Management Strategy
and p erform any negotiation required.
100
IS Operations Staff Provide and review the System Operations and Management Strategy. Indicate any aspects of the System Operations and
Management Strategy, which are unacceptable. Negotiate acceptable service levels.
*
Back to Top
PREREQUISITES
Prerequisite Usage
before you can begin this task. Therefore, if not available, you should obtain this information prior to beginning this
task.
Supplemental Requirements (RD.055) The Supplemental Requirements may also contain requirements that will translate into Operations Requirements.
Strategy (TA.020)
This work product contains the Initial technical architecture requirements on which the System Operations and
Management Strategy is based.
Back to Top
TEMPLATES AND TOOLS
TA-060_SYSTEM_OPERATIONS_AND_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
Distribute the System Operations and Management Strategy as follows:
users
IS support staff
IS operations staff
Back to Top
QUALITY CRITERIA
Do the requirements match and support the business information and reporting strategies?
Are all components of the system addressed (maintenance, publishing, load processes)?
Were the users and IS staff involved in defining the requirements?
Back to Top
TA.070 - DEFINE INITIAL ARCHITECTURE AND APPLICATION
MAPPING
In this task, you refine the Conceptual Architecture Model component of the Technical Architecture Requirements and Strategy (TA.020) to produce an Initial Architecture
and Application Mapping for the new system. While the primary focus of this task is on the future production environment, the requirements of interim environments to
support project activities should also be considered.
ACTIVITY
Back to Top
WORK PRODUCT
Initial Architecture and Application Mapping - The Initial Architecture and Application Mapping is the blueprint for the logical and physical architecture of the new
system. It contains a detailed architecture design based on the Conceptual Architecture Model component developed in the Technical Architecture Requirements and
Strategy (TA.020), and identifies the specific software, servers, server configurations, input and output subsystem configuration and maps the application components to
the hardware components of the architecture.
Back to Top
TASK STEPS
1 Review Prior work
products.
Gather and review TA work products defining requirements and strategic direction, design standards and initial sizing and
capacity requirements.
2 Create Introduction. Introduction The Introduction describes the Initial Architecture and Application Mapping and the purpose of it. Describe the use of this
document for other tasks and activities and discuss the scope.
3 Create Application
Functional
Architecture
Summary.
Application
Functional
Architecture
The Application Functional Architecture component describes the Application Architecture from a high-level functional view
It should include a diagram or pictorial representation of the key application elements which are then mapped to the
physical architecture in subsequent sections.
4 Describe Key
Architecture
Subsystems.
Key Architecture
Subsystems
The Key Architecture Subsystems component describes any standalone subsystems that address key application
requirements or policies.
5 Summarize Physical
Architecture.
Database and
Application
Server
Summary
The Database and Application Server Summary component provides a pictorial summary of the overall physical
architecture planned.
6 Describe Database
Server.
Database
Servers
The Database Servers component describes each of the database servers and their hardware and software configuration.
It should identify the application processing that will take place on the database tier. Important application and database
configurations should be documented.
7 Describe Application
and Web Servers.
Application Tier The Application Tier component describes each of the application and web servers and their hardware and software
configuration. It should identify the application processing that will take place on the middle tier.
8 Describe Desktop
clients.
Desktop Client The Desktop Client component describes the required configuration for desktop client tiers at the deployment sites. It
should address minimum hardware configuration, browser support requirements and any application components that will
run directly on the desktop.
9 Describe IO
Subsystem.
IO Subsystem The IO Subsystem component describes IO subsystem technology and deployment. It should include the data storage
and throughput requirements and include a description of any hardware specific features planned such as disk mirroring,
level of RAID, snapshot or split mirror configurations, etc.
10 Describe Network
Topology.
Network
Topology
The Network Topology component describes network requirements specific to the implementation effort and include any
known constraints, particular those that affect geographically distributed users.
11 Describe Data
Centers or Hosting
Data Centers or
Hosting
The Data Centers or Hosting Facility component describes each data center or hosting facilities and detail which
components of the architecture will reside in each site.
Facilities. Facilities
12 Review and Collect
Comments.
Design Review Architecture review sessions should be conducted to familiarize the project team and client staff with the planned
architecture and to collect any comments or feedback prior to publishing the document
13 Approve and publish. Final document Obtain document approval and publish to the project repository.
Back to Top
APPROACH
Low Complexity Projects
If your project is of a low complexity, such as a vanilla implementation of a limited number of packaged application models at a single site for a small number of users, it
may be possible to consolidate this task into the Technical Architecture Requirements and Strategy (TA.020).
Preconfigured Systems
In some cases, a client may used pre-configured servers with all technical components pre-staged, ready to run. In such cases, the architecture is assumed to be
provided by the vendor of the pre-configured environment.
Use of Advanced Technology Features
Certifications for Real Application Clusters (RAC) are performed against the Operating System and Clusterware versions. The corresponding system hardware is offered
by System vendors and specialized Technology vendors. Oracle will support the Oracle software on clusters comprised of RAC compatible technologies and certified
software combinations. It is critical to consult with your hardware vendor on hardware as not all vendors may choose to support their hardware in every possible cluster
combination.
Use of Advanced Technology Features in Combination with Packaged Applications
Not all core technology features in the latest releases are certified for use with the packaged applications suites. For example, architectures should not target the use of
the latest database version until the certification of the application suite is officially announce on Metalink. Refer to the Certify on Metalink for the most current guidance
related to products or features that apply to your implementation.
Review Requirements and Strategy
Review the various requirement and strategy documents and validate that no new requirements have emerged that would require revisiting the conceptual architecture
design. Some changes are likely in response to new identification of requirements or clarification of requirements. If the changes require enhancement to the original
strategy as opposed to a fundamental change, you can proceed with the creation of the detailed architecture design and application map. If new information has
emerged that requires a fundamental change to the conceptual architecture model, you should incorporate a detailed review process to gain acceptance and approval of
the the changes to the architecture design.
Resource Requirements
The application and technical system architects performing this task should have a good knowledge of the application and technical architecture of the application and
technology being implemented. The knowledge required includes application technical configuration, understanding of the technology components, understanding of
supported reference architectures and knowledge of existing systems and networks.
Application Mapping
Application mapping addresses the distribution of application components across the hardware architecture. It should address the location of executables and processing
and distribution of data. Some packaged applications, such as Oracle Applications, have multiple options for Application Mapping, such as alternative locations of the
Concurrent Manager and use of shared APPL_TOP. When selecting one option over another, document the analysis process and selection criteria used for future
reference.
Distributed Data Model
If the application will use a distributed data model, the following questions should be addressed:
What specific data will be distributed? Reference data? Additional data?
How will the consistency of different copies of the data be maintained?
If data distribution is to be used, then which data will be on which nodes?
Task Complexity and Project Scope
The complexity of this task varies with the scope of the project. Vanilla installations of packaged application without customizations or extensions may only require
documentation of the installation structure for future reference by the technical architect for capacity planning and for reference by the information systems organization
and staff. An application that requires a maximum availability architecture or a large enterprise level effort typically will require significantly higher level of detail.
Key Architecture Subsystems
Key Architecture Subsystems are architecture components that are standalone subsystems within themselves and and provide enterprise level services to the
information systems architecture. These types of components general affect multiple applications or installations. Examples include:
a hub and spoke integration architecture that links and distributes data between multiple applications
an operational data repository that is synchronized with multiple transactional applications
a critical third party application package with requirements to integrate with multiple transaction systems across the enterprise
a enterprise portal application that provides access to multiple applications via the intranet or the internet
an electronic commerce system that process multiple inbound and outbound documents
Each subsystem should be documented thoroughly, but at a high level, describing how the subsystem fits into the overall system architecture, what requirements or
policies it satisfies and what the possible approaches for developing or acquiring the subsystem, assuming it does not currently exist. These types of subsystems are
more important in larger scale, more complex projects, but the concept of a non-localized, enterprise-level component of an architecture that affects multiple applications,
interfaces or databases is general. Because of the possible impact of such a subsystem on the overall systems architecture and the risk associated with custom
development of such a system, it may be prudent to separate the detailed specification, design, and build of these systems into a separate sub project linked to the core
application and technical architecture process. Therefore a subsystem may equate to a development sub project, although that is not always the case.
Requirements for Interim Environments
An implementation project may need a number of interim environments to support project activities. Because the use of any particular environment is low and the
environments may be temporary, there may be a temptation to reduce the architecture components to use fewer resources. Care should be taken to ensure that interim
environments remain consistent with the planned production environment, at least to the extent that they permit thorough testing of all technical components. If the
production environment will use RAC, for example, at least some of the development and test environments should also be RAC enabled in order to provide a location to
test RAC specific patches and to validate the application functionality under node failure conditions. While interim environments may be scaled down or multiple
environments may share hardware resources, they should represent the same conceptual architecture planned for production, and should not be fundamentally different
in a way that introduces risk in the production environment due to the inability to thoroughly test technology components in the project interim environments.
Use of Diagrams
Diagrams can significantly enhance understanding of information system designs. Use diagrams wherever possible to avoid or enhance detailed text descriptions. For
some aspects of the system design, such a network topology, a diagram may be the only reasonable alternative to communicate the architecture.
Back to Top
Back to Top
System Architect Review architecture requirements and strategy and validate conceptual architecture. Develop the initial technical architecture.
Conduct design review sessions and prepare the Initial Architecture and Application Mapping.
100
IS Support Staff Answer queries and provide information regarding the current and proposed options for the new system. *
Back to Top
PREREQUISITES
Prerequisite Usage
(RD.001)
You should keep in mind the agreed on objectives when developing the Distribution Architecture.
Structures (RD.012)
The Present and Future Organization Structures documents the business units that perform business use cases and the
business units' locations. This combined with the high-level business models enable you to determine the number of
users performing the business functions at a certain location and the corresponding transaction volumes which are
calculated.
(RD.034)
Use the Current Business Baseline Metrics to capture the technical information about legacy systems that support current
business processes.
(RD.150.2)
The business models provide information about business requirements that should be considered when defining the
Distribution Architecture. These models may describe what data is used by which actors. The business use cases
describe how up-to-date the data can or must be. Together this would translate into requirements for the decision of how
to distribute the data.
Architecture Description (RA.035)
Architecture Description (DS.040.1)
The Architecture Description deals with the design and implementation of the system's high-level structure. These
elements satisfy the major functionality and performance requirements of the system as well as other, non-functional
requirements such as reliability, scalability, portability, and system availability. This serves as a basis to determine the
how and which components should be distributed.
Architectural Prototypes (IM.020) The Architectural Prototypes address architectural design decisions that should be taken into account when developing
the Initial Architecture and Application Mapping.
Strategy (TA.020)

Reporting and Information Access
Strategy (TA.040)

Back to Top
TEMPLATES AND TOOLS
TA-070_INITIAL_ARCHITECTURE_AND_APPLICATION_MAPPING.DOC MS WORD
Back to Top
The Initial Architecture and Application Mapping is used in the following ways:
by developers to implement the application executables
by the DBA and Operations Staff to establish adequate development, test and training environments
by the DBA and Operations Staff to plan for the implementation of the production environment
Distribute the Initial Architecture and Application Mapping as follows:
to all project team members with a need to be familiar with the architecture and application mapping
to the owners of external systems for information and approval
to the project sponsor and project leadership
Back to Top
QUALITY CRITERIA
Does the Initial Architecture and Application Mapping fit within the organization's information systems strategy?
Does the Initial Architecture and Application Mapping fulfill the requirements identified in the Architecture Requirements and Strategy?
Have key architecture subsystems been included
Is the architecture scalable and will it meet the planned capacity requirements?
Have cost, system availability, performance, server and database maintenance requirements been considered?
Are known constraints and risks specifically identified?
Are key database or application configurations documented?
Back to Top
TA.080 - DEFINE BACKUP AND RECOVERY STRATEGY
In this task, you define the proper methods and actions for backup and recovery, which enable the system to be recovered in case of failure. This failure can be either
physical or logical in nature, and can range from loss of a single file, loss of an application, or loss of an entire server. Compete loss of processing capability across one
or more Data Centers should be addressed in a comprehensive Disaster Recovery Strategy (TA.050).
The Backup and Recovery strategy should be developed in conjunction with the following tasks to ensure the strategy is appropriate and the necessary hardware and
software is present to support it:
System Capacity Plan (TA.160)
Initial Architecture and Application Mapping (TA.070)
System Operations and Management Strategy (TA.100)
The Backup and Recovery Strategy should also take into consideration the Service-Level agreements and availability requirements defined in the Technical Architecture
Requirements and Strategy (TA.020) to ensure that the strategy provides the mechanisms to fulfill the agreed upon levels for system availability.
For projects that involve the upgrade of Oracle products, this task involves a review of the client's existing Backup and Recovery Strategy, combined with a review of any
in-built backup and recovery utilities available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Backup and Recovery Strategy - The Backup and Recovery Strategy documents the techniques that are to be used to recover the system in case of failure. The aim of
the strategy is to make sure the availability and integrity requirements of the system are fulfilled. The strategy covers the online backups, offline backups, off site backups,
automatic archiving, roll forward, backup of large database objects, backup resource requirements and backup scheduling. The strategy also addresses recovery
scenarios, acceptable downtime and the resource requirements and defines the Backup and Recovery Test Plan.
Back to Top
TASK STEPS
1 Gather
information
related to
backup and
recovery.
Introduction The Introduction describes the purpose of the Backup and Recovery Strategy document. It should included elements in and out of
scope and define any special terms.
2 Provide
information
and
standards.
Standards
and
Requirements
The Standards and Requirements component lists the organizational or enterprise standards that pertain to backup and recovery,
including tools used, online and tape retention requirements, planned maintenance windows, etc. If this information has already be
documented in the Technical Architecture Requirements and Strategy (TA.020), you can refer to that document, or reproduce the
relevant sections here for ease of use.
3 Develop
Backup and
Recovery
Strategy.
Backup and
Recovery
Strategy
The Backup and Recovery Strategy includes the following:
Off Site Backups
Offline Backups
Online Backups
Automatic Archiving
Roll Forward
Backup Of Large Database Objects
Backup Resource Requirements
Backup Scheduling
Describe for each of these items how it is set up, which method is used for execution, the frequency and dependencies, for the items
as well as from the items. Describe the development environment, the test environment and the production environment separately.
4 Develop Monitoring The Monitoring and Validating Backups describes the processes that will be used to ensure that the backups are taken and planned,
#TOP #TOP
Monitoring
and
Validation
Approach.
and
Validating
Backups
how backups will be validated on an ongoing basis, and what metrics will be collected to evaluate the efficiency and effectiveness of
the process.
5 Document
Failure
Scenarios.
Failure
Scenarios
and
Recovery
Approach
The Failure Scenarios and Recovery approach documents :
The types of failure conditions that will require a recovery
Recovery Strategy
Acceptable Downtime
Resource Requirements
The Recovery Scenarios component should address the different types of recovery situations that could arise and document the
appropriate action to take under each situation.
6 Develop
Backup and
Recovery
Test Plan.
Backup and
Recovery
Test Plan
The Backup and Recovery Test Plan defines the test plan that will be conducted in the task Conduct the Backup and Recovery Test
(TA.130) to validate the elements of the backup and recovery strategy. The plan should be in the form of a checklist describing the
test scenarios, the backup or recovery action to be performed, the party or parties responsible for conducting the test and the
expected results. It is helpful to build a project plan covering the test activities, particularly if there is extensive testing required.
Back to Top
APPROACH
Gather Information
Review the prior architecture design work to identify the specific availability requirements that the Backup and Recovery Strategy must support.
Review the current backup standards and processes in place within the IS organization to determine if enhancement or changes are necessary to support the
project requirements. If no standards or guidelines relating to backup and recovery exist, they should be defined as part of this task.
Review the projected size of database objects to determine if any may have special requirements.
Review objects stored outside of the database, such as, logs, output files, interface files, etc. and consider their requirements for both backup and recovery.
Investigate dependencies between systems to be sure that the backup and recovery strategy that will allow key applications or system to be recovered to a
consistent state.
Back to Top
System Architect Investigate the organization's backup strategy. Read the work products from preceding tasks. Interview the technical personnel
to get more detail. Prepare the work product.
90
System Analyst Assist the system architect in providing information about the non-functional business requirements. 10
IS Operations Staff Answer queries and provide information regarding the current user backup and recovery strategy. *
IS Support Staff Answer queries and provide information regarding operational requirements. *
Project Manager - Review the Backup and Recovery Strategy. Perform any negotiation required.
Back to Top
PREREQUISITES
Prerequisite Usage
Strategy (TA.020)
The business models provide information about business requirements that should be considered when defining
the Backup and Recovery Strategy. These models may describe constraints on the business use cases and data
which also place requirements and constraints on the integrity requirements.
Disaster Recovery Strategy (TA.050) This work product provides the requirements for the operational procedures concerning recovery from large-scale
disaster loss, as well as requirements for service levels concerning availability of machines and technical support.
System Operations and Management Strategy
(TA.060)
The System Operations and Management Strategy describes the major hardware and software components of
the new system, such as operating systems, network software, Oracle tools and database servers. The Backup
and Recovery Strategy is developed within these boundaries using the standards available within the
environment.
(TA.070)
The Initial Architecture and Application Mapping provides a map for preliminary hardware and software
architecture, including server requirements for development, test and production.
Back to Top
TEMPLATES AND TOOLS
TA-080_BACKUP_AND_RECOVERY_STRATEGY.DOC MS WORD
Back to Top
The Backup and Recovery Strategy is used in the following ways:
by technical members to review for completeness
by technical personnel and users to review and make sure it accurately reflects the backup and recovery requirements for the proposed system
by developers to know what to do and who to turn to in case of failure
by the project manager to enable the recovery of the system in case of failure
by the production DBA to set up a backup plan and assist in case of failure
by the IS support staff to follow in case of failure
Distribute the Backup and Recovery Strategy as follows:
to all team members
to the IS support staff
to the production DBA
Back to Top
QUALITY CRITERIA
Do the requirements fit within the organization's information systems strategy?
Do the requirements fulfill the requirements of the Capacity Plan?
Do the requirements fulfill the requirements of the Architecture Requirements and Strategy?
Does the strategy take into account existing backup strategies?
Are the task steps of sufficient detail to perform a backup of appropriate accuracy and completeness?
Are the task steps of sufficient detail to perform a recovery to a sufficient point in time to allow for continuing business operations?
Do the requirements fulfill the agreed upon levels of availability as defined in the Service Level Agreement(s)?
Back to Top
TA.090 - DEVELOP SECURITY AND CONTROL STRATEGY
In this task, you develop the Security and Control Strategy for the system. This is a high-level task where you plan on how you are going to fulfill the system's security and
control requirements.
At the minimum, the strategy should address end-to-end security and access control flows from end-user entry points to the database and other internal components, and
back to the end-user exit points. At this stage of development, the system security requirements have been defined and validated against business security objectives.
The Security and Control Strategy is used as the basis for the physical security design.
Because the success of the security plan depends not only on the technical implementation but also on the security organization that will administer and enforce
application security, the plan should explain the role that will be played by the organizational security structure.
ACTIVITY
Back to Top
WORK PRODUCT
Security and Control Strategy - The Security and Control Strategy is a technical description of how the application will implement the organization's security policies via
the application. It covers access control to components, data and the system.
Back to Top
TASK STEPS
1 Review the Security
Requirements.
None None
2 Review Product
Capabilities.
None None
3 Define Security and
Access Capabilities.
None None
4 Describe the purpose
of the document.
Introduction The Introduction describes the purpose of the document, describes the scope of the document and provides references
to other project documentation or sources that were the source of the security requirements the strategy addresses.
5 Document approach
and Requirements.
Background The Background discusses the general approach used for developing the design of the Security and Control strategy,
and details the business and security requirements that the strategy has been designed to address.
6 Document Security
and Control Strategy.
Security and
Control
The Security and Control component describes the specific security and control approach for each project area in
scope, including network security, application security, security for publicly facing web pages, database security, data
security, operating system security and so on.
7 Document the Security
Requirement
Traceability Matrix.
Security
Requirements
Traceability
Matrix
The Security and Requirements Traceability provides a matrix that cross references the security requirements with the
design implementation.
8 Describe Security
Administration.
Security
Administration
The Security Administration describes the organizational components that will support the security and control strategy,
identifies roles and responsibilities and approval authorities.
Back to Top
APPROACH
Use All Available Resources
Interviews - Interview the Security staff to ascertain the company's strategy on security and control. Include access control, data integrity and audit trail issues in your
questions. Interview IT staff about current security implementations; they have background that can give you ideas on leveraging current capabilities. Both groups can
tell you about undocumented commonly-used security practices.
#TOP #TOP
Feedback - Keep the other members of the team informed of your design ideas. This will ensure a unified approach to the architecture. Review your design with the
customer. Conduct security workshops that explain the security philosophy behind the design, and the proposed security architecture.
Company Documents - Get a copy of their security policies and implementation guidelines; get a copy of their development guidelines.
Companys Web Site - Company web sites provide good background information on the organization.
External Security Sites - For information on compliance requirements and publicly available security guidelines.
Study the Security Drivers
Study the systems business to understand the business returns that the secure system will provide. For example, an e-store that does not protect customer credit cards
jeopardizes their ability to keep customers and stay in business. Data errors due to incorrect and/or unauthorized updates can result in erroneous business decisions.
Understanding the business reasons for securing the system helps prioritize and justify security capabilities.
Security Standards and Compliance Requirements
Study the government regulations that the business should comply to. The following is a list of sample compliance requirements:
Name Applies To Resource
Sarbanes-Oxley Act Public Companies Data protection, reliability http://www.sarbanes-oxley.com/
HIPAA (Health Insurance Portability and Accountability Act) Health Industries Privacy of patient data http://www.hhs.gov/ocr/hipaa/
Gramm-Leach-Bliley Act (GLBA) Financial Industry Privacy of financial services consumers
http://www.ftc.gov/privacy/privacyinitiatives/glbact.html
DOD 5015-2-STD Military Branches Strong authentication, auditability, encryption
http://www.dtic.mil/whs/directives/corres/pdf/50152std_061902/p50152s.pdf
FISMA (Federal Information Security Management Act) Federal Agencies Information security http://csrc.nist.gov/sec-cert/ca-background.html
Threats and Consequences
What are the threats that the security implementation should guard against? What are the consequences if these threats are not mitigated?
Fully Understand the Security Requirements
Understand not only the wording of the security requirements, but also the intent of the requirement. Development projects that relied solely on baselined
documented requirements sometimes fail to implement the obvious, undocumented requirements because the customer did not feel they have to state the obvious, and
the developer did not feel they had to implement anything that is not on paper. So part of the architects job is to understand the intent of the requirement, not just the
letter of the requirement. For example, when an architect builds a house, he does not have to be told that each room should have a door, and the entry into the house
needs some kind of lock. By the same token, the security architect does not have to be told that a username needs some kind of accompanying validation method like a
password.
Study the organizations security policies. The applications security requirements should have been based on the organizations security policy. Fully understand not
only the wordings of the policy, but also their intent. This will make it easier to expand the security requirements.
Review the Security Requirements. Review the security requirement document and conduct interviews to fully understand and confirm the following. Within this
process, you will also end up classifying the security requirements from the architectural viewpoint. The list below show examples of security subjects that should be
addressed. Note that they overlap because they are all interrelated.
Network security: How do they currently protect their networks and what additional capabilities will they need?
Web Server security: What access controls do they need for their web pages?
Application level security: How will application users authenticated and authorized? How will application code be protected?
Database level security: How will their data be protected from unauthorized actions? How is their data grouped according to their security characteristics?
Operating system level security: How will the operating system be protected from unauthorized users?
Remote access capabilities: What are the different methods by which their application can be accessed?
Identity Management: How will users identify themselves to their application? How are users grouped according to what they can and cannot do? How are users
grouped according to what data they can and cannot see?
Physical security: How will computer rooms and IT (Information Technology) areas entry and exit be protected points protected?
Validate the requirements against Security and Compliance Requirements. This will help ensure completeness of the security requirements.
Evaluate Security Products and Features
The security design should be technically possible to implement and is influenced by product capabilities. A good place to start aside from product documentation is
http://ias.us.oracle.com. Map the requirements with product features and draw a general flow of how they fit together into a comprehensive whole. Explain how the
products will be used by the application.
Assess Constraints and Acceptable Risks
Architecting a security model is a balancing act between access control, auditability and accountability on one hand, and practical concerns like cost, manpower
requirements, customer inconvenience, complexity on the other internal issues between the security organization and other organizations within the company. Your
objective is to produce a security plan that is acceptable to all parties, mediated by a high-level officer of the organization.
Get a full understanding of the organization's limits regarding the security implementation. Get a feel for acceptable development timeline, acceptable hardware,
software, manpower requirements and development, implementation and ongoing management costs. These should be already in the project plan; but get
confirmation nevertheless.
For each requirement group, define an implementation plan or plans that identify the plan's resource requirements (time, money, manpower, hardware, software),
and risks associated with compromises.
Understand practical implementation concerns. For example, how practical is a 15-character password with combination of small letters, capital letters, numbers
and special characters?
Define System Security and Control Plan
Design the General Architecture.
Network security: Draw a general diagram that shows data flow from the end-user to the database and back to the end-user. Draw both extranet and intranet
capabilities, firewalls, LAN (Local Area Network) and WAN (Wide Area Network) networks, general network topology.
Web Server security: Explain how web pages are going to be protected. Is there going to be multi-level security? Is Portal going to be used? If so, how are portal
groups going to be divided? Are there going to be public pages? Are users required to logon?
Application level security: Draw a diagram of how a user accesses the application. Is it going to be via web page? Forms? How will these pages be
protected? What are the security classifications of the various application functional components? Who can access these components? Are there going to be
batch processes? How will they be executed and by whom? What application features are open to the public?
Database/Data security: Is the application going to use the shared-schema model? Will the application require OLS (Oracle Label Security) ? VPD (Virtual Private
Database) ? EUS (Enterprise User Security)? TDS (Transparent Data Encryption)? What database roles will be defined? How are users going to be classified?
Is there a hierarchy of users? How will data be classified? What is the security matrix for the application data? Are you going to use database links between two
databases? Are there data stored in places other than the database?
Operating system level security: Who will be allowed to login to the operating system? What rights will they have? What user will own Oracle software? What
are the security methods for outputs produced by the application and stored in the operating system?
Remote access capabilities: How will remote access be controlled? What capabilities will be exposed to remote appliances?
Identity Management: Draw the identity management flow. How and who will users be created? Will you provide self-service registration? Define the workflow
for user-registration approvals. How will users be authenticated? Via password? SSL (Secure Socket Layer)? What ldap capabilities will be provided? Does the
company have existing source of truth for user information? How will identify information be disseminated to ldap? How will the database identify a particular end-
user? What are the password policies?
Data Integrity, Data non-repudiation, Data Quality. Explain how the integrity of transmitted data is going to be maintained. Is SSL going to be used? Explain how data
quality and consistency will be maintained.
Privacy, Permanence. Explain how access to private data will be maintained. Explain the design for keeping historical data available per compliance regulations.
Auditability and Accountability. Explain what auditing capabilities will be provided. How are user actions tracked? How are transactions and data updates tracked?
How are DBA (Database Administrator) actions tracked? How long will audit data be kept? Who can access auditing data?
Physical security: Explain the locks, gates, badges, security cards that will be used to keep computer rooms and office work areas secure.
Map the Requirements to the Design
Create a matrix that maps the requirement to the Design capability.
Explain Security Risks and Security Responses
What particular threats are addressed by this design and how does the design circumvent the threat? What particular threats cannot be avoided and how does the
application mitigate its affects? Include both manual and automatic responses. What is the method for handling security incidents?
Propose the Duties of Security Organization
Organizations now have security administrators whose function is to administer the organizations security policies. They will have additional duties when the application
is implemented. Also, their procedures might change because of the new application. Explain their interactions with the future application.
Contents
Aside from the normal documentation template that explains standard paragraphs like background, references, description, etc. the document should contain the
following: Refer to the previous paragraphs for understanding the contents.
Business Drivers
High-level view of Security Requirements
High-level view of Security Capabilities
Network security
Web Server security
Application Level security
Database and Data Security
Operating system Security
Remote Access
Identity Management
Data Integrity, data non-repudiation
Privacy Permanence
Auditability and Accountability
Physical Security
Matrix that contains Requirements to Design
Security Risks and Security Response
Duties of the Security Organization
Back to Top
Back to Top
System Architect Interview technical personnel to find the currently implemented security and control strategy. Interview the users to identify any
special requirements. Interview the development team to ascertain more detail on the structure of the application. Prepare the
work product.
80
Application/Product
Specialist
Internal Auditor Provide information about internal audit requirements. *
IS Support Staff Answer queries and provide information regarding the current security and control strategy. *
Back to Top
PREREQUISITES
Prerequisite Usage
before you can begin this task. Therefore, if not available, you should obtain this information prior to beginning
this task.
Business and System Objectives (RD.001) You should keep in mind the agreed on objectives when developing the Security and Control Strategy.
(RD.012)
The Present and Future Organization Structures documents the business units that perform business use cases
and the business units' locations. This combined with the business models enable you to determine the kind of
users performing the business functions.
Reviewed Requirements Specification (RD.150.2) The business models provide information about business requirements that should be considered when defining
the Security and Control Strategy. These models may describe the access that is needed by whom to which
business use case as well as the data and integrity rules between database objects.
Technical Architecture and Requirements
Strategy (TA.020)
This document describes includes operational requirements and security and control requirements.
(TA.070)
The Initial Architecture and Application Mapping describes the major hardware and software components of the
new system, such as operating systems, network software, Oracle tools and database servers. The Security and
Control Strategy is developed within these boundaries using the standards available within the environment.
Back to Top
TEMPLATES AND TOOLS
TA-090_SECURITY_AND_CONTROL_STRATEGY.DOC MS WORD
Back to Top
The Security and Control Strategy is used in the following ways:
by developers to determine what access and security mechanisms to take into consideration while developing the system
by the project manager to verify the security of the system
by the IS support staff to optionally define new standards for security and control
Distribute the Security and Control Strategy as follows:
to all team members
to the IS (Information Systems) support staff
to the internal auditor
Back to Top
QUALITY CRITERIA
Do the requirements fit within the organization's information systems strategy?
Does the strategy agree with existing security and control strategies?
Back to Top
TA.100 - DEFINE SYSTEM MANAGEMENT PROCEDURES
In this task, you document the technical procedures required to operate, manage, monitor and maintain the new system and supporting architecture. This task provides
the detailed guidance to implement the systems operation and management strategy developed in Define System Operations and Management Strategy (TA.060).
If your project includes complex architecture changes, such as a number of new operational requirements for the customer, or is of medium or high complexity, you should
perform this task.
ACTIVITY
Back to Top
WORK PRODUCT
Systems Management Guide - The System Management Guide is a set of procedures for the technical operation, monitoring and managing of the new application
system. These procedures implement the System Operations and Management Strategy (TA.060).
Back to Top
TASK STEPS
1 Review prior
deliverable
None Review the System Operations and Management Strategy (TA.060), Backup and Recovery Strategy (TA.080), Disaster
Recovery Strategy (TA.050) and identify the specific procedures that should be included in the System Management Guide.
2 Prepare an
introduction to
the document.
Introduction The Introduction describes the purpose of the document and provide references to prior documents defining strategy and
requirements relating to the procedures documented here. It should discuss the scope of the Systems Management Guide and
its intended audience and use.
3 Develop the
procedures.
Systems
Management
Procedures
The Systems Management Procedures should provide step-by-step guidelines for each of the Systems Management
Procedures.
Back to Top
APPROACH
The System Management Guide documents the procedures needed for managing and monitoring the new application system. It provides relevant system information to
internal support staff and should include step-by-step procedures for performing a variety of management, monitoring and maintenance tasks. Some tasks might be
required on a regular basis such daily, nightly or on another fixed schedule while others may only be performed on an as needed basis.
In a commercial off-the-shelf (COTS) application implementation, the System Management Guide includes all system management procedures and is organized by
process rather than by system function. System management personnel use it to determine how to backup, recover, and audit the application system.
Typical procedures that should be addressed include:
collection and review of system and application metrics
reporting of system and application metrics
performance management procedures
report generation procedures
exception handling procedures
database and application monitoring
archiving and purge procedures
database maintenance operations such as statistics collection, index rebuilds, table maintenance, etc.
backup and recovery procedures
interface management
refreshing of test environments
problem and issue resolution procedures
miscellaneous support procedures
#TOP #TOP
The System Management Guide should:
document how a task should be performed, including the use of any tools that support the procedure
identify who is responsible for performing the task
what metrics should be collected and what reporting or trend analysis is required
Many of the step-by-step procedures can be most easily documented using a checklist approach. Detailed checklists should be attached to the document as appendices.
Follow the development and editorial standards defined in the Documentation Standards and Procedures (DO.020).
Testing the System Management Procedures
The ideal time to begin using system management procedures is during the latter stages of testing in the implementation process. This approach allows the testing and
validation of the procedure and permits refinement of processes and supporting checklists prior to the time when they will be needed to support the production
environment.
Review Metrics and Reporting
Each System Management Procedure should have a measurable method of determining that the procedure is working correctly and effectively. The Systems Operations
and Management Strategy should have defined the metrics required, and the procedure should document how metrics are collected and reported.
Back to Top
Back to Top
System Architect Identify and document the procedures. 100
IS Support Staff Provide information on existing processes and tools, standards, policies and procedures. Review and approve the procedure
document and checklists.
*
Back to Top
PREREQUISITES
Prerequisite Usage
System Context Diagram (RD.005) The System Context Diagram helps to identify interfaces between the application to develop and external systems.
Future Process Model (RD.011) This model is used to determine the system interfaces required, and is a basis to document the functional requirements,
including the data usages at a high-level for each interface.
Domain Model (RD.065) The Domain Model is used to identify and gain an understanding of the existing data structures. This information is
needed to map the existing system data structures to the new system data structures in order to identify the data
requirements of each interface.
Business Use Case Model (RA.015) This model compliments the information provided in the context and high-level process model, and the domain model.
This deliverable may provide additional functional interface requirements.
Documentation Standards and Procedures
(DO.020)
Follow these development and editorial standards.
Back to Top
TEMPLATES AND TOOLS
TA-100_SYSTEM_MANAGEMENT_GUIDE.DOC MS WORD
Back to Top
The System Management Guide is used in the following ways:
by the project technical team to conduct systems operational procedures
by the client technical staff to operation and maintain the system after implementation in production
Distribute the System Management Guide as follows:
to the project technical team
to the clients IS personnel
Back to Top
QUALITY CRITERIA
Have all known process and procedures required been properly addressed?
Are the processes to measure system performance against requirements technically feasible?
Are the procedures consistent with existing enterprise standards?
Are the uses of system management tools clearly explained?
Are the metrics to be collected identified?
Back to Top
TA.110 - DEFINE OPERATIONAL TESTING PLAN
In this task, you document the aspects of the technical architecture that will require operational testing and define the testing plan.
If your project includes complex architecture changes, such as new technology, for example, implementation of Real Applications Clusters (RAC), implementation of
DataGuard, implementation of advanced IO subsystem features or other technology features that have not previously been in use in the enterprise architecture, you
should perform this task.
ACTIVITY
Back to Top
WORK PRODUCT
Operational Testing Plan - The Operational Testing Plan defines the technical testing activities that will be performed to validate that technical architecture components
are operational and working as planned. The Operational Testing Plan is the input to Conduct Operational Testing (TA.120), which is the task that performs the test
activities defined in this plan.
Back to Top
TASK STEPS
1 Review the
prerequisite work
products and
other background
material.
None The Technical Architecture Requirements and Strategy (TA.020), the Initial Architecture and Application Mapping (TA.70) and the
System Operations and Management Strategy (TA.060) will identify the components of the technical architecture that may require
operational testing, and describe the business and technical requirements that should be validated as part of the test scenarios.
The Integration Architecture Strategy (TA.030) and the Reporting and Information Access Strategy (TA.040) will identify
component requirements specific to integration and information access.
2 Determine which
aspects of the
technical
architecture
require
operational
testing.
Introduction The Introduction component defines the purpose of the Operation Testing Plan, the scope of the technical architecture
components that will undergo operational testing, the approach used for testing and the roles and responsibilities of the parties
that will participate in the testing process.
3 Define and
document the test
steps.
Operational
Testing
Plan
The Operational Testing Plan should define the specific tests that will performed, identify the environments that will be used to
conduct the tests, identify the persons responsible for conducting the tests and document the expected results of each test.
Back to Top
APPROACH
What should be included in the Operational Test Plan
The operational test plan documents specific technical testing that will be done to validate that architectural components provides the expected functionality. The scope
of the testing depends on the number and complexity of the new architecture components and the experience of the client with those components. If the project is
implementing features such as RAC or DataGuard for the first time as part of the project, the operational testing plan should cover expected functionality such as testing
the performance of the interconnect, adding or removing nodes from the cluster, conducting failover tests, performance of clustered file systems, etc. In addition to core
functionality, the test plan should validate that previously existing architectural components will interact with new components as expected.
The testing should focus primarily on the technology. While it may be possible to combine operational testing with functional testing, the risk of disruption to functional
test team plans should be carefully considered before selecting such an approach.
Back to Top
System Analyst 80
System Architect 20
IS Support Staff *
Back to Top
PREREQUISITES
Prerequisite Usage
Strategy (TA.020)
The Technical Architecture Requirements and Strategy defines the high-level architectural requirements including
availability requirements, performance requirements, Service-Level Agreements, high level security and control
requirements
Integration Architecture Strategy (TA.030) The Integration Architecture Strategy defines the architectural requirements specifically related to Integration.
Reporting and Information Access Strategy
(TA.040)
The Reporting and Information Access Strategy (defines the architectural requirements specifically related to
document and Information Access.
(TA.060)
The Reporting and Information Access Strategy (defines the architectural requirements specifically related to
document and Information Access.
(TA.070)
The Initial Architecture and Application Mapping defines the technical and application architecture, including the
specific architecture components that require operational testing.
Back to Top
TEMPLATES AND TOOLS
TA-110_OPERATIONAL_TESTING_PLAN.DOC MS WORD
Back to Top
The Operational Testing Plan is used in the following ways:
by the project leader to confirm the appropriateness of the operational testing planned
by the technical project team to conduct the operational testing
Distribute the Operational Testing Plan as follows:
to the technical team for execution
to the clients technical team for review and approval
Back to Top
QUALITY CRITERIA
Have all operational test requirements been properly addressed?
Have the specific parties responsible for conducting the testing been identified?
Is each test technically feasible?
Are expected results documented?
Back to Top
TA.120 - CONDUCT OPERATIONAL TESTING
In this task, you conduct the operational testing defined in the Operational Testing Plan (TA.110) and report the results. If any portions of the initial tests are unsuccessful,
the appropriate changes should be made and retesting should take place.
ACTIVITY
Back to Top
WORK PRODUCT
Operational Test Results - The Operational Test Results document the outcome of the Operational Test activities.
Back to Top
TASK STEPS
1 Review the prerequisite
work products.
None Read the Operational Testing Plan (TA.110).
2 Prepare the system
environment for operational
testing.
None
3 Conduct testing. None Perform the operational tests. Record the test results for inclusion in the Operational Test Results.
4 Analyze results for
success/failure against
success criteria.
None
5 Retest failed components. None Make any changes required to correct unsuccessful tests and retest. Note any items than are not corrected for
reporting in the Operational Test Results.
6 Report results of operational
testing.
Introduction The Introduction component describes when and how the test was conducted.
7 Provide Test Results
Summary.
Operational
Test
Summary
The Operational Test Summary provides a management level overview of the test results. It is best presented in the
form of charts or graphs showing the percentage of tests that passed as expected, or other summary information of
interest
8 Provide Test Results Detail. Operational
Test Detail
The Operational Test Detail component provides the specific results of each individual test scenario.
9 Document Outstanding
Corrective Actions.
Outstanding
Corrective
Actions
The Outstanding Corrective Actions component lists any test items that are unresolved, what action needs to be
taken, who has responsibility and what due date has been assigned.
Back to Top
APPROACH
Gather Information
Review the Operational Testing Plan (TA.110) document for planned operational testing requirements and activities. Determine which of the operational scenarios will be
tested. Determine the contextual processes and information that impact the operational test scenarios. Prepare the system environment for the operational testing
scenario to be performed.
Perform Operational Testing
Perform activities contained within the operational test scenario that was selected for testing. Record the results achieved from the operational test scenario performed.
Document Results and Analyze for Required Changes
Gather results of operational testing. Place results in required format for documentation of testing. Present results for analysis. Review results for success/failure against
previously agreed upon success criteria.
Back to Top
System Architect Ensure that all relevant areas have been addressed within the operational scenario to be tested. Ensure that all necessary
resources are available for operational testing.
20% allocated to the system architect. The team leader would then ensure that all necessary resources are available for
operational testing.
30
Database Administrator Perform the activities of the operational test scenario, and gather and report results. 70
IS Support Staff Review test results for completeness and success against measurable success criteria. *
IS Operations Staff Review test results for completeness and success against measurable success criteria. *
Back to Top
PREREQUISITES
Prerequisite Usage
Strategy (TA.020)
The Availability and Performance Requirements, along with the Service-Level Agreements will provide inputs for
comparison against results of testing.
(TA.060)
The System Operations and Management Strategy defines the operational processes that need to be tested.
(TA.070)
The Initial Architecture and Application Mapping provide technical detail on the architecture components within the
test.
Operational Testing Plan (TA.110) The Operational Testing Plan defines the test scenarios and provides the information used to conduct the testing.
Back to Top
TEMPLATES AND TOOLS
TA-120_OPERATIONAL_TEST_RESULTS.DOC MS WORD
Back to Top
The Operational Test Results are used in the following ways:
by the project leader to confirm the appropriateness of the architectural solution and gain the approval of the test performance metrics
by the project team to act as the basis for the documenting operational tasks in production.
by the production DBA to confirm test results and compare against estimates for operational requirements
by the IS support staff to confirm test results and compare against estimates for operational requirements
Distribute the Operational Test Results as follows:
to the technical architect to confirm technical appropriateness and feasibility
to the project leader to document testing activities performed
to the clients business personnel to confirm test scenario appropriateness
Back to Top
QUALITY CRITERIA
Have all activities within the tested operational scenarios been properly performed?
Are all relevant test results fully documented?
Have all relevant success criteria for testing?
Does each operational scenario provide might it's intended result within the expected time frames?
Do the operational performance metrics meet the Service Level Agreement guidelines for system availability?
Back to Top
TA.130 - CONDUCT BACKUP AND RECOVERY TEST
In this task, you conduct the backup and recovery test as defined in Define Backup and Recovery Testing Strategy (TA.080) and report the results. If any portions of the
initial tests are unsuccessful, the appropriate changes should be made and retesting should take place.
ACTIVITY
Back to Top
WORK PRODUCT
Backup and Recovery Test Results - The Backup and Recovery Test Results document the outcome of the Backup and Recovery Test activities.
Back to Top
TASK STEPS
None
1 Review the prerequisite work
products.
None Read the Backup and Recovery Strategy and review the Backup and Recovery Plan (TA.080).
environment for backup and
recovery testing.

3 Conduct testing. None Perform the backup and recovery test. Record the test results for inclusion in the Backup and Recovery Test
Results
success criteria.
None
reporting in the Backup and Recovery Test Results.
6 Report results of backup and
recovery testing.
Summary.
Backup and
Recovery Test
Summary
The Backup and Recovery Test Summary provides a management level overview of the test results. It is best
presented in the form of charts or graphs showing the percentage of tests that passed as expected, or other
summary information of interest.
8 Provide Test Results Detail. Backup and
Recovery Test
Detail
The Backup and Recovery Test Detail component provides the specific results of each individual test scenario.
Corrective Actions.
Outstanding
Corrective
Actions
Back to Top
APPROACH
Gather Information
Review the Backup and Recovery Strategy document for planned Backup and Recovery activities. Determine which of the Backup and Recovery scenarios that will be
tested. Determine the contextual processes and information that impact the Backup and Recovery scenario to be tested. Prepare the system environment for the Backup
and Recovery testing scenario to be performed.
Perform Backup and Recovery Testing
Perform activities contained within the Backup and Recovery test scenario that was selected for testing. Record the results achieved from the Backup and Recovery test
scenario performed.
Gather results of Backup and Recovery testing. Place results in required format for documentation of testing. Present results for analysis. Review results for
success/failure against previously agreed upon success criteria.
Back to Top
System Architect Ensure that all relevant areas have been addressed within the backup and recovery scenario to be tested. Ensure that all
necessary resources are available for Backup and Recovery testing.
Backup and Recovery testing.
30
Database Administrator Perform the activities of the backup and recovery test scenario, and gather and report results. 70
Back to Top
PREREQUISITES
Prerequisite Usage
Strategy (TA.020)
Backup and Recovery Strategy (TA.080) The Backup and Recovery Strategy provides the information used to construct the Backup and Recovery test and
provides the context within with the proper Backup and Recovery test scenario is performed.
Back to Top
TEMPLATES AND TOOLS
TA-130_BACKUP_AND_RECOVERY_TEST_RESULTS.DOC MS WORD
Back to Top
The Backup and Recovery Testing Results are used in the following ways:
by the project leader to confirm the appropriateness of the backup and recovery solution and gain the approval of the test performance metrics
by the project team to act as the basis for the documenting backup and recovery tasks in production.
by the production DBA to confirm test results and compare against estimates for backup and recovery performance
by the IS support staff to confirm test results and compare against estimates for backup and recovery performance
Distribute the Backup and Recovery Testing Results as follows:
to the technical architect to confirm technical appropriateness and feasibility
to the project leader to document testing activities performed
to the clients business personnel to confirm test scenario appropriateness
Back to Top
QUALITY CRITERIA
Have all activities within the tested backup and recovery scenario been properly performed?
Are all relevant test results fully documented?
Have all relevant success criteria for testing ?
Does each backup and recovery scenario provide availability in a timely manner for the business?
Do the backup and recovery performance metrics meet the Service Level Agreement guidelines for system availability?
Back to Top
TA.140 - CONDUCT DISASTER RECOVERY TEST
In this task, you conduct the Disaster Recovery testing as defined in Disaster Recovery Strategy (TA.050) and report the results. If any portions of the initial test are
unsuccessful, the appropriate changes should be made and retesting should take place.
This testing applies only to the technical systems components of the project, and is not intended to represent a complete restoration of business continuity functionality.
If your project includes establishing disaster recovery capability, you should perform this task.
ACTIVITY
Back to Top
WORK PRODUCT
Disaster Recovery Test Results - The Disaster Recovery Test Results document the outcome of the Disaster Recovery Test activities.
Back to Top
TASK STEPS
1 Review the prerequisite work
products.
None Read the Disaster Recovery Strategy and review the Disaster Recovery Plan (TA.090).
2 Schedule testing and test
resources
None Disaster Recovery Testing typically involves support from multiple organizational areas and is likely to require
advance scheduling.
environment for Disaster
Recovery testing.
None
4 Conduct testing. None Perform the backup and recovery test. Record the test results for inclusion in the Disaster Recovery Test Results.
success criteria.
None
reporting in the Disaster Recovery Test Results.
7 Report results of backup and
recovery testing.
Summary.
Disaster
Recovery Test
Summary
The Disaster Recovery Test Summary provides a management level overview of the test results. It is best presented
in the form of charts or graphs showing the percentage of tests that passed as expected, or other summary
information of interest.
9 Provide Test Results Detail. Disaster
Recovery Test
Detail
The Disaster Recovery Test Detail component provides the specific results of each individual test scenario.
Corrective Actions.
Outstanding
Corrective
Actions
Back to Top
APPROACH
Gather Information
Review the Disaster Recovery Strategy document for planned Disaster Recovery activities. Determine which of the Disaster Recovery scenarios that will be tested.
Determine the contextual processes and information that impact the Disaster Recovery scenario to be tested. Prepare the system environment for the Disaster Recovery
testing scenarios to be performed.
Perform Disaster Recovery Testing
Perform activities contained within the Disaster Recovery test scenario that was selected for testing. Record the results achieved from the Disaster Recovery test scenario
performed.
Gather results of Disaster Recovery testing. Place results in required format for documentation of testing. Present results for analysis. Review results for success/failure
against previously agreed upon success criteria.
Back to Top
System Architect Ensure that all relevant areas have been addressed within the disaster recovery scenario to be tested. Ensure that all
necessary resources are available for disaster recovery testing.
disaster recovery testing.
30
Database Administrator Perform the activities of the disaster recovery test scenario, and gather and report results. 70
Back to Top
PREREQUISITES
Prerequisite Usage
(TA.020)
Disaster Recovery Strategy (TA.050) The Disaster Recovery Strategy provides the information used to construct the Disaster Recovery test and
provides the context within with the proper Disaster Recovery test scenario is performed.
Back to Top
TEMPLATES AND TOOLS
TA-140_DISASTER_RECOVERY_TEST_RESULTS.DOC MS WORD
Back to Top
The Disaster Recovery Test Results are used in the following ways:
by the project leadership to confirm the ability of the disaster recovery strategy to meet the business requirements
by the project team to act as the basis for the production readiness determination
Distribute the Disaster Recovery Test Results as follows:
to the clients IS personnel for reference and to complete any follow up activity
to the clients business personnel to gain approval
Back to Top
QUALITY CRITERIA
Have all known disaster recovery test scenarios been successfully tested?
For any scenario requiring retesting, have the necessary changes been identified and planned?
Do the test results indicate that the Disaster Recovery Strategy will meet the business availability requirements?
Back to Top
TA.150 - DEFINE FINAL PLATFORM AND NETWORK
ARCHITECTURE
In this task, you define the physical platform and infrastructure that will be implemented to support your technical and application architecture. You map the physical
application and database server architectures on to specific computing platforms.
This task updates the work done in the Initial Architecture and Application Mapping (TA.070), incorporating any changes, additions or enhancements that have occurred
due to subsequent architecture design work. This task focuses on the future production environment and any supporting environments such as training or production
support. It does not address interim project environments that will not be retained after production cutover.
ACTIVITY
Back to Top
WORK PRODUCT
Final Platform and Network Architecture - The Final Platform and Network Architecture describes the deployment of the key platform (hardware) and network
components of the new system and their relations to the application and database architecture.
Back to Top
TASK STEPS
1 Review the prior
architectural design work
products.
Introduction In the Introduction, describe the purpose of the Final Architecture Overview. Specify scope and technical requirements,
particularly those that have not been addressed by prior tasks.
2 Review platform and
network standards.
Platform and
Network
Standards
Document any platform or network standards that have influences the final architecture design in the Platform and
Network Standards. If these standards have already been documented in the Architecture Requirements and
Strategy, you may refer to that document, or you may choose to reproduce some of the most relevant standards here
for ease of use.
3 Finalize the software and
hardware configuration for
each of the system
components.
Platform and
Network
Architecture
Document an overview of the platform and network architecture in the Platform and Network Architecture. Include each
data center or hosting facility that is affected by the implementation.
4 Complete detailed server
specification.
Server
Specification
In the Server Specification component, Provide detailed specifications of each server, including model, cpu and
memory configuration. Include servers that will house support components, such as tools or repository servers,
backup servers, etc.
5 Complete application
mapping.
Applications
Map
Use the Applications Map to map the application components to the specific servers they will run on. This is best
illustrated in a diagram.
6 Document network
configuration.
Network
Configuration
Document Network Configuration.
7 Document Client Desktop
configuration.
Client
Desktop Tier
In the Client Desktop Tier component, describe the minimum configuration required for client desktops, printers and
any required peripheral devices.
Back to Top
APPROACH
This task updates the work done in Initial Architecture and Application Mapping (TA.070) and the approach is the same. The task is separate in order to permit the
inclusion of new technical requirements that may have arisen as a result of capacity planning or performance testing, or from changes to the project business
requirements after the TA.070 was published. Use of diagrams should be emphasized to make the information as meaningful as possible, particular to a non-technical
audience.
Back to Top
Back to Top
System Architect Review prior architectural work and identify any technical requirement updates required. Prepare the work product. 70
System Analyst Provide information regarding the structure of the new system. 30
IS Operations Staff Provide information regarding the current and future software and hardware and review options for the new system. *
IS Support Staff Provide information regarding the current and future software and hardware and review options for the new system. *
IS Manager Review the Final Platform and Network Architecture and provide comments and approval. *
Back to Top
PREREQUISITES
Prerequisite Usage
before you can begin this task. Therefore, if not available, you should obtain this information prior to beginning
this task.
Reviewed Analysis Model (AN.110) Volume requirements, and the use cases that should be supported by the new system are included in the
Analysis Model. This information in conjunction with the distribution architecture is the basis for decisions
regarding the types, size and locations of processing and input/output devices for the new system.
(TA.020)
The Technical Architecture Requirements and Strategy describes the interfaces required for the new system to
co-exist with existing systems and is refined within the hardware and software definition.
Integration Architecture Strategy (TA.030) The Integration Architecture Strategy describes the integration requirements for the new system.
(TA.070)
The Initial Architecture and Application Mapping presents the proposed technical architecture, which updated in
this task.
Backup and Recovery Strategy (TA.080) The Backup and Recovery Strategy documents the requirements and approach used for application and system
backup and recovery.
(TA.060)
The System Operations and Management Strategy define the requirements for software support and
management tools.
Back to Top
TEMPLATES AND TOOLS
TA-150_FINAL_PLATFORM_AND_NETWORK_ARCHITECTURE.DOC MS WORD
Back to Top
The Final Platform and Network Architecture used in the following ways:
to procure the hardware and software needed to establish the production environment
by technical members to review
by technical personnel and users to review and to make sure it accurately reflects the technical architecture for the proposed system
Distribute the Final Platform and Network Architecture as follows:
to technical members for review
to technical personnel and users for review and agreement
Back to Top
QUALITY CRITERIA
Does the architecture fit within the IS organization's stated policies?
Are all the machines suggested available?
Are there sufficient ports for interconnection?
Does it fulfill the requirements of the System Capacity Plan?
Back to Top
TA.160 - DEFINE SYSTEM CAPACITY PLAN
In this task, you create the Capacity Plan for the new system. The plan should cover system capacity anticipated at production cut over and for some determined period
of future operations, allowing for business growth or other factors that could affect the system capacity requirements. The general term system capacity refers to the
ability of a system to support a number of user processing sessions, online and batch transactions rates, data volumes without unacceptable detriment to the
performance of the system.
This task focuses on the future production environment(s) and not interim project support environments. It's scope should include permanent support environments, such
as production support and training.
ACTIVITY
Back to Top
WORK PRODUCT
System Capacity Plan - The System Capacity Plan documents the projections of system capacity requirements for servers, disk, processing, memory and network
requirements and the corresponding detail worksheets that include the document the details, formulae, and assumptions on which the estimates were based.
Back to Top
TASK STEPS
1 Review existing
documentation.
Introduction Review existing documentation pertaining to system capacity planning, taking into account any subsequent architecture design
work.
2 Review or define
Capacity
Planning
Strategy.
Capacity
Planning
Strategy
The Capacity Planning Strategy component summarizes the approach used for capacity planning, and highlights any changes
required to the initial capacity planning or sizing methodology and the reasons for the change(s).
3 Document
Business
Volumes.
Business
Volumes
To complete the Business Volumes component, review the user and business volume estimates and predictions for future growth
. Confirm and summarize volume requirements
4 Document
Production
Environment
recommendations.
Production
Environment
The Production Environment component summarizes the capacity requirements for the production environments. Validate any
prior sizing or capacity planned done, research capabilities and requirements for the production platform servers and document
recommendations. Include recommendations related to short term or long tern capacity shortfalls.
5 Document
Support and
Training
Environment
recommendations.
Support and
Training
Environments
The Support and Training Environments component summarizes the capacity requirements for the any permanent non-
production environments, such as a training environment or development, test or production support environments. Validate any
prior sizing or capacity planned done, research capabilities and requirements for the support and training environment servers
and document recommendations. Include recommendations related to short term or long tern capacity shortfalls.
6 Document Client
Desktop
recommendations.
Client
Desktop
The Client Desktop component summarizes the capacity requirements for the client desktop machines that will access the new
application environments.
7 Document
Assumptions and
Constraints.
Assumptions
and
Constraints
The Assumptions and Constraints component lists the assumption used in the System Capacity Plan and any constraints that
were applied to the capacity planning process.
8 Document Risks
and Risk
management
recommendations.
Risks System Capacity Planning is an inherently risky process. The Risks component should articulate the risks and suggest mitigation
strategies, particularly in the areas of capacity shortfall.
Back to Top
APPROACH
This strategy for capacity planning may have been decided when the Technical Architecture Requirements and Strategy (TA.020) was created. If this is the case, review
the existing strategy, taking into account any subsequent architecture design work, and any requirement changes before executing this task. If the subsequent design
work has uncovered issues or changes of requirements that indicate a change of capacity planning strategy is needed, then an initial step of agreeing on a new strategy
may be required.
An initial system capacity analysis or sizing exercise may have been completed either as part of the sales cycle or as part of the Architecture Requirements and Strategy
task. These initial studies should be the basis for the work performed in this task, although here it is undertaken in more detail and to completion. Combine all the sizing
results, predictions for future growth, benchmark or performance test results and the strategy to address future shortfall to complete the System Capacity Plan.
System Capacity Planning Topics
The System Capacity Plan should cover the following topics:
database servers
application servers
tools and management servers
disaster recovery servers
client desktop machines
disk requirements
print servers and printing requirements
network infrastructure requirements
backup devices
tape storage requirements
Relationship Between System Performance and Capacity Planning
The relationship between system capacity and performance is an indirect and approximate one. In very simple terms, and transaction volume increases, the process
performance of the transactions should stay approximately constant or slightly decrease incrementally. At a certain level of transactions per second, the performance
begins to degrade dramatically because some limiting system resource in CPU cycles, memory or network has been exhausted. This "knee" in the performance curve
represents the system capacity for that resource.
It is important to understand the limitation of capacity studies of CPU and memory processing for servers. The System Capacity Plan attempts to understand the limits of
the relative performance of the server or servers (for example, the performance with a certain volume of users and transactions relative to alternative workload). The
capacity study of the CPU and memory of the server makes no prediction about the absolute performance of a particular transaction or portion of the application
software. Absolute performance depends on many factors, including the optimization of the application code, the speed and frequency of the processors, the scalability
of the processors against the system bus in a Symmetric Multiprocessor (SMP) platform, specific processor cache sizes, and so on. The absolute performance of a
particular transaction cannot be estimated without conducting a complex study of the relevant variables. Rather than undertake such an effort, absolute performance of
transactions should be measured empirically in a simulation of the future system or inferred from analogous implementations.
Obstacle to Accurate System Capacity Planning
In contrast to older mainframe environment where the technical configuration was limited to a small number for possibilities, modern web based open systems have a
multiple permutations of applications, platforms, network vendors, versions and products. The widespread disparity of technical components and configuration and the
rapidly changing technology stack means that there is limited access to detailed metrics for response times and transactions per second, particularly when compared with
older mainframe environments. The variability of technology coupled with the variability of industry specific business process and functions for different companies
makes it extremely difficult to use a purely theoretical analysis to planning capacity requirements.
Methods of Capacity Planning
There are a variety of approaches to capacity planning, each with it's own advantages and disadvantages and level of effort.
Analogous Implementation - this method is based on evaluating other implementations of the same application modules and user workload. While it may be difficult for
you to identify a duplicate implementation effort, the models the hardware vendor provide for sizing packaged application in partnership with Oracle are based on the
experience of multiple implementations and benchmark tests and represent a reasonably reliable form capacity planning based on Analogous Implementation. When
hardware vendor models for the application being implemented are available, this is the preferred approach.
Rule of Thumb - the simplest method of planning capacity is to use rule-of-thumb metrics for memory and processing requirements, network bandwidth and latency
requirements. While this method is simple, it is very unsophisticated, likely to be inaccurate and at best can only provide an order of magnitude estimate of actual
capacity requirements. This is better than no planning at all, but has a high degree of risk. An architecture using rule-of-thumb capacity planning should emphasis
flexible and easily scalable architecture design.
Statistical Summation - a mathematical model that attempts to derive meaning linear mathematical relationships between a few measurements of key system resource
metrics and individual system or user processes (transaction flows). This is a complex method, requiring experience and technical expertise to perform.
System Modeling - a more detailed analysis that looks at major transaction flows to be executed in the system architecture and determines the system and network
resource usage by transaction flow. Multiplication of usage per flow by the number of session executing the flow provides a system capacity estimate, especially when a
CPU queuing model is built in. This is a complex mathematical technique that requires experience and technical expertise to perform.
Capacity Planning by Simulation - this method builds a simulated of the system architecture to the level required to obtain a certain degree of confidence in the results
and to allow direct measure of system resource requirements. This technique is the the most able to generate accurate and reliable results, but it can be be costly,
resource intensive and time-consuming to perform simulations with provide a high degree of accuracy. This technique is discussed in more detail in the Performance
Management process method guidelines (PT), and capacity planning is one reason you might seek to conduct a system performance test.
Work with the Hardware Vendor
Hardware vendors have up-to-date metrics for the capacity and performance of their servers. The vendor may also offer technical consulting services with consultants
who are familiar with the applications you are implementing. You should discuss your capacity planning requirements with the hardware platform vendors and determine
what level of assistance they can provide for this task.
Capacity Planning Scenarios
In order to relate the capacity planning to realistic processing situations in the new system, system scenarios need to be defined. The system capacity planning scenarios
are analogous to the Performance Test Scenarios defined in the Performance Test Models and Scenarios (PT.040) task of the Performance Management process (PT).
They enable you to relate the results of your capacity planning or performance testing in a top-down method to system processing situation that concern the business,
either because of expected resource load during periods of heavy processing such as quarter end, or because of concern about the ability of the system to provide the
required performance service level to external customers or internal users.
When mapping the capacity planning scenarios to realistic point-in-time snapshots of system processing, consider:
Is there clear definition of the future period (the capacity planning horizon)?
Are projected changes to user numbers of business volumes well understood?
Are the plans to expand the number of transactions of increase user session as a result up planned system extensions or enhancements?
If the system is currently intranet only, will it be extended to the internet in the future?
How many simultaneous application session will each group of users require to perform their jobs?
Are there peak workload periods or seasonal processing requirements that should be considered?
Are there other applications sharing the same infrastructure, or will there be at some point in the future?
For more information on identifying scenarios for performance testing and capacity planning, refer to the Performance Test Models and Scenarios (PT.040) task of the
Performance Management process (PT).
Disk Sizing
Planning the capacity of disk space is one of the less risky aspect of capacity planning, unless the implementation hardware platform budget has a very slim margin of
error. The real cost of disk capacity continues to trend downward, allowing disk purchased for new implementation to provide a safety margin in the estimates. Disk
estimates completed at the time of initial architecture design may only account for initial business volumes and and should be targeted to provide a an approximate figure
that may have a margin of error of up to 50%.
As the project progresses, the required business data volumes, archive and purges processes and other factors such as use of disk mirroring and planned retention of
backups on disk will be better understood, and the disk estimated can be correspondingly improved. As with processing capacity, the disk capacity should be estimated
to handle the production cut over requirements as will as a predetermined period of production operations, including the requirements related to both business and data
growth.
Network Capacity Planning
Networks are constrained by two factors - bandwidth and latency. Network bandwidth is the data rate supported by a network connection or interface. Bandwidth is
commonly expressed in terms of bits per second (bps). For example, ethernet is available as 10 Mbps, 100Mbps and 1 Gbps. Bandwidth represents the capacity of the
connection. A common misunderstanding is that the the greater the capacity, the greater the performance. This is not always the case because also depends on
latency. In a network, latency, a synonym for delay, is an expression of how much time it takes for a packer of data to get from one designated point on the network to
another. The contributors to latency are:
Propagation: The time it takes for a packet to travel between one place and another at the speed of light
Transmission: The medium itself (whether cable, optical fiber, or some other) introduces some delay. The size of the packet is also a contributing factor since a
larger packet takes longer to receive and return than a small one
Router and other processing: Each node on the network requires time to examine and possibly change the header in a packer
Other computer and storage delays: Within networks at the end of each network, a packet may be subject to storage and hard disk access delays at intermediate
devices such as switches and bridges.
Multi-tier applications are sensitive to constraints in both bandwidth and latency. Applications should be designed to be "network friendly", that is, to limit the and size of
packets required to complete a transaction, but even the most optimally designed application's performance can be impacted if the bandwidth is consumed by other users
on the same network. It is possible to have poor performance even though the bandwidth is adequate due to the impact of latency. Latency is a critical component of
performance in a clustered GRID environment where only minimum delay can be tolerated in communication between the nodes.
If a network device is undersized or overloaded, it may impose a delay in forwarding the transaction to the next segment in the path. This can results in a high bandwidth
link being under-utilized. Both bandwidth and latency should be considered when addressing network capacity as increasing bandwidth alone may provide little to no
performance improvement if unresolved latency issues exist. Bandwidth and latency combine to determine the overall performance of a network, and careful sizing and
designing of both links and routing is critical to achieving high performance at a reasonable cost.
System Capacity Shortfall
If the System Capacity Plan predicts a shortfall in capacity after a certain period, it is possible that the technical architecture may need to be upgraded or altered to
provide extra capacity. Prior to changing the architecture, an evaluation of resource usage should be conducted to validate that the shortfall is not due to poorly optimized
application components that are consuming excessive resources. It is often possible to reduce capacity requirements in an existing architecture by optimizing the
workload using performance management techniques, thus avoiding or delaying an expensive architecture upgrade.
Shortfalls in capacity may arise because the business growth is larger than originally anticipated. While a thorough capacity plan should address the requirements of
future growth, the architecture should be designed to allow scalability either vertically (adding more cpu or memory to an existing server) or horizontally (adding additional
servers).
A shortfall in disk capacity can usually be remedied by adding addition disk to the IO subsystem. If the IO subsystem has reached it's maximum capacity, an alternative
configuration may be required. The disk capacity planning should predict this eventually and suggest a course of action before the actually shortage is encountered.
Application and Web servers may scaled horizontally adding additional servers, assuming that the application architecture includes a load balancing capacity. A shortfall
in the database servers can also be addressed either by scaling the database server vertically by adding additional processors or memory or by adding addition nodes to
the cluster. If the architecture uses a single SMP server for the database processing and the server has reached it's capacity, the server capacity planning should predict
this eventuality and suggest either a migration to a larger SMP or migration to a Grid architecture that provides horizontal scalability. Network issues related to bandwidth
may required either adding additional circuits or upgrading existing circuits. Network upgrades are typically required long lead times, so monitoring of capacity is
especially important. If the problem is related to latency, then a segment by segment analysis may indicate the need to upgrade a particular router or network device.
Back to Top
System Architect Review previous capacity planning, architecture and volume documents. Work with hardware vendor to perform or validate
capacity planning strategy. Prepare System Capacity Plan.
80
System Analyst Provide information regarding the capacity planning scenarios. 10
Database Administrator Provide information relating to database processing and disk requirements. 10
Network Administrator Provide information relating to network configuration and capacity. *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Capacity Plan (ENV.EA.057) Use this Envision work product or a similar enterprise-level document, if available. You may need this information
before you can begin this task. Therefore, if it is not available, you should obtain this information prior to beginning
this task.
Architecture Description (DS.040) The Architecture Description outlines the Design and Deployment models and their architecture. This provides a
necessary input to the System Capacity Plan.
Architectural Prototypes (IM.020) The Architectural Prototypes address architectural design decisions. These may also have addressed issues that
are related to capacity. The decisions made as part of that process provide an input to the System Capacity Plan.
Strategy (TA.020)
The Technical Architecture Requirements and Strategy provides the basis for initial capacity planning or sizing and
information on user volumes and transaction requirements.
(TA.070)
The Initial Architecture and Application Mapping details the technical architecture.
Back to Top
TEMPLATES AND TOOLS
TA-160_SYSTEM_CAPACITY_PLAN.DOC MS WORD
Back to Top
The System Capacity Plan is used in the following ways:
architecture team members to review and to prepare the production, support and training environments
by technical personnel to review and to make sure it accurately reflects the capacity requirements for the new system
Distribute the System Capacity Plan as follows:
Project Manager
Information System Manager
Architecture team members
Back to Top
QUALITY CRITERIA
Is there a clear strategy for system capacity planning?
Are the formulas and metrics used develop the system capacity plan based on a sound model and clearly documented?
Does the capacity plan cover database server processor, memory and disk requirements?
Does the system capacity plan address capacity issues after production cutover?
Does the system capacity plan consider future business growth and any other applications or systems that will compete for the same system resources?
Have the client platforms been considered?
Back to Top
[CV] DATA ACQUISITION AND CONVERSION
The objective of the Data Acquisition and Conversion process is to create the components necessary to extract, transform, transport and load the legacy source data to
accommodate the information needs of the new system. The data that is required to be converted is explicitly defined, along with its sources. This data may be needed
for system testing, training, and acceptance testing as well as for production. In some cases, it is beneficial to convert (some) data at earlier stages to provide as realistic
as possible reviews of the components during the development iterations. On the other hand, this may be difficult, as the actual Database Design for the new system is
not yet stabilized.
The amount of effort involved with conversion greatly depends on the condition of the data and the knowledge and complexity of the data structure in legacy systems and
existing applications. For large projects, where large existing systems will be replaced, and most all of the data needs to be converted, you should consider running this
as a separate project in parallel to the development project. In such situations, you need to thoroughly analyze the existing systems, map them to the new data model,
and build multiple conversion modules of various complexities. The process includes designing, coding, and testing any conversion modules that are necessary as well
as the conversion itself. The cleaning of legacy data is visibly identified as a user and client project staff task so that it can be staffed and scheduled. If data anomalies
exist in the current system(s), or there are an unusual number of exceptions, you should recommend data clean-up to the project sponsor.
The term "ETL" is commonly used to reference the steps of extracting, transforming, and loading of data from data sources to the new target system, which is also
sometimes referenced simply as conversion. It should be noted that in some cases the "T" (transformation) of "ETL" may be as minimal as encoding or decoding source
data during extraction and loading steps, or no transformation may occur at all in some solutions.
It is important to note that the Data Acquisition and Conversion process has two tasks that encompass initial (one-time) handling of data sourcing, as well as ongoing data
loads such as interfaces, but this dual coverage only occurs where there is overlap between the two distinct data handling processes (initial and ongoing).
The following are the two tasks within the CV process that pertain to both one-time, and ongoing data sourcing:
Define Data Acquisition and Conversion Requirements (CV.010)
Define Data Acquisition, Conversion, and Data Quality Strategy (CV.20)
The remainder of the tasks defined in the Data Acquisition and Conversion process apply strictly to the initial (one-time) loading of source data into the new system. The
comparable tasks for defining, designing, building, testing, etc. for ongoing data sources such as interfaces are addressed in the normal OUM full lifecycle processes and
tasks.
For example, ETL components for initial (one-time) data sources are built in OUM task of Implement Conversion Components (CV.055), and ETL components for ongoing
data sources such as interfaces are built in OUM task of Implement Components [IM.050]. There can be functional overlap between the initial and ongoing component
development where data sources are being used for both initial and ongoing ETL. In this situation one should attempt to maximize reuse between requirements definition,
design, building, etc. of components.
It should also be noted that Conduct Business Data Source Gap Analysis (RA.160), and Conduct Data Quality Assessment (RA.170) apply to both the initial (one-time)
and the ongoing data sourcing.
Converted legacy data may be needed for various types of testing, in particular system testing, and acceptance testing, and training as well as for production. In some
cases, it is beneficial to even convert (some) data at an earlier stage to provide as realistic as possible reviews of the components during the development iterations. On
the other hand, this may be difficult, as the actual Database Design for the new system is not yet stabilized.
It should be noted that the Data Acquisition and Conversion process is sometimes performed as a separate project for some types of engagements. For example, a
technology-centric solution is a possible scenario where one might find this project level work partitioning.
Early in the Data Acquisition and Conversion process, the project team determines an overall Data Acquisition, Conversion and Data Quality Strategy (CV.020) to meet
the Data Acquisition and Conversion Requirements (CV.010), including both automated and manual methods. These work products include defining the requirements
and strategy for both initial load (aka first-time load, one-time historical load, conversion) and ongoing (refresh) loads. At this time, data sources are identified and the
overall strategy is defined, in particular for the first-time load, subsequent refresh and to address any specific data quality issues. Analysis is performed on the data
sources and a mapping is created between the current state of the source data and the new set of objects that define the target system.
Later in the process, with the detailed analysis completed, the project team designs, codes and tests the conversion components that are used for the initial load only, that
is the conversion or the one-time initial load of historical data. Finally, the process ends with executing the conversion/load itself.
The amount of effort involved greatly depends on the condition of the data and the knowledge and complexity of the data structure in the legacy systems and existing
applications. For large projects, where large existing systems should be replaced, and most of the data needs to be converted, you should consider running this as a
separate project in parallel to the development project. In such situations, you need to thoroughly analyze the existing systems, map them to the new data model, and
probably build multiple components of various complexities.
The cleaning of legacy data is visibly identified as a user and client project staff task so that it can be staffed and scheduled. If data anomalies exist in the current
system(s), or there is an unusual number of exceptions, you should recommend data clean-up to the project sponsor.
#TOP #TOP
Back to Top
PROCESS FLOW
Back to Top
APPROACH
Depending on your project (e.g., large, complex, etc.), the project manager may designate a Data Acquisition and Conversion team leader. In some projects the data
conversion effort is a "sub-project" to the overall software implementation effort. If the project manager designates a Data Acquisition and Conversion team leader, they
are responsible for leading the Data Acquisition and Conversion process and reviewing the work products. The team leader plans, directs, and monitors the day-to-day
work of the team. The team leader assigns work packages to the team members and makes sure they understand the requirements. The team leader is responsible for
building team cohesion, motivating the teams, and providing assistance and encouragement to the team members. Each team leader performs the final quality control
and quality assurance for the team by reviewing all work products. The team leader also signs off on team work completion and quality. Work that is not up to quality
standards is returned. Team leaders review work products from other teams when these work products may impact aspects of the system. The team leader reports the
team's progress to the project manager. Refer to Project Management in OUM for additional information on team leaders.
The Data Acquisition and Conversion process starts with the definition of the functional requirements necessary to convert and load data from an existing information
system onto the new information system (CV.010). This includes analyzing the potential source and target systems to identify and document the following: data to be
converted, functional requirements for extracting and loading the data, requirements for validating and cleaning up both extract and load, and requirements for handling
the error conditions. In addition, you document the high-level source data available. This includes reviewing existing models and other descriptive information for the
operational and external data sources identifying preferred data sources, identifying the system of record for these sources, and documenting system constraints (for
example, batch windows, system interdependencies, access constraints, and availability). Data volumes gathered here feed into the Architecture Requirements and
Strategy (TA.020) and ultimately the System Capacity Plan (TA.160).
This data may be needed for system testing, training and acceptance testing as well as production. Following this, the project team determines an overall Data
Acquisition, Conversion and Data Quality Strategy (CV.020) to meet those requirements, including both automated and manual methods.
The acquisition needs can be identified by focusing on the following:
Data Extraction Interfaces
Data Transportation Mechanisms
Change Data Capture Methods and Corresponding Constraints
The conversion needs can be identified by focusing on the following categories:
Master Data: Master data is the kind of data that has a more or less static nature. This data is typically set up during the implementation system configuration. An
example is inventory part numbers in an inventory control system. This is also probably the data that will be most stable, and therefore best can be used during
validations and reviews.
Document Data: Document data is the kind of data that is more dynamic, but goes through a lifecycle in the system. This kind of data either establishes control or
initiates processes. An example of document data is a sales order which deducts inventory from an inventory control system.
Transactions Data: Transactions data is the kind of data that reflects an activity in the system, often related to document data. An example of a transaction is an
inventory, issue, receipt, or shipment. Each type of transaction should be evaluated for applicable status (open or closed), historical postings (weeks, months,
years), and present or future periods.
As soon as the requirements and the strategy have been documented, analysis is performed on the data sources and a mapping is created between the current state of
the source data and the new set of objects. Then you can start on what components need to be designed (CV.040) and implemented (CV.050), and finally tested
(CV.055, CV.060, CV.062 and CV.063). In most situations, the conversion is a one-time only process, therefore, the requirements on how the conversion components
should be developed are not as stringent as the requirements for the components developed to support the business. However, there might be situations where the
conversion needs to run multiple times, for example for different user groups or locations at different points of time.
When the Conversion components are ready and tested, an initial conversion can be done and the data verified (CV.065). Cleaning of data (CV.068) is primarily a user
task, with additional support from the client project staff. The work involved in cleaning legacy data, and in convincing those responsible that their data is inconsistent and
needs cleaning should not be underestimated. This may an iterative process, as you after having cleaned data, make a new attempt to convert, and clean data until you
have a satisfied result.
The data should preferably be cleaned in the originating systems. However, this is not always possible. Keep in mind that if the legacy system is still used when
performing the first conversion, and the the data is cleaned outside the existing system, any data that has been changed or new data that has been added in the existing
system since the first conversion will naturally not be included in the final conversion. If you need to clean data outside the existing system, identify all required cleaning
actions, and plan to do this after the last conversion to prevent duplication of work.
Finally, when the data has been cleaned and the result is acceptable, and the new system is ready to go production, we do another final conversion into the production
database (CV.065). Preferably this kind of conversion has also been tested by converting the data into both the System Test and Acceptance Test Environments.
During Production, these components are executed you populate the production databases with the initial and any historical data that is required.
Back to Top
Inception Phase
CV.010 Define Data Acquisition and Conversion Requirements Data Acquisition and Conversion Requirements
Elaboration Phase
CV.020 Define Data Acquisition, Conversion and Data Quality Strategy Data Acquisition, Conversion and Data Quality Strategy
CV.025 Define Data Acquisition and Conversion Standards Data Acquisition and Conversion Standards
Construction Phase
CV.040.2 Design Conversion Components (Initial Load) Conversion Component Desigs (Initial Load)
CV.065.1 Convert And Verify Data (Initial Load) Converted And Verified Data (Initial Load)
Transition Phase
CV.065.2 Convert And Verify Data (Initial Load) Converted And Verified Data (Initial Load)
Back to Top
OBJECTIVES
The objectives of the Data Acquisition and Conversion process are:
Define the needs for the conversion and migration of existing legacy data to the planned Oracle environment.
Design the strategy, programs, and test procedures needed to convert and migrate the legacy data to the planned Oracle environment.
Build the necessary components and test cases to convert and migrate the legacy data to the planned Oracle environment.
Provide test data in a timely manner.
Detect and correct errors and inconsistencies in legacy data.
Convert and migrate the legacy data to the Oracle environment to provide the users with accurate data which meets all predefined business requirements.
Verify the correctness of the converted data.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role ID Name Responsibility
Specialist
BA Business Analyst
DBA Database Administrator
DV Developer Lead the design and build and test of the data conversion components. Design and build the conversion components. Develop test
specifications and perform the test of the components. Plan and coordinate the initial test conversion. Run the conversion
components for a subset of production data and verify the production data. Track and analyze the problems identified with
conversion components and production data.
SAD System Administrator
SAN System Analyst Identify and document the source systems to be converted. Prepare the functional conversion requirements. Document the special
considerations and technical assumptions.
SA System Architect
SA (IA) System Architect
Formulate the projects Data Acquisition, Conversion and Data Quality Strategy. Contact appropriate technical experts for advice if
necessary. Develop a testing strategy for data conversion modules. Identify, assess and mitigate data conversion risks. Define
issue-tracking procedures. Review the Designed Data Conversion Components. Review the Implemented Conversion Components
code. Analyze the problems identified with the legacy data and refine strategies. Check the quality of the Data Acquisition and
Control process. Preferably, this should be done by a system architect that specializes in Information Architecture.
TE Tester Perform conversion component business object test and validation test.
Client (User)
KEY Ambassador User Select a representative subsection of production data for test conversion. Review and suggest amendments to be made to make
sure the data is consistent and complete. If the data must be manually cleaned, the ambassador user should be charged with
making these modifications.
CDA Client Data Administrator Provide the conversion requirements, special considerations and technical assumptions. Provide information on existing systems.
Analyze the problems identified with the legacy data. Make sure that the converted data meets the requirements of the business.
Review data provided for testing purposes to make sure it is consistent and complete.
CDDBA Client Development DBA
CPDBA Client Production DBA Create and run a master script that creates the necessary temporary tables.
CPM Client Project Manager
CSM Client Staff Member
CSA Client System Architect
ISM IS Manager
OS IS Operations Staff Provide information on data to be converted and current application structure. Assist with privileged access to external systems.
SS IS Support Staff Assist in interpretation of rejected records.
USR User Provide information on data to be converted.
Back to Top
Availability of Resources Knowing the Old System/Clear Understanding of Legacy System Data: It is important that at least one client resource that knows
the internals of the old system is appointed to take part in the Data Acquisition and Conversion process. There are various reasons why the the client may find it
difficult to find such a person. One reason might be that they feel ownership for the old system, and that system is being out phased. Try to make them see the
benefits of participating so that they have the opportunity to learn about the new system. To ensure that the data in the old system is interpreted correctly, it is
important to have such a resource available.
Adequate Documentation of Existing Data Definitions: If the documentation of the legacy system is poor, there is a larger risk that the data will be interpreted
incorrectly. If that is the case, the above critical success factor becomes even more critical.
Adequate Business Expertise to Assure Resulting Data Quality: As part of the data verification process, mainly performed by the client, resources must be
used that have sufficient business expertise to make a good data qualification. Convince the client to verify their data quality early in the process so that a cleanup
can be properly planned.
Clear Business Understanding of Historical Versus Current Business Needs: To determine what kind of data must be converted, it is important to be able to
distinguish between what is necessary data in the new system, compared to what was needed in the old system. Especially when you implement new and
improved business process, you must be aware that old data may not be needed for conversion, or, you may get a more complex conversion (for example, data
that is structured in many different tables in the old system(s) may be consolidated to fewer tables in the new). Ensure that the new business requirements are
considered when determining what should be converted.
Timely Access to Legacy System Data: To prevent any delays in the conversion process, it is important that the legacy system data is available whenever
necessary. If organizations or persons outside the project should deliver the data, make clear plans for when you need access to what kind of data so that this can
be communicated early.
Development of Conversion Execution and Transition Plan: The Data Acquisition and Conversion process must often be done in a certain order to prevent
certain errors. A step-by-step plan must be produced and tested to prevent as many rejections as possible.
Data Exception Handling Procedures in Place: Even when the conversion has been tested and the data has been cleaned, it is likely that errors will occur. A
proper exception handling procedure must be built into the conversion components to ensure that data records can be investigated and handled, possibly
manually, at the end.
Data Reconciliation and Error Handling Procedures in Place: The actual data conversion into the production database is often very time-constrained.
Therefore, there must be clear procedures in place to handle required data reconciliation or errors that occur during the Data Acquisition and Conversion process.
Back to Top
CV.010 - DEFINE DATA ACQUISITION AND CONVERSION
REQUIREMENTS
In this task, you define the conversion scope, objectives and requirements, document the high-level source data available to support both the initial load of legacy data
and ongoing integration requirements, and identify the high-level issues relating to data ownership and broad processes for resolving data quality issues.
Document the functional requirements necessary to convert and load data from an existing information system into the new information system. This includes analyzing
the potential source and target systems to identify and document the following: data to be converted, functional requirements for extracting and loading the data,
requirements for validating and cleaning up both extract and load, and requirements for handling the error conditions.The functional conversion requirements are
analyzed separately from the functional requirements necessary to meet the business objectives. This is necessary because they typically result in one-time system
functions that require further specialized detailed analysis. Functional conversion requirements are designed and developed as a separate distinct activity. This
separation is necessary to emphasize the complexity, special processing and testing requirements, skill sets necessary to perform the conversion, and the throw away
nature of the entire Data Acquisition and Conversion process.
In order to document the high-level data sources, review existing models and other descriptive information for the operational and external data sources to identify
preferred data sources, identify the system of record for these sources, and document system constraints (for example, batch windows, system interdependencies,
access constraints, and availability). Data volumes gathered here feed into the Architecture Requirements and Strategy (TA.020) and ultimately the System Capacity
Plan (TA.160).
ACTIVITY
Back to Top
WORK PRODUCT
Data Acquisition and Conversion Requirements - The Data Acquisition and Conversion Requirements defines the scope and objectives as well as the critical success
factors and risks associated with the data conversion. It also identifies the selected list of operational and external data sources required to meet any information
requirements and the high-level approach and criteria for ensuring ongoing data integrity. It provides recommendations for preferred systems for each source data and
creates a system of record for those original data sources. It defines the flow of data between business functions and source systems, and identifies any operational
constraints, which could impact the solution. Data Volumes should also be collected. The Data Acquisition and Conversion Requirements is the highest-level document
that describes the business conversion requirements and identifies data sources. It also clearly defines the scope of the project and is used as a reference point for scope
and change management.
Back to Top
TASK STEPS
1 Provide an introduction for the document. Introduction The Introduction describes the purpose, content, uses,
and quality criteria of the work product.
2 Document any pertinent overview information. Data Acquisition
and Conversion
Overview
This component provides details on how the Data
Acquisition and Conversion process is used to realize
the data acquisition, data conversion and data quality
requirements of the project.
3 Identify all potential source systems and define a System Type for each source.
Capture information about the source, (e.g., H/W, DB, Op.Sys). Include a comment
as to this sources suitability. Lastly, examine the potential source systems to
determine if there are any existing extracts that could be reused (their frequency and
format). For new extracts determine the record layouts. For new and existing extracts
add a comment to suggest full or incremental and or data quality.
Data Acquisition -
Source System
Identification
One of the most critical tasks in Data Acquisition is
determining source systems. Typically, several systems
of varying types (legacy, operational, packaged, or
external) provide source data. This component
documents the various elements of the source systems.
4 For each source system determine what batch window is available on a regular basis
to extract the required data. Determine the loading on the machine to determine the
off peak period in which the schedule data extracts. Record any existing reporting or
maintenance tasks that are already being run in these off peak batch windows.
Data Acquisition -
Source System
Constraints -
Batch Windows
Information will periodically be extracted from the source
systems identified to the targets of the data warehouse
solution being designed. Although simple in concept,
there are many factors that impact the extraction of data.
This component documents how batch window time
frames, system dependencies, and access constraints
should be analyzed.
5 Meet with client to see if a Source System Interdependency study and diagram exist.
Create a Source System Interdependencies diagram.
Data Acquisition -
Source System
Constraints -
System
Interdependencies
The System Interdependencies diagram should identify
all systems considered as data sources with a clear
indication of the main data flows and dependencies.
6 Investigate each potential source system to identify access constraints. Determine
the severity of the constraint and potential mitigation.
Data Acquisition -
Source System
Constraints -
Access
Constraints
The Access Constraints documents any and all possible
system constraints for all source systems previously
identified.
7 For each of the existing or potential extracts from each source system investigate the
data volumes. Aim to record logical and physical volumes of the largest extracts,
comment on the smaller ones. Determine the likely growth in these source systems
and record that information.
Data Acquisition -
Data Volumes
This component describes the data volumes on the
various source systems identified.
8 Describe any pertinent project history. Data Conversion -
Background
The Background component describes the project's
history including previously initiated and completed
tasks which may impact conversion, as well as decisions
and any related scope-setting information.
9 Document functional requirements for extracting and loading the data. Data Conversion -
Scope
Data Conversion
- Constraints
The Scope lists all information that sets management
and client expectations.
The Constraints component provides relevant
information for all constraints. All dependencies within
the Data Acquisition and Conversion process as well as
dependencies with other processes should be listed as
constraints. Traditional constraints such as resources,
hardware, software, etc. should also be listed.
10 Specify conversion requirements Data Conversion -
Requirements
The Requirements provide a table displaying an
organized way to gather and document the detailed
conversion requirements of the business. This table
should contain the following columns:
Source Application
Business Objects
Order
Disposition
Number of Records
Oracle or Target Application
11 Define requirements for validating and cleaning up both extract and load. Data Conversion -
Validation and
Data Cleaning
Requirements
The Validation and Data Cleaning Requirements lists any
requirements for validating imported data.
12 Identify requirements for handling the error conditions. Data Conversion -
Data Conversion
Error Conditions
This component provides information on any automated
tests that will be performed against the data and how
exceptions (error conditions) encountered will be
handled.
13 Document the identified data quality objectives. It is important to enter only those
objectives, that were identified and which are essential for the solution.
Data Quality -
Objectives
This component defines a high-level overview of the
objectives of the data quality management in the
solution, as well as the objectives. Include any details
that are known at this time in the project, such as, data
quality measures (KPIs).
14 Review the source systems previously identified and collect any relevant reference
information to document the broad processes for resolving data quality.
Data Quality -
Processes
This component provides the description of the
processes related to the data quality, such as, Data
Transfer, Data Cleansing, Audit and Control, and Error
and Exception Handling.
15 Document any high-level high-level issues relating to data ownership relevant to data
quality.
Data Quality -
Data Ownership
This component defines any high-level issues relating to
the ownership of data components and responsibility for
solving end escalating data quality related issues.
Back to Top
APPROACH
This task is mandatory and should be performed at least once (always consider the iterative nature of OUM).
Data conversion can be a major component of a project and is critical to the success of the overall project. (For some projects, the conversion effort may be organized as
a subproject.) Identify data to be converted in conjunction with both the user and technical staff to help ensure that the data to be converted is meaningful. It is important
to obtain samples of the conversion data. When determining the legacy data for conversion, keep in mind external audit requirements that the data must meet and
accurately record the business rules of your organization that you will translate to the target applications.
Data Acquisition
SOURCE SYSTEM IDENTIFICATION
Source Systems
There are many types of source systems (listed in the deliverable template as background information.) All potential systems should be considered and all source systems
identified using the steps listed above.
All source systems must be categorized as a legacy system, operational system, packaged application or external data. For each source system, it is necessary to identify
the hardware platform and operating system, application version, and installed module. It is also important to capture the main entities stored by the system and whether
the system is the primary source for an entity (i.e., whether the entity is primarily maintained by this system).
Extract Format and Frequency
Provide a table that captures the record formats of data extracts that could be re-used. For existing extracts, record all extracts that could be possibly used including their
frequency. For the new extracts (to be developed) record the preferred format. For the mainframe data, capture format of records (if no extracts exists). In comment,
mention whether the extract is incremental or full (=all records).
For each source systems identified above, identify the mechanism for recording data. For the ETL tool to be used, it is necessary to evaluate how the tool will tackle the
record format.
SOURCE SYSTEM CONSTRAINTS
Batch Windows
All source system data must be analyzed to determine optimal batch windows for extracting the data, transforming it and loading it into the new system. Remember to
schedule batch windows during off-peak hours whenever possible so as to reduce the impact on the daily operations of the business.
Remember to also consider regularly scheduled reporting and database maintenance tasks that must also be completed. Also remember that as data volumes grow, there
is greater stress is placed on the ETL processes to complete in the allotted batch window time frame.
Provide the list of windows that are available for ETL processes in each of the source systems. This input should be factored into the design. The impact on the time
window due to increase in data volume should also be considered.
System Interdependencies
System Interdependencies are critical to consider when the data is spread over multiple systems. Because the data is multi-sourced, there may be constraints placed on
the extraction procedure since the data from multiple systems must be merged into a unified data format.
As a result, when there is a failure during extraction from one system, data from dependent systems cannot be processed. Therefore, it is necessary to identify in advance
which systems depend on or flow into other systems.
The project team has to perform an analysis of interdependencies between source systems and record it in this section so these aspects can be addressed during design.
The client may already have completed and documented a similar system dependency analysis. If not, be sure the client confirms any analysis and conclusions.
Access Constraints
For each source systems identified above, any and all possible system constraints must be identified and documented. Locating potential bottlenecks in source system
data access can also identify constraints.
Considers all constraints that may impact data acquisition from source systems. Access constraints may be security restrictions such as system firewalls or restrictions
based on time of access. The types of constraints that should be considered include:
System Security and Firewalls
Time of Data Access (this may have become apparent during the Batch Window analysis)
Network capacity
These constraints need to be identified and addressed when designing the ETL process. In cases where access to source systems are restricted, then a non-invasive
data push strategy must be adopted.
DATA VOLUMES
Large volumes of data from various sources need to be extracted and transformed and loaded within the time-period allotted (batch-window). Hence, information
regarding the volume of business data is a very vital input for the architectural design and the capacity planning process for the solution.
For the all the source systems identified above, the data volume and the expected rate of growth needs to be recorded. This information feeds into the Architecture
Requirements and Strategy (TA.020) and ultimately the System Capacity Plan (TA.160).
Capture the volume per extract/entity. If possible, capture both logical size (number of records) and physical size (number of bytes). Do not spend time analyzing smaller
extracts. Simply note that such extracts will have up to 1000 or 10000 rows. Instead, focus on large extracts (more then 100k rows) that will drive the target data volume
and processing time.
Data Conversion
System analysts (and also architects and developers) may identify the data to be converted and must document the functional requirements for extracting and loading the
data. Requirements for validating and cleaning up data are defined. Remember that clean up can occur both on original and on extracted data. Identify requirements for
handling error conditions and document all findings in a technical document to be reviewed by the system administrator.
It is also very important to involve system analysts or developers that know the source systems and its data structures. During this task, identify if it will be necessary to
involve experts in non-Oracle databases for obtaining the data.
SCOPE AND CONSTRAINTS
The Scope varies by project, depending on client need. When defining scope, include the following:
General - This section includes general project size (number of sites, application types, etc.).
Platform - This section lists the type of platforms included and/or excluded and the reasons why.
Tools - This section lists any automated tools that will be used to facilitate the conversion project:
Third-Party Software and Systems - This section lists the third-party software and systems included and/or excluded, and the reasons why. Be sure to include
the anticipated level of data cleanup that will occur before conversion versus the data that will be cleaned up using the screens/pages after conversion.
When defining constraints, consider the following:
Schedule
Required Resources
Business Constraints
Technical Constraints
Business constraints, such as foreign language requirements, should be documented. Technical requirements, such as hardware, software, and network constraints,
should be clearly defined.
CONVERSION REQUIREMENTS
Define the detailed conversion requirements and organize them for presentation to the client. Include the following information:
Source Application - List the systems that will supply the data to be converted, for example, a receivables system. List also how data will be delivered (text files,
xml, database links, etc.).
Business Objects - List the individual business objects, business domains or business groupings of data which are going to be converted. For example, for a
receivables system, the client company may want to convert their customers as well as their open invoices (invoices which still have open balances). However,
they may not want to convert closed invoices and the payments which were made towards those closed invoices. A business object in this context is a business
grouping of data. It is not meant to represent a true entity class that has a one-to-one mapping to a table. Customers, for example, could have attributes stored in
more than one table.
Order - Identify the order in which the objects for a given application or system will be converted. Keep in mind the interdependencies between the objects.
Obviously in the above example, the customers need to be converted before an invoice which references the customer can be converted. Under the table you may
want to expand this column to take into account the interdependencies between more than one application if more than one application is going to be converted.
Disposition - Indicate if the conversion of a specific object is going to be done programmatically, manually, or in another way.
Number of Records - Document the number of records per entity object that will be converted, as well as a column to indicate whether this will be a one time
conversion or a periodic conversion. An example of a periodic conversion is a conversion of data from one division of a company - if the implementation will be
made one division at a time, conversion processes will be repeated.
Oracle or Target Application - Identify the target application to which the data is going to be converted. In some cases, you may not able to determine this
information for all applications, then list any open issues or notes which need to be resolved before this information can be determined.
VALIDATION AND DATA CLEANING REQUIREMENTS
Determine the requirements for validating the imported data, for example, a list of tests or verifications that should be made to the migrated data.
Depending on the quality of original data, define the data cleaning requirements, such as, a percentage of data that could be refused or alternative values to fill new
obligatory fields. For example, an address street value of "not given" will be inserted in all invalid/non-existent fields. Also define a future process of verifying and
correcting the invalid data.
DATA CONVERSION ERROR CONDITIONS
Define the automatic tests that can be made on the data and how exceptions will be treated. Also consider problems such as different field sizes or invalid dates that can
be automatically refused by the target system.
Data Quality
Document the identified data quality objectives. It is important to enter only those objectives, that were identified and which are essential for the solution. Review the
previous Data Acquisition component for details about the types of sources and their data formats. Identify high-level issues relating to data ownership and broad
processes for resolving data quality issues.
Back to Top
Back to Top
System Analyst Identify and document the source systems to be converted. Prepare the functional conversion requirements.
Document the special considerations and technical assumptions. Participate in the process and review the
requirements.
If a Data Acquisition and Conversion team leader has been designated, 20% of this time would be allocated
to this individual, leaving 60% allocated to the system analyst. The team leader would then participate in the
process and review the requirements.
80
Application/Product Specialist Provide knowledge and guidance regarding the functionality and capabilities of the product(s) being
implemented.
20
Client Data Administrator Provide the conversion requirements, special considerations and technical assumptions. Provide information
on existing systems.
*
Ambassador User *
Back to Top
PREREQUISITES
Prerequisite Usage
Relevant existing reference material Review any documents provided by the client on existing data sources, as well as any meeting notes on volume of
data, access restrictions on existing data sources.
Project Management Plan (Manage) The Project Management Plan should include data conversion requirements.
High-Level Business Descriptions (RD.020) The Data Acquisition and Conversion Requirements identifies the selected list of operational and external data sources
required to meet the information requirements described in the High-Level Business Descriptions.
Supplemental Requirements (RD.055) The Supplemental Requirements contains additional requirements that may impact Data Acquisition and Conversion.
Back to Top
TEMPLATES AND TOOLS
CV-
010_DATA_ACQ_AND_CONVERSION_REQUIREMENTS.DOC
MS WORD
Back to Top
The Data Acquisition and Conversion Requirements is used in the following ways:
to understand the different source systems (platforms, operating system details, security access constraints and data volumes)
to document and communicate the Data Acquisition and Conversion scope and objectives
Distribute the Data Acquisition and Conversion Requirements as follows:
to the development project leader and the project leader from the business side (if any)
to Data Acquisition and Conversion team members
to other process leaders who have dependent tasks with the Data Acquisition and Conversion process
to other teams (e.g., client's team) that could be responsible for obtaining the source data
Back to Top
QUALITY CRITERIA
Does the document capture all data sources for the solution?
Are the proposed way of accessing data from the data sources discussed with the client and document?
Are any access constraints, if any, on the source systems records, so that they are considered in the final solution?
Have the data volumes present on the identified source systems, as well as the rate of growth, been discussed with the client?
Are the scope and objectives clearly identified?
Have you taken into account the impact of dependent tasks from other processes?
Have you deleted any tasks and associated work products which do not pertain to your project requirements?
Are the requirements clearly defined?
Are all legacy applications and objects included?
Has the level of detail and history to be converted been defined?
Back to Top
CV.020 - DEFINE DATA ACQUISITION, CONVERSION AND DATA
QUALITY STRATEGY
In this task, you use the Data Acquisition and Conversion Requirements to develop how the data is to be extracted, transported, loaded, transformed and converted or
loaded from all data sources into the new system, as well as define the strategy and criteria for ensuring ongoing data integrity. This includes identifying and specifying
the requirements for the identification, escalation, and resolution of data quality issues. Lastly, a high-level assessment of the source data should be performed as part of
this task in order to effectively verify the strategy for data quality.
In order to avoid unnecessary programming effort, it is recommended that you fully investigate alternative solutions for conversion of data from legacy systems, early in
the project. In most cases this provides both a significant savings in effort and a reduction in risk to the schedule.
In OUM, the Data Acquisition and Conversion process captures information for data acquisition, data conversion and data quality. Although very close to the other project
development activities, it is not unusual to have Data Acquisition and Conversion iterations with different objectives. This process also contains specific characteristics,
recommendations, tools, and techniques in Oracle projects.
On the other hand, Data Acquisition and Conversion should be understood as a sub-project following the same principles of OUM. The work should be iterated and
prioritized. A base architecture should be established and tested before committing too much resource.
Lastly, the term "ETL" refers to the steps of extracting, transforming and loading data from data sources to target sources during the Data Acquisition and Conversion
process. It should be noted that in some cases "T" (transformation) may be as minimal as encoding or decoding source data during extraction and loading steps, or
transformation may not occur at all for some solutions.
Attention: Findings made during this task may impact the MoSCoW List.
For projects that involve the upgrade of Oracle products, the majority of data will be copied from existing tables using standard Oracle migration utilities. However, there
may be some objects where it is more appropriate to use custom written data migration routines. Therefore, the focus of this task becomes the definition of the strategy
for the creation and management of any such custom migration routines.
ACTIVITY
Back to Top
WORK PRODUCT
Data Acquisition, Conversion and Data Quality Strategy - The Data Acquisition, Conversion and Data Quality Strategy records the strategy for meeting the previously
defined Data Acquisition and Conversion Requirements. It has three major components:
Data Acquisition Strategy
Data Conversion Strategy
Data Quality Strategy
The Data Acquisition Strategy defines the scope and objectives as well as the critical success factors and risks associated with the data extraction, transportation,
transformation and data loads to support the solution. It describes the business conversion and interface requirements. Topics include:
data acquisition techniques for extract, transport (move), transform (map)
data conversion
refresh strategies
load frequencies
data availability
inbound processes outbound interfaces
data to be converted
functional requirements for extracting and loading the data
requirements for validating and cleaning up both extract and load
error condition handling
In addition, it lists all of the system interfaces (both automated and manual) that interact with the data warehouse solution. Information contained should include the
interfaces that provide input to the warehouse and the interfaces that receive output from the warehouse. The report contains the following information for each interface:
the type of interface
the name of the source or destination system
the system location
the type of database
#TOP #TOP
if it is an automated system interface
a brief description or purpose of the interface
the data flows
flat file formats
The Data Conversion Strategy is intended to provide a road map for performing the conversion of data from the legacy system(s) to the new Oracle system.
The Data Quality Strategy defines the strategy and criteria for ensuring ongoing data integrity. This includes identifying and specifying the approach for the identification,
escalation, and resolution of data quality issues.
data management and movement of data between data warehouse components
error and exception handling methods
data cleansing criteria
audit and control processes
data standards for naming metadata and database objects
data ownership guidelines and reconciliation processes
data issue resolution strategies
escalation policies
modes of communication
Lastly, the Data Quality Strategy also includes a High-Level Data Quality Assessment that documents findings related to source data, its integrity, availability, ability to
meet business requirements, and overall quality. It includes issues and possible approaches to resolution.
Back to Top
TASK STEPS
1 Provide an introduction for the document. Introduction The Introduction describes the work product and how it is used.
2 Document any pertinent background
information.
Background The Background describes how the system is used by your client management and any other pertinent
information you wish to include.
3 Document any pertinent overview
information.
Data
Acquisition
and
Conversion
Overview
This component provides details on how the Data Acquisition and Conversion process is used to
realize the data acquisition, data conversion and data quality requirements of the project.
4 Review the appropriate Technical
Architecture (TA) work products.
Data
Acquisition -
Strategy -
Logical
Architecture
This component provides the basic information about the logical architecture of the data solution and
its components. The main reason why this section is included is to describe the data stores that are
referenced in the data flow definitions.
Note that the term data store is used for architectural components of the solution, that are used as a
source and/or target of a data flow, i.e., a data store can be a Staging Area, Data Warehouse, Data
Mart, OLAP Area, etc.
5 Document source system information for
all the data sources identified in the
approved Data Acquisition and
Conversion Requirements (CV.010).
Data
Acquisition -
Strategy -
Source
Systems
This component provides source system information for all the data sources. There may be multiple
interfaces from each source system, each interface with different format, frequency and/or content. For
the purpose of this component, interface is defined as a set of files or tables that are extracted and
transferred at the same time using the same extraction and data transfer method.
6 Document the target systems and
interfaces to the target system.
Data
Acquisition -
Strategy -
Target
Systems
This component of the task documents the target systems. Note there might be multiple interfaces from
each source system, each interface with different format, frequency and/or content. If there is no target
system (i.e., the data is used for reporting only) then delete this section. For the purpose of this
component, interface is defined as a set of files or tables that are extracted and transferred at the
same time using the same extraction and data transfer method.
7 Analyze the required source and target
system interfaces and required business
functionality and prepare a list of data
flows needed to support the requirements.
Data
Acquisition -
Strategy -
Data Flows
This component includes a diagram that represents data flows. Examples of are provided in the
template. Data flow is a process that takes data from a source interface (or data store) and it loads the
target data store (or output interface), e.g., a data flow processes data from a particular source system
and it loads it into the staging area. Another data flow then loads target data warehouse from the
staging area.
Data flows described in this section correspond to the processes or jobs executed when running and
refreshing the data warehouse.
8
Review the business requirements
regarding the initial and historical data in
order to document each requirement. Get
the sign off from the customer for the
initial and historical load requirements.
Data
Acquisition -
Data Load
Strategy -
Initial and
Historical
Loads
The Initial and Historical Loads component provides a table listing the requirements for the initial or
historical loads from source systems. It is important to note for each requirement how many months
(days) of data have to be loaded, whether the historical data is available, what is the expected volume
of data and whether it is possible to load the historical data with the processes developed for regular
updates.
*Use the following to access task-specific
custom BI supplemental guidance.
9 Provide guidelines for raising errors,
notifying administrators and enabling error
recovery.
Data
Acquisition -
Data Load
Strategy -
Error Handling
Strategy
This component describes strategies for raising errors, notifying administrators and recovery steps after
the error is resolved.
10 Review the Data Acquisition and
Conversion Requirements, specifically the
Data Conversion sections.
Data
Conversion -
Requirements
This component lists the legacy system entities being converted.
11 Review the Data Acquisition and
Conversion Requirements, specifically the
Data Conversion sections.
Data
Conversion -
Constraints
and
Assumptions
This component lists any constraints and assumptions on which the tasks, resources, and conversion
execution strategies are based.
12 Develop a simple, effective and quick
approach to convert only the data needed
to provide business benefits in the initial
production period.
Data
Conversion -
Conversion
Approach
The Conversion Approach describes the general approach that will be used to guide the conversion
portion of the Data Acquisition and Conversion process.
13 Review the source systems and Data
Quality components of the Data
Acquisition and Conversion Requirements
(CV.010). Define the objectives of data
quality in detail.
Data Quality -
Objectives
This component defines the objectives of the data quality management in the solution. The following
areas are described in this component:
Data Quality Overview
Data Quality Objectives
(CV.010). Provide the detail requirements
for the Data Quality processes.
Data Quality -
Processes
This component provides the description of the processes related to the data quality. The following
processes will be designed in such a way in order for the solution to meet the data quality objectives.
Data Transfer
Data Cleansing
Audit and Control
Error and Exception Handling
(CV.010). Provide the detail requirements
for the Data Quality ownership.
Data Quality -
Data
Ownership
This component defines the ownership of data quality components and responsibility for solving end
escalating data quality related issues. Include the following sections.
Data Ownership
Issue Resolution
Escalation Hierarchy
16 Document the transformation rules in a
table.
Data Quality -
Transformation
Details
This component defines the data quality transformations.
*Use the following to access task-specific custom BI supplemental guidance.
Back to Top
APPROACH
Data Acquisition and Conversion Overview
Provide specific information on how the OUM method and Data Acquisition and Conversion process is used to realize the data acquisition, data conversion and data
quality requirements of the project. Include the following:
Project Management - The Manage Focus Area (Project Management) is used to manage OUM projects and as such will also be used to manage the Data
Acquisition and Conversion process. Refer to the Project Management Plan (PMP) for specific information (e.g., for Issue and Problem Management and
Configuration Management). Any project management information for Data Acquisition and Conversion that deviates from what is specified in the (PMP or is in
addition to what can be found in the PMP should be included (e.g., any additional version control procedures for the development of the components and data
files). Issue tracking procedures and supporting tools must support the correction of errors in legacy data. The workflow for these errors might be different from the
one used to process application and database errors. It may be also different from the project issue tracking system although usually the same tools are used.
Version control procedures and supporting tools must support versioning of data files and of any CV components that have to be written. Again, the same
Configuration Management system (version control) should be used for all project work products.
Task and Work Products - Provide a list of tasks and work products which will be performed.
Team Organization - Define the roles and associated skills needed to perform the Data Acquisition and Conversion process. Describe the team organization for the
project and document which Oracle and client team members are responsible for each defined role. Establish the requirement for human resources with these
skills. The following sections should be included; Conversion Team and Roles and Responsibilities.
Resource Requirements - List the resource requirements. Identify and document the physical resources, in terms of development tools, Oracle products, hardware
and other resources. Include the following sections: Software, Hardware Environment, Network/File Transport, Staffing and Other.
Project Standards - If your chosen approach involves the use of technologies and languages that are not used in other parts of the project, then you need to obtain
and deploy appropriate standards and guidelines. Document the project standards including the standards for application development tools, conversion tools,
source control, version control, system management tools, and work product naming conventions. The following sections should be included: Tool Standards and
Work Product Naming Standards. The standards mentioned in this component should be specific to the Data Acquisition and Conversion process. If there are no
process-specific standards which are applicable to the Data Acquisition and Conversion project then refer to the overall OUM project standards.
Data Cleanup Process - Except in the rare event of cast-iron certainty that the legacy source data is of very high quality, you need to allow time for data cleanup.
The responsibility for this activity, and for obtaining the resources to do the work, must be unambiguously located with the client data administrator (and not with
the core team). Remember to consider that data can be cleaned in the source system, in temporary structures or in the target system. List the legacy system
objects or domains (business groupings of data) which need to be cleaned up. Cleanup can be performed as a pre-conversion or a post-conversion activity.
Include sections for Data Cleanup and Key Data Translations. An example of data cleanup is the same customer entered in the legacy system multiple times due
to using capitals, mixed case, abbreviations, etc. It should also list key data translations which can be thought of as data cleanup. An example of a data translation
is to translate all YES to Y. Data translations can be coded into the interface programs or performed in the interface or temporary table prior to loading into the
production tables.
Testing Strategy - If your chosen approach involves the use of technologies and languages that are not used in other parts of the project, you need to develop a
specific testing strategy for the Data Acquisition and Conversion components. The lead QA should be able to perform this step.
Acceptance Criteria - In most projects, data quality is given a high priority, although not always explicitly. As part of the Data Acquisition, Conversion and Data
Quality Strategy, you should give consideration to criteria for acceptance and rejection of data. Consider for example the following scenario. You are converting
data from a mainframe DB2 database in which no constraints have been enforced. You have been told that the referential integrity of the source data has been
enforced during the previous 15 years by CICS and COBOL programs. Now you have agreed on a new data model with relationships that will be enforced in an
Oracle database by means of constraints. On the initial data load, 75% of the records are rejected by the loader program with constraint violation errors. Before
you arrive at this situation, agree with the client data administrator and if necessary with business managers how these rejected records will be analyzed, how the
data errors will be corrected and by whom. A firm and preemptive statement at this stage that "of course we are not going to turn off our constraints to
accommodate inconsistent data" is recommended. State the conditions and acceptance criteria which must be met before the conversion is signed off as
successful. Include the following sections; Delivery and Data Acceptance.
Project Milestones - It is important to establish milestones for Data Acquisition and Conversion. In addition to the milestones for delivery of the Conversion
Components and cleaned data, establish checkpoints to review the progress of the Data Acquisition and Conversion process, so that the project manager can
receive early indications of any developing problems. The major Data Acquisition and Conversion milestones should be made visible in the Project Management
Plan. These milestones are not limited to the specific CV tasks within OUM. Other milestones that are important to the Data Acquisition and Conversion process
which may be part of another OUM process should also be listed. An example of a milestone is the conversion instance is ready to be loaded or a conversion tool
has been installed.
Metrics - Before starting on Data Acquisition and Conversion, establish numbers for the data to be converted. Find out how many tables, files, records and so on
are to be converted. Aim to keep the volumes down to the minimum subset required at production start. If the users ask for everything to be converted, ask them to
justify this in terms of business benefits.
Risks - Identify any perceived risks which could keep this strategy from being implemented. Identify, assess and mitigate the risks. Data Acquisition and
Conversion is a relatively risky part of any development project. The project manager, assisted by the team leader for the Data Acquisition and Conversion
process, should identify, assess and mitigate data conversion risks. For example, give consideration to the following:
risks to schedule - Delays in data conversion can impact other parts of the project. It is advisable to get firm and public commitments from those responsible
for legacy systems that usable data will be available on the agreed dates. Unlike other parts of the project plan, you should not have significant slack in the
Data Acquisition and Conversion part of the workplan.
risks to budget - Assess the potential for additional resources, for example, if the data quality turns out to be so bad that the only practical approach is to hire
temporary staff to enter data manually into the new system. Check that there is budget provision against this risk.
risks to quality - The value of the new system to the business will be reduced if bad data from the old system is loaded into the new system. Develop and
implement a Data Acquisition, Conversion and Data Quality Strategy that will deliver a gain in data quality.
Data Acquisition
The primary objective of the Data Acquisition component of this task is to draw out a strategy for the overall data acquisition of data and to identify any approaches,
considerations and constraints. The goal is to describe all the data extraction interface components, data transportation mechanisms, change data capture methods and
corresponding constraints so that they may be addressed during the design.
DATA ACQUISITION - STRATEGY - LOGICAL ARCHITECTURE
Review the appropriate Technical Architecture (TA) work products. Copy or create an appropriate logical architecture diagram that shows all the major components
including the data stores and dependencies between them. Describe each data store and its purpose. Make sure all the required data stores are listed.
Document each data store in a table including the following:
Seq sequence number
Data Store short name of the data store
Purpose purpose of the data store
Comment any additional comments
DATA ACQUISITION - STRATEGY - SOURCE SYSTEMS
Provide a table listing each identified source system and their types. Be sure the list is accurate and has all required sign offs or approvals. Remember to include data
source types that typically include RDBMS, Files, Dun Bradstreet data, etc.
For each source system interface, document the following information in a table:
Seq sequence number
Source System short name of the source system
Target System short name of the target system (usually there is only one target system (e.g., data warehouse), but in more complex environments there might be
multiple target systems)
Interface Name short name of the interface (if there is only one interface for the given system, the interface name is usually the same as the system name)
Interface Frequency frequency with which the data are extracted, i.e., monthly, weekly, daily or online (for message based transfers)
Interface Type type and format of the interface, e.g., flat files, RDBMS access (pull), message transfer (push) etc.
Increment/Full indicate whether the interface is incremental or whether it provides always the complete (full) set of data
Change Capture Method in case the interface is incremental indicate how the change capture is performed for the interface
Transport Method describe how data is transferred over the network. For files describe the file transfer tool or protocol, for RDBMS access describe how RDBMS
is accessed etc.
Content shortly describe content of the interface, e.g., by listing the main entities within this interface
Comment any comments relevant to the interface
DATA ACQUISITION - STRATEGY - TARGET SYSTEMS
Provide a table listing each target system and their types. List the target systems and their types as required by the MoSCoW List (RD.045) and other requirements
documents. Be sure the list is accurate and has all required signoff's or approvals.
For each target system interface document the following information in the table:
Seq sequence number
Source System short name of the source system (usually there is only one source system (e.g., data warehouse), but in more complex environments there might
be multiple source systems)
Target System short name of the target system
Interface Name short name of the interface (if there is only one interface for the given system, the interface name is usually the same as the system name)
Interface Frequency frequency with which the data are extracted, i.e., monthly, weekly, daily or online (for message based transfers)
Interface Type type and format of the interface, e.g., flat files, RDBMS access (pull), message transfer (push) etc.
Increment/Full indicate whether the interface is incremental or whether it provides always the complete (full) set of data
Change Capture Method in case the interface is incremental indicate how the change capture is performed for the interface
Transport Method describe how data is transferred over the network. For files describe the file transfer tool or protocol, for RDBMS access describe how RDBMS
is accessed etc.
Content shortly describe content of the interface, e.g., by listing the main entities within this interface
Comment any comments relevant to the interface
DATA ACQUISITION - STRATEGY - DATA FLOWS
This component should accurately depict the data flow architecture to be used for this project and capture information on the components in the data flow.
Prepare data flow diagrams. If there are many data flows, it is usually better to prepare several diagrams, each describing flows for a particular subject area. Document
the data flows in a table. Make sure the data flows characteristics are consistent with the source interface frequency and availability. Use a numbering system to identify
each data flow in the diagram for future reference purposes.
Insert a graphical representation of the data flow. Indicate which ETL functionality is implemented by each stage (extraction, transfer, transformation, cleansing,
aggregation etc.) Use the data stores and source / target interfaces identified in previous diagrams.
Document the following characteristics of a data flow in a table with the following information:
Seq sequence number of the data flow
Source data flow source. It can be either a source system interface or a data store within the data warehouse.
Target data flow target. It can be either a data store within the data warehouse or a target interface.
Data Flow Name short name of the data flow
Data Flow Purpose purpose of the data flow, i.e., what is the function of the data flow
Data Flow Frequency frequency with which the data flow should be executed. The frequency should correspond to the frequency of source system interfaces.
Dependencies indicate any dependencies on other data flows or external conditions
Comment any additional comments relevant to the data flow
DATA ACQUISITION - DATA LOAD - STRATEGY - INITIAL AND HISTORICAL LOADS
Review the business requirements regarding the initial and historical data in order to document each requirement. Make sure that both the historical loads and initial
loads are included (i.e., list everything that has to be loaded before the target system can be refreshed on regular basis with the current data). Get the sign off from the
customer for the initial and historical load requirements.
Try to capture information on history data and the impact on that can be analyzed. The volume of business history data in terms of starting date (e.g., all the transaction
from 1.1.2004 or 6 month of initial history), number of rows or by size of data (how many GB or TB of data) is helpful.
Indicate whether the initial history can be loaded using the ETL modules developed for the current data or whether special processes for historical data load are needed. If
the historical data is available in the same format as the regular updates, it is usually possible to use the same processes and modules as for the regular updates.
However, if the format of historical data is different or there are different business rules needed to process historical data then it is necessary to develop modules for the
historical data load. It is necessary to be aware of this need as it may significantly change the project scope.
Document the requirements in a table format. It is important to note for each requirement how many months (days) of data have to be loaded, whether the historical data
is available, what is the expected volume of data and whether it is possible to load the historical data with the processes developed for regular updates. Include the
following information:
Seq sequence number of historical load requirement
Source System name of the source system
Interface Name name of the interface
Entities list of entities to be populated by historical load
Months to be Loaded how many months (days, years) of history should be loaded
Number of Loads how many loads will be required (e.g., if the requirement is to load 12 months of history and only monthly data are processed, than this will
require 12 loads. However, if the loads are on the daily basis, than the loads will require 365 loads for each day in a year)
Is Data Available indicate whether the historical data are available. If the data are not available then the historical loads are not feasible.
Expected Volume per Load indicate expected number of rows to be loaded per each load. This figure can be used to estimate how much time it will take to
perform historical loads.
Possible to Use Regular Processes indicate whether the historical loads will need special modules and processes or whether regular processes can be used.
Comment add any comment related to historical and initial loads
DATA ACQUISITION - DATA LOAD - STRATEGY - ERROR HANDLING STRATEGY
Provide guidelines for raising errors, notifying administrators and enabling error recovery. All exceptional conditions need to be identified up front and addressed in the
design.
Reporting errors while running the ETL processes need to be discussed with client and escalation paths have to be identified and clearly communicated.
This section is primarily aimed at developers working on the ETL components. It provides guidelines for raising errors and how to design the modules and processes in
order to enable error recovery.
Any errors that arise while running the ETL processes have to be captured and handled properly in order to successfully operate the data warehouse system.
Error Handling Approach
Describe the how errors are handled. Describe both errors raised by the tool (e.g., OWB) and exceptions programmatically raised by components. Define the how to
programmatically raise exceptions from all the component types used in the project.
Describe how errors, warnings and messages are logged.
Error Notification Approach
Describe the notification process executed when an error occurs. Define who should receive the notifications and how to react to notifications.
Error Recovery Approach
Describe how the system will recover from an error. Include guidelines for designing the modules in a way that enables graceful error recovery.
The typical requirement is to design the components to be repeatable, i.e., it should be possible to repeat the module if the previous execution has failed. That way the
process can be restarted from the point where it was stopped because of error.
Data Conversion
You need to develop a simple, effective and quick approach that converts only the data needed to provide business benefits in the initial production period. In doing this,
you should aim to minimize the programming effort needed. Take into account the following factors:
the quality of data in the legacy system and the degree of confidence that can be assigned to statements about the quality of this data - In particular, investigate
whether the data is consistent with the Existing System Data Model (if available). If the data is coming from a database without constraints, then you should be
prepared for inconsistencies.
the source data business transformation rules - If these are not fully defined, the team will need to spend some effort on defining the data transformation rules.
closeness of fit between the legacy system data model(s) and the new data requirements
whether the source databases are Oracle or non-Oracle - If they are non-Oracle, you should investigate use of appropriate Oracle integration and data architecture
tools.
possibilities for reuse (for example, data extraction programs and associated file formats) - There is no point in defining a new file format if there is an existing one
that can be used, with supporting code.
The conventional approach to data conversion has been to use a mixture of automated conversion using flat files, and manual data entry. The latter is still an option worth
considering when data volumes are small or where legacy data quality is suspect. But there are other options that should be considered. These include the use of
database links by which data can be copied directly from source databases into temporary tables
If the source database is not an Oracle database, then you need to investigate other Oracle tools which would be appropriate in support of the client's overall architecture.
Consider also the use of tools that can automatically document and transform your data.
Data Quality
Review the Data Acquisition and Conversion Requirements (CV.010) for details about the types of sources and their data formats. Review the Data Quality components of
CV.010 to identify high-level issues relating to data ownership and broad processes for resolving data quality issues. Use the information in the Data Quality component
of CV.010 as a starting point to develop the Data Quality Strategy. The strategy should build on these high-level issues by adding the specific data quality requirements.
These include error and exception handling criteria and any data cleansing requirements to be met.
The Data Quality component of the Data Acquisition, Conversion and Data Quality Strategy defines data quality in the solution for the business, and also identifies
ownership of the data, resolution of issues and escalation hierarchies that define the procedures related to the everyday operation and administration. This information is
used in subsequent tasks to produce components to address data quality requirements, and to ensure adherence to standards. Test cases are also defined to address
the issues identified in this document.
DATA QUALITY - OBJECTIVES
Provide an overview for data quality and define the data quality measures (KPIs) and define the objectives of the data quality management in the solution.
Data Quality Overview
Provide the general concerns regarding data quality in this section. This section should define what data quality is at a high level with respect to the implemented solution.
If there are some particular aspects of the quality important for the implemented solution they should be mentioned here.
This section defines the data quality measures (KPIs).
Interview the ambassador users about the data quality needs, i.e., what are the data quality requirements the system should have in order to meet the business needs.
Collect the data quality measures from ambassador users. Note the definition of data quality measures and acceptable values is usually a responsibility of a business
analyst. Ask the business analyst to focus on the most important entities and attributes to be measured.
Describe the data quality measures in a table:
ID unique identification of the measure
Business Entity entity that is subject of the measure
Business Attribute attribute that is subject of the measure
KPI name of the measure
Description description of the measure, i.e., how the measure is calculated
Acceptable value what is the acceptable value for business
Data quality measures are usually defined as how many records do not meet particular quality criteria. Some of the possible criteria that can be measured are:
Missing Data Values data that should have value are missing, including both mandatory fields and analytical fields.
Domain Value Errors data do not correspond to the domain definition (e.g., unexpected or unknown codes, formats etc.)
Duplicate Occurrences multiple records that represent a single real world entity. Typically customers or addresses are duplicated several times.
Business Rules Violation data do not conform to business rules, for example two fields have valid values but the combination of these values is not allowed.
Reconciliation Errors data in the data warehouse do not correspond with the same data from another surrogate data source (e.g., comparing sum of balances on
client accounts and sum of balances on GL accounts).
Data quality measures should be normalized in order to be able to define ranges that are acceptable or not acceptable to business, e.g., balances on customer accounts
are considered correct if the sum of balances on client balances do not differ more than 0.2% of the balance on GL account.
Data Quality Objectives
This section states the objectives for data quality. Document the identified data quality objectives. It is important to enter only those objectives, that were identified and
which are essential for the solution.
Interview the ambassador users about the data quality needs, i.e., what are the data quality requirements the system should have in order to meet the business needs.
Enter the identified data quality objectives. It is important to enter only those objectives, that were identified and which are essential for the solution.
Describe the data quality objectives in a table. Include the following:
ID unique identification of the objective
Objective short name of the objective
Description description of the objective
How to Measure how to determine the objective is met
Related KPIs KPIs related to the objective
If it is not possible to put the objectives into a tabular form delete the table and use a free text.
Be careful when completing this component. Non-realistic and non-measurable data quality objectives can significantly extend the scope of the project and could have
impact on the acceptance of the project. It is important to enter only those objectives, that were identified and which are essential for the business and the solution.
If possible, the objectives should be measurable, i.e., the objectives might be based on the data quality measures defined in the previous section.
It is usually useful to clearly state that the data warehouse is not responsible for the errors caused by the source system and that the data quality is not a function of one
system or one role. Instead, all the applications, architects, information producers and knowledge workers have to take responsibility for continually improving the data
quality.
The following is a list of inherent data quality characteristics (i.e., data quality measures that do not depend on how the data is used) that could be used in this section:
Definition Conformance consistency of the data definition and actual data values. For example, if an item "Loan Maturity Date is described as "the date when a
loan matures and the system populates the field with the contractual value but it does not update the value in case the loan is restructured, the value is incorrect.
Completeness if all required fields have data present the data is complete. The measure is the percentage of records that have a value for a particular field. For
example, it might be important to know for how many clients the attribute "Profession is missing if the number is large, reports broken up by this field will be
distorted.
Business Rule Conformance this characteristic measures conformance of data to its domain and business rules. The measure is the percentage of records that
conform to the business rule. For example, the business rule states that "all current accounts with overdraft which are in credit are not classified. This
characteristic measures how many records fail this rule.
Accuracy to Surrogate Source how the data agrees with the data in the original source of data. The measure is the percentage of records that correspond to the
"authoritative data source. For example, financial reconciliation that compares balances on general ledger accounts against balances of client accounts. Another
example is how company names correspond to the external register of companies.
Accuracy to Reality - how the data agrees with the real world object or event. This measure is considered the highest measure of information quality. Though data
might be accurate to surrogate source they still might not be accurate to reality. This measure must be evaluated by physical data assessment.
Precision precision is defined by the right level of granularity in data values. The measure is the percentage of records that have the required degree of
granularity. If multiple processes are using the data the precision then the lowest granularity must be used. For example, for marketing it is sufficient to have
locations on the level of regions while direct mail requires location accurate to address point.
Nonduplication non-duplication measures whether data has one to one relationship with real world objects or events. The measure is the percentage of records
that are duplicated, i.e. two or more records correspond to one real world object or event. Duplication is especially problem if data are maintained redundantly
across independent databases. Typical example is duplication of customers.
Concurrency of Distributed Data lag between data is changed or inserted in one database and propagated to another database. The measure is the duration
required to move the data from one place to another. Concurrency can cause problems with missed opportunity (information is not available in time) or with
discrepancy of reports coming from different sources being out of sync.
The following is a list of pragmatic data quality characteristics (i.e. data quality measures that measure how the data is presented, used and whether it is complete and
relevant for users and processes that use the data) that could be used in this section:
Accessibility degree how difficult it is to access data on demand. There is a potential accessibility (does the company and/or department possess the data?) and
actual accessibility (how easy it is to access the data?). Included in the accessibility is also the speed with which the data are retrieved and presented.
Timeliness availability of data to support a given process within the time plan defined for the process. This characteristics measures whether the timing of data
flow is acceptable.
Contextual Clarity degree to which the data presentation enables knowledge workers to understand the meaning and to avoid errors and misunderstandings. This
is a subjective measure of the way how the information is presented.
Derivation Integrity correctness of calculations performed from other data. The measure shows the percentage of correctly calculated records. In order to
measure this characteristic it is necessary to have a precise definition of the calculation.
Usability how easy it is to use and understand the presented information. This is a subjective measure of the degree to which the information presented is
efficiently usable for its purpose to support a process or a decision.
Fact Completeness characteristic of having the right data with the right quality to support a given process. This measure is not fulfilled if some facts are missing
or not having required quality.
DATA QUALITY - PROCESSES
Review the high-level Data Quality Processes component in the Data Acquisition and Conversion Requirements (CV.010). Describe the processes related to the data
quality. They should be designed in order for the solution to meet the data quality objectives.
Data Transfer
Collect the relevant reference information and information from workshops and identify possible data extraction and data transfer issues. Propose and document methods
to ensure the source data are available with the required frequency and at the required time. Propose and document methods to ensure the extracted data meets the
referential integrity requirements. Propose and document methods to ensure the files transferred over the network are complete (i.e., all files are transferred) and not
corrupted. Propose and document methods to ensure the correct character set and/or data format conversion takes place. Propose and document methods to ensure the
files (or messages) are produced and processed in the right order (sequencing). Propose and document methods to ensure the source data are available in the expected
structure and format (i.e., detect and prevent unexpected changes of source structure). Optionally provide a diagram showing the data transfer process and places where
the data transfer checks take place.
Describe the data quality considerations related to data transfer in a table:
ID unique identification of the data quality requirement related to data transfer
Source System if the requirement is specific to a particular system
Source File or Entity if the requirement is specific to a particular source file
Source Type provide the type of source data
Data Quality Requirement short name of the data quality requirement
Description description of the data quality requirement and how to handle to requirement
Depending on the data extraction and transfer approach it is necessary to include in this section methods ensuring the following characteristics of the data transfer
process:
Source data is available at the required time.
Source data meets the referential integrity requirements.
Data files are complete and not corrupted.
The expected character set and data format conversion takes place.
Files or messages are produced and transferred in right order.
Files are in the expected structure and format.
Describe in the document how the data quality requirements related to data transfer will be handled, i.e., what is the method and tools to meet these requirements.
Data Cleansing
Determine the requirements for data cleansing. The work product template provides strategies that you may want to consider this stage.
Review the data cleansing requirements from workshops. Optionally, a table with the data cleansing rules can be directly distributed to ambassador users to collect the
feedback from users. Review the data quality assessment of source systems. Identify the data quality issues that could be subject to data cleansing and agree on the
rules with the business. Document the data cleansing rules in the document. Document the transformations in the Transformation Details or (alternatively) in a separate
document. Update and extend the data cleansing rules as new information about source data quality and user requirements is available.
Describe the data cleansing rules in a table:
ID unique identification of the data cleansing rule
Business Entity entity the rule is related to
Business Attribute attribute the rule is related to
Cleansing Rule short name of the cleansing rule
Description description of the cleansing rule
Tools how the cleansing rule will be implemented
If necessary, provide free text describing how the cleansing rules are implemented, stored and maintained.
The data cleansing rules should be agreed on by all the business users of the data warehouse. This is especially important for the enterprise data warehouse (EDW) that
is used by many departments with many different views of the data. If business users cannot agree on a rule, the rule should not be implemented in the EDW and it
should be moved to a particular data mart.
The data cleansing rules should be stored in a metadata repository if possible.
Note that the data cleansing rules are only partially known at the time of Definition and Requirements Analysis. Usually the new rules are discovered when more data are
processed and the system (prototype) is tested. However, from the project management point of view, it is necessary to freeze the set of implemented data cleansing
rules at some point in time because otherwise the scope of the project is forever changing. This is especially important for fixed price implementations.
More detailed descriptions of the transformations for specific cases can be provided in the Transformation Details component.
Audit and Control
Describe audit and control procedures needed to ensure that all the data from the source systems are correctly loaded into the target system and that the data meet the
required business and technical checks.
Review the business checks requirements from workshops. Optionally the table with the business checks can be directly distributed to ambassador users. Review the
data quality assessment of source systems. Identify the data quality issues that should be monitored via technical checks and agree the rules with business. Identify the
technical checks to be implemented in order to ensure the ETL processes within the target system work correctly. Document the business and technical checks in the
document. Update and extend the checks as new information about source data quality and user requirements is available.
Describe the technical and business checks in a table:
ID unique identification of the technical or business check
Business Entity entity the check is related to
Business Attribute attribute the check is related to
Check Rule short name of the technical or business check
Description description of the technical or business check
Resolution how to handle records not meeting the check
If necessary, provide free text describing how the cleansing rules are implemented, stored and maintained.
The data business and technical checks should be stored in a metadata repository if possible.
For each business and technical check it is necessary to document what is the resolution of the check. The resolution might be to
Raise error (stop processing until the problem is resolved)
Load only the data meeting the checks
Mark the data not meeting the checks
Produce a report listing records not meeting the checks
Note that the business and technical checks may only be partially known at this time. Usually the new checks are discovered when more data are processed and the
system (prototype) is tested. However, from the project management point of view, it is necessary to freeze the set of implemented checks at some point in time because
otherwise the scope of the project is forever changing. This is especially important for fixed price implementations.
Error and Exception Handling
List the various exceptions and error conditions, how they are trapped and resolved.
For each error condition identified in Data Transfer, Data Cleansing and Audit and Control processes, design and document a method on how the error should be handled
and reported. Document the following information in a table:
ID unique identification of an error or exception
Error/Exception short name of an error or exception
Process name of the process or component the error is raised
Priority priority of error resolution
Description description of an error or exception
Notification/Reporting Requirements how to notify users and/or administrators the error was raised (e.g. send a notification to an administrator, distribute report to
end users etc.)
Resolution how to resolve the error (e.g. wait until the error is corrected and restart the process, repeat the process from the beginning, ignore the error and
continue, etc.)
Include a process diagram that illustrates how users are notified by the system if there is an error or exception and how they are resolved.
DATA QUALITY - DATA OWNERSHIP
Data Ownership
Identify the owners of each data component. For each data component, document the data ownership in the table. Decide whether to structure responsibility for data
components according to subject areas, source systems, both or other criteria. This decision has to be confirmed by the customer. Identify roles, departments or
individuals responsible for data ownership. Confirm the data ownership with the customer.
Data ownership is usually structured according to subject areas, source systems or both. Source system ownership is almost always available, i.e. there should be a
person or department who is responsible for a particular system and data extracts from this system. However, it is advantageous to have also somebody responsible for
a particular subject area to solve data definition and business rules issues that span multiple source systems.
For each data component document the data ownership in the table:
ID unique identification of a data component
Component name of the subject area or source system
Environment indicate for which environment is the ownership valid
Data Owner who is the data owner of the component
Owner Contact Detail document contact information of a data owner.
The data ownership has to be agreed on and eventually signed off by the customer.
Issue Resolution
Define how issues are resolved. For each issue, document the resolution and responsibility in the table. Identify data quality related issues that cannot be resolved
automatically. Use the issues described in previous chapters for a list of such issues. Define resolution process and expected resolution time for these issues. The
resolution time should be based on the impact of issues on data availability, subsequent processes, etc. Identify roles, departments or individuals responsible for solving
the issues. Confirm the responsibilities with the customer.
This section is focused on the data quality issues that cannot be resolved automatically and that require some level of human interaction. For each of such issue it is
necessary to document who should solve the issue, how and how fast.
For each issue type document responsibility for resolution of the issue in a table:
ID unique identification of an issue type
Issue Type short description of the issue type
Responsible Role - who is primarily responsible for solving the issue
Resolution what is the expected way how the issue should be solved
Expected Resolution Time when the issue should be resolved
The issue responsibility has to be agreed on and eventually signed off by the customer.
Escalation Hierarchy
Define how issues are escalated in case initial resolution fails or further notification is needed. For each issue, document an escalation hierarchy in a table. For each issue
defined in the previous component, identify an escalation hierarchy. Confirm the escalation hierarchy with the customer.
The escalation hierarchy defines the severity of the problem that must be tackled at each level. This is to be used in conjunction with the issue resolution section above.
If possible, define the method of reporting errors back to the data owner and include correction procedures. Otherwise errors will be escalated to ever-higher levels of
disinterested management. The ideal would be a closed loop that results in error correction within a predetermined period.
For each issue type, document escalation procedure and hierarchy in a table:
ID unique identification of an issue type
Issue Type short description of the issue type
Responsible Role - who is primarily responsible for solving the issue
Escalation Role to whom the unsolved issue should be escalated or who should be notified when an issue is reported
When to Escalate when the issue should be escalated (e.g., if the issue is not solved within 1 business date, etc.)
Escalation Process describe the escalation process (e.g., send mail, document the issue in a helpdesk system, etc.)
The issue escalation hierarchy has to be agreed on and eventually signed off by the customer.
DATA QUALITY - TRANSFORMATION DETAILS
Identify the data transformation requirements collected in workshops with ambassador users. Agree on the transformation rules with ambassador users. Document each
data quality transformation rule in a table:
ID unique identification of the transformation
Business Entity entity the transformation is related to
Business Attribute attribute the transformation is related to
Transformation short name of the transformation
Description description of the transformation using either the pseudo code or free text (depending on the transformation type)
Back to Top
Back to Top
System Architect (Information Architect) Formulate the projects Data Acquisition, Conversion and Data Quality Strategy. Contact appropriate
technical experts for advice if necessary. Develop a testing strategy for data conversion modules.
Identify, assess and mitigate data conversion risks. Define issue-tracking procedures. Preferably, this
should be done by a system architect that specializes in Information Architecture.
If a Data Acquisition and Conversion team leader has been designated, 60% of this time would be
allocated to this individual, leaving 20% allocated to the system architect. The team leader would
then develop a testing strategy for data conversion modules and identify, assess and mitigate data
conversion risks, and define issue-tracking procedures.
80
Application/Product Specialist Provide knowledge and guidance regarding the functionality and capabilities of the product(s) being
implemented.
20
Client Data Administrator *
Client System Architect (Information Architect) *
IS Operations Staff Provide information on data to be converted and current application structure. *
User Provide information on data to be converted. *
Back to Top
PREREQUISITES
Prerequisite Usage
Relevant existing reference material Review any documents provided by the client on existing data sources, as well as any meeting notes on volume
of data, access restrictions on existing data sources or any findings from Data Assessment/Client Workshops.
MoSCoW List (RD.045) Use the MoSCoW List to identify target systems.
Data Design (DS.090) The data the new system uses is detailed in the Data Design.
(CV.010)
The Data Acquisition and Conversion Requirements defines the scope and objectives as well as the critical
success factors and risks associated with the data acquisition and conversion.
Back to Top
TEMPLATES AND TOOLS
CV-
020_DATA_ACQ_CONVERSION_AND_DATA_QUAL_STRATEGY.DOC
MS WORD
Back to Top
The Data Acquisition, Conversion and Data Quality Strategy is used in the following ways:
by the Data Acquisition and Conversion project leader to communicate to the client the strategy you plan on using to successfully acquire/convert their legacy data
to the new Oracle system(s)
by the Data Acquisition and Conversion team to help the client clearly document their requirements
by the Data Acquisition and Conversion team as a road map for performing the acquisition/conversion - All members of the team, both application development and
business team members, should understand and follow the same strategy
by the project manager to understand how the Data Acquisition and Conversion team plans to perform the acquisition/conversion, what the client's conversion
requirements are, and how the effort may impact the overall project
Back to Top
QUALITY CRITERIA
Have all systems identified in the Data Acquisition and Conversion Requirements (CV.010) been considered and the constraints addressed?
Has the strategy been communicated clearly in the work product?
Are the conversion requirements clearly defined?
Have all legacy applications and objects been considered?
Has the level of detail and history to be converted been defined?
Are all assumptions, constraints, and risks which could impact the conversion process stated and understood?
Has sufficient effort been expended on seeking alternative approaches that will perform the data conversion quicker, cheaper and at lower risk to the project?
Has the ambassador user, who should validate the data ownership, issue resolution processes, points of escalation and the other data quality requirements
reviewed the document?
Does the work product describe methods for ensuring consistent and error prone data transfer from the data quality point of view?
Does the work product describe methods for handling exceptions and errors that have been identified?
Does the work product describe the checks performed in the Audit and Control section? Even if no business checks have been identified the document should
contain a minimum set of technical checks.
Does the work product describe data cleansing requirements and methods how to implement the data cleansing requirements? If no data cleansing requirements
have been identified the document should state so.
Back to Top
CV.025 - DEFINE DATA ACQUISITION AND CONVERSION
STANDARDS
In this task, you define the Data Acquisition and Conversion Standards that the project team follow when performing conversion tasks. Document the file structure and
naming conventions for the legacy and target systems, as well as for any automated tools used to facilitate the conversion.
ACTIVITY
Back to Top
WORK PRODUCT
Data Acquisition and Conversion Standards - The Data Acquisition and Conversion Standards documents the legacy system, target system, and automated tool
conversion standards. It should address the following:
standards to be followed in extracting data from the legacy systems
standards to be followed in uploading data to the target systems
standards to be followed for automated conversion tools
standards for preparation of Data Acquisition and Conversion work products
Back to Top
TASK STEPS
1 Review existing internal
organization and project
standards.

2 Review recommended standards
for selected automated tools.

3 Describe the purpose and
audience for the Data Acquisition
and Conversion Standards.
Introduction This component describes the purpose of the Data Acquisition and Conversion Standards.
4 Document conversion standards
for writing conversion programs to
extract data from the legacy
system.
Conversion
Standards for
Legacy Systems
This component describes the file system and naming conventions of the legacy systems for each business
object being converted. Do not assume that each legacy system has the same file structure.
for creating programs in the target
environment.
Conversion
Standards for
Target Systems
This component describes the file structure for the conversion programs written on the target
system/environment. You may want to refer to the target application database structure. This component
also documents the file naming conventions for the files associated with each conversion task in the
conversion process.
For example, the Design Conversion Components (Initial Load) (CV.040) task may have the following file
naming convention: invitmds.doc for inventory item design. Also consider the importance of version control
when defining your file naming rules.
6 Document specific automated tool
standards for the conversion
process.
Conversion
Standards for
Automated Tools
This component documents the file structure in this conversion effort so that conversion team members
know where to store files and how to name them. Keep in mind that each tool you use to facilitate the
conversion effort inherently has its own file structure.
for developing conversion work
products.
Conversion
Standards for
Data Conversion
Work Products
This component documents the following standards to be used when developing Data Acquisition and
Conversion work products:
writing standards
table standards
style standards
8 Review standards with the Data
Acquisition and Conversion team.

9 Secure acceptance of the Data
Acquisition and Conversion
Standards.

Back to Top
APPROACH
The Data Acquisition and Conversion Standards documents standards that are specific to the Data Acquisition and Conversion process. Make these standards
complementary to the other standards of the project.
If the organization already has a preferred file structure and naming conventions on the legacy system, minimize the impact by continuing to use these standards.
The standards for automated tools should detail the file structure used for each of the automated tools that you will use on the conversion project. You should consider
existing standards defined for common tools, such as SQL and PL/SQL.
You may be able to begin development of Data Acquisition and Conversion Standards prior to the completion of Design and Build Standards (DS.050), but avoid
duplicating or conflicting with its contents.
Back to Top
Back to Top
System Architect 100
IS Manager *
Back to Top
PREREQUISITES
Prerequisite Usage
Quality Management Procedures (PJM.QM.010)
These prerequisites document the quality policies for the overall implementation project.
Design and Build Standards (DS.050) The Design and Build Standards contain rules and assumptions to which the designers must adhere when
designing and building custom programs.
(CV.010)
The Data Acquisition and Conversion Requirements documents the conversion requirements that the Data
Acquisition and Conversion Standards must address.
Strategy (CV.020)
The Data Acquisition, Conversion and Data Quality Strategy is used to record the strategy for meeting the
previously defined Data Acquisition and Conversion Requirements. It is intended to provide a road map for
performing the conversion of data from the legacy system(s) to the new Oracle system.
Back to Top
TEMPLATES AND TOOLS
CV-025_DATA_ACQ_AND_CONVERSION_STANDARDS.DOC MS WORD
Back to Top
The Data Acquisition and Conversion Standards is used to document and understand the conversion standards that govern the legacy and target system environments.
Back to Top
QUALITY CRITERIA
Do the new CV standards conflict with other standards (DS.050 or client's already existing standards)?
Are the new standards understood by the team?
Are there examples or templates to ensure compliance?
Back to Top
CV.027 - PERFORM DATA MAPPING
In this task, you perform a data mapping. Start with the Business Data Source Gap Analysis (RA.160), which provides a preliminary mapping. For data acquisition, create
a cross-reference from the data source objects to the target logical database objects. Validate that the data required for analysis can be traced back to its original source
and that it supports the information requirements of the users.
For conversion, create a detailed conversion mapping from the source legacy system to the target application and an extract file layout to be used for extraction of the
data from the source system.
ACTIVITY
CV.027.1
CV.027.2
Back to Top
WORK PRODUCT
Data Mapping - The Data Mapping defines the key assumptions, mapping between source and target, and mapping rules and logic that is needed to create the
conversions and interfaces necessary to support the solution. It is intended to provide the developer with the necessary information for writing accurate conversion,
transformation and load logic.
Back to Top
TASK STEPS
1 Provide an introduction for
the document.
Introduction The Introduction includes the definition, purpose, practical application and related documents of the work product.
2 List any data acquisition
assumptions.
Data
Acquisition
Assumptions
The Data Acquisition Assumptions provides any assumptions for the data acquisition and provides the scope of the data
acquisition. Make certain that the scope accurately reflects any and all areas that this task and work product cover as
well as any areas that may have been taken out of scope for this project.
3 Review the Data Sources
component of the Data
Acquisition and Conversion
Requirements (CV.010).
Data
Acquisition
High-Level
Source to
Target
Mapping
Identify the objects in the source systems that map to the targets. Identify the type of source systems and interfaces that
can be used to extract data from them.
4 Provide a brief description
of the interfaces identified
in the solution.
Data
Acquisition
High-Level
Source to
Target
Mapping

5 Create sections for all target
objects as in the high-level
mapping table.
Data
Acquisition
Column-to-
Column
Mappings
List all the columns as in the Logical Database Design (DS.150) with their data types. Flag not null and primary
key/foreign key columns provided, and enter the default value the column would take, if applicable.
6 Identify the data sources of
the target columns and any
transformations that are
needed, such as calculated
Data
Acquisition
Column-to-
Column
The Business Data Source Gap Analysis (RA.160) may have certain resolutions affecting the mapping.
fields and aggregations. Mappings
7 Where needed, provide
explanatory notes for the
business logic used in the
mapping.
Data
Acquisition
Column-to-
Column
Mappings
Use the notes to describe filters, advanced transformations and others mapping attributes that cannot be described
within the column-to-column mappings.
8 Provide other
considerations that are
relevant for the mapping,
such as cleansing
requirements and
workarounds.
Data
Acquisition
Column-to-
Column
Mappings

9 List any conversion
assumptions.
Conversion
Assumptions
The Conversion Assumptions lists any conversion assumptions. It should contain the following sections:
Scope - This section briefly states whether the conversion of this entity object will be manual or programmatic
and the name of the legacy system to be converted as well as the volume of data to be converted and any
exceptions of which the developer needs to be aware.
Cleanup Criteria - This section addresses cleanup criteria specific to the entity object for which this document is
being written. An example of cleanup criteria could be that no closed sales orders will be converted. In this case
it should be stated that a pre-conversion component will be written to make sure that no closed sales orders are
brought into the new Oracle application. For some objects it makes most sense to cleanup or merge the data
after the conversion takes place. If this is the decision which has been made, it should be stated here.
10 Describe the conversion
approach.
Conversion
Approach
The Conversion Approach is a description of the Oracle tables that will be populated during the conversion and the
order in which the tables need to be populated. It should contain the following sections:
Conversion Tables - This section should list the Oracle tables for mapping and populating, the legacy file names
to be extracted, and any other file names which are important to the conversion of this entity object.
Dependencies - This section should list any other dependencies which may affect the conversion. For example,
this is a good place to list component and configuration prerequisites specific to the conversion of the entity
object.
If an automated conversion tool is being used to create templates and/or mapping documents, the directory location
and file name should be documented in this section.You may want to create a logical flow diagram of the conversion
approach for an object to help the reader visualize the flow of the conversion approach.
11 Define the data mapping
from the legacy system
data to the new database.
Conversion
Mapping
The Conversion Mapping component provides a table that shows to which table and column the legacy system data
fields map in Oracle. It should also indicate the datatype of the target field and whether the target column is required or
not. All of the rules that are detailed in other components of this work product document should be referenced in this
mapping table. This provides a cross-reference between this data mapping table and the rules tables.
You should prepare one mapping table in this document for each table to which you are mapping. For example, if for
customers you are going to be storing information in two tables (one for customer name and address and the other for
customer phone number information), you should prepare a mapping table for each of the two tables you are will be
populating.
12 Detail the extract file layout
from the legacy system.
Conversion
Extract File
Layout
The Extract File Layout component provides a table that details the extract file layout from the legacy system. It is
important to document the position of a specific data element for the legacy system. For example, document that the
customer name is always going to be in position 5 through 25 in the flat file. Depending on the tool you choose to use
for the conversion, it may be necessary to have the IS support staff provide a fixed length ASCII flat file.
Back to Top
APPROACH
This task precedes the actual build of the conversion components. The logical database designs of the target database(s) are available at this stage. Details of the source
systems have been identified such as their access constraints and the interfaces that can be used to extract data from them. By mapping the sources to targets, this task
ultimately reconciles the data requirements (from the target) and the data available (from the source).
For BI Engagements, The source to target mapping can be done in a tool, such as Oracle Warehouse Builder (OWB), and this task can be done concurrently with the
gap analysis performed in Conduct Business Data Source Gap Analysis (RA.160). The identified gaps in the Business Data Source Gap Analysis are actually an output
of the preliminary mapping done in the Conduct Business Data Source Gap Analysis when there are required fields with no source. This happens when attributes are
stored locally in spreadsheets or the operational system has evolved and needs to be changed to capture a key field.
The work product produced in this task is input to the Conversion Component Designs (CV.040).
Data Acquisition High-Level Source to Target Mapping
The types of interfaces that may be used in the extracting data from the sources may be:
Oracle database links: Database links are objects that allow extraction of data from Oracle RDBMS sources to target Oracle databases through SQL.
Enterprise Application Connectors: Extraction tools or components that enable extraction from common enterprise applications such as Oracle Applications, SAP
or PeopleSoft.
Flat files: Flat files may be loaded through standard database tools like SQL*Loader, or through database objects called external tables. External tables are Oracle
database objects that allow transparent access to flat files as though they were database tables.
Data Acquisition Column-to-Column Mappings
Be aware that for larger projects there might be many thousands of column-to-column mappings. In this case it is not feasible to store and maintain the mappings within
the MS Word document and it is better use another tool (e.g., MS Excel, database application, etc.).
The column-to-column mappings within the work product template is structured by target objects, i.e., there is one table for each mapped target object. You might also
consider structuring the mappings according to the Target Object / Primary Source Object pairs, in which case there will be one table per each Target Object and Primary
Source Object pair.
The mappings described in this work product should be understandable by business users. It is therefore necessary to describe the mapping in business terms.
Data Conversion
Map the legacy source business objects and attributes to the target application tables and columns. Provide a table that shows to which table and column the legacy
system data fields map. Developers use the conversion map and the Conversion Component Designs (CV.040) to develop the conversion code. Regardless of whether
you are using traditional coding methods or an automated conversion tool, the data map is the basis for the conversion design, build, and execution tasks.
Back to Top
Back to Top
System Architect (Information Architect) Perform and document the data mapping. Preferably, this should be done by a system architect that
specializes in Information Architecture.
100
Client Data Administrator Assist with the data mapping. *
Back to Top
PREREQUISITES
Prerequisite Usage
(CV.010)

Application Setup Documents (MC.050)
Logical Database Design (DS.150)
Business Data Source Gap Analysis (RA.160) The Business Data Source Gap Analysis is a preliminary mapping. Use it as a starting point.
Client Documents If available, review documents provided by client on existing data acquisition tools and methods.
Workshop/Meeting Notes If conducted, review any documents from any data acquisition workshops.
Back to Top
TEMPLATES AND TOOLS
CV-027_DATA_MAPPING.DOC MS WORD
Back to Top
The Data Mapping is used in the following ways:
by the project manager to assess the complexity of of the conversion components and to define development partitions and assign resources
by the project team during the execution of the Data Acquisition and Conversion tasks, specifically for the development of conversion components
Back to Top
QUALITY CRITERIA
Is it complete with all the columns of the target logical database designs listed and mapped to sources?
Does it include columns in target objects that do not map to any source, but are generated by the acquisition components, such as synthetic keys and audit
information (e.g., CREATED_DATE)?
Does it also list the problems identified in the sources in the Data Acquisition and Conversion Requirements (CV.010) that affect the mapping, such as security
controls on the source data that limit extraction?
Is it consistent with the resolution of the gaps specified in the Business Data Source Gap Analysis (RA.160)?
Back to Top
CV.030 - PREPARE CONVERSION ENVIRONMENT (INITIAL
LOAD)
In this task, you create the Conversion Environment (Initial Load), including the hardware platforms, servers and other software required to support the design and build
activities of conversion and/or initial load of legacy data to the new system.
For projects that involve the upgrade of Oracle products, the Conversion Environment is typically used to iteratively test the upgrade process. Therefore, depending of the
project phase and specific iteration, this task is used to create or refresh the Conversion Environment.
ACTIVITY
CV.030.1
CV.030.2
Back to Top
WORK PRODUCT
Conversion Environment (Initial Load) - The Conversion Environment (Initial Load) is a working applications system environment that includes all of the servers,
applications, and development tools required to develop and test conversion programs. It should address the following:
conversion environment hosting and environment sharing arrangement
conversion environment database, applications, and desktop client server architecture and configurations
automated tool requirements
Back to Top
TASK STEPS
1 Review Architecture Requirements and Strategy (TA.020) to understand the strategy for deployment of
project environments in general, and the conversion environment in particular.

2 Update the introduction component to reflect the conversion environment hosting and environment
sharing strategy per the Architecture Requirements and Strategy (TA.020).
Introduction This component describes the purpose for
the Conversion Environment and the
detailed configuration approach taken to
implement the environment.
3 Document the environment specifications for the Conversion Environment, including database, servers,
any special database objects or user IDs necessary to run the conversions, indexes to be dropped and
recreated after the conversion is completed, any security implications or access that only apply to the
Conversion Environment, etc.
Environment
-
Conversion
This component describes the Conversion
Environment configuration, including
infrastructure, database and application
user details.
4 List any other software applications needed to support data conversion. Other
Applications
This component describes the
configuration of any other software
applications that are required to support
the project.
5 Update the automated conversion tools component to reflect the configuration for each conversion tool. Automated
Conversion
Tools
This component describes the
configuration of any other software tools
that are required to support the
conversion activities of the project.
6 Set up the conversion environment.
7 Install the conversion programs and automated conversion tools.
#TOP #TOP
Back to Top
APPROACH
In some situations, you might combine the Conversion Environment (Initial Load) with the Development Environment if it is certain that conversion and development
activities can share an environment without the danger of one effort impacting the other.
Install and configure the Conversion Environment (Initial Load) so that the conversion design and build tasks can be completed without affecting the work performed in
other areas of the project. This usually requires the establishment of an entirely separate instance of the database and application software.
Large or complex conversions often require an environment where you can load legacy data into and purge data from the application tables multiple times. If you do not
set up a separate Conversion Environment (Initial Load), you run the risk of not being able to control the converted data adequately. Attempting to perform the conversion
activities in the same environment used for other project activities may adversely affect those environments.
There is a risk associated with setting up a separate conversion environment. If the other implementation instances update the application configuration, the changes
must also be applied to the Conversion Environment (Initial Load) to help make sure that the conversion tests mimic the eventual production instance. It is very important
that the conversion programs be designed and tested in an environment that has the same application configuration as the production environment.
Back to Top
Back to Top
Database Administrator 30
System Architect 10
Back to Top
PREREQUISITES
CV.030.1
Prerequisite Usage
Architecture Requirements and Strategy (TA.020) The Architecture Requirements and Strategy identifies the application and technical requirements for the
Conversion Environment (Initial Load).
(CV.010)
The Data Acquisition and Conversion Requirements defines which business objects are subject to
conversion. It also specifies the method of conversion and tools used for the conversion, which in turn helps
determine the variables required for building the conversion estimate and workplan.
Strategy (CV.020)
The Data Acquisition, Conversion and Data Quality Strategy is used to record the strategy for meeting the
Data Acquisition and Conversion Standards (CV.025) Refer to the Data Acquisition and Conversion Standards before establishing the file structure for the
Conversion Environment (Initial Load).
Present and Future Organization Structures (RD.012) The Present and Future Organization Structures may provide information on key transaction and data
volumes for preparing the Conversion Environment (Initial Load).
CV.030.2
Prerequisite Usage
Conversion Environment (Initial Load) (CV.030.1) Update the initial Conversion Environment (Initial Load), as appropriate.
Back to Top
TEMPLATES AND TOOLS
CV-030_CONVERSION_ENVIRONMENT.DOC MS WORD
Back to Top
The Conversion Environment (Initial Load) is used to develop and test Conversion Components.
Back to Top
QUALITY CRITERIA
Back to Top
CV.035 - DEFINE MANUAL CONVERSION PROCEDURES
(INITIAL LOAD)
In this task, you define the plan to convert the business objects that require manual entry for conversion, and/or initial load of legacy data to the new system.
The resulting procedure provides a detailed guide for manually converting data to successfully meet conversion project milestones.
ACTIVITY
CV.035.1
CV.035.2
Back to Top
WORK PRODUCT
Manual Conversion Procedures (Initial Load) - The Manual Conversion Procedures (Initial Load) define how to manually convert a business object. In addition, they
discuss the impact, if you do not successfully convert business objects in the required time frame. You should produce one work product for each manually converted
business object. Use this work product as a roadmap for those who will be performing the manual conversion. It should address the following:
the business object to be converted manually
the legacy data elements to be converted, and those that will not be converted
data cleanup and normalization
responsibility and schedule for manual conversion
navigation and data entry guidance for users
Back to Top
TASK STEPS
1 Describe the purpose and audience for the Manual
Conversion Procedures.
Introduction This component describes the purpose, use, and audience for the Manual Conversion
Procedures.
2 Describe the manually converted business object. Business
Object
Description
This component describes the business object that requires manual conversion.
3 List the data elements for this business object in the legacy
system and identify those that will be converted, and those
that will not be converted to the Oracle target application.
Data
Elements to
be
Converted/Not
Converted
This component lists the data elements within the legacy for the business object that
will be converted to the Oracle Application and identifies those that will not be
converted (do not assume that all data elements for this business object need to be
converted to Oracle).
4 Identify the legacy data that requires review for cleanup and
entry and the data that must be combined or adjusted to
match the structure of the target Oracle Application.
Legacy Data
Cleanup and
Normalization
This component defines data that requires visual identification and inspection for
cleanup and entry and data that must be combined or adjusted to match the structure
of Oracle Applications data.
For example, the legacy system may store different vendor addresses as separate
vendor records with the same vendor name. In Oracle Purchasing, each vendor has
one master record for the name and other common information with related address
records stored in a different table.
5 Identify the person responsible for the manual conversion of Conversion This component lists the person who is responsible for the success of this manual
#TOP #TOP
the business object and indicate who will be performing the
manual conversion. In addition, identify the instance
requiring manual data conversion and indicate the
conversion priority dates per conversion business object.
Responsibility
and Timeline
conversion effort, as well as the names of the individual users who will be entering
and verifying the data. It also documents the scheduled start and end dates for the
manual conversion of this business object. In addition, this component states the
impact of not meeting these deadlines on the overall conversion and implementation
project.
6 Complete a worksheet that shows the navigation path for
manually inputting the legacy data into the target
application and the values to be entered.
Conversion
Procedures
This component documents the navigation path that instructs the user how to navigate
and manually enter the data. This component also includes a table that lists fields to
be populated, the legacy data element needed to populate, whether there is a list of
values for the field, the default value if necessary, and any notes that would help the
user.
7 Secure acceptance that the Manual Conversion Procedures.
Back to Top
APPROACH
Manually converting legacy data is the appropriate decision in many cases. Although manually converting data is technically less complicated, it may take more time.
Therefore, it is critical to avoid underestimating the manual conversion effort and, as a result, delaying the production date. There is also a risk of introducing keystroke
errors.
Consider manually converting data for business objects with low data volumes. You need to weigh the time and expense of manually entering data into the target
application versus the time and expense of programmatically converting the data. Consider also the number of times this process will be repeated during and post project
end.
Think about this alternative also if the source data should be verified through some complex validation on the target system.
Screen Scraper/Testing Tools
In addition to the option of entering the legacy data into the Oracle target application via manual data entry, consider the option of using an automated screen scraper
(macro creating tool) or testing tool to load the data. A screen scraper (macro creating tool) is a utility that reads a text file and automatically send keystrokes to the target
application simulating user input. These tools allow you to partially automate a conversion without writing conversion programs.
Also consider using spreadsheets and transforming data through the use of formulas. This method allows also the generation of complete SQL commands inserting or
updating data.
Timing
During the production conversion, the users or data entry personnel will manually enter the legacy data if you are not using a screen scraper or testing tool. You can
begin manual data conversion of static business objects while developers are coding and testing automated conversion programs. This way, you minimize the amount of
manual conversion required during production cut over.
Manually Converted Data and Business System Testing
You must decide how much manually converted data you require for Perform System Test (TE.070) and Perform Systems Integration Test (TE.100). With an automated
conversion, you can simply run the conversion programs in both the testing environment and the production environment. For manually converted data, you must reenter
the information in both environments. Fortunately, a subset of data is usually adequate for testing purposes.
Back to Top
Business Analyst 100
Back to Top
PREREQUISITES
CV.035.1
Prerequisite Usage
Data Acquisition and Conversion Requirements The Data Acquisition and Conversion Requirements identifies manually converted business objects.
(CV.010)
Strategy (CV.020)
The Data Acquisition, Conversion Data Quality Strategy is used to record the strategy for meeting the
Legacy Data Cleanup Legacy data identified in the Data Acquisition and Conversion Requirements (CV.010) and Data Acquisition,
Conversion Data Quality Strategy (CV.020) for pre-conversion data cleanup should meet the data cleanup,
data reduction, and normalization requirements.
CV.035.2
Prerequisite Usage
Manual Conversion Procedures (Initial Load)
(CV.035.1)
Update the initial Manual Conversion Procedures (Initial Load), as appropriate.
Back to Top
TEMPLATES AND TOOLS
CV-035_MANUAL_CONVERSION_PROCEDURES.DOC MS WORD
A screen scraper (macro creating program) or testing tool with keystroke emulation may be an alternative to keying the legacy data directly into the target system. The
screen scraper tool reads the data extract flat file and automates the keystrokes required. By using such method, data is subject to the application level validations of the
target systems.
Back to Top
The Manual Conversion Procedures (Initial Load) is used in the following ways:
to document an easy-to-follow plan
as a guide for performing the manual conversion for a given business object.
Prepare a separate document for each business object you are converting manually.
Back to Top
QUALITY CRITERIA
Back to Top
CV.040 - DESIGN CONVERSION COMPONENTS (INITIAL LOAD)
In this task, you design and document all the components required to extract, transform, and load data into the new solution in order to support the Data Acquisition,
Conversion and Data Quality Strategy (CV.020) task for only the source data that is loaded once into the new solution (Initial Load). Data loaded on an ongoing basis,
such as data from interfaces are addressed through the normal development lifecycle of OUM (e.g., processes such as AN, DS, IM, etc.). This task also includes
describing the data and process flow, as well as test scenarios or procedures required for component testing and data integrity testing of all components utilized in the
initial loading of data into the solution.
The term "ETL" is commonly used to describe extract, transform, and loading of data. It should be noted that in some cases "T" (transformation) of ETL may be as minimal
as encoding, or decoding source data during extraction and loading steps, or transformation may not occur at all for some solutions.
The actual coding of these components is done in the subsequent task, CV.055, Implement Conversion Components (Initial Load). Remember to iterate design,
implementation and testing following the OUM principles.
ACTIVITY
CV.040.1
CV.040.2
Back to Top
WORK PRODUCT
Conversion Component Designs (Initial Load) - The Conversion Component Designs (Initial Load) defines the conversion components and transformation logic, as
well as the ETL process flows required for data extraction, transport, transformation and load for the solution. It identifies all the components of each ETL process
including data complexities or constraints for conversions and interfaces. It is intended to provide the developer with the necessary information for writing accurate
conversion components. In addition, test scenarios or cases are developed to support unit testing of each data acquisition components.
Back to Top
TASK STEPS
1 Provide an
introduction
for the
document.
Introduction The Introduction describes the purpose and practical application of the work product.
2 Define
conversion
rules
necessary
for
performing
the data
conversion.
Processing
Rules
Translation
Rules
Filter Rules
Foreign Key
Rules
The Processing Rules component provides a table that lists processing rules to be used, and assigns a processing rule number, such
as PR1, to a processing rule. The table should then document the source and target system and field to which the rule applies. Each
rule should be explained under the table. An example of a processing rule is for a general ledger account ID, the old account number
must first be mapped to the new account number. This may be accomplished by building a translation table in Oracle which maps the
old account number to the new account number.
The Translation Rules component provides a table that lists translation rules to be used, and assigns a translation rule number, such as
TR1, to a translation rule. The table should then document the source and target system and field to which the rule applies. Each rule
should be explained under the table. An example of a translation rule is the translation of a payment term which is stored as Net 30 in
the legacy system to NET 30 DAYS.
The Filter Rules component provides a table that describes the filter rules to be used, and assigns a filter rule number, such as FR1, to
each. The table should then document the source and target system and field to which the rule applies. Each rule should be explained
under the table. An example of a filter rule is if you filter the data to pad a field in the legacy system with blanks before the conversion of
the data element (field) to the target system because of the way the data is being stored in the legacy system. The tool you use may
dictate the use of filtering rules.
#TOP #TOP
The Foreign Key Rules component provides a table that lists the foreign key rules to be used, and assigns a foreign key rule number,
such as FKR1, to a foreign key rule. The table should then document the source and target system and field to which the rule applies.
Each rule should be explained under the table. An example of a foreign key rule is to select the order internal ID before you can assign
a order line to the purchase order. This rule requires that the legacy order numbers are converted before the detail lines of the order
are converted.
3 Define the
logic
necessary
for
downloading
data from
legacy
system.
Download
Logic
Temporary
Table
Creation
Logic
The Download Logic contains the logic required for the download or extract component. It also specifies who is going to perform the
extract. Typically, the IS support staff is responsible for providing extract files for conversion testing and conversion production loading.
However, depending on the tool that is going to be used to upload the data to Oracle you may have to be very specific about how you
want the extract file to look. An example of logic that needs to be documented is: there must be multiple records per order being
converted in the extract file for order lines.
The Temporary Table Creation Logic contains the logic required for the components that are written to create temporary tables for
conversion. It also specifies who is going to write the code to create these tables and how many tables need to be created.
Target system production tables should not be populated directly during conversion. The legacy data should first be moved to one or
more temporary tables. The number of temporary tables required for the conversion of an entity object depends on the complexity of
the entity object being converted. The level of complexity is not necessarily data volume driven, but is more dependent on the number
of processing, translation, filter, and foreign key rules. Traditional code can be written to create these tables, or if you are using an
automated conversion tool, the target system tables may be able to be copied. The temporary tables provide a place for you to perform
all of the rules you have defined for a specific entity before moving the data into the production tables.
4 Define the
logic
necessary
for
uploading
data to the
new
database
Upload
Logic
Translation
Logic
Interface
Logic
The Upload Logic contains the logic required for the components that are written to upload the data from the flat file to the temporary
tables. It also specifies who is going to write the code for the translation components. There are many tools available for uploading the
data. The temporary tables should already have been created before the upload component is run. Several automated conversion tools
provide loader functionalities.
The Translation Logic contains the logic required for the components that are written to perform any required processing, translation,
filter, or foreign key rules for conversion. It also specifies who is going to write the code for the translation components. Once you have
created and loaded the temporary tables, code must be written and executed to manipulate the data to be in the correct format that the
target application needs to operate. The translation logic must perform the logic dictated by the rules defined in the Conversion
Component Design document. This data manipulation must be executed before the data is moved to the production tables. Traditional
code can be written using tools such as for example SQL*Plus or PL/SQL, or an automated conversion tool can be used.
The Interface Logic contains the logic required for the components that are written to move the data being converted from the
temporary tables to the Oracle production tables. It also specifies who is going to write the code for the interface components. It is
important to remember that the these interface components not only move the data to the production tables but also perform any
required data validation.
Typically, the level of validation required is consistent with the validation being performed by any application logic. For example, if the
an order entry application validates that the customer on the order is already a customer that exists in the order entry system then your
interface component should typically do the same. If the level of validation is not the same as the application level validation, then when
the converted order is queried in the new Oracle system, the user may get an error message. An automated conversion tool may also
be the best option for writing your interface components. The tool can be used to perform the necessary lookups required to enforce
data validation in target application tables.
5 List all the
data flows
for the
solution.
Data
Acquisition
Components
-Solution /
Data Flow
This component contains a matrix listing all the Data Flows that comprise this solution.
6 Investigate
each flow
from
Source to
Target.
<Data Flow>
Process
Technical
Overview
This component describes each Data Flow in the solution. It should include the following sections for each data flow:
Data Flow Diagram
Data Flow / Mapping Matrix
Data Flow Assumptions
Data Flow Prerequisites
Frequency of Execution
7 Describe in
detail each
mapping
within each
data flow.
<Mapping>
Specification
This components describes in detail each mapping within each data flow. It should include the following sections:
Mapping Assumptions
Mapping Prerequisites
Interface Input/Output Parameters
Exception Handling
Pre-Processing Script
Post-Processing Scripts
Error Logs
Special Considerations
Data Requirements
ETL Processing Details
Unit Test Cases
Back to Top
APPROACH
Review the Data Mapping (CV.027). Develop the conversion rules, which include Processing Rules, Translation Rules, Filter Rules, and Foreign Key Rules. When the
rules have been defined, the developer must define the download logic and finally the upload to the Oracle database logic.
*Use the following to access the task-specific custom BI supplemental guidance.
Data Acquisition Components
The specifications of the Data Acquisition Components are actually comprised of three components: a summary level, a data flow level and a mapping level. These three
components combined comprise what is commonly referred to as a Data Acquisition Technical Model.
SOLUTION / DATA FLOW
List all the data flows for the solution. Give them meaningful names and full descriptions.
Ensure that all the data flows for this solution are listed.
Provide a table that acts as a checklist against which subsequent layers or detail can be specified.
The Data Flows should be given meaningful business names.
<DATA FLOW> PROCESS TECHNICAL OVERVIEW
Investigate each flow from source to target. Provide the following sections for each data flow:
Data Flow Diagram
Copy this component and complete it for each data flow listed in the first component, Solution / Data Flow matrix.
Data Flow Diagram
Show the information diagrammatically. Present a high-level diagram indicating the appropriate interfaces and the data flow stages.
The diagram should show clearly how data is extracted and transformed between source and target for the particular Data Flow.
Even though this is a logical level attention should be given to the potential reuse of mappings within and between Data Flows.
Provide a matrix listing all the mappings that comprise this data flow. Using the associated Data Flow Diagram as a base list all of the mappings that form this Data Flow.
Use agreed on naming standards and provide meaningful business descriptions. Define the ETL technology to be used. Identify any prerequisite mappings possibly from
other flows. Consider the following about the associated Data Flow Diagram when completing the Data Flow / Mapping Matrix
List the mappings that are part of this data flow of the data warehouse, and to identify the ETL technology that is going to be used for development of each
mapping.
This list is a subsection of what was already listed in Solution / Data Flow component.
If an ETL tool is going to be used for development then mention it here. However, there could be cases where a source system may want to push data out by
running a script within itself. Such cases should also be mentioned here.
For each mapping, any (immediate) prerequisite mappings should be identified so that the order of execution of all listed mappings is clear to developers and
testers, and for scheduling purposes.
List any assumptions for the development specifications that pertain to the Data Flow.
List any assumptions specific to each data flow. Where a component comprises more than one data flow, refer to assumptions made for a previous data flow rather
than repeat them (e.g., generic assumptions for all data flows are stated under first data flow and cross-referenced to).
Make appropriate references to the technical architecture and the requirements documents, etc.
List any prerequisite steps.
List the prerequisite steps that must be completed before this data flow component can be executed.
Mention the errors that can possibly result due to failure to complete these steps.
Mention the list of the tools that would be used for the development of this component. Also mention the role of usage of these tools. It is an implicit understanding
that the setup of the necessary runtime environments of these tools would be available during the execution of this component.
Make appropriate references to the technical architecture and the requirements documents, etc.
How often does this Data Flow need to be executed in the production environment, e.g., once only / ad hoc (i.e., as and when new data is required) / nightly / monthly /
etc., and/or any system events that are required to trigger execution of the Data Flow. Determine the frequency of execution of this Data Flow. Define any special cases.
When considering the frequency of execution, it is important to take a holistic view of the data being provided to the Data Warehouse.
During Requirements Analysis, discussion should have taken place on update frequency. Quite often unrealistic update frequencies are demanded. The important
thing to remember is the business context in which this data will be used. For example, call volumes in a Marketing Call center change frequently, but value of
production plant does not.
<MAPPING> SPECIFICATION
Describe in detail each mapping within each data flow. Where a mapping is reused by many data flows, it only needs to be described once. Provide the following sections:
Mapping Assumptions
Exception Handling
Post-Processing Scripts
Error Logs
Data Requirements
Unit Test Cases
Where a mapping is reused by many data flows, it only needs to be described once.
Mapping Assumptions
List any assumptions that pertain to this mapping.
List any assumptions that relate specifically to this mapping only. Omit this section if there are no such assumptions.
Make appropriate references to the technical architecture and the requirements documents.
List any Prerequisites for this mapping.
List any pre-requisite steps that must be completed before this mapping can be executed. Omit this section if there are no such pre-requisites.
Mention the errors that can possibly result due to failure to complete these steps.
Make appropriate references to the technical architecture and the requirements documents.
List all parameters for this mapping, stating clearly if they are input or output. Provide a meaningful comment for each. Document the meaning of specific return values,
using a table, if appropriate.
List all the parameters that would be required by the program / process accessing this ETL process.
Mention the usage and expected return values from these parameters.
Optionally, enclose a table listing the return values and the corresponding interpretation of these parameters.
Exception Handling
List any exceptions that may occur and how they should be handled. Identify and list the exception scenarios or situations that are specific to this mapping and how they
are to be handled. List of exceptions and ways of handling them through pseudo codes can be listed.
Describe the pre-processing scripts that must be called in the ETL process before the actual extraction and transformation logic is implemented. Also mention the return
parameters, if any, and usage of the same in the ETL process. Include a meaningful comment.
Post-Processing Script
Exactly similar to the pre-processing script section, only the impact of this section is directly on the output parameters created at the beginning of the development of the
ETL process. Impact of the return parameters, if any, should be documented. Include a meaningful comment.
Error Logs
List the steps for the Error Log generation. Include the expected format of the error logs for this ETL process, i.e., field names and expected contents for each field.
Optionally, also enclose a table with the expected error codes/messages and any suggested cause(s)/action(s) for each error.
List any special considerations. Indicate whether this mapping needs any special design considerations. For example, performance constraints, parallelism to be enabled,
any data quality issues or functionality to be performed, etc.
Data Requirements
List the objects involved in this mapping and the object type. Determine the role each plays in this mapping. Specify where the object is located and how to access it.
List all the database objects (tables, views, sequences, etc.) and/or files that the developer will be working with for the successful completion of the deliverable. The
purpose of this section is to identify all the objects that are part of this mapping.
Provide the type of objects and their locations.
In case the source objects are present in a different database environment, then the access details like gateway (non-Oracle databases), database link name,
schema name etc., can be optionally provided to aid the developer.
Describe the complete transformation details. The recommendation is that the ETL designer should use pseudo code to do this and each distinct ETL function (for
example, join, filter, etc.) should be clearly identified.
Bad records processing steps - Use this section to describe the criteria for identifying the bad records as well as for handling and reporting these records.
Change Data Capture logic - Describe the method for identifying the change records (i.e. new ones, or existing ones that have changed, since the previous load)
that need to be loaded into the entity under consideration. Examples of potential Change Data Capture mechanisms are: Timestamps, Partitioning, Triggers.
Target Insert / Update / Delete Criteria - Specify the criteria that would be used for identifying whether a new record should be inserted, updated or deleted.
Where applicable, it should also be clear if all existing records need to be deleted from a target object(s) before any new records need to be processed.
Unit Test Cases
Describe the unit test cases details. Write Mapping Unit Test scripts. List out any unit test cases that must be successfully completed by this mapping. This should be
high-level (for example, Verify if number of records at source and target tally or Verify if all records in fact table have values for dimension foreign keys).
Back to Top
Back to Top
Developer Lead the design process of the data conversion components. Design conversion components.
allocated to this individual, leaving 60% allocated to the developer. The team leader would then
lead the design process of the data conversion components and design the most complex
components.
80
System Architect (Information Architect) Review the Designed Data Conversion Components. Preferably, this should be done by a system
20
Client Data Administrator *
Client System Architect *
Back to Top
PREREQUISITES
CV.040.1
Prerequisite Usage
(CV.010)
Strategy (CV.020)
These work product contains the plan for executing the data conversion from the old system to the new
system as well as the high-level requirements and constraints of the interfaces.
Logical Database Design (DS.150.1) The initial Logical Database Design contains definitions of all database objects and the constraints to which
they are subject.
CV.040.2
Prerequisite Usage
(CV.010)
Strategy (CV.020)
These work product contains the plan for executing the data conversion from the old system to the new
system as well as the high-level requirements and constraints of the interfaces.
Logical Database Design (DS.150.2) The initial Logical Database Design contains definitions of all database objects and the constraints to which
they are subject.
Data Mapping (CV.027) The Data Mapping defines the key assumptions, mapping between source and target, and mapping rules and
logic that is needed to create the conversions and interfaces necessary to support the solution.
Conversion Component Designs (Initial Load)
(CV.040.1)
Update the initial Conversion Component Designs (Initial Load), as appropriate.
Final Platform and Network Architecture (TA.150) All components of the solution are identified in the Final Platform and Network Architecture
Back to Top
TEMPLATES AND TOOLS
CV-
040_CONVERSION_COMPONENT_DESIGNS.DOC
MS WORD
Back to Top
The Conversion Component Designs (Initial Load) is used in the following ways:
to document and communicate the component design specifications for the conversion of an individual entity object that is going to be converted
to understand the approach, they system constraints and the high-level interface requirements
Distribute the Conversion Component Designs (Initial Load) as follows:
to the developers who are responsible for writing the various pieces of conversion code
to the Data Acquisition and Conversion team members
to the client member who is responsible for signing off on the accurateness of this component design
to the overall project leader and the team leader for Data Acquisition and Conversion.
Back to Top
QUALITY CRITERIA
Is the data mapping complete?
Are there any setup decisions that have not been finalized which directly impact the data mapping and therefore the accuracy of the conversion code?
Are all of the rules which impact conversion documented so that they can be written in the conversion code?
Has the component logic required to write the conversion code been documented?
Have you identified required columns and assigned default values for those fields which will not be populated by data elements from the source system(s)?
Have all required data elements from the legacy system been mapped to target system elements?
Are the process flows and interfaces identified in the the Data Acquisition, Conversion and Data Quality Strategy (CV.020) listed in order and completely defined?
Are all sources and targets in the Data Mapping (CV.027) covered, with ETL mappings for each load? Does this includes any additions that have been made to the
Data Mapping?
Have all the constraints identified in the Data Acquisition and Conversion Requirements (CV.010) and the Data Acquisition, Conversion and Data Quality Strategy
(CV.020) been listed and addressed?
Back to Top
CV.050 - PREPARE CONVERSION TEST PLANS (INITIAL LOAD)
In this task, you outline the testing plans for the unit, business object, and validation testing for conversion, and/or initial load of legacy data to the new system.
The unit tests confirm that each component successfully completes the task it is designed to perform. For example, a unit test should verify that the download program
has extracted the expected number of records from the legacy system. The business object test verifies that the quality of the data converted to the target system is
accurate and functions properly in the individual system to which it has been converted. Validation testing verifies that the converted legacy data performs accurately
within the entire system.
ACTIVITY
CV.050.1
CV.050.2
Back to Top
WORK PRODUCT
Conversion Test Plans (Initial Load) - The Conversion Test Plans (Initial Load) provide plans for conversion unit, business object, and validation tests, as well as
conversion component testing and conversion data integrity testing. Subsequent Data Acquisition and Conversion tasks perform each of these three levels of testing and
then record the results as described in the work product guidelines. Prepare one work product for each business object you are converting. It should address the
following:
unit test plans
business object test plans
validation test plans
Back to Top
TASK STEPS
1 Describe
the
purpose
and
audience
for the
Conversion
Test Plans.
Introduction This component describes the purpose, distribution, and quality criteria for the document.
2 Prepare
test plans.
Conversion
Component
Test Plan
Conversion
Data
Integrity
Test Plan
The Conversion Component Test Plan documents the conversion components you are going to test and provides a place for the tester to
(later) record the results of the test. Conversion component testing verifies the accuracy of the smallest objects used in the data
conversion effort; in other words, SQL*Loader and PL/SQL scripts. This approach attempts to verify the logic and accuracy of each
object involved in processing conversion data. This is accomplished by reviewing, for example, record counts on completion of each
object processed.
A Conversion Component Test Plan should be prepared for each business domain of data you are converting. For each domain that is
being converted, there may be several conversion components that need to be tested. Each component may have several test types or
actions to betaken and each action may have to be performed more than once depending on the accuracy of the component being
tested.
The Conversion Data Integrity Test Plan documents the individual data elements you are planning to test during data integrity testing. In
many cases the client sets the level of testing expectations. For data integrity testing, usually the users are required to compare how a
data element appeared in the legacy system to how it appears and functions in the new application. This level of testing does not test
the flow of the data within in the entire system, but only how the data appears and/or functions in an individual application. By having the
users do the majority of the testing they become increasingly familiar with the navigation path of the new application. If users are going
to be the primary testers, they need to have been trained. It works best to have a member of the conversion team work with the users to
develop these test procedures.
Just as with the Conversion Component Test Plan component, a Conversion Data Integrity Test Plan should be prepared for each entity
object being converted. Prepare a table for or each entity object being converted. Copy the columns from your mapping spreadsheet
table you created in the Conversion Mapping component to this table. The fields in this table should be the same as those from your
data mapping spreadsheets. Use this data integrity table to select the data elements you want to test. After you have decided that you
want to test a certain field in this table, document how you plan to test this on both the legacy side as well as the Oracle side. The
Legacy Object Name field should contain the report to be run in the legacy system to perform the test.
3 Define the
conversion
unit test
plans and
procedures.
Conversion
Unit Test
This component documents which conversion programs you are going to test and provides a place for the tester to record the results of
the test. Conversion module testing verifies the accuracy of the smallest objects used in the data conversion effort; for example, SQL-
Loader and PL/SQL scripts. This approach attempts to verify the logic and accuracy of each object involved in processing conversion
data. This is accomplished by reviewing, for example, record counts on completion of each object processed.
4 Define the
conversion
business
object test
plans and
procedures.
Conversion
Business
Object Test
This component documents the individual data elements you are planning to test during business object testing. In many cases the user
sets the level of testing expectations. For business object testing, the users are required to compare how a data element appeared in
the legacy system to how it appears and functions in the new system. This level of testing does not test the flow of the data within the
entire system, but only how the data appears or functions in an individual application. By having the users complete the majority of the
testing, they become increasingly familiar with navigating the new application. If users are going to be the primary testers, they need to
be trained to perform the testing tasks. It works best to have a member of the conversion team work with the users designated as testers
to develop these test procedures.
When deciding which data elements need validation, consider how a particular data element affects the target systems functionality.
Think about the downstream effect on reports and concurrent processes of an incorrect data element on the target applications
performance.
Examples of business object testing:
In Oracle Receivables, verify the customer records so that if invoices are converted, the name on the invoice is the same as the
name in the Oracle customer tables. If the addresses are not the same, when a user queries an invoice, an Oracle error will occur
because the form verifies that the name on the invoice is the same as the name in the Oracle database.
Verify all of the list of values (LOV) fields in the Oracle forms to make sure that the legacy data elements being converted are valid
Oracle lookups.
In Oracle Accounts Payable, verify the vendor records to confirm that the vendor information that appears on the AP invoice and
purchase order is the same as the vendor data stored in the Oracle AP tables.
5 Define the
conversion
validation
test plans
and
procedures.
Conversion
Validation
Test
This component documents the procedures for performing the conversion validation test. This is the most comprehensive level of
conversion testing. These procedures should lay out a plan for the users to follow when they are testing the overall functionality of how
the converted legacy data performs in the entire system.
An example of one validation test is to test how an open converted order can be closed, shipped, deplete inventory, and be posted to
General Ledger. In most validation tests, testers must compare pre-conversion and post-conversion balances. This requires planning to
gather the pre-conversion totals. In addition, this may require that the legacy and new applications run in parallel for a predetermined
length of time.
6 Secure
acceptance
for the
Conversion
Test Plans.

Back to Top
APPROACH
Both conversion component testing and data integrity testing procedures are also included in this work product.
Prepare the Conversion Test Plans (Initial Load) for each business object you are converting. For each business object there are several conversion programs that need
to be tested.
If you are using an automated conversion tool to facilitate the conversion, testing is still very important. For unit testing, you may be testing the conversion template and
load functionality instead of the conversion programs. Adjust your test procedures accordingly to take into account any automated tools you are using.
For both conversion business object and validation testing, you need to identify record counts and plan for the pre-conversion test totals that will be compared to the target
system totals. A list of test totals that can be compared between the source and target systems follows:
Balances month-end, year-end balances, and so on
Hash Counts total number of items, customers, vendors, and so on
Valuations total value of open orders, receivables, and so on
Distributions total items per subinventory, locator, and so on
Execute the conversion programs several times to practice the data conversion. This allows the developers responsible for performing the data conversion during
production cut over to become familiar with using the conversion routines. By practicing the data conversion several times, you can predict the conversion program
performance before the final production load.
Relationship with Other Testing Processes
Converted data is also a critical part of integration, business system, and performance testing. Refer to Testing (TE) and Performance Management (PT) for more.
Much time is required to load 50,000 items or to perform a query of these converted items. Therefore, once you have completed the conversion testing tasks, use the
converted data, and the conversion programs, in Testing (TE) and Performance Management (PT).
Use the converted data that has been unit tested, business object tested, and validation tested in the following Testing (TE) tasks:
Perform Systems Integration Test (TE.100)
Support Acceptance Test (TE.120)
Determine with the help of the performance testing team, if conversion programs are within the scope of the Performance Manaement process for your project. If included,
use the conversion programs in the following Performance Management (PT) task:
Execute Performance Test (PT.100)
Back to Top
System Architect 80
Business Analyst 20
Back to Top
PREREQUISITES
CV.050.1
Prerequisite Usage
Conversion Component Designs (Initial
Load) (CV.040.1)
Design the conversion components or automated conversion templates so that you can identify the conversion
programs that should be unit tested.
CV.050.2
Prerequisite Usage
Manual Conversion Procedures (Initial Load)
(CV.040.2)

Load) (CV.040.2)
Design the conversion components or automated conversion templates so that you can identify the conversion
programs that should be unit tested.
Conversion Test Plans (Initial Load)
(CV.050.2)
Update the initial Conversion Test Plans (Initial Load), as appropriate.
Back to Top
TEMPLATES AND TOOLS
CV-050_CONVERSION_TEST_PLANS.DOC MS WORD
You may also want to use Systems Integration Test Sequences (TE.090) and the Performance Test Scripts and Programs (PT.070) to document the impact of the
converted data on Testing (TE) and Performance Management (PT).
Back to Top
The Conversion Test Plans (Initial Load) are used to create test plans for conversion unit, business object, and validation testing, which can be followed by the testers
performing the conversion tests.
Back to Top
QUALITY CRITERIA
Back to Top
CV.055 - IMPLEMENT CONVERSION COMPONENTS (INITIAL
LOAD)
In this task, you create the conversion components that perform all of the functions required to complete the initial load of legacy data to the new system, including the
following:
Download the data from the legacy system and create files (ASCII, XML) which can be uploaded to the target system tables.
Create temporary tables that can store the legacy data before the data is moved to the production tables of the target system.
Upload the legacy data to the temporary tables.
Perform data translation, transformation, or manipulation before moving the data to the production tables.
Loading, that is, move and validate the data to the target system production tables.
You also build the components required for the data extraction, transport, transformation and load of the initial load and of the database objects, as identified in the
Conversion Component Designs (CV.040).
ACTIVITY
CV.055.1
CV.055.2
Back to Top
WORK PRODUCT
Conversion Components (Initial Load) - The Conversion Components (Initial Load) is the source components for data acquisition and conversion. These components
differ from the application source components in their lifespan. Conversion Components (Initial Load) are usually used only during the transition to populate the new
system with data.
The Conversion Components includes the Conversion Components (Download, Temporary Table Creation, Upload, Translation and Interface), as well as the ETL
Components. The (ETL) Components define the key assumptions, mapping, rules, and logic that is needed to create the data acquisition components. It provides an
overview of the components that are going to be developed and assembled. To the future users it shows every piece of functionality that is needed to deliver the desired
solution and the way these pieces work together. It takes the language of the developers developed during requirements analysis and takes them one step closer to
technology. To the developers it shows the content, structure and complexity of the solution and guides them in implementing the entire system. It also contains detailed
design information about each of the interface modules to be built and the design of the overall integration approach.
Back to Top
TASK STEPS
1 Provide an introduction
for the document.
Introduction The Introduction describes the purpose and practical application of the work product.
2 Build and execute
generic components.
Download Components
Temporary Table Creation
Components
Upload Components
Translation Components
Interface Components
The Download Components provides a table that records the sequence in which the download
components should be run, the component name, the component purpose, the component file
location, the developer, and the resulting flat file. Typically, the IS support staff is responsible for
writing and maintaining the download components. As with the Designed Data Conversion
Components(CV.040), it is important that you provide the IS support staff with a flat file schema which
tells them how many flat files to produce for a given entity object, its structure, the order of the fields,
the delimiter to be used, etc. Depending on the tool you are using for the conversion you may want to
combine data that is going to populate multiple target system tables into one flat file extract. This
decision is largely dependent on the relationship and complexity of the target system tables which are
being populated.
#TOP #TOP
The Temporary Table Creation Components provides a table that records the sequence in which the
temporary table creation components should be run, the component name, the component purpose,
the component file location, the developer, and any additional comments. Typically, SQL*Plus is used
to create the temporary tables in Oracle. In most cases you can build a temporary table for each target
system production table you are eventually going to load. The temporary table can be a direct copy of
the production table or can have only the columns within the production table that you are going to
load. In most cases you do not want the temporary contain the constraints that the production tables
have. This is because you are going to be performing the data translation in the temporary tables.
Therefore, if you copy the production table to use as your temporary table you probably want to
remove the constraints. An example is if the extract file contains a Y but the database is expecting a
numeric value, then you may load the Y into the temporary table and translate the Y to a numeric
value of 1 before passing the value to the production table.
The Upload Components provides a table that records the sequence in which the upload components
should be run, the component name, the component purpose, the component file location, the
developer, and any additional comments. Typically, a loader component such as SQL*Loader is used
to load the legacy system data flat file into the temporary tables you have created. However,
automated conversion tools usually provide this functionality. The automated tools allow you to map
the legacy data to the target system table and columns, perform the required translations and
validations, and then load the data into the target system.
It is important that the chosen upload components could log errors and warning for analysis. Some
sophisticated tools allow interrupting the process and restarting it without interfering in the already
imported data.
The Translation Components provides a table that records the sequence in which the translation
location, the developer, and any additional comments. The translation components can be written
using a variety of different programming languages depending on the complexity of the translations
and the skills of the developer. The level of complexity of the translation depends on the legacy
system being converted. Is the legacy system normalized? Is new functionality being built into the
target system which was not used in the legacy system? These types of questions directly impact the
level of complexity of the translation components. Some or most of the data translation can be built on
the legacy side depending on available IS support resources. The data mapping tables should provide
the developer with all of the logic for the data translations. Some examples of translations follow:
date formatting
truncation of values
concatenation of values
if/then logic
As mentioned previously, automated conversion tools are an option for building and executing this
code.
The Interface Components provides a table that records the sequence in which the interface
location, the developer, and any additional comments. The complexity of the loading components is
primarily determined by the level of validation required for the data being converted. In order to mke
sure that the data is useable in the new system, your interface components need to perform the same
level of validation as the application. If for example, a page validates that a sales person assigned to a
customer must already exists in the system, your interface component needs to perform the same
validation. A lookup would have to be performed against the table which stores the sales person
information. The page validation also determines the order in which entity objects need to be
converted. In the example above, the entity object containing the sales person would need to be
converted before the customer records could be converted. You can write your own interface
components, but there are several automated tools which build and execute the code to perform the
needed validation and loading of the production tables.
Back to Top
APPROACH
Code the Conversion Components (Initial Load) as per the Conversion Component Designs (CV.040). Conversion Components refers to components for conversion,
extraction transformation and transport. Make sure after the components have been prepared that the code has been reviewed by a peer and checked for functional
correctness and standards conformity.
Back to Top
Back to Top
Developer Lead the build and test of conversion modules. Build and test the Implemented Conversion
Components.
allocated to this individual, leaving 60% allocated to the developer. The team leader would then lead
the build and test of conversion components and build the most complex components.
80
System Architect (Information Architect) Review the Implemented Conversion Components code. Preferably, this should be done by a system
20
IS Operations Staff *
Back to Top
PREREQUISITES
CV.055.1
Prerequisite Usage
Implemented Database (IM.040.1) The Conversion Components (Initial Load) must convert the data following the actual implemented database.
(CV.010)
Strategy (CV.020)
These work product contains the plan for executing the data conversion from the old system to the new system
as well as the high-level requirements and constraints of the interfaces.
(CV.040.1)
The Conversion Components (Initial Load) are developed according to the Conversion Component Designs
(CV.040.1).
Technical Coding standards document provided
by the client
Business Transformation Rules provided by the
client

CV.055.2
Prerequisite Usage
Implemented Database (IM.040.2) The Conversion Components (Initial Load) must convert the data following the actual implemented database.
Data Mapping (CV.027) The Data Mapping defines the key assumptions, mapping between source and target, and mapping rules and
logic that is needed to create the conversions and interfaces necessary to support the solution.
(CV.040.2)
The Conversion Components (Initial Load) are developed according to the Conversion Component Designs
(CV.040.1).
Conversion Components (Initial Load) (CV.055.1) Update the initial Conversion Components (Initial Load), as appropriate.
Technical Coding standards document provided
by the client
Business Transformation Rules provided by the

client
Back to Top
TEMPLATES AND TOOLS
CV-055_CONVERSION_COMPONENTS.DOC MS WORD
Back to Top
The Conversion Components (Initial Load) is used in the following ways:
to provide a format for recording important information about the components which are being written to perform the conversion of a particular entity object from the
legacy system to the target system
to provide a checklist for the ETL developers
to provide a checklist for the ETL testers for the unit tests
Distribute the Conversion Components (Initial Load) as follows:
to the developers who are building the conversion scripts to use as a worksheet to document their work
to the developers who are building the ETL components to use as a checklist
to the project manager in order to understand how the Data Acquisition and Conversion team plans to implement the work and in what ways this may impact the
overall project
Back to Top
QUALITY CRITERIA
Download Components:
Have you specified temporary files structure?
If there are blanks in the extract, do these need to be represented as blanks or nulls (this depends on the conversion tool you choose to use)?
Have you confirmed with the client in which order you need the data elements to appear in the files?
Have you told the client if you want one or multiple extracts for a given entity object?
Temporary Table Creation Components:
Have you created a table or tables to upload your data into to perform any required translations before moving the data to the production tables?
Upload Components:
Have you specified into which table and columns to load the legacy data?
Have you tested the different loader options to achieve the best possible performance?
Translation Components:
Have you validated that you have written code to perform all the translations, transformations, or data manipulations which have been specified by the data
mapping?
Have you verified that the columns, tables, or sequences specified in the code are correct?
Loading Components:
Have you verified the level of validation required by the application which will be using the converted data?
If the data is going to be used in many places of the target application, have you checked the level of validation for all of the user interface?
Have you checked the order that the target system tables need to be loaded?
ETL Components:
Do the ETL steps described in this work product adhere to the approach described in the Data Acquisition, Conversion and Data Quality Strategy (CV.020)?
Are the ETL components described as identified in the Conversion Component Designs (CV.040)?
Are the data mapping and transformation rules consistent with the source to target mapping information in the Data Mapping (CV.027)?
Verify if all the constraints identified in the Data Acquisition and Conversion Requirements (CV.010) have been listed and addressed?
Is the required sequence for development of the ETL components listed consistent with the above documents, more importantly, the final MoSCoW List (RD.045)
and clear?
Is the ETL logic for the mappings validated with respective process owners.
Has the Data Quality approach that has been agreed to (e.g., in the CV.010, Data Acquisition and Requirements) has been referred to, or accounted for? If not,
state that data quality or cleansing requirements will be out of scope for all Data Acquisition components and will be raised as issues during development.
Back to Top
CV.060 - PERFORM CONVERSION COMPONENT UNIT TEST
(INITIAL LOAD)
In this task, you unit test the conversion components required to complete the initial load of legacy data to the new system to make sure that all components work without
errors and according to the conversion testing specifications predefined in the Conversion Component Designs (CV.040) and in accordance with the Conversion Unit
Test component of the Conversion Test Plans (Initial Load) (CV.050).
ACTIVITY
CV.060.1
CV.060.2
Back to Top
WORK PRODUCT
Unit-Tested Conversion Components (Initial Load) - These components include conversion program source code that has been unit-tested to verify that the
processing logic of each program module functions without errors.
Use the Conversion Unit Test Plan and Results component of the Conversion Test Plans (CV.050) to record the following information:
whether or not the test was completed
the date that each conversion component was tested
the developer who tested each component
the sequence in which the component were tested
As with the test procedures, one checklist should be prepared for each entity being converted.
Back to Top
TASK STEPS
1 Review the
Conversion Unit
Test Plan and
Results
component of
Conversion Test
Plans (CV.050).
Conversion
Unit Test
Plan and
Results
Component
The Conversion Test Plans contains the Conversion Unit Test Plan and Results component that not only defines the plan for the
test but also provides a Results section for recording the actual test results.
2 Conduct the
conversion unit
test for each
conversion
component, per
the
Conversion Test
Plans
(CV.050)
Conversion
Unit Test
Plan and
Results
Component
Conduct the conversion unit test per the The Conversion Unit Test Plan and Results component of the Conversion Test Plans
(CV.050).
3 Record
conversion unit
test
results in the
Conversion
Unit Test
Plan and
Results
Use the Conversion Unit Test Plan and Results component of the Conversion Test Plans (CV.050) to record the results. This
component provides a table to document that each conversion component was actually unit- tested. Typically, developers are the
responsible for unit testing their own code. The prerequisite for completing the unit tests are having the Conversion Components
written. Another prerequisite is to have an extract file from the legacy system ready to download so that the entire conversion
tables provided in
Conversion Test
Plans (CV.050).
component process can be tested. Insert a row in the table in this section for each conversion component (program) which has
been written to convert each object being converted.
Back to Top
APPROACH
It is assumed that the Conversion Components (Initial Load) (CV.055) are back-end processes, and therefore, have fixed requirements as defined in the Conversion
Component Designs (Initial Load) (CV.040). Test cases should be created for each conversion component developed and should test each requirement defined in the
component design documents. Because the Conversion Components (Initial Load) have fixed requirements, it is preferable if the developer who wrote the component
runs the test cases.
Perform the tests as specified in the Conversion Unit Test Plan and Results component of the Conversion Test Plans (CV.050). Complete this component by recording
your results.
Back to Top
Back to Top
Developer Develop test specifications and perform test. 100
Back to Top
PREREQUISITES
CV.060.1
Prerequisite Usage
Conversion Environment (CV.030.1) To test the interface and validation conversion programs, the legacy data needs to be loaded into a properly configured
configured Conversion Environment to meet your business requirements.
(CV.050.1)
Use the Conversion Test Plans (Initial Load) to perform the conversion component test and record the results.
Conversion Components (Initial Load)
(CV.055.1)
The Conversion Components (Initial Load) are the items under test.
CV.060.2
Prerequisite Usage
Conversion Environment (CV.030.2) To test the interface and validation conversion programs, the legacy data needs to be loaded into a properly configured
configured Conversion Environment to meet your business requirements.
(CV.050.2)
Use the Conversion Test Plans (Initial Load) to perform the conversion component test and record the results.
Conversion Components (Initial Load)
(CV.055.2)
The Conversion Components (Initial Load) are the items under test.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Use the Unit-Tested Conversion Components to show that the processing logic of each conversion program functions without errors.
Use the Conversion Test Plans (CV.050) to record the test results.
Back to Top
QUALITY CRITERIA
Back to Top
CV.062 - PERFORM CONVERSION COMPONENT BUSINESS
OBJECT TEST (INITIAL LOAD)
In this task, you test the complete conversion of each business object by executing all conversion components for the business object in the appropriate sequence and
verify that the resulting data is correct.
ACTIVITY
CV.062.1
CV.062.2
Back to Top
WORK PRODUCT
Business Object-Tested Conversion Components (Initial Load) - The Business Object-Tested Conversion Components include conversion components that have
been tested to verify that, when run end to end in the proper sequence, they result in converted business objects that satisfy the pre-determined business object test
specifications.
Back to Top
TASK STEPS
1 Review the Conversion Business Object Test
component of Conversion Test Plans (CV.050).
Conversion Business
Object Test Component,
Details and Results
The Conversion Test Plans contains the Conversion Business Object Test
component that not only defines the Details for the test but also provides a Results
section for recording the actual test results.
2 Conduct the business object test for each
business object being converted, per the
Conversion Test Plans (CV.050).
Conversion Business
Details and Results
Conduct the conversion unit test per the The Conversion Business Object Test,
Details and Results component of the Conversion Test Plans (CV.050).
3 Record conversion business object test results
in the tables provided in Conversion Test Plans
(CV.050).
Conversion Business
Details and Results
Use the Conversion Business Object Test, Results component of the Conversion
Test Plans (CV.050) to record the results.
Back to Top
APPROACH
Test the data elements previously selected for business object testing in the Conversion Test Plans (CV.050) and compare them to the original data state in the legacy
system.
Either members of the Conversion team or users may be responsible for performing the business object tests. A prerequisite for performing the business object tests is
having the Conversion components written and having the legacy data (or at least a representative sample of the data) loaded into the Oracle Applications tables. It is
also necessary to have trained users to navigate in the new application and run the necessary reports for comparison of converted data to legacy system data.
Depending on the level of testing, it may be necessary to designate a person whose primary responsibility is to manage the business object testing effort. It is critical that
the failures discovered during testing are properly managed and resolved in a timely manner. A business object test case is not complete until all test failures have been
resolved. A test suite is defined as all business object tests performed for the complete testing of a given business object (for example, customers, invoices, and so on).
Back to Top
Tester Perform test. 90
System Architect 10
Back to Top
PREREQUISITES
CV.062.1
Prerequisite Usage
Conversion Environment (Initial Load) (CV.030.1) In order for the testers to verify that the converted data performs correctly in the new application, a properly
configured Conversion Environment is required to meet the defined business requirements.
Conversion Test Plans (Initial Load) (CV.050.1) Use the Conversion Test Plans (Initial Load) to perform the conversion component test and record the actual test
results.
Unit-Tested Conversion Components (Initial
Load) (CV.060.1)
The Unit-Tested Conversion Components (Initial Load) are the items under test.
CV.062.2
Prerequisite Usage
Conversion Environment (Initial Load) (CV.030.2) In order for the testers to verify that the converted data performs correctly in the new application, a properly
configured Conversion Environment is required to meet the defined business requirements.
Conversion Test Plans (Initial Load) (CV.050.2) Use the Conversion Test Plans (Initial Load) to perform the conversion component test and record the actual test
results.
Unit-Tested Conversion Components (Initial
Load) (CV.060.2)
The Unit-Tested Conversion Components (Initial Load) are the items under test.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Use the Business Object-Tested Conversion Components to show that, when the conversion programs for a given business object are run in the proper sequence, the
resulting converted data meets the requirements for that business object in the target Oracle Application.
Back to Top
QUALITY CRITERIA
Back to Top
CV.063 - PERFORM CONVERSION COMPONENT VALIDATION
TEST (INITIAL LOAD)
In this task, you validate that the target applications function correctly with the converted business objects.
ACTIVITY
CV.063.1
CV.063.2
Back to Top
WORK PRODUCT
Validation-Tested Conversion Components (Initial Load) - The Validation-Tested Conversion Components include conversion programs that have been tested to
verify that the resulting converted legacy data performs correctly in the new system.
Back to Top
TASK STEPS
1 Review the Conversion Validation Test
component of Conversion Test Plans (CV.050).
Conversion
Validation Test
Component
The Conversion Test Plans contains the Conversion Validation Test component that not
only defines the details for the test but also provides a Results section for recording the
actual test results.
2 Conduct the validation test for each business
object being converted, per the Conversion Test
Plans (CV.050).
Conversion
Validation Test
Component
Conduct the conversion validation test per the The Conversion Validation Test
component of the Conversion Test Plans (CV.050).
3 Record conversion validation test results in the
tables provided in Conversion Test Plans
(CV.050).
Conversion
Validation Test
Component, Results
Use the Conversion Validation Test, Results component of the Conversion Test Plans
(CV.050) to record the results.
Back to Top
APPROACH
Test and compare data elements selected for validation testing in the Conversion Test Plans (CV.050) to the original data state in the legacy system.
Either members of the Conversion team or users may be responsible for performing the conversion validation tests. The prerequisites for performing the conversion
validation tests are having the Conversion components written and having the legacy data (or at least a representative sample of the data) loaded into the Oracle
Applications tables. Trained users are required to navigate in the new application and run the necessary reports for comparison of converted data to legacy data.
Decide how thorough your validation test will be. Depending on this decision, it may be necessary to designate a person whose primary responsibility is to manage the
validation testing effort. It is critical that any failures be properly managed and resolved in a timely manner. A validation test case is not complete until all test failures have
been resolved.
The validation test should mimic the entire flow of the converted data through the suite of Oracle Applications. For example, if you convert an open receivables invoice,
can you post cash to that invoice? Can you generate aged trial balance reports? Can you post to the general ledger? If you are interfacing Oracle Applications to legacy
or third-party applications, test the flow of the converted data through these interface points as well.
Back to Top
#TOP #TOP
Tester Perform test. 60
Business Analyst 30
System Architect 10
Back to Top
PREREQUISITES
CV.063.1
Prerequisite Usage
Conversion Environment (Initial Load) (CV.030.1) A properly configured Conversion Environment is required for testers to verify that the converted data
performs correctly in the new application.
Conversion Test Plans (Initial Load) (CV.050.1) Use the Conversion Test Plans (Initial Load) to perform the conversion component test and record the
Business Object-Tested Conversion Components (Initial
Load) (CV.062.1)
The Business Object-Tested Conversion Components (Initial Load) are the items under test.
CV.063.2
Prerequisite Usage
Conversion Environment (Initial Load) (CV.030.2) A properly configured Conversion Environment is required for testers to verify that the converted data
performs correctly in the new application.
Conversion Test Plans (Initial Load) (CV.050.2) Use the Conversion Test Plans (Initial Load) to perform the conversion component test and record the
Business Object -Tested Conversion Components (Initial
Load) (CV.062.2)
The Business Object-Tested Conversion Components (Initial Load) are the items under test.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Use the Validation-Tested Conversion Components to show that the resulting converted data performs correctly in the new system.
Back to Top
QUALITY CRITERIA
Back to Top
CV.064 - INSTALL CONVERSION COMPONENTS (INITIAL LOAD)
In this task, you perform and document the installation of the conversion components in the production environment.
This task presumes that the conversion components have been tested. If you are using an automated conversion tool, this task requires that you install the software,
tested conversion templates, and conversion maps needed for the task Convert and Verify Data (CV.065).
ACTIVITY
CV.064.1
CV.064.2
Back to Top
WORK PRODUCT
Installed Conversion Components (Initial Load) - The Installed Conversion Components represent the installation of the conversion components in the Production
Environment. Use the Installed Conversion Components document to support this work product and assist in the proper execution of this task.
Back to Top
TASK STEPS
1 Review the Production Environment (TS.050) to
understand the configuration of the Production
Environment.
None
2 Describe the purpose of the Installed Conversion
Components and the supporting document.
Introduction The Introduction describes the purpose of the Installed Conversion Components and
the supporting document.
3 Describe the Production Environment. Production
Environment
This component describes the hardware platform, database configuration, operating
system, and installed Oracle Applications for the Production Environment.
4 Describe the directory structure of the Production
Environment.
Directory
Structure
This component describes the directory structure for the installed Oracle Applications
and custom extensions.
5 Install the conversion components and automated
conversion tool software (if used).
Installation
Procedures
Checklist
This component documents the procedures for performing the conversion software
and program installation.
6 List the location of each conversion component in the
Production Environment.
Conversion
Components
This component lists the location of the conversion programs within the production
environment directory structure.
7 List the location of any conversion tools in the Production
Environment.
Automated
Conversion
Software
This component lists the location of any conversion tools within the Production
Environment directory structure.
Back to Top
APPROACH
Verify the installation of the necessary conversion software in the production environment prior to performing the conversion of production data. This is particularly
important if you are performing the final conversion without the aid of the team that developed and tested the conversion code.
Back to Top
#TOP #TOP
System Architect 10
Back to Top
PREREQUISITES
Prerequisite Usage
Load) (CV.063.2)
The Validation-Tested Conversion Components (Initial Load) are the tested conversion components or tool
templates and maps that are to be installed in the Production Environment.
Production Environment (TS.050) The Production Environment is a fully configured production environment in which to install the conversion
software.
Back to Top
TEMPLATES AND TOOLS
CV-064_INSTALLED_CONVERSION_COMPONENTS.DOC MS WORD
Back to Top
The Installed Conversion Components document is used in the following ways:
to document the Production Environment, its directory structure and installation procedures
to document the location of the conversion components and automated conversion tools in the Production Environment
Back to Top
QUALITY CRITERIA
Back to Top
CV.065 - CONVERT AND VERIFY DATA (INITIAL LOAD)
Initially, you convert sufficient data in each information category for test purposes, at the same time making visible any inconsistencies or inadequacy in the legacy data.
Ultimately, you convert and migrate the production data from the old system to the new Production Environment or populate the production databases with the initial and
any historical data that is required. Completion of this task provides data that is ready for production use.
Run the conversion routines and verify the production data.
ACTIVITY
CV.065.1
CV.065.2
Back to Top
WORK PRODUCT
Converted and Verified Data (Initial Load) - Initially, Converted and Verified Data (Initial Load) is a database containing sufficient data in each information category for
test purposes. Ultimately, the Converted and Verified Data (Initial Load) is clean production data.
For tracking purposes, prepare an Initial Production Database Load Log for every production database instance, and for every load schedule for the given instance, if
there are more load schedules to populate the given instance.
Back to Top
TASK STEPS
1 Plan and control the conversion test run. Conversion
Timetable
Establish your conversion activities plan.
2 Select representative subsection of
production data for test conversion.
Data
Subsection
Determine a minimum but representative subset of source data to be converted and tested.
3 If using download conversion
components, define the order in which
these components will be executed.
Download
Components
The Download Components provides a table that records the sequence in which the download
components should be run, the component name, the component purpose, the component file location,
the developer, date executed and the resulting flat file created by executing these components.
4 If creating temporary tables, make a
single master script to create them.
Temporary
Table Creation
Components
(script)
The Temporary Table Creation Components provides a table that records the sequence in which the
temporary table creation components should be run, the component name, the component purpose, the
component file location, the developer, execution dates, results and any additional comments.
5 If using upload components, define the
order in which these components will be
executed.
Upload
Components
List
The Upload Components provides a table that records the sequence in which the upload components
should be run, the component name, the component purpose, the component file location, the
developer, execution dates, results and any additional comments.
6 If using translation components, define
the order in which these components will
be executed.
Translation
Components
List
The Translation Components provides a table that records the sequence in which the translation
the developer, and any additional comments.
7 If using any loading components for
conversion purposes, define the order in
which these components will be
executed.
Interface
Components
List
The Interface Components provides a table that records the sequence in which the interface
the developer, execution date, results and any additional comments.
8 Run conversion components for a
subsection of production data.
Conversion
Test Results
The Conversion Test Results is a representative subset of converted production data. This data can be
used for test purposes.
9 Check for any inconsistencies or
inadequacy in the legacy data.
List of
Problems in
the Converted
Data
The List of Problems in the Conversion Data is a list of inconsistencies or inadequacy in the legacy data.
10 Run the conversion routines after fixing
problems.
Bad Record
File
The Bad Record File consists of a file containing the rejected records. It should be made available to the
team and to the client data administrator for analysis.
11 Verify data. Converted and
Verified Data
This Converted and Verified Data is the actual production data in the production database.
12 Obtain the list of initial load jobs to be
executed, along with their parameters.
Initial Load of
<Instance>,
Schedule
<No>
This component is prepared for every production database instance, and for every load schedule for the
given instance, if there are more load schedules to populate the given instance. It consists of two
sections:
Instance Information - contains the details of the database instances
Load Log - consists of the list of jobs planned and executed, and their details
Back to Top
APPROACH
During the Construction phase, this task should be iterated with the design and implementation tasks until the conversion process has been proven. Problems with
production data is usually invisible until the conversion processes have been run. This task is a dry run of the production conversion and should be as close to the actual
production as feasible. A representative subsection of production data should be selected and all conversion components should be run against it. This task gives the
project manager a good indication of the condition of the legacy data, and should allow the estimates given for conversion to be confirmed or adjusted as appropriate.
The client data administrator should be involved in verifying the data and initiating corrective measures. In the Transition phase, the conversion process should be
completely tested during system testing and therefore, there should be only one iteration of the production process. This task is mostly concerned with the running of
conversion programs and the verifying that the production data is consistent and correct.
During the Transition phase, the initial load of the production database is typically carried out after the production environment is set up. Once this task is complete regular
updates of the production database can commence. A checklist and log of the initial loads that were executed on the production database should be provided and the
correctness of the loads should be verified.
Initial Load of <Instance>, Schedule <No>
This component is prepared for every production database instance, and for every load schedule for the given instance, if there are more load schedules to populate the
given instance. It consists of two sections:
Instance Information - contains the details of the database instances, including the instance owner, its physical location and its administrators. Once the initial loads
are complete, the name of the person verifying the load along with the date/timestamp is entered.
Load Log - consists of a table listing jobs planned and executed, and their details. Note that this list might be supplemented with a complete audit log.
Obtain the list of initial load jobs to be executed, along with their parameters. You might also solicit information with respect to the use of the scheduling components and
error resolution. The list should be checked against the scope of initial and historical loads as described in the Data Acquisition, Conversion and Data Quality Strategy
(CV.020). The jobs are first categorized by flow (such as from source to staging, staging to warehouse). These jobs are listed in the provided checklist. They are divided
logically into sets, where each set comprises of jobs that can be run in parallel. The ordering of these sets should also ensure that no load is executed before the
completion of the jobs that precede it. Once the list is prepared, the jobs are scheduled according to the list and the execution is started. The execution is monitored and
any issues that might occur are resolved. The details of the jobs are entered in the job execution sheet. If any errors have occurred, the steps for correction are taken,
such as re-scheduling failed jobs and their successors. During issue solving, care must be taken that all the dependencies are observed. Once the database is loaded
and all the load issues are resolved, a check is performed that the required initial and historical data is present in the production database.
The above is repeated for every production database instance.
INSTANCE INFORMATION
Enter the common information about the production database environment, start and end date of the load, responsibilities etc. into a table. Include the following
information:
Instance Name name of the production instance
Instance Owner owner of the production instance
Instance Location location of the production instance
System Administrator administrator responsible for the loads
DBA database administrator responsible for the instance
Load Start Date and Time start date and time of the load
Load Start Date and Time end date and time of the load
Load Notes comments about the loads
Verified By who is responsible for the verification
Verification Start Date and Time date and time of the verification
Verification Results results of the verification
LOAD LOG
Document each job and its execution details in a table. Include the following information:
Set ID identification of the load set (or process)
Job ID identification of the job (or module)
Job Name name of the job
Description description of the job
Parameters runtime parameters such as effective date
Result result of the execution, e.g. OK, Error
Number of rows inserted number of inserted rows
Number of rows updated/merged number of updated or merged rows
Number of rows deleted number of deleted rows
Start Date and Time start date and time of the job
End Date and Time end date and time of the job
Issues issues encountered during the execution including information how the issues have been resolved and Issue# if an issue tracking system is used
Log File link to the log file
Back to Top
Back to Top
Developer Run conversion components for a subset of production data. Convert and verify production data. Plan and coordinate the initial
test conversion.
If a Data Acquisition and Conversion team leader has been designated to lead the process and review the work products, 20%
of this time would be allocated to this individual, leaving 60% allocated to the developer. The team leader would then plan and
coordinate the initial test conversion.
80
System Architect
Analyze the problems identified with the legacy data and refine strategies. Check the quality of the Data Acquisition and
Control process. Preferably, this should be done by a system architect that specializes in Information Architecture.
20
Client Data Administrator Analyze the problems identified with the legacy data. Make sure that the converted data meets the requirements of the
business.
*
Ambassador User Select a representative subsection of production data for test conversion. Review and suggest amendments to be made to
make sure the data is consistent and complete. If the data must be manually cleaned, the ambassador user should be charged
with making these modifications.
*
Client Production DBA Create and run a master script that creates the necessary temporary tables. *
Client Development DBA *
IS Operations Staff Assist with privileged access to external systems. *
IS Support Staff Assist in interpretation of rejected records. *
Back to Top
PREREQUISITES
CV.065.1
Prerequisite Usage
Validation-Tested Conversion Components (Initial Load)
(CV.063.1)
Validation-Tested Conversion Components (Initial Load) are used during the initial conversion of
the data.
CV.065.2
Prerequisite Usage
Data Acquisition, Conversion and Data Quality Strategy (CV.020) This work product contains the scope of the initial and historical loads. It should be checked
whether all initial and historical loads are covered.
Conversion Component Designs (Initial Load) (CV.040.1) The Conversion Component Designs is used to prepare the checklist of processes and jobs that
have to be executed and to order them according to dependencies.
Conversion Components (Initial Load) (CV.050.1) The Conversion Components list names and descriptions of individual modules that have to be
executed.
Validation-Tested Conversion Components (Initial Load)
(CV.063.2)
Validation-Tested Conversion Components (Initial Load) are used during the initial conversion of
the data.
Production Environment (TS.050) This work product is used to define production instances that should be loaded.
Back to Top
TEMPLATES AND TOOLS
CV-065_CONVERTED_AND_VERIFIED_DATA.DOC MS WORD
Back to Top
The Converted and Verified Data (Initial Load) is used in the following ways:
to prove the accuracy of the conversion components to indicate the condition of the production legacy data before conversion is attempted to provide a format for
recording important information about the components which are being executed to convert data for a particular entity from the legacy system
to analyze rejected data so that any additional cleanup that might be needed can be initiated
to verify that all initial load jobs are included with the correct parameters
to validate the final load
Distribute the Converted and Verified Data (Initial Load) as follows:
to the developers who are executing the conversion scripts to use as a worksheet to document their work to other conversion team members to the client data
administrator for analysis of rejected data records
to the overall project manager and the team leader for Data Acquisition and Conversion
Back to Top
QUALITY CRITERIA
Download Components:
Have you confirmed to the IS support staff in which order you need the data files will be created? Have you told the staff if you want one or multiple extracts for a
given entity object?
Have you insured which version of the flat file is being provided and for what purpose (for example, incremental versus full loads, etc.)?
Temporary Table Creation Components:
Have you created a table or tables to upload your data into and perform any required translations before moving the data to the production tables?
Upload Components:
Have you specified which table and columns to load the legacy data into?
Have you tested the different loader options to predict and achieve the best possible performance?
Are all initial load jobs that were identified in the Data Acquisition, Conversion and Data Quality Strategy (CV.020) listed in the checklist? This must be in the
correct order to take care of any dependencies.
Have all job parameters that are required for an initial load been defined?
At the completion of the initial loads, does the above checklist contain details of all loads, and have all issues encountered in the load, if any, been resolved?
Has a verification been performed that all the required initial and historical data have been loaded?
Back to Top
CV.068 - CLEAN DATA
In this task, you make sure that the data provided is consistent, complete and satisfies the constraints implied by the business data model.
ACTIVITY
CV.068.1
CV.068.2
Back to Top
WORK PRODUCT
Clean Legacy Data - Clean Legacy Data is data from the source (legacy) system that have been verified, transformed and is ok for being loaded into the target system.
Back to Top
TASK STEPS
1 Review Data Acquisition, Conversion,
and Data Quality Strategy
None None
2 Make sure that the ambassador users
have the appropriate tools to review
and amend data, where necessary.
None None
3 Review data provided for testing
purposes to make sure it is
consistent and complete.
Data
Cleaning
Steps and
Guidelines
See Description in Task Step 4.
4 Complete recommendations for fixing
problems in the production data.
Data
Cleaning
Steps and
Guidelines
The Data Cleaning Steps and Guidelines provides a list of potential problems encountered by the ambassador
user who has reviewed the representative subsection of production code. It may include date problems,
missing fields, wrong cardinality, etc. This component also contains the remedies to fix these problems.
5 Create scripts to correct incorrect
data.
Data
Cleaning
Scripts
The Data Cleaning Scripts are all the scripts necessary to run on the production data to make sure that it is in
a clean state for the production conversion run. These scripts would have been created by the developer on
recommendations from the ambassador user once this subset of data has been reviewed.
6 Make sure that the data provided for
testing purposes is consistent and
complete.
Clean Data Clean Data is a subsection of production data which has been cleaned to make sure that it is consistent and
complete for loading into the development or test environments for test purposes.
7 Review data provided for testing
purposes to make sure it is
consistent and complete.
None In many times users should establish and confirm policies for cleaning legacy data. Depending on the
decisions it is very important to receive formal confirmation of these decisions.
Back to Top
APPROACH
This task aids testing for the system and gives an indication of the condition of the production data. This task is iterative.
Data is verified to ensure that constraints implied by the business data model are satisfied, as well as requirements defined in the Data Acquisition, Conversion, and Data
Quality Strategy (CV.020) are fulfilled. It is important to note that this task does not imply any or all data quality issues associated to the data sources are in-scope, but
rather verifies that data quality issues identified in the original statement of work, or the Data Acquisition, Conversion, and Data Quality Strategy are met.
It should also be noted that in situations where the original assumptions or statements about data quality related to data sources fail to hold true, it is not unusual for a
separate data quality project to be created in order to address significant unforeseen data quality issues that were stated or implied as being nonexistent.
All task documentation should be updated for each new iteration and a backup of the results and problems of the last iteration should be stored. Clean Legacy Data is
designed to give the user population and project sponsor an idea for the condition of the production data and the ease with which the production data can be converted.
Often conversion is taken as a trivial task because the project sponsor has been assured that the data in production is in a state that can be easily be converted. This
task should reinforce the size and complexity of the task which has to be completed.
If possible scripts should be used to alter production data, as manual alteration of production data can not be reproduced in the case of a rerun. All changes to production
data should be audited to make sure that changes can be traced.
Back to Top
Developer Run conversion components for a subset of production data. Track and analyze the problems identified with conversion
components and production data.
If a Data Acquisition and Conversion team leader has been designated, 30% of this time would be allocated to this individual,
leaving 50% allocated to the developer. The team leader would then track and analyze the problems identified with conversion
components and production data.
80
System Architect
Analyze the problems identified with the legacy information (data) and refine strategies. Preferably, this should be done by a
20
Client Data Administrator Review data provided for testing purposes to make sure it is consistent and complete. *
Ambassador User Review and suggest amendments to be made to make sure the data is consistent and complete. If the data must be manually
cleaned, the ambassador user should be charged with making these modifications.
*
Back to Top
PREREQUISITES
CV.068.1
Prerequisite Usage
Domain Model (RD.065) The Domain Model is a top-level model of the information requirements needed to meet business objectives. It provides
a definition of the structure of all the data that the business areas use or generate. It should include all the information
about data collected.
Converted and Verified Data (Initial Load)
(CV.065.1)
The Converted and Verified Data (Initial Load) provides the converted data. This data has also been verified to
determine whether the data can be converted into the new application. Any inconsistencies or incorrect data have been
identified.
CV.068.2
Prerequisite Usage
Domain Model (RD.065) The Domain Model is a top-level model of the information requirements needed to meet business objectives. It provides
a definition of the structure of all the data that the business areas use or generate. It should include all the information
about data collected.
Converted and Verified Data (CV.065.2) The Converted and Verified Data (Initial Load) provides the converted data. This data has also been verified to
determine whether the data can be converted into the new application. Any inconsistencies or incorrect data have been
identified.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Clean Legacy Data is used in the following ways:
to populate the development and test environments with a clean subset of production data
to find and document problems with the production data
to recommend fixes to production data problems
to provide scripts and other techniques to fix production data such as manual data entry screens
Distribute Clean Legacy Data as follows:
to the client data administrator to populate the development and test environments for testing purposes
to the developer to make sure correct modules using the data are working correctly
Back to Top
QUALITY CRITERIA
Does the data now satisfy the constraints implied by the High-Level Existing System Data Model (if it exists)?
Does the data now satisfy the constraints implied by the Domain Model?
Back to Top
[DO] DOCUMENTATION
Quality documentation is a key factor in the transition to production, gaining user acceptance, and maintaining the ongoing business process. The requirements and
strategy for this process vary based upon project scope, technology, and requirements.
For projects that include Oracle Application products, the Oracle Application manuals are the foundation of implementation documentation. The Documentation process
will develop documentation to augment the standard Oracle Application products manuals with specific information about the organization's custom software extensions
and specific business procedures.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
Successful project documentation reflects the final applications system as it is approved for use. It is accurate, concise, and uses diagrams and charts to explain broad or
complex concepts. It should be useful to both beginners and experienced users of the system and have a user-friendly tone that is neither too academic nor too technical.
During the Inception Phase, a Documentation Requirements and Strategy (DO.010) is developed to drive this process. From that strategy, Documentation Standards and
Procedures (DO.020) are developed to guide the documentation work products to be produced.
Writing Standards
If you have a writing standards guide, follow it when writing any custom documentation. You can use other appropriate style guides as well.
Prototypes
After you complete the Documentation Requirements and Strategy (DO.010) and define the Documentation Standards and Procedures (DO.020), create a prototype of
each document. A prototype consists of a table of contents and a sample chapter. The first purpose for prototyping is to tangibly display your understanding of
documentation requirements, standards, and procedures in terms of form and content. The second purpose is to set user expectations. Showing a tangible prototype is
far more effective than discussing documentation.
Parallel Work Effort
The project team should begin Documentation tasks whenever the appropriate prototype and the required documentation inputs have been approved. Several required
documents may be worked on simultaneously.
Previously Completed Materials
The documentation writers should build on the documents that have been completed during earlier implementation tasks. Earlier documents can be used as is, or
portions can be incorporated as required.
The following sections can be included in both user and technical documentation.
Table of Contents
Generally, a table of contents is necessary for all documents that are over several pages and cover a variety of subtopics. If a user does not need to read the entire
document from start to finish each time it is referenced, add subtopic headings and create a table of contents.
Introduction
If the customization or subject area includes multiple forms, reports, or programs, consider beginning with an overview of the process explaining how the individual pieces
relate to each other.
Appendices
If detailed charts, diagrams, and examples are confusing or cause a loss of continuity in the text, put them in an appendix where they can be referenced.
Glossary
Include any unfamiliar or confusing terms in the glossary. For example, the term FOB may not be familiar to all users, or the term demand may have a different meaning
for each audience. Including these terms in the glossary removes doubt about their meaning.
The Glossary (RD.042) is a good source of terms that should be included in your Glossary. You may want to incorporate the Glossary (RD.042), in part or total, in some or
all of the Documentation work products.
Index
If the documentation is more than a few pages, an index helps the user locate key topics or words.
Types of Media
Documentation may be published in a number of electronic and published media.
Printed Documentation
The documentation may be produced on printed pages. This has been the standard media in the past for publishing documentation. Some organizations may choose to
go paperlessif they do, they may not allow any documents to be published in printed form.
Portable Electronic Documents
The OUM documentation work product templates are based upon Microsoft Word. From the Microsoft Word documents, documentation work products may be produced
as a portable electronic document using a format such as Adobes Portable Document Format (pdf). These portable documents may be exchanged among users and
read on a variety of computing environments using Adobes Acrobat Reader. The key benefit to this approach is that a single publication activity yields a multitude of
platforms in which the documents may be read.
Web Pages
The documentation can be published on a web page and can be accessed via a web browser and an URL address.
User Validation
Users should review documentation along with early test results for programs, reports, enhancements, and new forms.
Testing Documentation
If it is to be a valuable resource, Documentation must accurately reflect the system. During Testing (TE), applicable documentation should be referenced by the testers, as
it would be in production. If the documentation is unclear or outdated, appropriate changes must be made. Testing is not complete until the documentation is verified as
correctly reflecting the new system.
Back to Top
Inception Phase
DO.010 Define Documentation Requirements and Strategy Documentation Requirements and Strategy
Elaboration Phase
DO.020 Define Documentation Standards and Procedures Documentation Standards and Procedures
DO.040 Prepare Documentation Environment Documentation Environment
Construction Phase
DO.060 Publish User Reference Manual User Reference Manual
DO.070 Publish User Guide User Guide
DO.080 Publish Technical Reference Material Technical Reference Material
DO.100 Produce Online Help Online Help
Transition Phase
DO.110 Finalize Documentation Final Documentation Work Products
Back to Top
OBJECTIVES
The objectives of the Documentation process are:
Produce a reference that shows the users how to use application functionality (User Reference Manual - DO.060).
Produce a User Guide to show the users how to use the system (User Guide - DO.060)
Assemble the documents that describe the technical details of the application for the maintenance staff (Technical Reference Material - DO.080).
Produce Online Help (DO.100)
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
BA Business Analyst Describe documentation needs and current documentation usage. Agree on documentation standards. Assist with content for the User
Reference Manual and User Guide.
DV Developer Provide assistance in verifying the documentation is correct and complete. Provide material for the Technical Reference Material (DO.080).
Provide assistance generating Online Help from the User Guide (DO.070) and the User Reference Manual (DO.060). Provide any final
updates or changes for Documentation work products.
SAD System
Administrator
Procure, install and test the Documentation Environment.
SA System Architect Provide assistance in verifying the documentation is correct and complete. Provide material for the Technical Reference Material (DO.080).
Provide any final updates or changes for Documentation work products.
TW Technical Writer Write, edit, and review the various work products. Obtain agreement with users on the work products. Write, edit, and review the
accompanying documentation for the Documentation Environment. Write, edit, and review the User Reference Manual. Design, gather
material, organize, write, edit, and review the User Guide. Revise sections of the User Guide (DO.070) based on system test scenarios.
Gather, organize, edit, and review the Technical Reference Material. Generate or develop the Online Help from the User Guide (DO.070)
and the User Reference Manual (DO.060). Update Documentation work products with any final updates or changes.
TE Tester Write, edit, and review the Documentation Requirements and Strategy when offshore input is utilized.
Client (User)
KEY Ambassador User Review the Online Help and provide feedback.
BLM Business Line
Manager
Assist in describing documentation needs and current documentation usage. Agree on documentation standards.
CPM Client Project
Member
Provide input into developing the work product. Review the Online Help and provide feedback.
CSM Client Staff Member Install the Documentation Environment and assist in testing.
Back to Top
Back to Top
DO.010 - DEFINE DOCUMENTATION REQUIREMENTS AND
STRATEGY
In this task, you outline the overall requirements for creating documentation and specify the work products to be produced. You also identify the strategy you will use in
publishing project-specific documentation.
For projects that involve the upgrade of Oracle products, this task involves a review, and potentially an update, to the client's existing Documentation Strategy in order to
accommodate new features and technologies available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Documentation Requirements and Strategy - The Documentation Requirements and Strategy identifies the list of project-specific documentation that needs to be
published and the strategy for publishing this documentation.
This work product should address the following:
the list of requirements for producing documentation
the list of documents that need to be published
the strategy used to produce project-specific documentation
Back to Top
TASK STEPS
1 Verify the documentation descriptions in the project level
scope, objectives, and approach as contained within the
Project Management Plan. Review the project
documentation standards, if available. Organize the
work product.
Introduction Provide an introduction for the work product. Include the following sections:
Scope, Approach, and Methods discusses the objectives and approach to
documentation
Information Sources lists the information sources for the Documentation
How to Review lists the criteria for reviewing the content of the Documentation
Summary of Findings summarizes the reasons for the proposed structure and
content of the documentation and provides a qualitative summary of the
proposed documentation and identifies any problems or concerns that were
found
Next Steps outlines the Documentation process
2 Identify the scope of the documentation, milestone
publishing dates, and constraints.
Scope Describe the scope of Documentation in as much detail as possible. The scope
statement should state exactly how many project-specific documents will be published
and the level of content included in these documents. Scope statements can be made in
terms of whether certain documentation is in or out of scope for the project.
Examples of components that can define the documentation scope include:
Business Processes
Functions
Sites
Languages
Application Extensions
Interfaces to Third-Party or Legacy Systems
In addition to discussing the overall scope of Documentation, include any assumptions
#TOP #TOP
made, the risks inherent in the Documentation process, the expectations for new
systems documentation, whether new technology will be used to publish the document,
and the relationship of Documentation tasks to other process tasks already underway.
3 Discuss the project with the project manager and
establish the specific scope for Documentation.
Scope
4 Identify Documentation objectives and critical success
factors.
Objectives List the high-level objectives communicated by the business and project managers. In
addition, it should contain a description of the critical success factors for Documentation.
Include the following sections:
Objectives
Critical Success Factors
Since this is a strategic document, the stated objectives should not be too detailed;
however, they should be specific and measurable. Critical success factors associated
with meeting the objectives of the process within the context of the overall project are
also identified within this component.
5 Review the work products that will be produced by this
process. Review the list of work products with client staff
members.
Approach Describe the method, policies and procedures, project dependencies, and other
background for Documentation. Include a high-level discussion of the approach selected
for the Documentation work, the tasks and work products involved, the reasons for
selection of the approach, and the benefits of the particular method adopted.
The project dependencies section of the component describes the dependencies
between tasks in Documentation and tasks in other processes taking place within the
overall implementation project.
In relation to the statements about the technical requirements for the documentation
subproject, the work product should indicate which Documentation Environments are
needed to support the documentation subproject. Typically, at least one separate
environment is needed for documentation.
If the process uses different polices, procedures, or standards from the main project in
any of the key control and reporting areas, the work product should document the
differences in detail and explain why they differ. The following are examples of areas
where the process typically inherits standards and procedures from the main project:
issue management and resolution
change management
reporting format
reporting relationship to main project
acceptance
project policies and procedures
process team meetings
logistics and administrative support
The technical background should describe the technical circumstances affecting the
approach to the project. Examples of the points that might be included are:
implementation sites
documentation direction
computing platforms and technical infrastructure
major system or application requirements
innovative or unusual technical requirements
6 Identify constraints and assumptions that are associated
with the process.
Approach
7 Review risks to the process activities and objectives. Approach
8 Define policies and procedures unique to
Documentation.
Approach
9 Identify the mechanism for publishing documentation. Documentation
Strategy
Describes the documentation strategy and includes the means for determining the
documents to be authored, published, and produced. It also covers which media will be
used to publish documentation. The media could include printed documentation,
portable electronic documents, or web pages that can be accessed via a web browser
and URL address.
Requirements may be highlighted and discussed because of their criticality in the
documentation work, the inherent risk to the project, an innovative or unusual approach
to be applied in the project, or for some other implementation-specific reason.
10 Establish the procedures for maintaining the
Documentation Environment.
Documentation
Strategy

11 Identify potential risks in the strategy outlined. Documentation
Strategy

12 Identify the documentation requirements at a summary Documentation Describe the human and physical resources required to develop and deliver
and detailed level. Requirements documentation. Make sure you include user participation as part of your plan. It
describes the specific resources needed for Documentation, which may include
resources in the following areas:
software
hardware and networks
hardware and software delivery schedule
staff
This component includes the following sections:
Summarized Requirements
Detailed Requirements
Human Resource Requirements
Software Requirements
Server Platform and Network Requirements
Server Platform and Software Delivery Schedule
The Summarized Requirements should summarize the detailed requirements gathered
for the business and information systems and their likely impact on the documentation
and systems.
The Detailed Requirements should detail the individual business and information
systems requirements that affect the documentation. Some of the requirements that
may be included are:
New custom software - Document all new custom software developed during
Modified software - Document all software modified during this project
Application Extensions Document all custom extensions built for the new
system as standard documentation does not address this new functionality.
Interface to Third-Party and Legacy Systems Document all custom interfaces
that move data between the custom software and Oracle Application and third-
party and legacy systems.
13 Identify users for each document to interview them to
determine their requirements.
Documentation
Requirements
Record of
Interviews
Document who has been interviewed.
14 Prepare and conduct interviews. Interview
Preparation
Comprise of a list of questions to help you prepare for interviewing the applicable users
of the documentation. Depending on the project, the checklist can be used for internal
reference only, or it can be part of the user work product. You may want to send this
questionnaire to the respondents before the interview to help them prepare for the
requirements gathering process.
15 Describe the resource requirements needed to support
the Documentation process.
Documentation
Requirements

16 Document the Documentation Environment
requirements.
Documentation
Requirements

17 Document the staffing requirements for publishing
project-specific documentation.
Documentation
Requirements

18 Identify human and physical resources required to
develop and deliver documentation.
Documentation
Requirements

19 Document specific tool requirements for the
Documentation process.
Documentation
Requirements

20 Describe the components of each document. Determine
the format for transferring ownership to the user.
Documentation
Synopses
Describe each document that is to be produced. This includes the document format and
content, as well as the required format for transferring ownership of the documentation
to the users. In addition, the following questions should be addressed:
Will both soft and hard copy be needed?
If hard copy is required, how many copies must be provided?
For soft copy, should a particular text processing package or format be used?
Are you required to publish the manuals and guides in hypertext markup
language (HTML) format?
Will learning be required for the users to assume ownership of the work product?
What types of edits and reviews must be performed?
21 Identify the documentation audience. Documentation
Synopses
Identify the documentation audience and what they need to know. The degree of overlap
and commonality in tasks determines how you group the job roles into documentation
audiences.
22 Review the draft work product with senior management
and seek approval.

23 Secure acceptance for the Documentation Requirements
and Strategy.
Acceptance
Certificate
(PJM.SM.040)

24 Identify any material changes to project scope and
associated task estimates with the project manager.

Back to Top
APPROACH
Every project must determine the requirements for project-specific documentation. The documentation requirements vary depending upon the nature of the project. Each
custom application system generally requires written documentation of specific types. These documents help with training and on-going support of the application system.
The types of documentation that can be produced are well-known, although some types of applications may call for a slightly different suite of documents.
You should start with the the list of standard set of documentation work products, and check the Project Management Plan for a variations from this list. Gather additional
requirements by interviewing users and asking them questions about their documentation needs. For example, during Oracle Applications implementations, these
interview questions should help you determine if the organization is building any application extensions, whether interfaces to third-party or legacy systems are to be
used, and whether there or any other compelling reasons for which you may want to build project-specific documentation.
Once you have defined the Documentation Requirements and Strategy, it should be reviewed and accepted by management before progressing with the remaining
Documentation tasks.OUM follows an iterative approach to developing documentation. Prepare a prototype, and an initial draft version of each document in order to
gather feedback on the documents content and make revisions as necessary. This allows for continuing improvement in the quality of the documents. Project-specific
documentation is often used during testing, learning, and the ongoing support of the new system.
Required Document List
Review any documentation requirements in the Project Management Plan. If the Project Management Plan specifies the documents to be produced, use this list and
indicate in the Documentation Requirements and Strategy where the list is located in the Project Management Plan.
If the Project Management Plan is not specific, work with the project leader and user management to determine the list of required documents. The following documents
have Documentation tasks specifically designed for publishing manuals and guides:
User Reference Manual (DO.060)
User Guide (DO.070)
Technical Reference Material (DO.080)
Online Help (DO.100)
Each section of the User Reference Manual explains the details of a single system function and includes information for each field, option, data validation, error message,
and so on. It is an important reference for experienced users of the system who need information on infrequently used functions.
User Guide (DO.070)
The User Guide is business oriented and contains the manual-and application-based procedures needed by the users to respond to business events. It is an instruction
manual for the business area and is the basis for user learning. New applications users rely on the User Guide to learn how to perform their jobs on the system.
The Technical Reference Material describes the application's technical architecture and design, and documents all custom modules, interfaces to other systems and
products, and extensions to any COTS (Commercial Off the Shelf ) products. For example, during implementations of the Oracle Applications products, it should
supplement the Oracle Application Technical Reference Manual. This documentation is used by anyone responsible for future application maintenance.
The Online Help is loaded into the application and may be available in several contexts, such as: form-level full-screen help text, field-level full-screen help text, field-level
hint text, and error help text.
Scale and Scope of Documentation
Scale of the Documentation Process
The creation of a separate Documentation Requirements and Strategy for Documentation may be different depending on the type of project.
Small- to Medium-Sized Implementations - If documentation is part of a small implementation project, the scope definition, work management, and funding of the
Documentation process may be incorporated into the management of the overall project, and this task is greatly simplified. In such cases, you should review the existing
Project Management Plan, verify that it is an accurate statement of the Documentation process, and then move to the next task. In some cases you may wish to
incorporate many or all of the work product components of the Documentation Requirements and Strategy (DO.010) into the Project Management Plan.
Large, Complex Projects - In a large and more complex implementation project, the Documentation process may need to be semi-autonomous because of its number,
size, and complexity, and a separate documentation subproject may be needed to provide effective control. In these types of implementation projects, the Project
Management Plan defines the high level scope and policies, but does not provide enough detail about individual subprojects. This detail would be documented in this
work product
Task Complexity Depends on Project Scope
The level of detail required for this task depends on the scope of the implementation project and the Documentation process within it. If the Documentation work is being
performed for a small number of applications that need only to fit into existing documentation or information systems strategy, you need only to document the parts of the
strategy that are relevant to the limited Documentation scope and proceed to the next task. At the other extreme, if this is an enterprise-level documentation for a large-
scale replacement of business systems, or there is no clear documentation or information systems strategy in place already, you may need to go into some detail to
document the documentation policies and expectations.
Business Vision
The vision for the new business systems is a key initial ingredient of the design of any documentation, especially where the Documentation process is covering the
strategic aspects of the new systems as well as the tactical design. The vision must be documented and understood early in the process. Examples of business visions
are listed below:
Users must be able to access their documentation online over the organizations intranet.
The corporation will standardize all corporate-wide documentation and allow each site to document their site-specific documentation as they wish.
The business will offer all documentation in electronic form. Some documentation may not be offered in hardcopy format.
Documentation Policies and Standards
At the heart of every documentation project are directives and policies that are fundamental to the documentation design. In large projects that are modifying many of the
standard application modules, you may be defining these directives and policies for the first time. These are the guiding principles for the design and distribution of the
new documentation, which might be using new technology for the first time. In projects where the implementation is more limited in scope, this may be a matter of
conforming to policies and principles that the information systems department has already established for any new documentation.
In situations where a formal information systems strategy project has preceded the implementation Documentation process, a set of principles, directives, and strategies
may already be in place, which you can directly input as requirements to the implementation documentation. The selection of a particular publishing tool or technology
may be partly in response to the demands of the particular information systems strategy.
Documentation Scope and Objectives
When setting scope for the Documentation process, it is important to understand that project-specific documentation can be expensive to author, publish, and maintain.
Proper scope setting and management of expectations are essential. The project and business managers should specify their high-level goals for preparing
documentation and how this project will use the documentation once it is published.
Attention: Documentation may be one aspect of an overall performance quality management program within a project. If this is the case, the scope should indicate how
documentation fits into that program.
Staffing Resources
The staff resources needed for the Documentation process are directly dependent on the type and amount of project-specific documentation being published. Technical
writers are the primary resources used for publishing documentation. If the documentation project is large enough, you should consider adding a document administrator
to help manage documentation files.
Environments Required
The Documentation team should have access to a Documentation Environment (DO.040) that supports the organizations authoring and publishing needs. This
environment could be as simple as a laptop computer with desktop publishing software, or as complex as integrated publishing tools, platform servers, data storage
devices, communication networks, and documentation libraries with version control.
Back to Top
Back to Top
Business Analyst Describe documentation needs and current documentation usage. Agree on documentation standards. 30
Technical Writer Write, edit, and review the work product. Obtain agreement with users on the work product. 70
Business Line Manager Assist in describing documentation needs and current documentation usage. Agree on documentation standards. *
Client Project Manager Provide input into developing the work product. *
Back to Top
PREREQUISITES
Prerequisite Usage
Project Management Plan (PMP)
(PJM.WM.010)
These PJM work products provide a high-level discussion of the scope for publishing project-specific documentation, list the work
products specific to this project, and indicate how the project should be organized and run.
Oriented Team (PJM.STM.050) Prior to defining the Documentation Requirements and Strategy, the project team members attend a project team orientation
meeting.
(RD.001)

Back to Top
TEMPLATES AND TOOLS
DO-010_DOCUMENTATION_REQUIREMENTS_AND_STRATEGY.DOC MS WORD
Tool Comments
processes.
Back to Top
The Documentation Requirements and Strategy is used in the following ways:
to determine the custom documentation that is needed for the project - User requirements for each document are analyzed and an agreement regarding design,
format, and content is reached. Every user that relies on documentation as an ongoing resource for their day-to-day operations should be represented during this
critical task.
to establish and document the strategy for the documentation as part of the project
The Documentation Requirements and Strategy should expand the Project Management Plan created for the overall project in greater detail for the Documentation
process. It should make reference to the main project work product where appropriate, and indicate those objectives and approaches that are inherited from the main
project. It should not, however, be just a duplication of the Project Management Plan.
Distribute the Documentation Requirements and Strategy as follows:
to the project manager who should sign off on the Documentation Requirements and Strategy and resources needed
to IS manager who should sign off on the Documentation Requirements and Strategy
to Documentation team members
to other process leaders who have dependent tasks with the Documentation process
Back to Top
QUALITY CRITERIA
Are the project scope and objectives clearly identified?
Does this document take into account the impact of dependent tasks from other processes?
Is the Documentation Requirements and Strategy clearly defined?
Does the strategy discuss existing information systems policies and strategies and indicate how they relate to this project?
Are all resource and tool requirements that could impact the Documentation process stated and understood?
Is the work product thorough in capturing different types of business and information systems requirements that are directly relevant to documentation?
Back to Top
DO.020 - DEFINE DOCUMENTATION STANDARDS AND
PROCEDURES
In this task, you specify the standards for all documentation work products and determine the look and feel of the project documentation. In addition, you also specify the
procedures that the team uses to develop documentation.
For projects that involve the upgrade of Oracle products, this task involves a review, and potentially an update, to the client's existing Documentation Standard and
Procedures in order to accommodate new features and technologies available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Documentation Standards and Procedures - The Documentation Standards and Procedures identify how the documentation should look and feel. It should also list the
procedures to be followed when preparing project-specific documentation. It address the following:
standards for how the published documents will look
procedures covering how to author and publish documentation
Back to Top
TASK STEPS
1 Write the front material. Introduction Explain the purpose of the work product and areas covered by the document. References to any
documentation standards and procedures already defined are included as well.
2 Understand any existing
documentation standards. If no
standards exist, determine
what guidelines should be
used.
Paragraph and
Sentence Structure
Usage
User Input and System
Output Lists
Attention, Suggestion
and Warning Icons
Numbers and
Operations
Translation and
International
Audiences
Preferred Terms
In the Paragraph and Sentence Structure, document the many elements of writing, such as guidelines on
how to structure a paragraph and a sentence, and provides examples of paragraph and sentence
structures.
In the Usage, document standards on language usage and includes a list of right and wrong examples of
language usage. This resource gives numerous examples of how to use certain text in constructing your
document.
In the User Input and system Output, identify the standards for user input and system output. When
developing documentation, use these standards for user inputs and system outputs.
The List provides guidelines to be used when creating lists. This component addresses numbered lists,
bulleted lists, descriptive lists, and others and provides examples.
Provide guidelines for using attention, suggestion, and warning icons in the documentation. Oracle
Method icons for attention, suggestion, and warning can be inserted into a document to draw attention to
specific content.
Provide guidelines for using numbers and operations in the documentation. Examples that show the right
and wrong way to present numbers and options are included.
Provide standards for writing documentation for international audiences. Specific advice for preparing
documentation for international audiences is included.
List preferred terms. This list contains words that are preferred in Oracle documentation and specifies the
way in which the term should be used. This list also provides the proper spelling and capitalization for the
term.
3 Determine the documentation
development procedures.
Initial Material The Initial Material identifies the source of the initial content for each work product. In some cases, you
may have a work product from a predecessor task that becomes the initial material for the current task.
Writing and Editing
Translation
Procedures
Downloading
Testing and Change
Control
Hard Copy and
Reproduction
Backups and Archives
Review and Approval
Process
Publication/Deployment
In the Writing and Editing section, identify the individuals who will be assigned as subject matter experts,
writers, editors, and reviewers of the User Reference Manual (DO.060), User Guide (DO.070), Technical
Reference Manual (DO.080), and Online Help text (DO.100).
Translation Procedures lists the translator, editor, and reviewer assignments. Identify the resources used
to translate documents and then obtain the necessary review, approval, and acceptance of the
documents.
The Downloading component indicates how to download documentation from another system.
Downloading procedures indicate how to download documentation to and from the documentation
library.
The Testing and Change Control component documents testing and change control for your User
Reference Manual (DO.060), User Guide (DO.070), Online Help text (DO.100), and other documentation
work products. Any changes made to the system should be reflected in the latest version of the
documentation.
The Hard Copy and Reproduction component defines the hard copy and reproduction requirements for
the User Reference Manual (DO.060), User Guide (DO.070), and Technical Reference Manual
(DO.080). Depending on the extent of printing required, you may be able to print your documents from a
local printer, a network printer, or you may need to take your print job to the print center or an outside
printing service.
Define the backup and retrieval process for the documents produced during Documentation. This
component also includes the archival information.
The Review and Approval component defines the organizations standard procedures for reviewing and
approving documentation. Documentation review and approval occurs several times during
documentation. Secure client acceptance for the documents that have been reviewed and approved.
There are several media types available for publishing/deploying documentation. Document the type of
media used and the procedures to be followed.
4 List any outstanding issues and
record their resolution.
Open/Closed Issues
5 Finalize the Documentation
Standards and Procedures.

Procedures from the client
project manager.
(PJM.SM.040)

Back to Top
APPROACH
Use the Documentation Standards and Procedures to outline the guidelines on how the documentation will look and feel. You can either define your own documentation
standards and procedures or you can use an authoring and publishing tool, such as Oracle Tutor, which has documentation standards and procedures built in.
Participants
Participants in this task determine the look and feel of the documentation and the process for producing it. Be sure to include the project team members who write the
documentation and the users who reference it during their ongoing business processes.
Documentation Standards
If possible, do not start with a blank piece of paper when defining documentation standards because too much time may be lost reaching agreement, documenting the
standards, and creating the necessary tools to implement them. There are authoring and publishing tools available that have proven documentation standards built into
the software product.
The standards provide a consistent style even though several people may be involved in the writing process. Standards are an important part of the Documentation
process since they provide a common look and feel to the documents. Documentation standards should address the following:
Paragraph and Sentence Structure describes the standards for paragraph and sentence structure
Usage describes the standards for language usage
User Input and System Output describes the standards for displaying user input and system output in the documents
Lists describes the standards for using lists
Attention, Suggestion and Warning Icons describe the standards for using
Attention, Suggestion and Warning Icons
Punctuation describes the standards for punctuation
Numbers and Operations describes the standards for displaying numbers, mathematical operators, and date formats
Translation and International Audiences describes the standards for writing documents that will be translated or read by global audiences
Preferred Terms describes standards for presenting an organizations preferred terms in the documentation
Media describes printed, portable (pdf), and web documentation
Documentation Procedures
Procedures specify the way that the documentation will be produced. Include an explanation of the following:
Initial Material identifies the source of the initial content for each work product
Writing and Editing identifies writers and editors for the documents and defines the document review process
Translation Procedure determines the procedures for translating documents
Downloading determines whether significant content comes from other systems and how it gets from one system to another
Testing and Change Control determines the method for verifying that the documentation matches the application implementation and defines the process for
applying application changes to the documentation
Hard Copy and Reproduction determines hard copy requirements and identifies how the documentation is produced, stored, and distributed
Backups and Archives identifies documents for backup, backup frequency, and restore procedures and in addition, identifies archive requirements for soft and
hard copy
Review and Approvals verifies that the appropriate individuals have reviewed the documentation to meet the requirements for clarity and consistency and have
approved the documentation for final publication
Back to Top
Back to Top
Technical Writer Write, edit, and review the work product. Obtain agreement with users on work product. 100
Business Line Manager Describe documentation needs and current documentation usage. Agree on documentation standards. *
Client Project Manager Provide input into developing the work product. *
Back to Top
PREREQUISITES
Prerequisite Usage
Documentation Requirements and
Strategy (DO.010)
The Documentation Requirements and Strategy defines all of your Documentation work products. Once these
Documentation work products have been identified, standards can then be created to define the look and feel of each
work product.
Existing Business Documentation
Standards
Obtain the standards that the organization uses for other application systems documentation, if it exists. This prerequisite
is only necessary if the project team plans to adopt any existing documentation standards.
Back to Top
TEMPLATES AND TOOLS
DO-020_DOCUMENTATION_STANDARDS_AND_PROCEDURES.DOC MS WORD
Tool Comments
processes.
Back to Top
The Documentation Standards and Procedures is used in the following ways:
to define the guidelines for how the documentation will look and feel
to guide the quality management of the documentation
to clarify the expectations being set for the writers
to define the writing process so that all writing is completed at the appropriate time with the required reviews, edits, and updates
Back to Top
QUALITY CRITERIA
Back to Top
DO.040 - PREPARE DOCUMENTATION ENVIRONMENT
In this task, you prepare a hardware and software environment that supports documentation development. At the end of this task, you are ready to begin developing
documentation.
For projects that involve the upgrade of Oracle products, the requirement for a Documentation Environment largely depend on the scope and complexity of the clients
Documentation Requirements. Refer to the Documentation Requirements and Strategy (DO.010) for more details.
For upgrade projects that involve the upgrading of custom online user help files, a specific Documentation Environment is not typically required. On the other hand, if the
project involves the upgrading of content management and provisioning facilities, a specific Documentation Environment may be required.
ACTIVITY
Back to Top
WORK PRODUCT
Documentation Environment - The Documentation Environment is the platform and software environment that allows you to support documentation development. It
should address the following:
proposal for hardware, software, and documentation production utilities
hardware, software, and utilities for the Documentation Environment
hardware, software, and utilities installation for the Documentation Environment
hardware, software, and utilities testing for the Documentation Environment
documentation contingencies
Back to Top
TASK STEPS
1 Review the documentation procedures.
2 Review the number of technical writers and development team
members assigned to the project. Assess their availability to the
project.

3 Propose hardware, software, and utilities. Hardware
Proposal
Software
Proposal
Utilities Proposal
The Hardware Proposal documents the detailed information about the
proposal for procuring hardware for the Documentation Environment.
The Software Proposal documents the detailed information about the
proposal for procuring software for the Documentation Environment.
The Utilities Proposal documents the detailed information about the
proposal for procuring utilities for the Documentation Environment.
4 Procure hardware, software, and utilities. Hardware
Procurement
Software
Procurement
Utilities
Procurement
The Hardware Procurement identifies the issues involved in the
procurement of hardware for the Documentation Environment.
The Software Procurement identifies the issues involved in the
procurement of software for the Documentation Environment.
The Utilities Procurement identifies the issues involved in the
procurement of utilities for the Documentation Environment.
5 Install hardware, software, and utilities. Hardware
Installation
Software
Installation
Utilities
The Hardware Installation identifies the issues involved in the installation
of hardware for the Documentation Environment.
The Software Installation identifies the issues involved in the installation
of software for the Documentation Environment.
The Utilities Installation identifies the issues involved in the installation of
#TOP #TOP
Installation utilities for the Documentation Environment.
6 Test hardware, software, and utilities. Hardware Testing
Software Testing
Utilities Testing
Hardware Testing documents the testing of hardware used in preparing
the Documentation Environment.
Software Testing documents the testing of software used in preparing the
Utilities Testing documents the testing of utilities used in preparing the
7 Determine contingency plans. Contingency
Plans
This component documents the contingency plans for hardware, software,
and utilities used in the preparation of the Documentation Environment.
8 Secure acceptance of the Documentation Environment. Acceptance
Certificate
(PJM.SM.040)

Back to Top
APPROACH
Use the Documentation Environment to prepare project documentation and to control access to project documents. The Documentation Environment allows you to have a
hardware and software environment that is properly set up to support documentation development.
Documentation Environment Specifications
Make sure that the hardware (platform), software, and utilities accommodate the documentation procedures you have specified. You may have to use an existing platform
or software (modify your procedures accordingly). If possible, specify an environment that is familiar to the team, thereby reducing the learning curve. A list of critical
points that are sometimes overlooked follows:
screens should be large and high-resolution
a high-speed printer is required
quick and accurate file transfer capability is required if writing is to be done in more than one location
If necessary, revisit the Physical Resource Plan and add any updates to material that relates to the Documentation Environment.
If necessary, revisit the Project Team Learning Plan (TR.020) ) and add any software to the learning needs for the team involved in the documentation.
Attention: Confirm that the individuals selected to assist in the environment proposal have a thorough knowledge of the documentation development procedures, as well
as the hardware, software, and utilities being considered.
Procurement, Installation, and Testing
Consider the potential of significant lead times in procuring hardware and software that is not available off the shelf.
The time required to set up the environment can vary greatly. Plan well in advance if approval, purchasing, or procurement delays are common for the products you need.
You should plan to test the environment against the actual procedures you have specified.
Back to Top
Back to Top
System Administrator Procure, install and test the Documentation Environment. 80
Technical Writer Write, edit, and review the accompanying documentation for the Documentation Environment. 20
Client Staff Member Install the Documentation Environment and assist in testing. *
Back to Top
PREREQUISITES
Prerequisite Usage
Physical Resource Plan (PJM.IFM.030) The Physical Resource Plan defines the overall requirements and responsibility for all physical resources and supporting
services needed to execute project tasks.
Strategy (DO.010)
The Documentation Requirements and Strategy list all of the documents to be produced for the project.
Procedures (DO.020)
The Documentation Standards and Procedures specify the standards for all documentation work products and determine the
look and feel of project documentation.
Project Team Learning Plan (TR.020) Use the Project Team Learning Plan to identify any software to accomplish the learning needs for the team involved in the
documentation.
Back to Top
TEMPLATES AND TOOLS
DO-040_DOCUMENT_ENVIRONMENT.DOC MS WORD
Tool Comments
processes.
Back to Top
The Documentation Environment is used in the following ways:
to formally track the proposal, procurement, installation, and testing of elements involved in creating the Documentation Environment - Sufficient features must be
available in the chosen hardware, software, and utilities to support the Documentation Requirements and Strategy (DO.010).
Back to Top
QUALITY CRITERIA
Back to Top
DO.060 - PUBLISH USER REFERENCE MANUAL
In this task, you gather material and publish the User Reference Manual. The User Reference Manual documents the custom software developed.
During the Transition phase, you will have an opportunity to review all implemented system changes and system defects for any impact on the User Reference Manual
and finalize this work product.
In a commercial off-the-shelf (COTS) application implementation, this manual supplements the Oracle Commercial Off-the-Shelf (COTS) application user reference
material.
For projects that involve the upgrade of Oracle products, this task is used to update the clients existing User Reference Manual so that they correctly reflect how the
custom extensions will function with the new release.
ACTIVITY
Back to Top
WORK PRODUCT
User Reference Manual - The User Reference Manual shows users what custom software functionality was developed and how to use that functionality.
Back to Top
TASK STEPS
1 Gather information on the functionality of the custom software and
on any system extension from the Use Case Specification
(RA.024) and the Designed Classes (DS.090).

2 Write the front material and introductions to the chapters. Title Page
Preface
Contents
Chapters
The Preface documents how the manual is organized.
The Contents provide a format for the table of contents.
The Chapters provide boilerplate text that can be used to format each chapter.
3 For each application extension, write a topical essay that explains
how to use the new software or application extension functionality.
Topical Essay This component provides information about the scope, approach, and methods
of the User Reference Manual.
4 Add any appendices, as needed. Appendices This component provides an outline for creating an appendix.
5 Define any terms, as appropriate. Glossary Include any pertinent, unfamiliar or confusing terms in the glossary. Refer to
the Glossary (RD.042). You may decide to incorporate the Glossary (RD.042)
in total or in part as part of this work product.
6 List any outstanding issues identified while authoring and
publishing this manual and record the resolution of each issue.
Open/Closed
Issues

7 Review the preliminary User Reference Manual for consistency.
Make corrections as necessary. Publish a preliminary version of
the manual.

8 Make a preliminary version of the manual available to system
testers.

9 Receive documentation feedback from testers. Make corrections to
the User Reference Manual.

10 Publish the latest version of the User Reference Manual.
11 Secure acceptance of the User Reference Manual. Acceptance
Certificate

(PJM.SM.040)
Back to Top
APPROACH
Use the User Reference Manual to explain to users in functional terms how the custom software and any application extensions work. This task should be executed in
parallel with Perform Unit Test (TE.030) and Perform Use Case Test (TE.040). Review and update the User Reference Manual as each round of unit and use case
testing is completed for the custom software or the application extensions.
The initial information for building the User Reference Manual comes from the Use Case Specification (RA.024), which defines the custom software and application
extensions in functional terms and the Designed Classes, which include the actual design.
When preparing material for the User Reference Manual, remember that writing the manual is an iterative task and that the quality of the manual improves with each
successive round of testing. Although a preliminary User Reference Manual is available for testers to use, testers are encouraged to give constructive feedback to the
technical writers. Sometimes changes are introduced into the software components as a result of testing or functional review. After feedback comments are analyzed,
new information can be updated in the User Reference Manual.
It is important to edit each initial chapter thoroughly and verify that the sections are written with a similar style and tone, and that errors are revealed before they are
perpetuated. Even if the task involves only a single writer, you may want to engage a professional technical writer to edit several of the initial chapters. One of the last
steps is to read the entire User Reference Manual to find and correct inconsistencies. Once these corrections have been made, you can prepare to transfer ownership of
the document to the users by formatting the User Reference Manual as required. You may be required to publish your documents in HTML format to make them available
via the intranet.
During Transition, use the Finalize Documentation task to catch any last minute changes and finalize the User Reference Manual.
Planning
If you directly involve developers, this task can be executed more quickly. If you plan to use multiple technical writers, it is important to schedule time to review and edit
sections soon after they are written. This helps make sure that errors are not repeated in multiple sections.
Include the task of reviewing and revising previous versions of the User Reference Manual directly in the procedures for completing the module test of primary modules.
The developers who were involved in detailed design should do the initial review to incorporate additions and identify errors. Technical writers should do the final review
and edit.
Back to Top
Back to Top
Technical Writer Write, edit, and review the User Reference Manual. 80
Business Analyst Assist with content for the User Reference Manual. 20
Back to Top
PREREQUISITES
Prerequisite Usage
Glossary (RD.042.3) You may want to include some or all of the terms in the Glossary in the User Reference Manual Glossary.
Use Case Specification (RA.024.2) The Use Case Specification defines the custom software and application extensions in functional terms.
Data Design (DS.090.2) The Data Design is used to see the actual design that should be documented. The work product contains the design of the
classes, including boundary classes, entity classes, and control classes. The boundary classes represent the classes to
which the end user will interact, such as screens and reports, while the control classes represent the control, or flow
allowed, and the entity classes represent how data will be stored and accessed.
Behavior Design (DS.100.2) The Behavior Design consists of the previously-defined Use Case Specifications and Analysis Specification updated to
reflect the interaction of the components in each scenario. This complements and supplements the diagrams and models
created in the Architecture Description and Analysis Specification to better explain them.
Strategy (DO.010)
The Documentation Requirements and Strategy specify the overall requirements for creating documentation and the work
products to be produced.
Procedures (DO.020)
Follow these development and editorial standards when writing the User Reference Manual chapters.
Documentation Environment (DO.040) Once the Documentation Environment is set up, the User Reference Manual can be created.
Back to Top
TEMPLATES AND TOOLS
DO-060_USER_REFERENCE_MANUAL.DOC MS WORD
Back to Top
The User Reference Manual is used in the following ways:
to provide relevant functional information to the user community
to show the users how the new software will implement the required custom functionality (use the preliminary versions of the User Reference Manual)
for Oracle Applications extensions, to show users how the application extensions enhance standard Oracle Applications functionality (use the preliminary versions)
Once all system testing (TE) is complete, publish a final version of the User Reference Manual. to provide users with final functional information.
A user should be able to reference any topic, screen, or report that is available in the production system. The final version of the User Reference Manual should include all
changes that were made during unit and integration testing.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this deliverable:
Is the material free from technical inaccuracies?
Is the material free from business inaccuracies?
Does the material adhere to Documentation Standards and Procedures?
Is the information appropriate for the target audience?
Back to Top
DO.070 - PUBLISH USER GUIDE
In this task, you publish a User Guide that defines a set of detailed procedures for using the applications.
Suggestion: If your organization must meet compliance requirements, such as Sarbanes-Oxley, this task can be helpful in achieving such compliance.
During the Transition phase, you will have an opportunity to review all implemented system changes and system defects for any impact on the User Guide and finalize this
work product.
For projects that involve the upgrade of Oracle products, this task is used to update the clients existing User Guide so that they correctly reflect the new features and
processes available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
User Guide - This guide describes each business procedure and provides detailed instructions for using the applications in response to day-to-day business events.
Back to Top
TASK STEPS
1 Compile and review the Use Case Specifications (RA.024.2), Future Process
Model (RD.011), Business Procedure Documentation (RA.055) and other
documentation which describe the usage of the system.

2 Write the front material and introductions to the chapters. Title Page
Preface
Contents
Chapters
The Preface identifies how the User Guide is organized.
The Contents provide a format for the table of contents.
The Chapters provide boilerplate text that can be used to format
each chapter.
3 For each application extension, write a topical essay that explains how to use
the new application extension functionality.
Topical Essay This component provides information about the scope, approach, and
methods of the User Guide.
4 Add any appendices, as needed. Appendices This component provides an outline for creating an appendix.
5 Define any terms, as appropriate. Glossary Include any pertinent, unfamiliar or confusing terms in the glossary.
Refer to the Glossary (RD.042). You may decide to incorporate the
Glossary in total or in part as part of this work product.
6 List any outstanding issues identified while authoring and publishing the User
Guide and record the resolution of each issue.
Open/Closed
Issues

7 Review the User Guide for consistency and make necessary corrections.
Publish a preliminary version of the guide.

8 Make a preliminary version of the manual available to system testers.
9 Receive documentation feedback from testers. Make corrections to the User
Guide.

10 Publish the latest version of the User Guide. This may include publishing the
document in HTML format.

11 Secure acceptance of the User Guide. Acceptance
Certificate
(PJM.SM.040)

Back to Top
APPROACH
Use the User Guide to support the day-to-day usage of the new system. It describes each business procedure and highlights any system-specific uses of screens and
reports. The User Guide introduces the user to the purpose of procedures (such as Create a Standard Customer Invoice) and then explains the detailed steps and
options needed to perform the business task or transactions.
The User Guide may simply be a compilation of all the updated Oracle Tutor Procedures developed.
Develop and update the User Guide in parallel with the system testing (TE.070). As business system test scenarios are executed, the team should review the
corresponding section of the User Guide for accuracy.
While creating the User Guide, actively involve the users (especially if they have not participated in creating the initial draft). The ongoing success of the application
system depends a great deal on the users ability to follow the correct procedures in response to business events without the assistance of the project team.
Revisit the front matter of the User Guide for possible revisions. Create an index for the document if it is specified in the Documentation Requirements and Strategy
(DO.010). Prepare to transfer ownership of the document to the users by formatting the User Guide as required.
The writer should assemble all relevant documents, flow charts, and Business Procedure Documentation prior to writing the guide. Especially for application
implementations, the Future Process Model (RD.011), and Business Procedure Documentation (RA.055) are useful inputs.
When preparing the User Guide, there are several points to remember:
Project documentation should be brief and concise.
The tone of the documentation should be simple and straightforward, rather than academic or technical.
Anticipate questions that the user may ask regarding a procedure, and answer them. As you document these procedures, compare the current and future approach
and add more detailed explanations to the areas that may be confusing to a user.
Write the documentation to the level of the targeted audience. If you are documenting a technical process, include technical details; if you are documenting a
business process, only include technical details if they are necessary to convey a concept.
Use diagrams and charts to explain broad or complex concepts. For example, a paragraph containing many conditions may be more easily understood when the
information is presented in a table or chart.
It may be appropriate to refer the reader to another section or document for more information on a subject. Create a symbol or wording style that can be used consistently
to identify references and verify that these references remain accurate as the documentation evolves.
Attention: When assembling the User Guide, consider including the following:
preface
table of contents
introduction
procedures
graphs or illustrations of the process
glossary of terms
indexes
management override (optional)
controls and mechanisms that are required at each business process stop
The User Guide helps you provide the user community with documentation that reflects all aspects of the business and not just the areas that require system usage.
Incorporate customizations into the procedures. Remember that users typically do not distinguish between standard and custom modules. The following list identifies
some of the basic information to include in the User Guide:
pictures of forms and reports, preferably with data recognizable to the reader
the input of information or materials to process
the source of input of information or materials
explanation of standard system, custom, and manual processes
step-by-step procedures
description of exception cases
reversals of any manual or system transactions
how to complete the procedure
how to review the transaction
how transactions are reported
how to navigate to the system through menus
how to correct mistakes and reverse undesirable actions
During Transition, use the Finalize Documentation task (DO.110) to catch any last minute changes and finalize the User Guide.
Planning
If you are using multiple technical writers, it is important to schedule time to review and edit sections soon after they are written. This helps make sure that information is
fresh and errors are not repeated in multiple sections. You should include the task of reviewing and revising previous versions of the User Guide directly in the
procedures for completing the business system test scenarios.
Back to Top
Back to Top
Technical Writer Design, gather material, organize, write, edit, and review the User Guide. Revise sections of the User Guide (DO.070) based
on system test scenarios.
80
Business Analyst Assist with content for the User Guide. 10
System Architect 10
Back to Top
PREREQUISITES
Prerequisite Usage
Glossary (RD.042.3) You may want to include some or all of the terms in the Glossary in the User Guide Glossary.
Use Case Specifications (RA.024.1) The Use Case Specifications include scenarios which describe the functionality of the system.
Installation Plan (TS.030)
Documentation Requirements and Strategy
(DO.010)
Refer to the Documentation Requirements and Strategy for an outline of the overall requirements for creating
documentation and a listing of the specific work products to be produced.
(DO.020)
Follow these development and editorial standards when writing the chapters of the User Guide.
Documentation Environment (DO.040) The Documentation Environment includes the hardware and software used to prepare project documentation.
(RA.055)
These work products define the future business processes.
Back to Top
TEMPLATES AND TOOLS
DO-
070_USER_GUIDE.DOC
MS WORD - Many of the recommended User Guide sections are not included in the template. You need to create most of the material
manually using the standard styles supported by the template.
Suggestion: Divide your User Guide into chapters using multiple chapter components.
The styles used in the template are consistent with the standards used in all Oracle user documentation. If you have customized the User
Guide template, use the customized template for this task.
Tool Comments
processes.
Back to Top
The User Guide is used in the following ways:
to document the day-to-day procedures for using the new system - These procedures are responses to day-to-day business events.
to provide learning content and a comprehensive source for answering daily procedural questions for new users
Back to Top
QUALITY CRITERIA
Back to Top
DO.080 - PUBLISH TECHNICAL REFERENCE MATERIAL
In this task, you assemble the Technical Reference Material for the custom software.
During the Transition phase, you will have an opportunity to review all implemented system changes and system defects for any impact on the Technical Reference
Material and finalize this work product.
In a commercial off-the-shelf (COTS) application implementation, this manual is intended to be a supplement to the Oracle COTS application product technical reference
manuals and other technical documentation. These materials are usually consistent in format and content with Oracle documentation standards. The size of this task
depends on the extent of the technical changes that were made to support the new applications.
For projects that involve the upgrade of Oracle products, this task is used to update the clients existing Technical Reference Material so that they correctly reflect the
technical features that are available within the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Technical Reference Material - The Technical Reference Material includes technical details of the application for the information technology maintenance staff. For
projects including Oracle Applications products, the Technical Reference Material provides technical information regarding application extensions and interfaces. It should
address the following:
module descriptions
new or updated seed data
descriptive flexfields (for Oracle Applications projects)
value sets (for Oracle Applications projects)
profile options
grants and synonyms
installation and upgrade
archiving
database diagram
tables, indexes, and sequences
system performance issues
glossary of unique terms
Back to Top
TASK STEPS
1 Review the Architectural Design Description, the Database
Design, the Use Case Realizations and other available
technical materials on the software.

2 Interview system architects.
3 Compile the Technical Reference Material based upon the
requirements of the Documentation Requirements and
Strategy (DO.010)
Contents
Chapters
Appendices
The Contents component provides a format for the table of contents.
The Chapters component provides boilerplate text that can be used to format each
chapter.
The Appendices component provides an outline for creating an appendix.
4 Define any terms, as appropriate. Glossary Include any pertinent, unfamiliar or confusing terms in the glossary. Refer to the
Glossary (RD.042). You may decide to incorporate the Glossary (RD.042) in total
or in part as part of this work product.
5 List any outstanding issues identified while authoring and Open/Closed
publishing the Technical Reference Material and record the
resolution of each issue.
Issues
6 Review the Technical Reference Material for consistency and
make necessary corrections. Publish a preliminary version of
the guide.

7 Make a preliminary version of the material available to system
testers.

8 Receive documentation feedback from testers. Make
corrections to the Technical Reference Material.

9 Publish the latest version of the Technical Reference Material.
This may include publishing the document in HTML format.

10 Secure acceptance of the Technical Reference Material. Acceptance
Certificate
(PJM.SM.040)

Back to Top
APPROACH
The Technical Reference Material brings together and organizes the technical documentation prepared for the custom software.
Developers may have implemented technical changes in the system without updating the appropriate design and build documents. In order to locate all relevant technical
information, you may want to interview the system architects and developers as well as review change control forms, specification updates, or memos relating to
technical issues.
In addition, update the Technical Reference Documentation to include changes made to the software as a result of Perform Unit Test (TE.030) and Perform Integration
Test (TE.040).
The most important step in this task is to understand the requirements for the Technical Reference Material. The Documentation Requirements and Strategy (DO.010)
should clearly state what is included in the Technical Reference Material and describe how the document is to be used. You determine the contents of the document
based on this information.
Assemble the following relevant technical material and designs that are being implemented):
software architecture descriptions
database designs
use case realizations
Compile these documents in a logical format and add any written material needed to guide the user through the manual.
To perform this task, you need a technical writer who understands technical design issues (or alternatively, a system architect who writes well).
During Transition, use the Finalize Documentation task to catch any last minute changes and finalize the Technical Reference Material.
Planning
If multiple technical writers are used, it is important to schedule time to review and edit sections soon after they are written. This helps make sure that the information is
fresh and errors are not repeated in multiple sections.
Back to Top
Back to Top
Technical Writer Gather, organize, edit, and review the Technical Reference Material. 70
Developer Provide assistance in verifying the documentation is correct and complete. Provide material for the Technical Reference
Material (DO.080).
10
System Architect Provide assistance in verifying the documentation is correct and complete. Provide material for the Technical Reference
Material (DO.080).
20
Back to Top
PREREQUISITES
Prerequisite Usage
Glossary (RD.042.3) You may want to include some or all of the terms in the Glossary in the Glossary component.
Architecture Description (RD.130)
Logical Database Design (DS.150) The Logical Database Design includes the tables, indexes, views, and sequences for the application
Reviewed Design Model (DS.160) Obtain final signoff of completed designs prior to producing the Technical Reference Manual.
Documentation Requirements and Strategy
(DO.010)
The Documentation Requirements and Strategy state what the user expects of the technical documentation.
(DO.020)
Follow the documentation standards and development procedures when writing the Technical Reference
Manual.
Documentation Environment (DO.040) The Documentation Environment provides an installed environment for developing documentation.
Back to Top
TEMPLATES AND TOOLS
DO-
080_TECHNICAL_REFERENCE_MATERIAL.DOC
MS WORD - This template provides documentation styles similar to the styles used in the Oracle Applications
Technical Reference Manuals.
Back to Top
The Technical Reference Material is used in the following ways:
to describe the custom modules and extensions that are developed during Implementation (IM)
to provide technical information regarding the custom modules and extensions - This information is helpful later when the maintenance staff updates the
application.
Back to Top
QUALITY CRITERIA
Back to Top
DO.100 - PRODUCE ONLINE HELP
In this optional task, you create the online help text files for the user interface modules developed during implementation of the system. The strategy for Online Help
should have been defined in the Architecture Description (DS.040), the Documentation Requirements and Strategy (DO.010), and the Documentation Standards and
Procedures (DO.020).
During the Transition phase, you will have an opportunity to review all implemented system changes and system defects for any impact on the Online Help and finalize
this work product.
For projects that involve the upgrade of Oracle products, the standard Oracle supplied online help files will usually be updated during the automated upgrade process.
However, if the client has created any custom online help files, this task can be used to update those files to match the features and functions of the new release.
ACTIVITY
Back to Top
WORK PRODUCT
Online Help - Online Help is the text help files for the application, including references from online modules to batch/reporting modules. Online Help may include page
level help, block level help, field level help, hint text, and other text.
Back to Top
TASK STEPS
1 Review the requirements for online help text in the Documentation Requirements and
Strategy (DO.010)

2 Use the content from the User Guide (DO.070) and the User Reference Manual
(DO.060) to develop the online help text according to the Documentation Standards
and Procedures (DO.020)
Online Help
Text Files
This component consists of the help files for the
application, including references from online modules to
batch/reporting modules.
3 Distribute the online help text for review
4 Identify any open issues, and work to resolve them
5 Link the online help text into the Tested Software subsystems
6 Incorporate the online help text files into the software configuration management
baseline.

7 Secure acceptance of the Online Help. Acceptance
Certificate
(PJM.SM.050)

Back to Top
APPROACH
Review the Documentation Requirements and Strategy (DO.010) and the Documentation Standards and Procedures (DO.020). Usually online help text will be developed
for all significant user interfaces.
This online help text may include:
page level help
block level help
field level help
hint text error message help
a searchable online help system
a glossary
The User Guide (DO.070) and the User Reference Manual (DO.060) will usually contain most of the source text needed for the online help text. Whenever possible, the
online help text should be generated from sections of those manuals using automated tools.
Once the online help text has been created, it should be reviewed by the ambassador users, and then officially accepted.
Back to Top
Developer Provide assistance generating Online Help from the User Guide (DO.070) and the User Reference Manual (DO.060). 30
Technical Writer Generate or develop the Online Help from the User Guide (DO.070) and the User Reference Manual (DO.060). 70
Ambassador Users Review the Online Help and provide feedback.
Client Project Manager Review the Online Help and provide feedback. *
*
Back to Top
PREREQUISITES
Prerequisite Usage
Assembled Components (IM.070) This is the software to which the the Online Help is to be linked.
Documentation Requirements and Strategy (DO.010)
Documentation Standards and Procedures (DO.020)
User Reference Manual (DO.060) This manual contains the technical source references for the developed software.
User Guide (DO.070) This guide contains the user source references for the developed software.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
processes.
Use an automated tool to generate Help Text from the User Guide (DO.070) and the User Reference Manual (DO.060).
Back to Top
Online Help is used in the following ways:
as a reference when using the system
as a reference for future enhancement of the system
Distribute Online Help as follows:
to the configuration management software management tool for control
to the users for future reference
Back to Top
QUALITY CRITERIA
Does the material adhere to Documentation Standards?
Back to Top
DO.110 - FINALIZE DOCUMENTATION
All of the documentation work products should be completed by the end of the Construction phase. However during the Transition phase, minor revisions or changes to
the software system may cause updates to any or all of the documentation work products. This task covers the incorporation of any of those changes into the
Documentation work products.
ACTIVITY
D.ACT.FD Finalize Documentation
Back to Top
WORK PRODUCT
Final Documentation Work Products - This task may create a revised version of any of the Documentation work products including:
User Guide (DO.070)
Back to Top
TASK STEPS
Component
Description
1 Review system changes in the Change Request Log and system defects for impact on any of the
documentation work products.

2 If necessary, consult the developer or architect on the required documentation change
3 Update the affected documentation work products to reflect the system changes and defects from the
Transition phase.

4 Re-issue the revised documentation work products
5 Secure acceptance of the revised documentation work products Acceptance Certificate
(PJM.SM.050)

Back to Top
APPROACH
During the Transition Phase, review all implemented system changes and system defects for any impact on the Documentation work products.
When required, Documentation changes are identified as follows:
1. when necessary, consult the developer or architecture on the required change
2. update the affected document, and log the change in the document's change history section.
3. re-issue the revised document and include it into the project's baseline.
This task may create a revised version of any of the Documentation work products including:
User Guide (DO.070)
In each revised document, create an entry in the document's change log specifically listing the revision made to the document.
Back to Top
Back to Top
Technical Writer Update Documentation work products. 50
Developer Provide any updates for Documentation work products. 25
System Architect Provide any updates for Documentation work products. 25
Back to Top
PREREQUISITES
Prerequisite Usage
Approved Project Change Requests (PJM.SM.030) These are the source of documentation revisions for this task.
Corrected System Issues and Problems from QA
(PJM.IPM.030)
These are the source of documentation revisions for this task.
User Reference Manual (DO.060) This manual shows users what custom software functionality was developed and how to use that
functionality. For Oracle applications projects, it also shows users how application extensions enhance
standard Oracle Applications functionality.
User Guide (DO.070) This guide describes each business procedure and provides detailed instructions for using the applications
in response to day-to-day business events.
Technical Reference Material (DO.080) This material includes the technical details of the application for the information technology maintenance
staff. For projects including Oracle Applications products, the Technical Reference Material provides
technical information regarding application extensions and interfaces.
Online Help (DO.100) The Online Help is help files for the application, including references from online modules to
batch/reporting modules. Help text may include page level help, block level help, field level help, hint text,
and other text.
Back to Top
TEMPLATES AND TOOLS
As necessary, revise the following previously created work products:
User Guide (DO.070)
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
[OCM] ORGANIZATIONAL CHANGE MANAGEMENT
Enterprises are increasingly recognizing that adequately preparing their people for a major technological change can make the difference between the success and failure
of a project. However, they dont always have the capabilities to adequately manage the transition from the old to new systems.
needs. In addition to increasing user adoption rates, carefully planning for and managing change in this way allows organizations to maintain productivity throughout
potentially difficult technological transitions. Furthermore, it enables the organization to more easily meet deadlines, realize business objectives, and maximize return on
investment.
In OUM, Organizational Change Management begins at the enterprise level during an Envision project, where many projects across the IT Portfolio are being examined
and planned. There are enterprise stakeholders that need to be identified prior to implementation project start-up. By beginning at the enterprise level, and then
continuing on through each Implementation project, Organizational Change Management supports the organizational move to utilize the new technology, and solutions
that are put in place to support the business of the enterprise.
The Organizational Change Management process increases the probability that the technology implementation will be successful, first by getting executive commitment
and anticipating the human and organizational challenges and then by creating a strategy that is aligned with the organizations culture to help managers and users
accept the new or updated technology. The Organizational Change Management process helps better manage the "soft side" of the implementation by:
identifying and mitigating risks
generating change momentum
fostering effective communication
preparing managers and end users for the new processes, roles and responsibilities
supporting end-user acceptance
The Organizational Change Management process helps to decrease transition time, meet deadlines, meet business objectives and stay within project timeframes.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
The nature of the OUM approach, often requiring a significant change in the implementing organizations business processes and coupled with the rapid implementation
timelines, increases the importance of the Organizational Change Management process.
Change management is action oriented to anticipate risks and to manage them, rather than resolve them in a crisis situation or after resistance has become entrenched.
It is a well-known fact that when users and managers are involved in the change planning, the less likely there will be resistance during the transition. In addition, change
can be managed, and the earlier this happens, the greater the opportunity for success. Organizational Change Management activities should begin early in a project and
help maintain client accountability for the change, ensuring that the client remains involved that can help reduce any barriers to the new application system. To this end, a
considerable number of change management activities are designed to involve both executives (executive and/or steering committee) and managers in supporting the
change effort. Oracle's Organizational Change Management leading practices also address communication and adoption strategies to help build momentum and reduce
potential resistance.
Organization Change Management focuses on addressing the human and organizational factors and aligning them to minimize the implementation risk and optimize
system performance from a human perspective. Organizational Change Management increases stakeholder commitment to the new technology and resulting changes
and builds support for the implementation by informing, involving, and including stakeholders throughout the process. Organization Change Management includes the
following benefits for the organization:
Identifies organizational issues that will either lengthen the implementation or harm it and overcomes those barriers
Improves organizational knowledge and skills for the new environment, as well as organizational effectiveness during implementation
Realizes projected benefits by focusing on post-implementation issues like user acceptance, productivity, and human performance support
Change Management Roadmap and Communication Campaign
Organizational Change Management is action oriented to anticipate risks and to manage them, rather than resolve them in a crisis situation, or after resistance has
become entrenched.
A large part of Organizational Change Management is organizing change and communication activities for specific target populations from the executive level to the end-
user level to mitigate specific issues and challenges (risks). All these activities and the associated details are organized in the Change Management Roadmap and the
Communication Campaign. The Change Management Roadmap and the 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. The activities in the Change Management Roadmap and the Communication Campaign are conducted at established milestones during the
project and are aligned with the overall project deployment schedule.
Impacts on Various Audiences
Organizational Change Management impacts the following five major audiences:
Executives
Implementation Project Teams
Functional Managers
End Users
Information Technology Groups
Each of these audiences has a stake in the expected performance of the new system and can impact the success of the implementation. However, the audiences are not
mutually exclusive. For example, functional managers or members of the information technology groups may be users and also members of the implementation project
team.
Executives - Advocate Successful Change
The tasks targeted for executives consist of a facilitated Executive Alignment Workshop and a Sponsorship Program. The workshop assists executives to effectively
develop strategies for the successful execution of the enterprise-wide implementation and the management of implementation risks. A Sponsorship Program is put in
place to identify the best executives to address specific organizational challenges and coach them in mechanisms, activities and communications in order to remain
aligned throughout the project. Its goal is to mitigate risks and get management aligned behind the change. By participating in these tasks, executives have the ability to:
understand the role they are to play in the implementation, as well as the time commitment and energy required for that role
understand the benefits the implementation provides to their business, as well as the costs and timeframes
comprehend the barriers to success, based on experience with a number of similar implementations
make timely and informed project startup decisions
initiate a sponsorship network to sustain the momentum of the project
Implementation Project Team - Give the Team a Jump Start
The tasks targeted for the project team include Team-Building Workshop with a series of activities, processes, tools, and learning events to quickly orient the
implementation team to the project. Project team members acquire the skills they need to function as a team, and to represent the project to the rest of the organization.
By participating in the Team-Building Workshop, the project team has the ability to:
become a high-performance team from the onset, reducing startup time and costs
establish appropriate Project Team Rules
function as a more cohesive working group throughout the life of the implementation
Functional Managers - Create a Stepladder for Performance
Functional managers learn how the technology impacts their work groups processes and procedures. They are provided with tools to assume their role as change
leaders, and with learning events to acquire necessary application skills. They define newly required roles, competencies, and performance support and contribute to the
improvement of the workflows to take advantage of the new technology and to manage to new performance expectations. By participating in the Organizational Change
Management activities, the managers have the ability to:
develop a reasonable expectation of the benefits the implementation provides to their business units
increase performance through more effective change leadership
design optimal job roles to meet business objectives
develop new organizational structures to help maximize productivity
define recognition and rewards to encourage user performance in their new roles and responsibilities
End Users - Achieve Business Performance
Through a series of change and communication events, users acquire the skill and the motivation to perform their new role using the full potential of the technology. This
includes the procedural, functional, and technical proficiencies users need to achieve their new performance expectations. By participating in the Organizational Change
Management activities, users have the ability to:
become involved in the definition of application and business requirements
participate in just-in-time learning and receive performance reinforcement
increase their acceptance and effective use of the system
create a post-implementation environment to facilitate productivity
Information Technology Groups - Sustain Technical Gains
The tasks targeted to the information technology community provide the right skills base to enable ongoing technical support to users after the implementation and
leverage business and technical system capabilities. It includes certification paths and retention strategies for the information technology population. By participating in
the Organizational Change Management activities, the information technology groups have the ability to:
smoothly transition from implementation to on-going technical performance
develop proficiency for ongoing system improvement, furthering technical performance gains
Back to Top
Envision
Initiate Phase
EOCM.050 Assess Enterprise Change Readiness Preliminary Enterprise Change Readiness Assessment
Implement
Inception Phase
Elaboration Phase
OCM.155.1
Effectiveness
Assessment
Construction Phase
OCM.155.2
Effectiveness
Assessment
Transition Phase
OCM.155.3
Effectiveness
Assessment
Production Phase
OCM.155.4
Effectiveness
Assessment
Back to Top
OBJECTIVES
The objectives of the Organizational Change Management process are:
Establish executive sponsorship and management advocacy.
Align business objectives and technology capabilities throughout the organization.
Increase stakeholder commitment to the new technology and resulting changes; build support for the implementation by informing, involving and including
stakeholders throughout the process.
Accelerate the implementation project team's ability to work together through team building and organization-specific application learning.
Determine human performance support implications so that the organizational structures and job roles align to meet new performance expectations resulting from
the technology change.
Create a user-friendly environment for learning about the new technology by developing learning and performance strategies and plans that promote the optimum
performance of users on the new system.
Optimize the information technology groups infrastructure to help ensure the ongoing support of the applications (including ongoing learning and certification plans
so that information technology employees can continuously optimize system functionality to meet business needs).
Establish a measurement system that provides an evaluation of organizational performance to determine whether expectations were met during implementation
and after production cutover.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
BA Business Analyst Assist with Job Impact Analysis activity.
Specialist
The change management specialist provides the client with experience with leading practices in the human and organizational facets
of change management. Change management specialists support the Organizational Change Management (OCM) process by
identifying and mitigating risks, generating change momentum, fostering effective communication, and supporting end-user
acceptance. The change management specialist works directly with executives to gain their commitment and put in place a project
governance model.
PM Project Manager Participate in definition and maintenance of an optimal project environment. Support events to help the project team function as a
TS Training Specialist Assist with Job Impact Analysis activity. Assist with Training Needs Analysis.
Client (User)
CAT Client Assessment Team Gather and analyze assessment data.
CIO Client Chief Information
Officer
Provide input for IT Alignment activities.
CCML Client Change
Management Lead
Assist with the Change Agent Workshop. Assist with gathering and analyzing assessment data.
CCS Client Communication
Specialist
Work with the Change Management Communication Specialist on all communication tasks.
CE Client Executive Participate in Executive Alignment Workshop. Participate in change and communication events.
CFS Client Functional
Specialist
Provide functional expertise.
CHRS Client HR Specialist Work with the Change Management Organizational Development Specialist and Change Management Human Performance
Specialist on Job Impact Analysis and IT Alignment activities.
CITD Client IT Director Assist with IT Alignment activities.
CPM Client Project Manager Participate in definition and maintenance of an optimal project environment. Support events to help the project team function as a
CPS Client Project Sponsor Communicate publicly and privately on change initiatives. Provide resources for change management activities. Remove barriers
identified by the change management team. Serve as a role model. Make decisions or see to it that they get made to assist in the
change management work products. Build coalitions. Manage risks.
Back to Top
definition of clear and realistic business expectations and organizational performance measures for the project
availability of the organizations stakeholders to participate fully in readiness tasks
provisions made for workload while project team members participate in readiness tasks
inclusion of key stakeholder constituencies in the change process and clear description of project impact and benefits
visible support and participation of key leaders and sponsors throughout the impacted business units
mechanism to listen and respond to top concerns about the new systems
early establishment of ongoing communication and feedback/evaluation mechanisms that fit the organizational environment
Back to Top
OCM.010 - CREATE AND MANAGE AD HOC COMMUNICATIONS
Ad Hoc Communications are utilized in the initial stages of a project before the Change Readiness Assessment takes place and the Change Management Roadmap and
the Communication Campaign have been created. They respond to the stakeholders' need for information and the reality that the project is underway. Ad Hoc
Communications lowers the risk of rumors and negative perceptions about the project and organizes the communication. This task is used at the enterprise level when it
is necessary to communicate that an enterprise-level project is underway or to assess technology alternatives and how they apply to potential projects as well as existing
projects in the IT Portfolio
In this task, you assess the project communication needs and make recommendations regarding which ad hoc communication activities are appropriate and then
implement those activities. The need for Ad Hoc Communications during an enterprise-level project will depend on communication and agreement between the
implementing organization's Sales team and technology specialists and the client.
ACTIVITY
A.ACT.CMAHC Create and Manage Ad Hoc Communications
Back to Top
WORK PRODUCT
Ad Hoc Communications - Ad Hoc Communications are initial project communication activities that can facilitate the first communications quickly and professionally.
Back to Top
TASK STEPS
1 Detail the Communication
Structure for the project.
Internal
Communication
Channel Audit
Communication
Strategy
Communication
Approval Process
Grid
The Internal Communication Channel Audit identifies and records in spreadsheet format all communication
channels currently in use in the client organization, their frequency, person responsible and audience.
This section describes the initial Project Communication Strategy as well as the overall Communication Strategy
for the enterprise.
The Communication Approval Process Grid clarifies the approval process that all communications must go
through before being released.
2 Select appropriate Ad Hoc
Communications
Ad Hoc
Communications
Select from the standard types of Ad Hoc Communications those that are appropriate for the project.
3 Implement Ad Hoc
Communications
Ad Hoc
Communications
Back to Top
APPROACH
The Ad Hoc Communications are the first initiative of the project communications. It demonstrates that the project is well organized by having the first communication
ready for the project start. It also manages the project kickoff and delivers the first key messages from the project sponsor and key leaders of the project. The Ad Hoc
Communications consist of a series of key communication events, well known for their efficiency in the project start up (for example, launched newsletter, project
presentation that the core project team can use, kickoff event read).
The purpose of the Ad Hoc Communications is to manage the initial communication needs of the stakeholders for information that the project is real and that it is
underway. These communication initiatives lower the risks of rumors and potential negative perceptions about the project due to possible political challenges. These
communication activities start on day one of the project and end when the full Communication Strategy and Change Management Roadmap (OCM.130) and the
Communication Campaign (OCM.140) are created in the Implement Inception phase. Therefore, the Ad Hoc Communications could span many weeks.
Detail the Communication Structure
Before selecting the appropriate Ad Hoc Communications for the project, detail the Communication Structure. This information will assist you in selecting the appropriate
Ad Hoc Communications. The Communication Structure consists of the following:
INTERNAL COMMUNICATION CHANNEL AUDIT
The Internal Channel Communication Audit identifies and records in spreadsheet format all communication channels currently in use in the client organization, their
frequency, person responsible and audience.
Capture the communication culture and the most efficient mediums in the organization. Provide information on the key players who are managing the internal
communications and the approval process for the communications. Finally, integrate the project communication structure that we usually see during an implementation
(for example, the communication channels with the steering committee, project team members, etc.). All the Ad Hoc Communications will be integrated in the Change
Management Roadmap (OCM.130) to capture the build up of the communication and avoid any duplication.
PROJECT COMMUNICATION STRATEGY
The Project Communication Strategy is a high-level description of how communication will be utilized in the project. It leverages the clients mediums and communication
culture. The Project Communication Strategy is also a topic covered during the Executive Alignment Workshop (OCM.030). Therefore, for consistency, work together on
these tasks, especially if different change management specialists are are involved.
The Project Communication Strategy is the link between all work products and describes how people will be kept informed about the project. It is reviewed based on the
Change Readiness Assessment findings. The strategy follows the client culture and considers target groups/ audiences/stakeholders impacted by the change. It is based
on the involvement of key players including executive leaders, supervisors, communications liaisons, etc.). The strategy (and the Communication Campaign which is
created later) reflects the phases of the project and is aligned with project milestones.
COMMUNICATION APPROVAL PROCESS GRID
The Communication Approval Process Grid clarifies the approval process all project communications must go through before being released. It is crucial to capture the
approval process to avoid any political problems. This process also follows the leadership structure. You need to get an official approval for each step and document the
approval with emails.
The grid captures the leaders and subject matter experts who need to review communication before it is released to the intended audiences. Following the approval
process will also ensure that all subject matter experts and affected areas agree with the information that will be released to ensure that there are no surprises when
communications are published. Adequate time should be built into the communication timeline to allow for all necessary approvals.
Select Ad Hoc Communications
Ad hoc communications can take many forms. The important thing is that communication needs to start as soon as possible to ensure that the audience will receive
accurate information right away, setting the stage for successful change management.
Select from the standard types of Ad Hoc Communications those that are appropriate for the project. The following table contains the some typical types of Ad Hoc
Communications. This list is not all-inclusive. There may be other types of Ad Hoc Communications that you decide to use. You may also decide not to use any of these
Ad Hoc Communications.
Ad Hoc Communication Description
Kick-Off Newsletter Newsletters are internal news bulletins that periodically inform stakeholders on the project's progress. They serve as the official
communication link with the project team. Newsletters give background information on the project and help stakeholders prepare for the
change gradually. Topics include: the Project Background, Vision and Objectives, Training, Important Dates, How to Prepare for the
Change, etc. Create the first issue of the newsletter, the Project Kick-Off Newsletter for the Ad Hoc Communications.
Intranet Site The Project Intranet Site is highly interactive and contains the most up-to-date information about the project. It can store a wide range of
communication tools using various formats such as Official Presentations (PowerPoint), Newsletters (Adobe), White Papers (Word),
Charts (Visio), etc. The site is usually accessible via the organizations intranet site. This communication channel promotes two-way
communication by linking stakeholders to the project teams e-mail address or a centralized address for comments and questions.
Project Calendar The Project Calendar can take a variety of forms including the traditional monthly calendar format, or more graphic representations like a
mountain or path that represents the project's timeline with milestones illustrated with stars or dots. To get more visibility, calendars are
often printed in poster size.
E-Mails E-mails are used to communicate project-related information to stakeholders and are often employed in the initial project stage prior to the
formation of the Communication Campaign. The advantage of using this channel is that it can reach a vast group of stakeholders quickly
and simultaneously. E-mails can be used to announce important news or to give regular updates on the project.
FAQ Sheet Frequently Asked Questions is a document that addresses stakeholders key questions and concerns about the project. FAQs are
frequently updated to follow the projects evolution and can also be created for specific events later in the project such as Readiness
Assessments or Training.
Glossary of Terms and
Acronyms
A Glossary is a document that clarifies specific project-related terms. It is usually distributed/posted at the beginning of a project to
provide stakeholders with the knowledge they need to follow project-related communications. The glossary and acronym list are updated
as the project evolves.
Project Overview
Presentation
The Overview is a PowerPoint Presentation that explains the project at a high level, answering the 5Ws: What? Where? When? Who?
How? Topics discussed include the project timeline and scope, rationale, project vision and objectives, training strategy, etc.
Naming Contest and
Collateral
Provide advice and best practice on branding the project and producing branding collateral. Material includes naming contest steps,
posters, email content, flyers and logo samples.
Implement Ad Hoc Communications
closely with the project manager on Ad Hoc Communication activities. The change management specialist provides guidance on leading change management practices
and direction for project change management activities. The project manager promotes cooperation, provides input and validates work products. Together, the change
management specialist and project manager determine and document responsibilities for project team vs. organizational communications as soon as possible in order to
eliminate any confusion as the project progresses. This collaboration facilitates the agreed upon Ad Hoc Communications for organizational change and enables a
smooth project initiation.
Back to Top
Change Management
Specialist
Create and manage the Ad Hoc Communications. 100
Specialist
Assist with the creation and management of the Ad Hoc Communications. *
Back to Top
PREREQUISITES
Prerequisite Usage
Background documentation on project vision
direction and governance rules
The background documentation provides the necessary information to initiate the development of materials for
Ad Hoc Communications (ENV.EOCM.010)
Executive Business Objectives and/ Governance
Rules (ENV.EOCM.030)
Rules (OCM.030)
Use the Communication Strategy component of the Executive Business Objectives and Governance Rules, if
available. The Communication Strategy provides an approach for generating and coordinating communication
for all impacted audiences.
Project Team Communication Plan (PJM.CMM.020) The Project Team Communication Plan documents the overall communication strategy for the project team.
Back to Top
TEMPLATES AND TOOLS
OCM-010_AD_HOC_COMMUNICATIONS_STRATEGY_APPROACH.DOC MS WORD
Back to Top
The Ad Hoc Communications are used in the following ways:
to provide key project information
to lower the risk of rumors and negative perceptions about the project
to provide background information
Distribute the Ad Hoc Communications as follows:
to all stakeholders, as appropriate
Back to Top
QUALITY CRITERIA
Back to Top
OCM.020 - PREPARE FOR EXECUTIVE ALIGNMENT
WORKSHOP
In this task, you prepare for the Executive Alignment Workshop. The Executive Alignment Workshop aligns executives behind the project objectives, vision and success
criteria to provide consistent cross-organizational project success and a valued delivery. Preparing for the Executive Alignment Workshop includes the following:
Obtaining commitment from the project sponsor to lead, prepare for and conduct the Executive Alignment Workshop.
Researching and reviewing background materials on the project direction and governance rules.
Conducting selected executive interviews.
Comparing the client data with the leading practices project direction and governance.
Developing a timeline that will ensure that the discussion focuses on the need to fill the gaps and reach a decision on governance rules.
ACTIVITY
Back to Top
WORK PRODUCT
Executive Alignment Workshop Materials - The Executive Alignment Workshop Materials consists of all the background materials, interview feedback, analysis findings
and recommendations, workshop presentations, and the workshop facilitation grid cataloged and organized in order to conduct the Executive Alignment Workshop.
Back to Top
TASK STEPS
1 Obtain commitment from the project sponsor. None None
2 Research and review background materials on
project direction and governance rules.
Existing Background
Materials
It is imperative that all project-related material be read. This includes but is not limited
to a business case, consulting service proposal, the web site of the organization and
any other relevant documents.
3 Meet with facilitating organization and client project
managers to capture the project challenges and
client culture.
Interview Questions The Interview Questions address current and or foreseen challenges and those that
address the client culture including but not limited to questions regarding leadership,
reaction to change, communications and training.
4 Prepare and tailor the Executive Interview Grid. Executive Interview
Grid
The Executive Alignment Workshop Materials contain an Executive Interview Grid that
can be used to capture the responses to the interview questions from the executives.
Responses are entered into this grid and the analysis is then conducted.
5 Conduct selected executive interviews. Schedule
one-on-one interviews lasting approximately 45
minutes in order to be mindful of the executives
time.
Project Alignment
and Commitment

6 Compile and analyze findings. Executive Interview
Analysis and
Findings
Recommendations
for Project Direction
and Governance
Rules
These components provide a qualitative assessment of the information collected from
the executive interviews.
7 Schedule workshop. Workshop Logistics The Executive Alignment Workshop Materials contain a section to capture the
Workshop Logistics and provide the pertinent logistical details for the workshop (for
example, date, location, times, etc.).
8 Identify and invite participants.
Workshop
Participants List
The Executive Alignment Workshop Materials contain a section to capture the list of
participants, as well as a template for an Invitation Memorandum that can be used to
invite the participants to the workshop.
#TOP #TOP
Invitation
Memorandum
Presentation
Materials
The Workshop Presentation Materials consist of any materials that need to be
prepared for use during the workshop.
10 Build a Facilitation Grid. Facilitation Grid The Executive Alignment Workshop Materials contain a Facilitation Grid that includes
selected exercises and activities that will be implemented during the workshop to
11 Validate the Facilitation Grid with client. Validated Facilitation
Grid
Validate the Facilitation Grid with the project sponsor and client change management
lead. Make changes, as required.
12 Prepare Session Planning Checklist(s) Session Planning
Checklist
The Session Planning Checklist provides a way to verify that all necessary details for
the workshop have been addressed.
Back to Top
APPROACH
A technology change requires executive-level visibility and commitment to increase the potential for project success and return on investment. It is more efficient to align
the project team and direction when the executives lead the way. It is also easier to cascade the alignment at the management level when the executives have defined
the project governance, success criteria, and goals. The Executive Alignment Workshop provides the fastest and most effective mechanism to ensure executives are
aligned and stand behind the project vision, objectives and success criteria. Executives have to be aware that a Sponsorship Program will be built on risks identified
during interviews.
The project governance rules have to be defined before the start of the project or early on in the project. The executives also have to create a consensus around the roles
and responsibilities for the Steering Committee.
The Executive Alignment Workshop (OCM.030) is a complete day of meeting and will cover the topics determined in this task.
Before you can assist the customer in conducting the Executive Alignment Workshop, baseline information is required. Executives have to dedicate time to take part in
activities that help to mitigate the risks that have been identified. The change management specialist must know the project and the organizational culture. It is also
helpful to know the leadership style of the project sponsor.
Obtain Commitment from the Project Sponsor
Introduce the Executive Alignment Workshop to the project sponsor as well as to the implementing organization and client project managers, if they are identified. The
client project manager and the change management specialist should lead the discussion with the project sponsor to obtain the commitment. This demonstrates the
partnership and commitment from the project team. Walk the project sponsor through the steps of the Executive Alignment Workshop by explaining what the output will
be. It is imperative for the client project manager and project sponsor identify which leaders should participate in the interviews. It is often the case that some leaders may
not be directly involved in the project or at the steering committee level but can influence the success of the project or have knowledge of specific risks for the project.
By obtaining the commitment from the project sponsor and moving forward with the Executive Alignment Workshop, you ensure that we can create alignment and active
sponsorship from the executives by obtaining the following output for the project governance:
Project Vision and Institutional Objectives - Shows the alignment of the project vision with the institutions strategy and identifies the rationale for the project and
expected institutional objectives, success criteria and benefits.
Project Direction - Identifies the high-level project risks and challenges. Includes action items to manage the impact, mitigate the risks, support key project roles,
and manage the project at the executive level.
Roles - Documents roles within the project environment, including the Executive Sponsor, Steering Committee , and Advisory Committee.
Reporting Structure - Illustrates the required level of influence and involvement that each group has related to making project decisions.
It is necessary to gain approval from the project sponsor that all individual answers and information provided by participants will be kept anonymous. This is key for
obtaining honest input from the leaders. The data will be compiled and the results will be presented in aggregate so no one executive can be identified as supplying
specific information.
To summarize:
Obtain commitment from the project sponsor to lead, prepare for and conduct the Executive Alignment Workshop.
Gain the perspective on organizational and human risks from the project sponsor.
Obtain commitment from the project sponsor to lead the alignment activity.
Assign an appropriate party to coordinate the logistics.
The workshop must be carefully planned in order to avoid any political issues and to obtain the involvement of the executives for the workshop. For this reason, get
approval from the project sponsor to keep the individual interview data confidential and only provide the analysis to ensure confidentiality and obtain additional
information from VPs, where required. Before starting the interviews, inform the participant on the confidentiality of the interview and how the information will be
communicated with integrated data.
Research and Review Background Materials
Research and review background materials on project direction and governance rules. It is imperative that all project related material be read which includes but not
limited to: a business case, consulting service proposal, the web site of the organization and any other relevant documents.
During interviews with vice presidents, validate their understanding and level of commitment and alignment to the following items if determined:
Project Vision
Project Objective
Guiding Principles
Project Rationale
To summarize:
Validate the level of executive alignment obtained.
Identify the leadership style of the project sponsor.
Obtain the first read into specific information regarding organizational challenges.
Meet with Facilitating Organization and Client Project Managers
Project managers are already aware of key organizational risks and political challenges in place for the project. Their insight is very important to capture and they can
often sense what they see has current and foreseen challenges that can negatively affect the project. The client project manager can provide insight on the organization
culture, leadership and past commitment of executives during projects. In addition, it is very important to ensure that the facilitating organization (for example, Oracle) and
client project managers support the change management initiative.
This input from project managers can affect the change management specialists approach and it is always necessary to align to the client culture. In addition, it is
imperative that the efforts put forth can mitigate project risks before they create potential problems. If we are reactive to the risks and not strategically plan to mitigate
them, we are at risk of pushing out the timeline and going over budget.
Items listed below can serve as topics and questions of interest:
1. Project goal /vision/success criteria
2. Name of Project Sponsor
3. Project priority
4. Political issues that they may be aware of
5. Past implementation experience
6. Staffing commitment
7. Client's culture (leadership style, communication and training culture)
8. People who are likely to oppose the project and how they can resist
9. Major implementation challenges anticipated
10. Potential impact on people work most impacted groups
Prepare and Tailor the Executive Interview Grid
Based on the leading practices in governance and from the input of the project managers, generate your interview grid to capture the level of alignment, commitment and
identify the organizational risks in place. Determine appropriate questions for interviews. (If availalbe, select questions from a directory or repository of interview
questions.)
Conduct Selected Executive Interviews
Schedule the time and location of each executive interview in collaboration with the facilitating organization and client project managers. It is typical that the project
sponsor will take the lead in scheduling the logistics.
The project sponsor will send an invitation message to his/her directs to introduce the process and request participation. This initiative will confirm the importance of this
process.
Collect information to the questions listed in the Executive Interview Grid in 30 to 45 minute interviews with executives and the project sponsor. Be sure that you introduce
your self, specify what the purposes of the interviews are and that this information will be analyzed and reviewed as a collective. Encourage them to answer openly and
honestly as no individual level data will be shared with the collective and the project sponsor.
Gather the information regarding project barriers, potential political issues and organizational risks.
Capture the level of alignment and gaps to manage.
Identify the level of priority this project has within the organization.
Identify the project risks and how executives can reduce roadblocks and maintain alignment.
Identify the level of alignment between executives.
Identify the level of commitment for the project.
Identify project risks and political issues.
Compile and Analyze Findings
Compare the client data with the leading practices project direction and governance. Capture the data in the Executive Interview Analysis and Findings. The Executive
Interview Analysis and Findings is built so that you can easily capture the qualitative data and be able to calculate how many respondents are sharing the same thoughts
or disagree on a topic.
The accuracy of data collected is imperative to capture. As the interviews progress there will be some consistencies and inconsistencies and is therefore important to use
a grid that enables you to quickly capture and tally up the consistencies and inconsistencies. Have each question pre filled and assign each interviewee a number. If the
interviewee says something that corresponds to anothers response check the box that corresponds to that individual for the specific question.
Identify gaps from the interview data to discuss during the Executive Alignment Workshop.
Determine if there is misalignment around project priority, vision, commitment, etc.
Identify the key organizational challenges and risks in place to mitigate.
Identify the political situation to manage.
Identify the situations that will make or break the project.
Get the executives input on the project.
Involve the executives early on in the project.
Compare the commitment and alignment with leading practices.
Schedule the Executive Alignment Workshop
Along with the facilitating organization and client project managers and the project sponsor, determine the Executive Alignment Workshop logistics, including:
date
location
times
proposed agenda
Collect the names and contact information of those executives that will be required to attend the workshop from the facilitating organization and client project managers
and project sponsor. The invitation should be sent by the project sponsor to ensure that the workshop will be well attended. The impact of people missing will push out
the timeline as each designated executives input is required. Include an RSVP so that set up, materials, food, etc. is sufficient.
Ensure that all presentation materials along with tools and templates are printed and appropriately packaged prior to the Executive Alignment Workshop. Reserve all
items that are necessary to run the workshop and ensure that they are in the room prior to the start of the workshop. Such items include pens, markers, whiteboards,
presentation.
handouts
workbooks, etc.
A successful Executive Alignment Workshop depends on a well-planned and well-structured timetable. The Facilitation Grid includes selected exercises and activities and
topics for discussion that will be implemented during the workshop to accomplish the workshop objectives presented in a well-planned and well-structured timetable. It is
a timetable for the entire time of the workshop showing what activities or exercises will be accomplished at what time. It should include time allocated for breaks and
meals. Create exercises and activities (if available, select from a directory or repository of exercises and activities) that will be implemented during the workshop to
Ensure that the actual working activities are introduced and well explained at the time of their kickoff. This eliminates any potential surprises and ensures that there is full
participation.
Build on situations that need to be discussed in order to reduce misalignment or gain more commitment. Also cover topics which require clarification (for example, project
objectives or success criteria). Finally, it will respect the leadership in place and provide opportunities for participants to share their ideas. Ultimately, the grid must meet
the objectives of the Executive Alignment Workshop to ensure that the executives will lead the way by creating and fostering strong alignment and commitment to the
project. The Facilitation Grid dictates the following:
Executive Alignment Workshop Objectives
Assumptions
Background
Validate the Executive Alignment Workshop Facilitation Grid with the project sponsor. Obtain the signoff on the completed workshop materials including the Facilitation
Grid with the project sponsor. Socialize the materials with the facilitating organization project manager so he can promote cooperation, provide input and validate work
products. This collaboration facilitates the agreed upon organizational change. Revise and re-socialize where and when required. Do not conduct the workshop without
the validation and required signoff.
The change management specialist (leadership) is the one who will keep the discussion on time and make the link between each leader who may be invited to speak. The
topics are planned for facilitating the discussion and for the decision making process. It is challenging keeping leaders on schedule but the efficiency of the workshop is
related to this capability to structure the work. Include an open issue section in the grid timetable if some follow ups are required. The Sponsorship Program (EOCM.040)
is also introduced at the end of the workshop.
prior to conducting the Executive Alignment Workshop to make sure last minute preparations have been accomplished.
manager determine and document responsibilities for the Executive Alignment Workshop as soon as possible in order to ensure that the workshop is adequately planned.
This collaboration facilitates the agreed upon division of workshop activities, roles and responsibilities.
Back to Top
Change Management
Specialist
Prepare the interview materials. Prepare the materials for the Executive Alignment Workshop. 50
System Architect Assist with determining possible architectural sessions and attendees. 50
Client Project Sponsor Identify the alignment challenges early on. Get a first level understanding of project barriers. Assess and articulate the level of
executive commitment for the project. Validate the Executive Alignment Workshop Facilitation Grid.
*
Client Project Manager Participate in the preparation of the Executive Alignment Workshop. *
Back to Top
PREREQUISITES
Prerequisite Usage
Background materials on project direction and governance
rules
This material allows you to understand what change management work has been conducted to date. It
also provides information on what has and what has not been successful in managing change.
Contractual and Business Agreement Documentation This documentation may include collective and ancillary documents such as vendor agreements,
contract/labor agreements, system requirements documentation, board level directives and
communications, and requests for proposal. These documents assist in the identification of the
business drivers for the project and provides details on the scope of the implementation, the modules
purchased, the agreements, and so on.
Return on Investment (ROI) Analysis A Return on Investment (ROI) analysis can document the business case and the return that the
executive management team can realistically expect from its investment in technology. If an ROI has
been performed, you need it as an input.
Project Management Plan (PJM) The Project Management Plan defines the scope, objectives, and approach for the project and refers to
the detailed standards and procedures employed during the execution of the project.
(PJM.OCHM.010)
The Client's Organizational Change Management Strategy documents how the project solution is to be
Change Management Warning Signs (PJM.OCHM.020) The Change Management Warning Signs identifies early change management warning signs.
(ENV.EOCM.020)
(ENV.EOCM.030)
Enterprise Stakeholder Inventory (ENV.BA.015)
High-Level Business Process Model (RD.011)
Software Requirement Specification (RD.140.1)
These work products include a description of how the new processes operate, and the principles that
regulate the operation of the new processes.
These work products provide insights and the framework for the project and the related plans and
expectations. They also assist in identifying key stakeholder groups.
Present and Future Organization Structures (RD.012) The Present and Future Organization Structures contains the Organization Structure. This work product
or an Organizational Chart assists in stakeholder analysis.
Ad Hoc Communications (OCM.010) The Communication Structure component of the Ad Hoc Communications provides input into this task.
Back to Top
TECHNIQUES
Technique Comments
Back to Top
TEMPLATES AND TOOLS
OCM-
020_EXEC_ALIGNMENT_WORKSHOP_MATERIALS.DOC
MS WORD - Use this template to prepare for the workshop.
OCM-020_EXEC_ALIGNMENT_WORKSHOP.PPTX MS POWERPOINT - Use this template to create a presentation for your workshop.
Back to Top
The Executive Alignment Workshop Materials are used:
to conduct the Executive Alignment Workshop
Distribute the Executive Alignment Workshop Materials as follows:
Back to Top
QUALITY CRITERIA
Back to Top
OCM.030 - CONDUCT EXECUTIVE ALIGNMENT WORKSHOP
In this task, you conduct the Executive Alignment Workshop. The Executive Alignment Workshop is the fastest and the most effective mechanism to ensure executives
are aligned and stand behind the project vision, objectives, and success criteria. It provides the opportunity to identify the project risks and how executives can reduce
roadblocks. During the workshop, executives document how to track project benefits, sponsor the project, and prepare the organization for changes.
ACTIVITY
Back to Top
WORK PRODUCT
Executive Business Objectives and Governance Rules - The Executive Business Objectives and Governance Rules captures the decisions made during the Executive
Alignment Workshop about project vision, objectives, and success criteria in order to communicate them to the project team so that they can then provide direction to
middle managers and end users in order to manage the impact of the project on the organization as well as to mitigate organizational risks.
Back to Top
TASK STEPS
1 Prepare for the work session. None Use the Session Planning Checklist from the Executive Alignment Workshop Materials (OCM.020).
project vision and business
objectives.
Project Vision and
Business
Objectives
This component shows the alignment of the project vision with the business strategy and identifies the
rational for the project and expected business objectives and benefits.
project direction.
Project Direction This component identifies the high-level project risks and challenges. Includes action items to manage the
impact, mitigate the risks, support key project roles and manage the project at the executive level.
4 Introduce the Sponsorship
Program
Sponsorship
Program
This component describes the Sponsorship Program.
reporting structure.
Reporting Structure The Reporting Structure describes the reporting structure for the project.
roles.
Roles This component documents roles within the project environment, including the executive sponsor, Project
Management Office, and Advisory Committee.
communication.
Communication
Strategy
The Communication Strategy is the link between all work products and it keeps people informed about the
project. The working session will help specify the roles of the executive sponsor and Steering Committee.
8 Perform a post-workshop wrap up. Updated Materials,
Workshop Results
Update any materials, if necessary. Document results.
Back to Top
APPROACH
Some organizational issues can break the project and need to be addressed as soon as possible in order to ensure the success of the project. During the Executive
Alignment Workshop, the executives will highlight the key issues to address. The Sponsorship Program (OCM.040) will be the tool used to mitigate those issues.
The Executive Alignment Workshop (OCM.030) is a complete day of meeting and will cover the topics determined in this task.
An integration process requires executive-level visibility and commitment to increase the potential for project success and return on investment. It is more efficient to align
the project teams and set direction when the executives are seen to lead the way. It is also easier to cascade the alignment to the next level of management when the
executives have defined the project governance, success criteria, and goals. The key objectives of the Executive Alignment Workshop are:
Ensure that the executives are aligned and stand behind the objectives for each project's, vision and success criteria to ensure that there will be consistent cross-
organizational project success and a valued delivery.
Identify the project risks for each project and determine how the executives can maintain alignment while reducing roadblocks.
Develop actionable governance improvements and provide recommendations for reducing risks.
Create a guidance coalition.
Address political issues.
Define key actions to put in place in order to reduce project barriers.
Set up a Steering Committee.
Use the Session Planning Checklist(s) from the Executive Alignment Workshop Materials (OCM.020). Ensure that all of the work from the Prepare for Executive Alignment
(OCM.020) task has been preformed. By accomplishing the necessary pre-work, you will have already attained the full commitment and buy-in from the client. If there is
something that is not completed, it is crucial to complete the activity before to the kick off of the workshop to ensure the full success of the workshop.
Facilitate Interactive Work Sessions
Key executives are assembled to identify the scope and organizational impact of the projects in the IT Portfolio, on the business, and to plan for a successful delegation to
the project team. The interactive work sessions look at key considerations when introducing new enabling technology, in order to maximize the business benefit to the
organization and reduce the implementation risks.
Use the Executive Alignment Workshop Materials (OCM.020) to facilitate the workshop.
PROJECT VISION AND OBJECTIVES SESSION
The facilitation of this topic will take into consideration the level of alignment or lack of alignment identified during the interviews. The alignment of the project vision with
the business strategy identifies the rational for the project and expected business objectives and benefits. All executives will have to communicate this vision and ensure
that there is buy-in behind it.
The project objectives are aligned with the project vision and executives need to agree on them before having an effective discussion on the vision. They also have to
agree on the project success criteria to have a targeted discussion on the vision.
Before starting any discussion on project vision, objectives and success criteria, it could be relevant to invite the facilitating organization (for example, Oracle) and/or the
client project manager to introduce the solution. Usually, executives have a very high understanding of the project but do not always understand the magnitude or the
scope and what it is in scope and out of scope. This first step will smoothly guide the discussion.
The facilitator should call on the project managers to introduce the solution. It is best if both of them share the presentation in order to demonstrate that there is balanced
leadership positioning. Also, the facilitator should know what will be presented and can integrate the information into his/her slide deck.
Typically, executives have to agree on the top four or five objectives to build the necessary commitment. From the interviews, the workshop facilitator (change
management specialist) explains the level of alignment behind objectives:
The objectives with overall consensus.
The objectives that are not the same.
The objectives that some executives are not comfortable with or question.
The prioritization of each objective.
The facilitator should guide the discussion in a way to obtain agreement on the prioritization of the objectives for four or five of them by identifying:
Which objectives are aligned to the goals and vision of the organization
Which objectives create the greatest overall positive impact
Identifying those objectives that can be achieved in the short term vs. long term
Which objectives create the least amount of job impact
For providing direction to the project team, executives have to agree on the success criteria of the project. The measurement of these criteria also guides the Steering
Committees involvement in the project. The workshop facilitator should:
Summarize what is a good criterion (measurable, observable, etc.).
Introduce the criteria identified during interviews and recognize where there is and is not consensus.
Differentiate between those criteria that are hard to reach but attainable from those that will not be reached.
Assess the overall readiness and preparatory work that has already been conducted.
Usually the project vision is presented by the project sponsor and the draft of the vision is ready for the presentation and will follow these criteria:
Is based upon the stated beliefs and values of the organization
Is developed collaboratively by representatives from the key project groups
Is a broad, comprehensive statement of what the organization should look like as a result of the project within a certain time period
Is a future-oriented statement consistent with the current status of the organization as well as important trends within the organization
The change management specialist (workshop facilitator) supports the project sponsor with facilitating the discussion. Facilitation techniques help the participants to share
their level of comfort with the draft vision statement and will:
Define where the organization wants to be in the next few years.
How the organization will be a better/more efficient organization after the implementation.
Define what this will mean for their employees, the organization, their share holders, the industry and their competition.
What will the executives have to do in order to move this vision into action.
Facilitate the discussion in order to gain consensus on the foundations of the vision and provide opportunities for the participants to influence each other as they
share their perceptions on the way to building overall consensus.
Avoid wording work and stay on key elements.
Give opportunities to get more input as possible from participants.
Get a vote at the end of the key foundation point for validating the consensus.
Assess if the executives are able and willing to exert their own time and energy to support the vision.
When the key elements of the vision are agreed to but they cannot formulate a final vision within the group, than the facilitator will propose another version which will be
sent for approval within 24 hours. The participants will then have to send their comments within the next 24 hours and if comments are not received from some
individuals, it means that this individual(s) agreed on the statement.
PROJECT DIRECTION SESSION
During executive interviews, the high-level project risks and challenges were captured and some key risks and challenges were selected to be addressed. The project
sponsor has agreed on this prioritization. Some key actions have been identified to manage their impact and mitigate their risks.
The facilitation of this topic must ensure that the executives are on the same page on the challenging situations that can make or break the project. The participants
should discuss the organizational risks; identify what are the key actions to put in place, their role and how their direct reports can be involved in the cascade of the
problem-solving approach.
From the series of challenges (for example, cultural, organizational, political, employee resistance or relation to union potential reactions), the executives will select those
that need to be managed at the executive level and in the management cascade. The change management specialist (facilitator) will introduce the risks that were
identified at the time of the executive interviews and described as being major risks for the project.
Introduce the Sponsorship Program
As stated previously, during the individual interviews with executives, key issues have been captured. Executives are challenged with removing organizational barriers
and addressing these key issues.
During the Project Direction Session, this topic is addressed in a way to prioritize the problems that can break the project. The change management specialist will define
the Sponsorship Program for the executives and explain the leading practices related to it. The Sponsorship Program identifies the best executives to address specific
organizational challenges and coaches them on mechanisms, activities and communications in order to remain aligned throughout the project. The goal of the
Sponsorship Program is to mitigate risks and get management aligned behind the change. Therefore, a Sponsorship Program:
Identifies actions that could be taken at the executive level to address project risks/ and challenges.
Identifies what the executives will do to support the implementation team.
The Sponsorship Program is not built during the workshop, however, an outcome of the workshop will be a prioritization of the major challenges in order to give direction
and make inputs into the Sponsorship Program (OCM. 040).
The project sponsor should explain why it is important for the project to get commitment from the executives (VPs) in reducing project barriers and ensuring the success of
the project. The project sponsor should also elaborate that the Sponsorship Program is a tool to measure the commitment of each executive. Finally, the project sponsor
should inform the executives of their commitment to the Sponsorship Program by:
Ensuring that they model the change
Conducting weekly Steering Committee meetings
Conducting periodic meetings with the core and extended project team
In some organizations, the Sponsorship Program may be integrated in the executive performance incentive plan or an additional bonus may be applied. If that is the case,
the project sponsor should provide the details to the executives.
REPORTING STRUCTURE SESSION
Executives have to synthesize an effective process for reporting key project information up and down through the organization. This process must be captured to ensure
that reporting is performed effectively and efficiently.
During the session, this topic is addressed so clear lines of reporting can be structured.
ROLES SESSION
Project Sponsor
While all the executives will be involved in the Sponsorship Program, some members will also participate in the Steering Committees work. It is also possible that the
project sponsor will not be the steering committee leader, so the roles must be clearly defined to ensure a clear alignment for the work.
The project sponsor should introduce his role to the workshop participants. Before the meeting, the change management specialist will have worked with the project
sponsor to define his role. Role options include but are not limited to:
Provide policy guidance
Mobilize the resources to implement the project
Participate in establishing major practices for the new system
Remove barriers
Facilitate communications
Chair the Steering Committee
Steering Committee
If a proposed structure for the Steering Committee is already completed and agreed to, the project sponsor should introduce the Steering Committee charter and
members. If not, present a typical role definition for the Steering Committee:
The purpose of the Steering Committee is to create an environment conducive to a successful implementation. The Steering Committee will provide strategic direction,
allocate resources, remove barriers, protect the project from internal politics, make decisions at the appropriate level, resolve issues which have been escalated from the
advisory committee and project team, serve as the link to the project with stakeholders external to the project, and keep the project focused on the business objectives it
is intended to meet.
Invite the executives to define the roles of the Steering Committee members.
In discussions during the workshop, the executives determine the conditions for the Steering Committee success in term of participation, commitment, decision making
process (consensus, vote rules), issues resolution approach, quorum (rules for members who missed a meeting), etc.
After the Executive Alignment Workshop, you may need to facilitate the first Steering Committee for facilitating a session on the role and responsibilities of the Steering
Committee and governance rules.
Advisory Committee
For a global implementation or depending on the client culture (consensus culture), an Advisory Committee may be put in place. The project sponsor can recommend this
structure and the workshop participants can advise on this approach by defining the role of this advisory committee and select who can be members of this group. Guide
the group to consider the following:
role of the advisory committee
responsibilities
number of people who can participate
nomination process for the regions/countries
meeting schedule (quarterly? monthly?)
leader of the committee
link with the steering committee with its communication process
It is also possible that the project manager puts forth the recommendation to establish an Advisory Committee. If this is the case the decision will then be made by the
project sponsor.
COMMUNICATION SESSION
The Communication Strategy is the link between all work products and it keeps people informed about the project and helps with rumor control. The working session will
help specify the roles of the project sponsor and Steering Committee. It will be reviewed based on the Change Readiness Assessment findings. The strategy will follow
the clients culture and consider target groups impacted by the change (audiences or stakeholder groups). It is based on the involvement of key players including
executive leaders, supervisors, communications liaisons, etc.) and is aligned with the needs of the target group. The strategy and the communications portion of the
Communication Strategy and Change Management Roadmap /Communication Campaign (OCM.130) will reflect the phases of the project and will be aligned with project
milestones.
Have the executives discuss their preferred process and provide the direction of the Communication Strategy, specifically regarding the communication cascade.
Perform Post-Workshop Wrap Up
Prepare the Executive Business Objectives and Governance Rules that integrates into one document all the decisions reached during the workshop and complete the
related documentation to ensure that there is sign off from the project sponsor.
The Executive Business Objectives and Governance Rules that summarizes the decisions should be finalized in less than one week in order to sustain the momentum. In
some organizations, the project sponsor may require that executives sign off on the document.
change management specialist and project manager perform the required activities for the Executive Alignment Workshop. This collaboration facilitates a more
successful workshop that leads to better understanding of the requirements for the organizational change.
Back to Top
Change Management
Specialist
Lead and facilitate the Executive Alignment Workshop. 100
Client Project Sponsor Commit to managing potential political issues. Cascade the involvement to the next management level. Actively participate in
*
Client Project Manager Support, provide input and participate in the Executive Alignment Workshop. *
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.EOCM.020)
(ENV.EOCM.030)
Ad Hoc Communications (OCM.010) The Communication Structure component of the Ad Hoc Communications provides input into this task.
Executive Alignment Workshop Materials (OCM.020) The Executive Alignment Workshop Materials consists of all the materials necessary to conduct a
successful Executive Alignment Workshop, including the interview data collected from the executives.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
OCM-030_EXECUTIVE_BUS_OBJECTIVES_AND_GOV_RULES.DOC MS WORD
Back to Top
The Executive Business Objectives and Governance Rules is used:
to create a consensus around the project governance
to mitigate organizational risks that can make or break the implementation
to identify the alignment challenges early on
to asses and articulate the level of executive commitment for the project
to derive a common understanding of project vision/objectives/governance rules
to provide a picture of the level of alignment and commitment that exists at the executive level
to get a first level understanding of project barriers
Back to Top
QUALITY CRITERIA
Back to Top
OCM.040 - BUILD AND DEPLOY SPONSORSHIP PROGRAM
In this task, you build and deploy a Sponsorship Program. The Sponsorship Program identifies the best executives to address specific organizational challenges and
coaches them on mechanisms, activities and communications in order to remain aligned, lead the change and mitigate organizational risks throughout each project in the
IT Portfolio. These executives then cascade (or sponsor) the involvement to the next level and lead the next level of management in the change path in order to obtain
their buy-in. The objectives of the Sponsorship Program are to:
Obtain commitment from the executives to lead the way and model the change.
Reduce organizational barriers and obtain the buy in from the middle managers and stakeholders.
ACTIVITY
Back to Top
WORK PRODUCT
Sponsorship Program - The Sponsorship Program identifies the best executives to address specific organizational challenges and coaches them on mechanisms,
activities and communications in order to remain aligned throughout the project. The goal of the Sponsorship Program is to mitigate risks and get management aligned
behind the change.
Back to Top
TASK STEPS
1 Identify who is the best executive to be the owner of the Sponsorship
Program as well as the best executives who can handle these
organizational risks and lead the organization to address specific
organizational challenges.
Sponsorship
Program
Leaders
This component identifies the leader for the Sponsorship Program as
well as other executives that will assist in deploying the Sponsorship
Program.
2 Using the executive interviews conducted for the Executive Alignment
Workshop Materials (OCM.020), identify the key risks that need to be
mitigated as well as an action to put in place to mitigate the risk.
Sponsorship
Grid - Risks to
Manage
Sponsorship
Grid - Action
to Put in
Place
The Risks to Manage is a list of all the risks that have been identified
and selected to include in the Sponsorship Program.
The Action to Put in Place describes the mechanism, activity and/or
communication that will be used to mitigate each risk throughout the
entire project.
3 Define executive responsibilities in deploying the Sponsorship Program. Sponsorship
Grid -
Leadership
Accountability
The Leadership Accountability assigns a leader to each risk. The leader
is responsible for putting the mitigating action in place and monitoring
the action as well as cascading the action to the next level, if
appropriate.
4 Determine the cascade to the next management level. Sponsorship
Grid - Other
Level of
Involvement
The Other Level of Involvement will identify the next level(s) in the
organization that will participate in the mitigating action, as appropriate.
5 Put measures in place to monitor the accomplishment of the actions.
Back to Top
APPROACH
reduce organizational project barriers. The project governance rules have to be defined before the start of the project or early on in the project. The executives will also
have to create a consensus around the roles and responsibilities for the Steering Committee. This alignment work was performed in the Executive Alignment Workshop
(OCM.030).
During the interviews for the Executive Alignment Workshop, a series of questions were asked to address the challenges and issues for the project. During the workshop,
executives identified and prioritized those issues and determined which ones would be addressed in the Sponsorship Program.
Some organizational issues can break the project and need to be addressed as soon as possible in order to ensure the success of the project. The Sponsorship Program
will be the tool used to mitigate those issues. The prerequisite for this task is the Executive Business Objectives and Governance Rules (OCM.030) developed during the
Executive Alignment Workshop. The Sponsorship Program will be utilized and deployed during all phases until the end of the project.
The Steering Committee and the change management specialist meet to identify key risks and determine actions to mitigate them, identify Sponsorship Program leaders,
define responsibilities, and put measures in place to mitigate those risks. The change management specialist captures the highlights of this discussion and documents
them in the Sponsorship Program document.
Identify Sponsorship Program Leaders
Identify who is the best executive to be the owner of the Sponsorship Program as well as the best executives who can handle these organizational risks and lead the
organization to address specific organizational challenges.
The Sponsorship Program is a risk mitigation plan that can only be managed at the organizational level. It requires leaders who are visible and capable to make decisions
for the organization. The project sponsor needs to be involved at the highest level in order to avoid any potential political issues.
Some people within the organization may associate the deployment of the Sponsorship Program with the executive compensation program, for this reason the highest
level is required to manage this plan.
The project sponsor determines who will lead and carry out the sponsorship activities and articulates the importance of actively sponsoring the project. The project
sponsor articulates the importance of being actively engaged through out the project as each executive has a direct affect on each other. Usually, the project sponsor
assumes this responsibility, but increasingly, the Steering Committee leader assumes it.
If the leader of the Sponsorship Program is not the CEO (for a large transformation) or the project sponsor, it is crucial that this program receives the approval from these
leaders. In addition, if an executive member is the leader of the program, they need the authorization to escalate tasks to the CEO or project sponsor, as required.
Identify Key Risks and Actions
Use the Executive Interview Grid from the executive interviews conducted in preparation for the Executive Alignment Workshop Materials (OCM.020) to help identify the
key risks that need to be mitigated. The Executive Interview Grid contains the analysis conducted on assessing the key organizational risks that need to be managed at
the executive level. Some of these were selected by the executives during the Executive Alignment Workshop or by the project sponsor to include in the Sponsorship
Program.
Once the risks are identified, define a mitigation plan for each risk that consists of actions to be put into place in order to mitigate the risk. The actions can be any
mechanism, activity and/or communication that can be used to mitigate each risk throughout the entire project.
Define Executive Responsibilities
In general, the Sponsorship Program executives responsibilities include but are not limited to the following:
Participate actively in the process be accountable for what activities are assigned and perform by the assigned date
Facilitate open and regular communication
Demonstrate personal commitment
Address issues in an open and timely way
Support those involved in the implementation process
By adhering to these responsibilities, enhance the positive
In addition, the executives are assigned to specific risks in order to deploy and monitor the mitigating action for that risk as well as cascade the action to the next level, if
appropriate.
Determine the Cascade to the Next Management Level
The Sponsorship Program identifies the best executives to address specific organizational challenges and coaches them on mechanisms, activities and communications
in order to remain aligned throughout the project.
The leaders accountable for some activities may have some actions that will start at their level and, in a second step, transfer some deployment activities to the next level.
In this case, the leader will monitor the work to be sure that the alignment is properly followed. The Sponsorship Program follows a top down approach for demonstrating
the level of commitment at the highest level of the organization. Usually, the executives will give the direction and establish the appropriate conditions, and monitor the
work in order to succeed and involve their managers in the day to day activities.
For each risk, establish a cascade order, beginning with the next level down in the organization, if appropriate.
Put Measures in Place
The monitoring of the accomplishment of activities is the responsibility of the executive who was assigned to the risk. Follow ups are conducted in order to ensure that the
necessary actions are appropriately performed.
The leader of the Sponsorship Program will request status reports for the plan from the various executive leaders. During the Steering Committee meetings, an item is
integrated in the agenda in order to monitor the deployment of the Sponsorship Program.
Different measurements can be utilized based on the organizations culture and the preference of the Sponsorship Program leader. They may include:
Evaluate with departments/constituencies/region/countries the number of activities accomplished during an appropriate period of time
Conduct a web cast in order to check if the managers planned activities are in place
Regularly follow up during the Steering Committee meetings
Ask project managers to see if they have observed significant commitment from the management team
Lastly, examine the wider issues that need to be considered that can affect the continued effectiveness of the Sponsorship Program. Continue to evaluate the cascade
orders as the Sponsorship Program contains mechanisms, activities and communications that will be used to remain aligned and to mitigate risks throughout the entire
project.
change management specialist and project manager perform the necessary activities to build and deploy the Sponsorship Program. This collaboration facilitates the
agreed upon organizational change.
Back to Top
Change Management
Specialist
Build and deploy the Sponsorship Program. 70
System Architect Assist with any architectural topics. 30
Client Project Sponsor Assist with deploying the Sponsorship Program. *
Client Project Manager Assist with buliding and deploying the Sponsorship Program. Also provide input and validate the program before presenting it
to the project sponsor.
*
Back to Top
PREREQUISITES
Prerequisite Usage
(ENV.EOCM.020)
Executive Execution Plan / Governance Rules
(ENV.EOCM.030)
Sponsorship program (ENV.EOCM.040)
(OCM.020)
Use the interviews from the Executive Alignment Workshop Materials.
Executive Execution Plan / Governance Rules
(OCM.030)
The Executive Execution Plan / Governance Rules captures the decisions made during the Executive Alignment
Workshop about project vision, objectives, and success criteria in order to communicate them to the project team,
middle managers, and end users and manage the impact of the project on the organization as well as to mitigate
organizational risks.
Back to Top
TEMPLATES AND TOOLS
OCM-040_SPONSORSHIP_PROGRAM.DOC MS WORD
Back to Top
The Sponsorship Program is used in the following ways:
to commit executives to managing potential political issues
to deploy the Sponsorship Program
Back to Top
QUALITY CRITERIA
Back to Top
OCM.050 - PREPARE FOR TEAM-BUILDING WORKSHOP
In this task, you prepare for the Team-Building Workshop. The Team-Building Workshop orients and supports core project team members with the project vision, direction
and strategies and provides exercises to learn how to work together more efficiently. It also prepares the team for the project kick off and can be an opportunity to
highlight roles and responsibilities prior to project commencement.
ACTIVITY
Back to Top
WORK PRODUCT
Team-Building Workshop Materials - The Team-Building Workshop Materials consists of all the materials necessary to conduct a successful Team-Building Workshop.
Back to Top
TASK STEPS
1 Meet with client and facilitating organization
project managers and gather initial information
for workshop.
The information gathered provides the pertinent details for preparing the workshop.
2 Schedule workshop. Workshop
Logistics
The Workshop Logistics section of the Team Building Workshop Materials provides the pertinent
logistical details for the workshop (for example, date, location, times, etc.).
3 Identify and invite participants. Workshop
Participants
List
Invitation
Memorandum
The Team Building Workshop Materials contain a section to capture the list of the participants, as
well as a template for an Invitation Memorandum that can be used to invite the participants to
the workshop.
Presentation
Materials
The Workshop Presentation Materials consist of any materials that need to be prepared for use
during the workshop.
5 Build a Facilitation Grid. Facilitation
Grid
The Facilitation Grid includes selected exercises and activities that will be implemented during
the workshop to accomplish the workshop objectives.
6 Prepare Session Planning Checklist(s). Session
Planning
Checklist
The Session Planning Checklist provides a way to verify that all necessary details for the
workshop have been addressed.
Back to Top
APPROACH
Meet with Project Managers
Meet with client and facilitating organization (for example, Oracle) project managers and gather information for workshop. During this meeting, determine workshop
details, including:
Performance expected
Leadership style
Challenges anticipated
Clients culture
Client's communication style
Issues anticipated (for example, potential personality type issues or fit)
Get a sample of conflict situation that has happened (for the exercise on conflict situation)
#TOP #TOP
Project sponsor involvement (for example, Can the PS launch the workshop?)
Key messages that project sponsor wants to communicate (Link with Executive Workshop)
Key messages that project managers want to communicate
Schedule Workshop
Determine the workshop logistics, including:
date
location
times
proposed agenda
You may have already identified the participants during meeting(s) with the client and facilitating organization project managers. If not, determine who the workshop
participants should be and invite them to the workshop.
Prepare any presentation materials that will be used during the workshop:
handouts
exercise materials
tools and templates for review
workbooks, etc.
Create a Team-Building Workshop Presentation that orients and supports core project team members with the project vision and direction.
Create exercises and activities (or, if available, select from a directory or repository of exercises and activities) that will be implemented during the workshop to encourage
and enable the project team members to work together more efficiently.
Prepare checklist(s) that are to be used prior to conducting the workshop to make sure last minute preparations have been accomplished.
manager determine and document responsibilities for the Team Building Workshop as soon as possible in order to ensure that the workshop is adequately planned. This
collaboration facilitates the agreed upon assignment of workshop activities, roles and responsibilities.
Back to Top
Change Management Specialist Prepare the materials for the Team-Building Workshop. 100
*
Back to Top
PREREQUISITES
Prerequisite Usage
(OCM.030)
The Executive Business Objectives and Governance Rules captures the decisions made during the
Executive Alignment Workshop about project vision, objectives, and success criteria in order to
communicate them to the project team, middle managers, and end users and manage the impact of the
project on the organization as well as to mitigate organizational risks.
Back to Top
TECHNIQUES
Technique Comments
Back to Top
TEMPLATES AND TOOLS
OCM-050_TEAM_BLDG_WORKSHOP_MATERIALS.DOC MS WORD - Use this template to prepare for the workshop.
Back to Top
The Team-Building Workshop Materials are used:
to conduct the Team-Building Workshop
Distribute the Team-Building Workshop Materials as follows:
Back to Top
QUALITY CRITERIA
Back to Top
OCM.060 - CONDUCT TEAM-BUILDING WORKSHOP
In this task, you conduct the Team-Building Workshop. The Team-Building Workshop orients and supports core project team members with the project vision, direction
and strategies and provides exercises to learn how to work together more efficiently.
ACTIVITY
Back to Top
WORK PRODUCT
Cohesive Project Team - Cohesive Project Team members are oriented with a thorough knowledge of the project vision, direction and strategies and are able to work
together more efficiently.
Back to Top
TASK STEPS
1 Prepare for workshop. Session Planning
Checklist(s)
Use the Session Planning Checklist(s) from the Team-Building Workshop Materials (OCM.050).
2 Facilitate Team-Building
Workshop.
Cohesive Project Team
Project Team Rules
Cohesive Project Team members are oriented with thorough knowledge of the project vision,
direction and strategies and are able to work together more efficiently.
The Project Team Rules provide a collaborative and problem-solving approach for the project team.
3 Perform post-workshop wrap
up and tool hand-off.
Updated Materials,
Workshop Results and Tools
Update any materials, if necessary. Prepare tools for the Enabled Project Team. Document results.
4 Provide ongoing coaching. Ongoing Coaching Ongoing Coaching is provided during the project to support the project team members.
Back to Top
APPROACH
The objectives of the Team-Building Workshop are to:
Encourage and enable working together more efficiently as a team.
Support team leads in generating a collaborative and problem-solving approach.
Define the team rules.
Use the Session Planning Checklist(s) from the Team-Building Workshop Materials (OCM.050).
Facilitate the Team-Building Workshop
Core project team members are oriented with through knowledge of the project vision, direction and strategies.
The high-level project plan is presented.
An overview of the project methodology (OUM) is presented and expectations are set regarding its use.
Project templates, such as status reports, are introduced.
Project Team Rules are set.
Team members are prepared to act as change and communication agents.
The Project Team Rules provide a collaborative and problem-solving approach for the project team. General rules allow participants to accomplish the following:
Set Project Team Rules.
Act as change and communication agents.
#TOP #TOP
Prepare the client and the facilitating organization resources to work efficiently together.
The Project Team Rules are used:
to prepare the client and facilitating organization resources to work efficiently together
to establish and deliver effective team rules
Perform Post-Workshop Wrap Up and Tool Hand-Off
In order to ensure consistent messaging, roles and responsibilities, as well as make sure that expectations are clearly understood by project team members, perform a
post-workshop wrap up. This step also serves as the groundwork for building and maintaining team cohesion.
Update and maintain any documents, tools or materials, if necessary (for example, presentation slides and documents). Prepare tools for the project team to go forward
and accomplish their tasks as a team. Document any results or observations from the workshop. Produce The Team Rules and Solution-Problem Process and provide it
to managers. Create a Team Rules Poster.
Provide Ongoing Coaching
Just because the workshop is over does not mean the support ends. Ongoing coaching is provided to the project team, as required.
manager support each other during the Team Building Workshop in order to present cohesive and collaborative leadership to the team. This collaboration facilitates the
agreed upon workshop activities as well as ensuring the team understands the specific assignment of roles and responsibilities between change management and project
management.
Back to Top
Change Management
Specialist
Facilitate the Team-Building Workshop. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Team-Building Workshop Materials
(OCM.050)
The Team-Building Workshop Materials consists of all the materials necessary to conduct a successful Team-Building
Workshop.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Cohesive Project Team members are core project team members oriented with thorough knowledge of the project vision, direction and strategies as well as their
contribution as a team member.
Back to Top
QUALITY CRITERIA
Back to Top
OCM.070 - DESIGN MANAGERS' PROJECT ALIGNMENT
WORKSHOP
In this task, you prepare for the Managers' Project Alignment Workshop. It is specifically designed to create awareness and involvement. The purpose of the Managers'
Project Alignment Workshop is to:
Inform the managers of the changes that are taking place.
Coach the managers in order to cascade the alignment and prescribed direction that was initially developed by the senior executives.
Involve managers early in the project and mobilize them to manage change at their level.
ACTIVITY
Back to Top
WORK PRODUCT
Managers' Project Alignment Workshop Materials - The Managers' Project Alignment Workshop Materials consists of all the materials necessary to conduct a
successful Managers' Project Alignment Workshop.
Back to Top
TASK STEPS
Logistics
The Workshop Logistics section of the Team Building Workshop Materials provides the pertinent logistical details for
the workshop (for example, date, location, times, etc.).
2 Identify and invite
participants.
Workshop
Participants List
Invitation
Memorandum
The Managers' Project Alignment Workshop Materials contain a section to capture the list of the participants, as well
as a template for an Invitation Memorandum that can be used to invite the participants to the workshop.
3 Prepare any
presentation materials.
Workshop
Presentation
Materials
The Workshop Presentation Materials consist of any materials that need to be prepared for use during the workshop.
4 Prepare Workshop
Tools and Key
Messages
Workshop Tools
and Key
Messages
The Workshop Tools and Key Messages support the presentation content of the workshop.
5 Prepare
Communication
Guidelines.
Communication
Guidelines
Communication Guidelines are strategies that can be given to or coached to the managers for accomplishing their
goals.
6 Build a Facilitation
Grid.
Facilitation Grid
Workshop
Activities
The Facilitation Grid includes selected exercises and activities that will be implemented during the workshop to
Specific Workshop Activities will be used during the workshop.
7 Validate Facilitation
Grid with the client.
Validated
Facilitation Grid
The Validated Facilitation Grid ensures that the client and necessary reviewers accept the content that will be included
as part of the workshop.
8 Prepare Session
Planning Checklist(s).
Session Planning
Checklist
The Session Planning Checklist provides a way to verify that all necessary details for the workshop have been
addressed.
Back to Top
APPROACH
#TOP #TOP
The mangers are one of the most important groups to receive buy-in from and to get engaged early in the project. They are typically the first to face resistance from the
end-user community and are often directed by the executives to take ownership in ensuring that the new technology and processes will be adopted by all those who are
affected by the change. The managers can also provide us with accurate information that relates to the overall change readiness, points of resistance, support and can
easily identify those persons that we can leverage to help support and model the change. Therefore, it is very important to provide them with project related details early
on in the project.
The Managers' Project Alignment Workshop requires at least a half day meeting.
The Managers' Project Alignment Workshop should be specifically designed to create awareness and involvement. The purpose is to:
Ensuring that the managers are aware of what the project will bring to the organization is very important. They must be the first to understand the components of this plan
as they will be tasked with the responsibility of supporting the project.
Schedule Workshop
Along with the facilitating organization and client project managers, determine the Managers' Project Alignment Workshop logistics, including:
date
location
times
proposed agenda
Collect the names and contact information of those managers that will be required to attend the workshop from the facilitating organization and client project managers.
The invitation should be sent by the project sponsor to ensure that the workshop will be well attended. The impact of people missing will push out the timeline as each
designated manager s input is required. Include an RSVP so that set up, materials, food, etc. is sufficient.
Ensure that all presentation materials along with tools and templates are printed and appropriately packaged prior to the Managers' Project Alignment Workshop. Reserve
all items that are necessary to run the workshop and ensure that they are in the room prior to the start of the workshop. Such items include pens, markers, whiteboards,
presentation.
handouts
workbooks, etc.
Prepare Workshop Tools and Key Messages
The Workshop Tools and Key Messages support the presentation content of the workshop. Prepare tools for managers in order to actively engage them in the project.
These tools may be used during the workshop as well as by the managers after the workshop so that they can continue to mitigate specific risks. Ensure that all
workshop tools and key messages are timely and accurately based on the project schedule. Confirm with the project manager that this information is correct and
accurate. Ensure that all tools are printed and appropriately packaged prior to the Managers' Project Alignment Workshop. If there are marketing costs assigned to the
project, ask the project manager to see if key messages that are branded to the project can be created as posters, banners, etc.
Prepare Communication Guidelines
Communication Guidelines are strategies that can be given to or coached to the managers for accomplishing their goals. Project communications will support the change
effort and provide the vehicle for generating two-way communications. In order to do this there is a need to take part in effective communication and this workshop
provides an excellent platform to practice. Provide Communication Guidelines to be coached by the change management specialist. Introduce them to the project
Communication Strategy developed in the Executive Alignment Workshop (OCM.030).
A successful Managers' Project Alignment Workshop depends on a well-planned and well-structured timetable. The Facilitation Grid includes selected exercises and
activities and topics for discussion that will be implemented during the workshop to accomplish the workshop objectives presented in a well-planned and well-structured
timetable. It is a timetable for the entire time of the workshop showing what activities or exercises will be accomplished at what time. It should include time allocated for
breaks and meals.
Involve the project sponsor from the executive level to open the workshop and communicate the alignment that is required. Identify key issues to address. Create specific
exercises and activities (if available, select from a directory or repository of exercises and activities) that will be implemented during the workshop to accomplish the
workshop objectives. Develop a Facilitation Grid and timetable that ensures that the discussion focuses on the need to support managers and their responsibilities in
transitioning their people to adopt to the new technology and processes.
The Facilitation Grid dictates the following:
Managers' Project Alignment Workshop Objectives
Assumptions
Background
Validate the Managers' Project Alignment Workshop Facilitation Grid with the project sponsor. Obtain the signoff on the completed workshop materials including the
Facilitation Grid with the project manager and required client representatives. Socialize the materials with the project manager so he can promote cooperation, provide
input and validate work products. This collaboration facilitates the agreed upon organizational change. Revise and re-socialize where and when required. Do not conduct
the workshop without the validation and required signoff.
prior to conducting the Managers' Project Alignment Workshop to make sure last minute preparations have been accomplished.
manager determine and document responsibilities for the Managers' Project Alignment Workshop as soon as possible in order to ensure that the workshop is adequately
planned. This collaboration facilitates the agreed upon assignment of workshop activities, roles and responsibilities.
Back to Top
Change Management
Specialist
Design and prepare the materials for the Managers' Project Alignment Workshop. 100
Client Project Manager Assist with the workshop preparation. *
Back to Top
PREREQUISITES
Prerequisite Usage
Governance Rules (OCM.030)
The Executive Business Objectives and Governance Rules captures the decisions made during the Executive Alignment
Workshop about project vision, objectives, and success criteria in order to communicate them to the project team,
middle managers, and end users and manage the impact of the project on the organization as well as to mitigate
organizational risks.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
OCM-070_MGRS_PROJ_ALIGNMENT_WORKSHOP_MATERIALS.DOC MS WORD - Use this template to prepare for the workshop.
Back to Top
The Managers' Project Alignment Workshop Materials are used:
to conduct the Managers' Project Alignment Workshop
Distribute the Managers' Project Alignment Workshop Materials as follows:
Back to Top
QUALITY CRITERIA
Back to Top
OCM.080 - CONDUCT MANAGERS' PROJECT ALIGNMENT
WORKSHOP
In this task, you conduct the Managers' Project Alignment Workshop. It is specifically designed to create awareness and involvement. The purpose of the Managers'
Project Alignment Workshop is to:
ACTIVITY
Back to Top
WORK PRODUCT
Aligned Managers - Aligned Managers are able to help put in place initiatives to manage and understand cultural reactions and mitigate specific risks.
Back to Top
TASK STEPS
1 Prepare for workshop Session Planning Checklist(s) Use the Session Planning Checklist(s) from the Managers' Project Alignment Workshop
Materials (OCM.070).
2 Facilitate the workshop. Aligned Managers Aligned Managers have knowledge of the project vision, direction and strategies and
know their individual roles and responsibilities.
3 Perform post-workshop wrap up and
tool hand-off.
Updated Materials, Workshop
Results and Tools
Document and distribute workshop results.
4 Provide ongoing coaching to the
organization managers.
Ongoing Coaching Ongoing Coaching is provided during the project to support the managers as change
agents.
Back to Top
APPROACH
Getting buy-in and engagement from the managers within an organization is one of the most important tasks to accomplish early in the project. They are typically the first
to face resistance from the end-user community and are often directed by the executives to take ownership in ensuring that the new technology and processes will be
adopted by all those who are affected by the change. The managers can also provide accurate information that relates to the overall change readiness, points of
resistance, support and can easily identify those persons that we can leverage to help support and model the change. Therefore, it is very important to provide them with
project related details early on in the project.
The Managers' Project Alignment Workshop requires at least a half day meeting.
Prepare for the Workshop
Use the Session Planning Checklist(s) from the Managers' Project Alignment Workshop Materials (OCM.070). Ensure that all of the work from the task, Design Managers'
Project Alignment Workshop (OCM.070) has been performed.
Facilitate the Workshop
Facilitate the workshop according to the prepared Facilitation Grid that has been approved by the client. Park issues that are lingering and require further discussion
ensure that those issues are addressed immediately. Take into consideration that the managers will be expected to serve as a model for the change. They will have to
work with the direct reports, change agents and colleagues to support the organization, departments and individuals in their project related efforts. The managers must
#TOP #TOP
feel that they will be supported during the transition but they must be aligned with their executives. The workshop should accomplish the following:
Get managers engaged early and often.
Discuss the concerns brought up by the managers regarding potential challenges from their respective target groups.
Inform the managers on the changes that are taking place.
Obtain the voice of the managers - gather their input.
Integrate the managers' input in the Change Management Roadmap.
Communicate all of the work conducted by the executives in order to ensure alignment, accuracy and consistency.
Align middle management with executive understanding and commitment to the project.
Prepare managers to adopt and support the transition.
Build awareness of the project objectives, potential challenges and other high-level success factors.
Align managers behind the project and start to obtain their buy-in.
Educate/assist business unit managers in understanding their roles in making the project successful.
Communicate challenging situations and issues that the managers must address.
Enable the managers to practice effective two-way communication and processes that are both critical success factors.
Clarify decisions and directions that have been made by the executives regarding the project in order to support the planned initiatives, as required.
Upon completing the workshop, the managers should be aligned and understand their role in the alignment effort. As part of the workshop wrap up ensure that the
mangers have a true understanding as to what the executives have established and will be expected to act in accordance with the Executive Business Objectives and
Governance Rules (OCM.030).
After the workshop, provide tools and materials to support the Aligned Managers in cascading the alignment to the end-user community. Ensure that the tools fit the client
culture and both relevant and timely to the current state of the project. Update any materials, if necessary and document results.
Just because the workshop is over does not mean the support ends. Ongoing coaching should be provided to the managers within the organization, as required. It is vital
for the managers to know that they are supported. Ensure that an executive provides communication to the managers so that their influence and challenges are
recognized and their efforts will be supported. Reach out to the managers on a consistent basis to address their department-specific questions and concerns so they can
support the change effort and feel confident in their ability to engage and obtain buy in from the end-user community. Depending on the communication guidelines of the
project, provide the necessary resources that are readily available to them in order to build and sustain the change momentum. Drive the managers to the project web
site for accurate project related information. Have them utilize the network of their peers and ensure that the project news letters are read and understood by the end-user
community. Always enforce that the managers have the support and can utilize the change agents as required.
manager support each other during the Managers' Project Alignment Workshop in order to present cohesive and collaborative leadership to the organization
management. This collaboration facilitates the agreed upon workshop activities as well as ensuring the managers are aware of the goals for the organization
transformation and understand how they can support the organizational change.
Back to Top
Change Management
Specialist
Facilitate the Managers' Project Alignment Workshop. Provide ongoing coaching. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Managers' Project Alignment Workshop Materials
(OCM.070)
The Managers' Project Alignment Workshop Materials consists of all the materials necessary to conduct a
successful workshop detailing the project vision, objectives and challenges.
Rules (OCM.030)
The Executive Business Objectives and Governance Rules are communicated to the managers in this
workshop.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Aligned Managers have knowledge of the project vision, direction and strategies and know their individual roles and responsibilities. They:
are aware of the project objectives, potential challenges and other high-level success factors
are committed to managing potential political issues
can act as a model in their environment and to help them accommodate to the changes
Information gathered from the Aligned Managers during this workshop is used:
to put in place initiatives to manage and understand organizational changes
to provide additional tools for the managers so that they can continue to mitigate specific risks
Back to Top
QUALITY CRITERIA
Are the managers practicing an effective two-way communication and processes?
Back to Top
OCM.090 - DESIGN CHANGE AGENT WORKSHOP
In this task, you design the Change Agent Workshop. The purpose of the Change Agent Workshop is to provide leaders and key stakeholders (change agents) from
impacted groups with the skills and knowledge they need to effectively lead the change, manage end-user expectations and support two-way communications for their
area.
ACTIVITY
Back to Top
WORK PRODUCT
Change Agent Workshop Materials - The Change Agent Workshop Materials contains all the necessary materials to conduct a successful Change Agent Workshop.
Back to Top
TASK STEPS
Session Planning Checklist
1 Schedule workshop. Workshop Logistics The Workshop Logistics section of the Change Agent Workshop Materials provides the pertinent logistical details
for the workshop (for example, date, location, times, etc.).
2 Identify and invite
participants.
Workshop Participants
List
Invitation
Memorandum
The Change Agent Workshop Materials contain a section to capture the list of the participants, as well as a
template for an Invitation Memorandum that can be used to invite the participants to the workshop.
3 Prepare any presentation
materials.
Workshop
Presentation
Materials
The Workshop Presentation Materials are the materials that will be used during the workshop.
4 Prepare Workshop Tools. Workshop Tools Workshop Tools are provided to the the change agents and are designed to help them successfully fill their
project role. The Workshop Tools include a set of workshop / meeting topics to be used as a guide for the
workshop/meetings.
5 Build a Facilitation Grid. Facilitation Grid The Facilitation Grid includes selected exercises and activities that will be implemented during the workshop to
accomplish the workshop objectives
6 Validate the Facilitation
Grid with the client.
Validated Facilitation
Grid
The Facilitation Grid should be validated by the project manager, the change management specialist and the
client and should be updated as necessary.
7 Prepare Session
Planning Checklist(s).
The Session Planning Checklist provides a way to verify that all necessary details for the workshop have been
addressed.
Back to Top
APPROACH
The client organization should identify key leaders (managers as well as business owners and users) who represent the stakeholder groups most affected by the
proposed changes. Key individuals from these groups participate in the workshop and are trained as change agents for their respective groups. During the workshop,
these change agents are given tools, templates, coaching and information to enable them to work effectively with other users who are directly impacted by the changes.
The Change Agent Model builds upon a strong core change management team and fully leverages the power of relationships and social networks (that already exist in
the organization) to enable the change effort.
Schedule Workshop
Along with the facilitating organization (for example, Oracle) and client project managers, determine the Change Agent Workshop logistics, including:
date
#TOP #TOP
location
times
proposed agenda
Speak with project managers in order to determine how materials, printing, food, drinks and refreshments will be provided.
Collect the names and contact information of those key stakeholders that will be required to attend the workshop from the facilitating organization and client project
managers. Ensure that the correct participants are invited to the Change Agent Workshop. Determine how you will provide make up sessions or conduct one-on-one
training sessions for change agents who are unable to attend the scheduled workshop.
The invitation should be sent by the project sponsor to ensure that the workshop will be well attended. The impact of people missing will push out the timeline as each
designated change agents input is required. Include an RSVP so that set up, materials, food, etc. is sufficient. You may have already identified the participants. If not,
use the Change Agent Criteria to determine who the workshop participants should be and invite them to the workshop.
Prepare Any Presentation Materials and Tools
Ensure that all presentation materials along with tools and templates are printed and appropriately packaged prior to the Change Agent Workshop. Reserve all items that
are necessary to run the workshop and ensure that they are in the room prior to the start of the workshop. Such items include pens, markers, whiteboards, easels, paper,
projectors etc. Additional items may include name tags, badges and security passes.
Be consistent with your messaging as you develop your presentation materials. It is also important that the participant have tools as a take away to re-enforce messages
given in the workshop.
presentation.
Develop and/or validate the following workshop materials/tools:
Change Agent Workshop Presentation
Job Aids
The Change Agent Workshop Presentation should cover the following key topic areas:
Project Summary (vision, objectives, scope, critical success factors, and timeline)
Change Management Team Overview (Team Charter, Operating Principles, Team Structure, Key Deliverables, Project Management Approach)
Change Agent Role (selection process, role responsibilities, and team operating model)
Change Agent Knowledge and Skill Areas :
Understanding and Experiencing Change
Stakeholder Management & Change Communications
Managing Change Resistance
Enabling Change
Leading Change
Change Management Roadmap / Communication Campaign (Activities and Delivery Responsibilities)
Next Steps
A successful Change Agent Workshop depends on a well-planned and well-structured timetable. The Facilitation Grid includes selected exercises and activities and topics
for discussion that will be implemented during the workshop to accomplish the workshop objectives presented in a well-planned and well-structured timetable. It is a
timetable for the entire time of the workshop showing what activities or exercises will be accomplished at what time. It should include time allocated for breaks and meals.
The Facilitation Grid includes selected exercises and activities that will be implemented during the workshop to accomplish the workshop objectives. For each workshop
objective that must be accomplished prepare an appropriate exercise. Develop a Facilitation Grid to assist the presenter in staying on track and ensuring that the
exercises, key messages, and objectives of the workshop are achieved.
Change Agent Workshop Objectives
Assumptions
Background
Validate the Change Agent Workshop Facilitation Grid with the client change management lead. Present the draft Facilitation Grid to the client for review, feedback, and
approval. Present and discuss the objectives, components, and desired outcomes of each individual exercise and activity listed in the draft Facilitation Grid. Review the
workshop tools that have been created for the session. Review the anticipated length of each exercise/activity to ensure that you have enough time to complete your
selected exercises/activities within the allotted workshop timeframes. Adjust workshop exercises and activities (as needed) based on client feedback.
prior to conducting the Change Agent Workshop to make sure last minute preparations have been accomplished.
manager determine and document responsibilities for the Change Agent Workshop as soon as possible in order to ensure that the workshop is adequately planned. This
collaboration facilitates the agreed upon assignment of workshop activities, roles and responsibilities.
Back to Top
Change Management
Specialist
Design and prepare for the Change Agent Workshop. 100
Client Change Management
Lead
Assist in the design and preparation of the Change Agent Workshop. *
Client Project Manager Be transparent and share information with stakeholders. See that change agents are involved in project meetings, where
applicable. Ensure that those affected by the technological changes are able to participate in design decisions and working
sessions. Ensure that the change agents will be available to do the work.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Change Agent Structure (ENV.EOCM.070) If a Change Agent Structure was identified in Envision, these are the key stakeholders who should participate in the
workshop.
Governance Rules (OCM.030)
Alignment Workshop about project vision, objectives, and success criteria in order to communicate them to the project
team, middle managers, and end users and manage the impact of the project on the organization as well as to
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
OCM-090_CHANGE_AGENT_WORKSHOP_MATERIALS.DOC MS WORD - Use this template to prepare for the workshop.
Back to Top
The Change Agent Workshop Materials are used:
to conduct the Change Agent Workshop
Distribute the Change Agent Workshop Materials as follows:
Back to Top
QUALITY CRITERIA
Have you prepared a Facilitation Grid and Change Agent Workshop Presentation that have been validated and approved by the client?
Back to Top
OCM.100 - CONDUCT CHANGE AGENT WORKSHOP
In this task, you conduct the Change Agent Workshop. The purpose of the Change Agent Workshop is to provide leaders and key stakeholders (who may take the role of
change agents) from impacted groups with the skills and knowledge they need to effectively lead the change, manage end-user expectations and support two-way
communications for their area.
ACTIVITY
Back to Top
WORK PRODUCT
Enabled Change Agents - Enabled Change Agents have the ability to effectively model the change and use their networking skills to influence positive outcomes for the
project.
Back to Top
TASK STEPS
1 Prepare for the workshop. Session Planning Checklist(s) Use the Session Planning Checklist(s) from the Change Agent Workshop
Materials (OCM.090).
2 Facilitate the workshop. Enabled Change Agents Enabled Change Agents can manage cultural reactions on a daily basis.
3 Perform post-workshop wrap up and tool
hand-off.
Updated Materials, Workshop Results
and Tools
Update any materials, if necessary. Prepare tools for Change Agents.
Document results.
4 Provide ongoing coaching. Ongoing Coaching Ongoing Coaching is provided during the project to support the change agents.
Back to Top
APPROACH
The Change Agent Workshop provides change agents with the knowledge and skills they need to role model the change and teaches them how to effectively use their
networking skills to achieve positive outcomes for the project. During the workshop, change agents are provided tools, templates, and coaching on how to rollout the
change management and communication activities for their area.
Use the Session Planning Checklist(s) from the Change Agent Workshop Materials (OCM.090). Ensure that all of the work from the task, Design Change Agent Workshop
(OCM.090) has been performed.
Consider if it is feasible to conduct the Change Agent Workshop concurrently with the Team-Building Workshop (OCM 60). Holding these workshops together provides a
great opportunity for core project team members and change agents to interact with each other. Facilitated social interactions between core and change agent team
members will illustrate the natural networking opportunities that exist on the project. Working relationships that form as a result of these social gatherings can also
increase team collaboration among people from different countries and cultures.
Facilitate the workshop according to the prepared Facilitation Grid that has been approved by the client.
Discuss the project vision, objectives and success criteria with the change agents.
Provide the change agents with an opportunity to share information, collaborate and have an opportunity to ask questions and gain a better understanding of the
project.
Coach the change agents so they are able to deploy the communications in their area and manage the interaction with the end users.
Identify change agent concerns, issues and participation constraints.
EXPERIENTIAL-DRIVEN APPROACH
#TOP #TOP
The workshop is facilitated using an experiential rather than concept driven approach. The experiential approach enables better retention of key learnings and provides
participants with sufficient opportunities to apply what they learned during the workshop. The facilitator should encourage participants to share work related experiences
and to exchange their ideas/perspectives on the topics and information covered during the workshop. The facilitator must also identify change agent issues; questions,
concerns, and support needs during the session and assure participants that ongoing coaching will be made available to them. Some additional tools and templates may
also be provided to change agents after the workshop based on need. At the end of the workshop participants will:
Understand the actions they must take to role model the change
Be confident using change management and communication techniques with their network
Be capable using the change management tools and templates to complete their work
Feel comfortable enough to contact the change management core team should they encounter issues or have questions/concerns.
Be able to facilitate and deliver effective two-way communications within their area
RELATIONSHIP BUILDING
If the project is a global (or large) implementation, many of the change agents may not know each other or members of the core project team. As the project is being rolled
out, change agents will often need to rely on each other for assistance and support. Additionally, change agents can share valuable lessons learned with other change
agents as they attempt to deploy communication activities within their respective areas. Change agents may also hold misconceptions about the projects objectives
because of stories they heard though the rumor mill. As you conduct the workshop, be sure to provide change agents with sufficient opportunities to:
Build relationships
Share information
Ask questions
Gain an accurate understanding of the projects purpose and objectives
COACHING
Many of the change management concepts and techniques covered during the workshop will be new to change agents. It is helpful if change agents can gain some
hands on experience working with the tools/templates in the session before using them in their respective implementation areas. Have the change agents begin working
on one of the activities they will be responsible for completing during the areas implementation. A good activity they can complete during the session is to develop a
mini communications deployment plan for their area that is aligned with the projects communication campaign. In their communication deployment plan they should
outline:
The internal communication vehicles they can leverage to deliver project messages
The anticipated challenges or issues they feel they will encounter as they try to perform their communications role
The support they need from the Change Management Team to overcome this issues/challenges they will face
Provide constructive feedback and coaching on the communication plans and draft deliverables that the change agents complete during the session.
ISSUES AND CONCERNS
Change Agents are sometimes selected for the role by their boss without any discussion ever taking place. They are told (via email) that they must attend a Change
Agent Workshop and no other information or supporting rationale is provided to them. In other scenarios, personal or professional challenges significantly impact change
agents ability to fully participate in the project. Often, you find about these extenuating circumstances after a change agent misses a key deadline or does not complete a
task as agreed upon. To mitigate these risks and to start building a relationship based on two-way dialogue, conduct an exercise during the workshop that will enable you
to quickly identify change agent concerns, issues, and participation constraints.
Upon completing the workshop, update any workshop materials, as needed and document and distribute workshop results to participants.
Capture and share the major themes, issues, concerns, and prioritized actions resulting from the Change Agent Workshop. Also summarize and include the participant
workshop evaluation scores as part of your workshop outcomes. If possible, document the workshop outcomes directly into the Change Agent Workshop presentation
that was used to conduct the workshop. The aforementioned can then be easily presented and distributed to workshop participants and the PMO.
Change agents will expect that the concerns, issues, and ideas they shared during the workshop will be further considered (and acted upon) by the client change
management lead and project manager. Consequently, it is important that the outcomes of the session are both captured and shared with participants and the PMO after
completing the workshop. During the project phases, change agents will deploy communication and change management activities. Build enough time in your plan to
distribute information to change agents a few days before launching events so they have adequate time to adapt and deploy the messages within their
country/region/culture. Change Agents will need pre-formatted presentations, tools/templates to support each activity, and check lists to ensure that they have completed
all the necessary process steps.
Provide Ongoing Coaching to Change Agents
Change agents will encounter challenges as they begin to apply the workshop techniques and templates within their business unit. Consequently, it is imperative that
ongoing coaching be provided to change agents, as required throughout the project lifecycle. Coaching can be done on a one-on-one basis, via a web cast, or in a group
format during subsequent Change Agent Workshops or working sessions. During your coaching sessions, be sure to provide clear direction to change agents, encourage
them to share key learnings with their colleagues, and ask them to report out on actions they have taken to implement the Change Management Roadmap and
Communication Campaign for their area. Prior to conducting coaching sessions, get input from business unit leaders regarding key change management challenges and
issues the implementation team might face in the different areas/regions/countries. Before you conduct your coaching session, you should also try to identify the specific
change management knowledge and skill areas on which each change agent requires coaching.
manager support each other during the Change Agent Workshop in order to present a cohesive and collaborative presentation to the change agents. This collaboration
facilitates the agreed upon workshop activities as well as ensuring the change agents are aware of their roles and responsibilities.
Back to Top
Change Management
Specialist
Facilitate the Change Agent Workshop. Train change agents to deploy the change management activities and
communications.
100
Client Project Manager Be transparent and share information with stakeholders. See that change agents are involved in project meetings, where
applicable. Ensure that those affected by the technological changes are able to participate in design decisions and working
sessions. Ensure that the change agents will be available to do the work.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Change Agent Workshop Materials
(OCM.090)
The Change Agent Workshop Materials consists of materials necessary to conduct a successful Change Agent
Workshop.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
Back to Top
Enabled Change Agents can model the change, using networking to influence change on a daily basis. They:
are able to deploy the communications in their area and manage the interaction with other end users in order to model the change and mobilize peers.
can bring attention to the concerns and cultural requirements from their perspective target groups
Back to Top
QUALITY CRITERIA
Have the change agents completed workshop evaluation materials?
Do the change agents understand their role?
Are the change agents executing their role as designed?
Is there two-way communication between the change agent and the core project team?
Back to Top
OCM.110 - DEVELP CHANGE READINESS ASSESSMENT
STRATEGY AND TOOLS
A Change Readiness Assessment determines the organization's capacity to undertake and sustain large-scale change. The Change Readiness Assessment identifies
change enablers, change barriers and risks that must be managed for the project to achieve its desired outcomes.
In this task, you develop the Change Readiness Assessment Strategy and create, design and build the Change Readiness Assessment Tools to support the strategy.
ACTIVITY
Back to Top
WORK PRODUCT
Change Readiness Assessment Strategy and Tools - The Change Readiness Assessment Strategy and Tools includes the Change Readiness Assessment Strategy,
Assessment Team, Assessment Communications and any Change Readiness Assessment Tools (Stakeholder Analysis Grids, Focus Group Grids, Surveys, etc.) needed
to assess an organization's readiness for change.
Back to Top
TASK STEPS
1 Design the Change Readiness
Assessment Strategy.
Change Readiness
Assessment Strategy
The Change Readiness Assessment Strategy defines the objectives, data gathering approach and
target audience for the Change Readiness Assessment.
2 Identify Assessment Team. Assessment Team The Assessment Team is the core and extended project team members who participate in the
assessment design and administration process.
3 Develop the Assessment
Communications.
Assessment
Communications
The Assessment Communications are the messages that must be developed and delivered to the
organization to conduct the assessment process.
4 Create, design and build
necessary Assessment Tools.
Change Readiness
Assessment Tools
The Assessment Tools include all the tools that support the assessment effort. Some examples are:
Stakeholder Analysis Grids
Focus Group Grids
Surveys
Back to Top
APPROACH
Consider the organizational culture and companys previous experience with assessments when selecting assessment tools to use for the project. For example, if
employees do not trust company surveys or are not comfortable with how survey data has been used in the past, than you may want to select focus groups or interviews
as an alternative. Data collected via the Change Readiness Assessment is used to complete the Change Readiness Assessment Analysis and Recommendations
(OCM.120), which is used to complete the Communication Strategy and Change Management Roadmap (OCM.130).
Develop Change Readiness Assessment Strategy
The Change Readiness Assessment Strategy defines the objectives of the assessment and data gathering approach, along with the target audience for the readiness
assessment. It is important to define and reach agreement with the Steering Committee regarding the overall assessment approach and objectives. Conduct a
Stakeholder Analysis to determine from whom you need to gather change readiness assessment data. Specify what you intend to accomplish as a result of conducting
the readiness assessment. In your strategy, articulate the approach you will use to gather assessment data from end users and key stakeholders. The three techniques
most often used to gather readiness assessment data include:
Stakeholder Interviews
Focus Groups
Surveys
These techniques can be used alone or in combination, depending on the level of information desired, the culture of the organization, and various stakeholder
demographics. The higher the relative importance of the target group in question, the more likely you are to use multiple data gathering tools to evaluate the change risks
and impacts to them.
Select a data gathering approach that:
Takes into consideration any project constraints (for example; time, budget, workload, etc.)
Produces reliable data
Causes minimal disruption to the clients business operations
Use a Stakeholder Analysis Grid to help you determine relevant assessment tools by target audience.
Identify Assessment Team
Identify the Assessment Team. The Assessment Team includes the core and extended client project team members who participate in the assessment design and
administration process. It is important to identify and secure assessment team members from stakeholder groups and business units that will be significantly impacted by
the changes. Assessment team members can be change agents, key stakeholders, business unit leaders, client project team members, or communication specialists
within the client organization.
Conduct a series of large group working sessions with Assessment Team members to:
Share the assessment design, development, and administration process.
Gather feedback on the data gathering approach.
Identify and confirm target audiences for the assessment.
Validate the initial assessment focus (or topic) areas and questions.
Distribute and discuss assessment communications.
Develop assessment conclusions and recommendations.
The objectives of the work session are:
Confirm target groups and individuals interviews
Identify assessment content per target group
Ensure key leaders' involvement
Set up assessment activities
Develop Assessment Communications
Assessment Communications are the messages that must be developed and delivered to the organization so that the readiness assessment process can be completed.
The assessment communication messages and their anticipated timing (both from a development and delivery standpoint) should be added to the overall Communication
Strategy and Change Roadmap for the project.
Work with the change management specialist and/or communication specialist to identify internal communication vehicles that can be leveraged for the assessment
process. Respondents will have numerous questions regarding the assessment that may include the following:
Why are we doing this?
How long will this process take?
What will happen to the data I provide?
Additionally, participants will need to know what actions they must complete and when they must complete them so they can plan their involvement in the assessment
process accordingly.
Create, Design and Build Assessment Tools
The assessment tools include all the tools that must be deployed to complete the readiness assessment process. These tools can include stakeholder analysis grids,
focus group grids and online surveys. It is important to design and build tools that:
Support the assessment objectives and strategy
Take into consideration assessment constraints
Generate reliable information and promote both ease of use and ease of analysis
Use the outcomes of your working sessions with the readiness assessment team to assist you with the tool development process. To build the assessment tools you
should complete the following activities:
Define and validate the assessment items/questions
Develop the data collection templates/grids
Print or deploy your assessment tools online, as appropriate.
Conduct a pilot test of your assessment tools with a representative sample of your target audience
Gather feedback from your pilot test and revise the assessment tools, as needed
manager work to develop the Change Readiness Assessment Strategy and Tools in order to ensure that the project information needed for the assessment and tools are
accurate, cohesive and aligned with the project activities. This collaboration facilitates the agreed upon assessment and set of tools as well as the assignment of roles
and responsibilities for the assessment itself.
Back to Top
Change Management Specialist Define the assessment target audience and identify and secure assessment team members
from impacted stakeholder groups. Lead the Change Readiness Assessment and analyze
results and recommend change management activities to address the human and
organizational risks of the project.
100
*
Client Project (Change Management) Sponsor The Change Management Sponsor is a leader who can present change management risks and
action plans (identified via the assessment) at the Steering Committee level. This individual
fully supports the readiness assessment and has the position power/credibility to ensure
assessment process compliance.
*
Client Project Manager Be transparent and share information with stakeholders. See that change agents are involved
in project meetings, where applicable. Ensure that those affected by the technological changes
are able to participate in design decisions and working sessions. Ensure that the Assessment
Team is available to do the work.
*
Client Assessment Team Participate in the assessment design, development, administration, and analysis process. *
Back to Top
PREREQUISITES
Prerequisite Usage
Change Management Strategy (ENV.EOCM.060) If a Change Management Strategy was done in Envision, use it as an input for the assessment to avoid
duplication.
Enabled Change Agents (OCM.100) Enabled Change Agents may be part of the Assessment Team.
(OCM.030)
Executive Alignment Workshop about project vision, objectives, and success criteria for the project. This
document also outlines actions that must be taken by leadership (at all levels) to mitigate organizational
risks for the project.
Back to Top
TEMPLATES AND TOOLS
OCM-
110_CHANGE_READINESS_ASSESSMENT_STRATEGY_TOOLS.DOC
MS WORD
Back to Top
The Change Readiness Assessment Strategy and Tools is used:
to gather assessment data
Distribute the Change Readiness Assessment Strategy and Tools as follows:
to the assessment team members to use appropriately
Back to Top
QUALITY CRITERIA
Has the Change Readiness Assessment Strategy and Tools Tools been validated and approved by the client?
Back to Top
OCM.120 - CONDUCT CHANGE READINESS ASSESSMENT AND
ANALYZE DATA
In this task, you use the Change Readiness Assessment Strategy and Tools (OCM.110) to gather and analyze change readiness data and develop the recommendations
for Communication Strategy and Change Management Roadmap (OCM.130).
ACTIVITY
Back to Top
WORK PRODUCT
Change Readiness Assessment Analysis and Recommendations - The Change Readiness Assessment Analysis and Recommendations document is a high-level
analysis (executive summary) of the assessment data that includes change management recommendations to address the issues and risks identified via the assessment.
Back to Top
TASK STEPS
1 Gather assessment data. Quantitative and Qualitative
Assessment Data
The Quantitative and Qualitative Assessment Data is the change readiness data collected via the
Assessment Tools.
2 Analyze data. Assessment Analysis The Assessment Analysis provides a comprehensive analysis of the collected data and compares the
client data leading practices.
3 Develop recommendations. Assessment
Recommendations
The Assessment Recommendations are communication and change management recommendations
that address key issues/risks, can realistically be implemented, and that clearly tie to the principles of
successful change to desired business results.
4 Validate Change Readiness
Assessment Analysis and
Recommendations.
Validated Change Readiness
Assessment Analysis and
Recommendations
The Validated Change Readiness Assessment Analysis and Recommendations have been validated
by the change management specialist and the Assessment Team.
Back to Top
APPROACH
The goal of this task is to gather and analyze assessment data and translate the analysis into recommendations for the Communication Strategy and Change
Management Roadmap (OCM.130). Change Readiness Assessment data is gathered and analyzed to determine the organization's capacity to undertake and sustain
large-scale change. The assessment will identify risks to mitigate, expectations to manage, and communication needs by target group.
Gather Assessment Data
The Change Readiness Assessment data is collected from the surveys, interviews, and focus groups that are conducted with impacted target audiences. Gathering
assessment data allows you to accurately identify change enablers, change barriers, and risks that must be managed for the project to succeed. Through the assessment
data you can also determine the expectations, concerns, and needs of each target audience.
Use the Change Readiness Assessment Strategy and Tools (OCM.110) to gather both quantitative and qualitative assessment data.
Complete the following:
Determine how the assessment data will be used and shared (for example, position on respondent anonymity).
Determine location, schedule and availability of assessment respondents.
Schedule assessment events.
Deploy effective assessment communications.
Launch survey/facilitate focus groups.
Conduct interviews.
Maximize the opportunity to involve stakeholders.
Minimize disruption to the work place.
Prepare the Change Readiness Assessment Team to support the assessment activity and mobilize their peers.
Gather data information from survey/focus groups/interviews.
DOCUMENT AND COMPILE ASSESSMENT DATA
The approach that is used to document and compile assessment data can impact the accuracy of the data. During interviews and focus groups, there will be both
consistencies and inconsistencies in the collected data and is therefore important to use a grid that enables you to quickly capture and tally up the consistencies and
inconsistencies. Have each question pre-filled and assign each interviewee a number. If the interviewee says something that corresponds to anothers response check
the box that corresponds to that individual for the specific question.
Analyze Data
Analyze the assessment data that was collected. The Assessment Analysis should provide a comprehensive analysis of the collected data and compares the client data
with normative data.
A quantitative analysis could include calculations of the average, standard deviation, and response rate polarity for each assessment survey question. Use qualitative data
to supplement and further expand on the key findings from your survey. A qualitative analysis can be conducted by reviewing the survey comments, interview notes, and
focus group findings to identify common themes. When conducting the readiness assessment analysis:
Substantiate findings with well-documented data analysis.
Give data life and immediacy with graphical representations and quotes.
Identify both strengths and areas for improvement; look for leverage points.
Move from cause to effect; explain what the data means.
Look for underlying causes.
Compare data across the different respondent groups to determine if specific groups/regions present different levels of change readiness per assessment topic:
Conduct a thorough analysis of the qualitative comments to identify when (and why) specific respondent groups have had different change experiences (for
example, a recent negative change, more dissatisfaction with communication/training, less trust with the management team, etc.).
Develop Change Readiness Assessment Analysis and Recommendations
Develop analysis and recommendations based on the assessment data that was gathered. The Change Readiness Assessment Analysis and Recommendations (once
accepted by the steering committee) serve as the foundation for the Communication Strategy and Change Management Roadmap (OCM.130).
The Change Readiness Assessment Analysis and Recommendations are communication and change management recommendations that address key stakeholder
issues/risks, needs, expectations, can realistically be implemented, and that clearly tie to the principles of successful change to desired business results. The
recommendations are developed using leading practices. Each assessment recommendation is developed to mitigate a specific risk, respond to a specific need, or
manage expectations.
Collaborate with change management specialist to create recommendations that address key issues/needs/expectations and are compatible with the organization's
culture. When developing the Change Readiness Assessment Analysis and Recommendations:
Provide data to support each conclusion.
Emphasize both strengths and improvement areas as you present the findings.
Keep the language associated with findings neutral, a report of facts, not your judgment of them.
Tie recommendations to the assessment findings.
Limit the number of recommendations you propose.
Prioritize and sequence the recommendations in order of anticipated importance/impact.
Create recommendations that can realistically be implemented and measured.
Validate Change Readiness Assessment Analysis and Recommendations
The change management specialist and the Assessment Team should validate the Change Readiness Assessment Analysis and Recommendations before they are
presented to the project managers and to the Steering Committee for review and consideration.
To validate the Change Readiness Assessment Analysis and Recommendations:
Design and conduct a workshop with the assessment team to validate your initial analysis.
Challenge assessment team members to provide constructive feedback on the draft assessment analysis and recommendations.
Ask assessment team members, why the proposed recommendations will and/or will not work in their implementation area.
Work with assessment team members to jointly identify actions that can be taken to implement the proposed readiness assessment recommendations.
Use the feedback collected from assessment team members to revise your assessment recommendations before presenting them to the steering committee.
Present the validated assessment analysis and recommendations to project managers.
Due to political issues or concerns, it is possible that some assessment recommendations may need to be validated only with the change management lead,
project manager, or project director.
Include executive recommendations into the Sponsorship Program (OCM.040) for the project.
Once the Steering Committee has approved your assessment recommendations they should be incorporated into the Communication Strategy and Change
Management Roadmap (OCM.130).
manager support each other during the Change Readiness Assessment in order to present cohesive and collaborative leadership to the organization and address any
questions or concerns regarding the assessment. This collaboration facilitates the agreed upon Change Readiness Assessment activities and the associated roles and
responsibilities for the change management and project management teams.
Back to Top
Change Management Specialist Define the assessment target audience. Identify and secure Assessment Team members from impacted
stakeholder groups. Lead the Change Readiness Assessment, analyze results and recommend change
management activities to address the human and organizational risks of the project.
100
Project Manager See the above The Project Manager and OCM section. Effort for the project manager is not included at the task
level.
*
Client Project (Change Management)
Sponsor
The Change Management Sponsor is a leader who can present change management risks and action plans
(identified via the assessment) at the Steering Committee level. This individual fully supports the readiness
assessment and has the position power/credibility to ensure assessment process compliance.
*
Client Project Manager Be transparent and share information with stakeholders. See that change agents are involved in project meetings,
where applicable. Ensure that those affected by the technological changes are able to participate in design
decisions and working sessions. Ensure that the assessment team members will be available to do the work.
*
Client Assessment Team Participate in the assessment design, development, administration, and analysis process. *
Back to Top
PREREQUISITES
Prerequisite Usage
Preliminary Enterprise Change Readiness Assessment
(ENV.EOCM.060)
If available, use the Preliminary Enterprise Change Readiness Assessment from
Envision.
Change Readiness Assessment Strategy and Tools (OCM.110) Use the Change Readiness Assessment Strategy and Tools to gather the data.
Back to Top
TEMPLATES AND TOOLS
OCM-
120_CR_ASSESSMENT_ANALYSIS_AND_RECOMMENDATIONS.PPTX
MS POWERPOINT - Use this template to present the Change Readiness Assessment
Analysis and Recommendations.
Back to Top
The Change Readiness Assessment Analysis and Recommendations is used:
as input into the Communication Strategy and Change Management Roadmap
Distribute the Change Readiness Assessment Analysis and Recommendations as follows:
to the change management specialist responsible for building the Communication Strategy and Change Management Roadmap
to the change management specialist responsible for building the Communication Campaign
Back to Top
QUALITY CRITERIA
Have the Change Readiness Assessment Analysis and Recommendations been validated and approved by the client?
Back to Top
OCM.130 - BUILD COMMUNICATION STRATEGY AND CHANGE
MANAGEMENT ROADMAP
In this task, you translate the Change Readiness Assessment Analysis and Recommendations (OCM.120) into actionable plans, the Communication Strategy and
Change Management Roadmap, which together increase the organization's capacity to undertake and sustain the proposed changes. Ultimately, the Communication
Strategy is used to create a detailed Communication Campaign that along with the Change Management Roadmap is deployed at various milestones throughout the
project duration.
ACTIVITY
Back to Top
WORK PRODUCT
Communication Strategy and Change Management Roadmap - The Communication Strategy and Change Management Roadmap provide a leading practices
approach for effectively managing large-scale change and communicating it with impacted stakeholders/end-users throughout the change process. This work product
consists of a Communication Strategy based on the the Executive Business Objectives and Governance Rules (OCM.030) and the overall Change Management
Roadmap.
Back to Top
TASK STEPS
1 Review the Communication Strategy component of the Executive Business
Objectives and Governance Rules (OCM.030) if one was created. Review
the Change Readiness Assessment Analysis and Recommendations
(OCM.120). Use these two documents to create a standalone
Communication Strategy.
Communication
Strategy
The Communication Strategy provides a leading practices approach
for determining the areas for communication focus, themes and
topics for discussion, various audiences to receive communications,
types of vehicles for the communication messages and potential
events activities for target audiences.
2 Translate the Change Readiness Assessment Analysis and
Recommendations (OCM.120) into an actionable plan.
Change
Management
Roadmap
The Change Management Roadmap provides a timeline and
descriptions of activities to be conducted in order to increase the
organization's capacity to undertake or sustain the proposed
changes.
Back to Top
APPROACH
Review the Communication Strategy component of the Executive Business Objectives and Governance Rules if available. Review the Change Readiness Assessment
Analysis and Recommendations (OCM.120) and create the standalone Communication Strategy as required.
Utilize the results of the Preliminary Enterprise Change Readiness Assessment (ENV.EOCM.050) if one was done during an Envision engagement.
Incorporate the Change Readiness Assessment Analysis and Recommendations (OCM.120) into actions within the Change Management Roadmap. This work product
identifies major change management issues and challenges (risk areas) that should be addressed. Define the activities that are required to mitigate the major issues and
challenges. Focus only on the critical activities that will increase the organization's capacity to undertake and sustain the proposed changes.
The activities listed in the Change Management Roadmap should:
Create a sense of urgency.
Involve employees.
Communicate the vision.
Mitigate organizational risks.
Create opportunities for involvement.
Involve client leaders.
Align with project milestones.
Be based on leading practices.
Both the Communication Strategy and Change Management Roadmap will be used later to build the Communication Campaign (OCM.140) by defining and incorporating
the essential communication components that include a specific timeline and more detailed descriptions of communication activities to be conducted. From the Change
Management Roadmap, the activities are based on the following:
Impacts / Issues to Manage - to increase the organization's capacity to undertake or sustain the proposed changes
Action to Implement - to mitigate risk
Timeframe for Completion or Resolution - to determine the appropriate timing for the activities
manager work to develop the Communication Strategy and Change Management Roadmap in order to ensure that the information is accurate, cohesive and aligned with
the most current project activities and milestones. This collaboration facilitates the agreed upon assignment of roles and responsibilities for the various activities required
to complete the Communication Strategy and Change Management Roadmap.
Back to Top
Change Management Specialist Lead the Change Readiness Assessment, analyze results and recommend change management activities to address
the human and organizational risks of the project.
100
Client Project (Change
Management) Sponsor
The Change Management Sponsor is a leader who can present change management risks and action plans (identified
via the assessment) at the Steering Committee level. This individual fully supports the Communication Strategy and
the Change Management Roadmap and has the position power/credibility to ensure its successful rollout.
*
Client Project Manager Be transparent and share information with stakeholders. See that change agents are involved in project meetings,
where applicable. Ensure that those affected by the technological changes are able to participate in design decisions
and working sessions. Ensure that the change agents are available to do the work.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Preliminary Enterprise Change Readiness Assessment
(ENV.EOCM.050)
If available, use the Preliminary Enterprise Change Readiness Assessment from Envision.
(OCM.030)
Executive Alignment Workshop about project vision, objectives, and success criteria for the project. This
document outlines the actions that must be taken by leadership (at all levels) to mitigate organizational
risks for the project. It also contains an initial Communication Strategy that is the link among all of the work
products and it keeps people informed about the project. Incorporate the Communication Strategy from
this work product, if possible.
Recommendations (OCM.120)
Translate the findings and recommendations in the Change Readiness Assessment Analysis and
Recommendations into an actionable plan that will increase the organization's capacity to undertake and
sustain the proposed changes.
Back to Top
TEMPLATES AND TOOLS
OCM-
130_CHANGE_MGMT_ROADMAP.DOC
MS WORD - Use this template to start building the Change Management Roadmap and define the timeline and
descriptions of activities to be conducted in order to increase the organization's capacity to undertake or sustain the
proposed changes.
OCM-
130_COMMUNICATION_STRATEGY.DOC
MS WORD - Use this template to describe the aim, objectives and core elements of the communication approach to be
used including key stakeholder groups, messages and vehicles for the communications. You will use this template along
with the Change Management Roadmap to complete the Communication Campaign in OCM.140 by adding the detailed
communication components.
Back to Top
The Communication Strategy and Change Management Roadmap are used:
as input for the Communication Campaign
Distribute the Communication Strategy and Change Management Roadmap as follows:
to the change management specialist responsible for building the Communication Campaign
Back to Top
QUALITY CRITERIA
Have the Communication Strategy and Change Management Roadmap been validated and approved by the client?
Back to Top
OCM.140 - DEVELOP COMMUNICATION CAMPAIGN
In this task, you take the Communication Strategy and Change Management Roadmap (OCM.130) and design the essential communication components to create the
Communication Campaign. The Communication Campaign provides a process and tools to communicate effectively with stakeholders throughout the project and
includes detailed communication activities and timing.
ACTIVITY
A.ACT.DCMRCCI Deploy Change Management Roadmap/Communication Campaign - Inception
Back to Top
WORK PRODUCT
Communication Campaign - The Communication Campaign includes activities and a two-way communication initiative organized by audience, expectations, issues,
speaker, and preferred communication channels to communicate the right information to the right people using the right vehicle at the right time.
Back to Top
TASK STEPS
1 Review the Change Readiness Assessment Analysis and
Recommendations (OCM.120) and the Communication
Strategy and Change Management Roadmap (OCM.130).
None None
2 Confirm target groups. Target Group The Target Groups are the groups that are targeted for the change management event
or communication.
Use the Stakeholder Analysis created in the Change Readiness Assessment Strategy
and Tools (OCM.110) to help confirm target groups.
3 Select communication channels. Communication
Vehicles
The Communication Vehicles are the most effective communication delivery methods
for each target group.
Use the Internal Communication Channel Audit created with the Ad Hoc
Communications (OCM.010) that identifies and records in spreadsheet format all
communication channels currently in use in the client organization, their frequency,
person responsible and audience.
4 Determine communication media. Communication
Media
The Communication Media is the type of content delivered via the communication
vehicle, e.g., a Progress Report (media) delivered via email (vehicle) for each target
group or audience.
5 Develop key messages. Key Messages The Key Messages are tailored in the Communication Campaign to mitigate issues
identified. They are designed in a way to way a change momentum
6 Using the information gathered in the previous steps, add
the necessary communication details to the
Communication Campaign.
Communication
Campaign
The Communication Campaign translates the Communication Strategy into an
actionable plan.
Back to Top
APPROACH
The purpose of the Communication Campaign is to define key messages per audience, including media, frequency, delivery resources and reinforcement methods. It is
built on the Communication Strategy, incorporating the communication focus areas in detail and defining the level of commitment desired. The Communication Campaign
supports the change effort and provides the vehicles for generating the two-way communications around the key messages related to the project. It is aligned with project
milestones and builds momentum for change. The communication is built by audiences, which are the target groups already identified during the Change Readiness
Assessment (OCM.110, OCM.120 and OCM.130).
The Communication Campaign:
Helps individuals prepare for, understand and accept changes in their work environment
Informs and involves all affected groups whose commitment will be required
Provides accurate information to keep stakeholders focused
Reduces rumors and performance dips
Provides timely information, using a multi-media approach, tailored to various audience groups
Sustains the interest and energy of the team members and business representatives
In the task, Build Communication Strategy and Change Management Roadmap (OCM.130), the initial components of the Communication Campaign were created with
activities (Action to Implement) that are aligned with the identified issues and challenges, or potential risks (Impacts/Issues to Manage) that need to be managed. This
process includes an initial timeframe for completion or resolution in order to mitigate potential risks with the project. It also incorporates the anticipated risks identified in
the Change Readiness Assessment activity for each stakeholder group.
Using communication objectives from the Communication Strategy (OCM.130), define key messages per audience, including media, frequency, delivery resources and
reinforcement methods and the level of commitment desired. The fully defined Communication Campaign includes the change management activities that relate to
communications along with 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. It identifies communication events and key messages, as well as the
deployment date and accountability measures. It is aligned with the client's culture and the project milestones, builds momentum for change and leverages the current
client communication vehicles.
The Communication Campaign is ongoing, tailored, and two-way. One of the primary requirements of an effective Communication Campaign is that it provides
opportunities for gathering information as well as disseminating it.
The Change Readiness Assessment Analysis and Recommendations is designed to help the organization in being proactive in addressing current project challenges. It
was used to build the initial Communication Campaign. Use the Change Readiness Assessment Analysis and Recommendations to:
Help identify key challenges by population group
Determine the organization's willingness to participate in the project
Uncover past failures and successes of like projects
The initial information for the Communication Campaign was created in OCM.130 and identified Impacts/Issues to Manage (risks) and Actions to Implement. In this task,
you will continue to build the Communication Campaign by confirming and/or adding the following details:
Any additional anticipated risks (Impacts/Issues to Manage)
Communication events and key messages per risk identified (Key Messages)
Accountable person who will carry the message (Accountability)
Identify deployment date and accountability measures (Timeframe)
Create communications that address project risk (Action to Implement)
Help structure communications (Action to Implement)
Identify areas of special attention within the organization
Leverage the clients communication channels
Confirm Target Groups
Identify the different audiences affected by the project in the Communication Campaign. Organize and prioritize groups requiring communication. Document and group the
different audiences that need to be included in the communication -- key players, decision makers, users, and general audiences. Use the Stakeholder Analysis created
in the Change Readiness Assessment Strategy and Tools (OCM.110) to help confirm target groups.
All communication initiatives (Action to Implement) are built per audience. This is the most efficient way to reach people with their communication preferences and
managing their specific expectations, fears and concerns. This approach per audience provides the opportunity to tailor messages to reach and mobilize properly
impacted people. This ensures that the Communication Campaign addresses the key stakeholders as well as builds a strong foundation for:
Assisting in building a strong relevant and timely communication foundation
Ensuring the correct level of messaging is reaching the appropriate audiences
Creating messages that are relevant to the client audience
Validating the various audiences for message delivery
Usually the audiences are confirmed with the change agents or with the project managers.
Start with the Stakeholder Analysis created in the Change Readiness Assessment Strategy and Tools (OCM.110) to help confirm target groups. Use a Key Stakeholder
List, Core Project Team and Key Player List to identify who is affected by the project to ensure that messages can be targeted to meet the needs and challenges of
specific groups.
Key Stakeholder List - This list includes the impacted groups identified during the Organizational Readiness Assessment. You may also want to include the change
agent as an audience for the Communication Campaign. During the Communication Campaign, some communications will have to reach all employees to explain project
progress and to prepare them for the upcoming change. For this reason, a general audience will be created meaning that the communication initiative will be sent to all
employees.
Core Project Team - The core project team members will communicate frequently during the creation of the solution and it is crucial to keep them well informed and
ensure that they will communicate the right information during their work. Key messages from the project team are the key to mitigating risks and keeping the project on
time and on budget. The project team is also the group with the most intimate knowledge of where the project is, and where it is going.
Key Player List - Key players must be included in the communication audience. In fact, the Steering Committee is considered as an audience. The change agents are
also an audience due to close work done with them. The clients customers can also be considered as an audience.
The purpose of identifying the target groups is to organize and prioritize the groups requiring specific communication in order to validate the messages for delivery
throughout the project. Many of the messages about the project will be generic for all stakeholders; some will be targeted to a specific audience. For each of these
audiences, the following questions must be answered:
Who is the audience?
What behavior do we need of them?
How will the new technology affect them?
How significant are they to the success of the project?
What is their current level of commitment?
What role(s) will they play?
What are their major concerns?
Who should communicate the messages to them?
Select Communication Channels
Identify the most appropriate and effective communication delivery method (vehicle) for each communication within the client culture.
In organizations, there are different ways to reach people based on the culture, the past communication experience and the leadership style. Some channels may be more
efficient than others for reaching people during a project. The communication channels are used to reach audiences in different ways. Examples of channels are:
Staff Meetings where the most important topics are communicated
Official communication channels, such as, the corporate newsletter
New channels created by the project, for example, Communication Cascade from project team to Advisory Committee to Steering Committee
The natural networking that is efficient in organizations who prefer the person to person communication channel
Technology Communication Channels, such as, the Corporate web site, blogs or e-mail
Refer to the Internal Communication Channel Audit created with the Ad Hoc Communications (OCM.010) that identifies and records in spreadsheet format all
communication channels currently in use in the client organization, their frequency, person responsible and audience. For each communication, determine which
communication vehicle is the most efficient based on organizational risks in place, the audiences communication needs and the timeframe of the project. Consider the
following:
Creating a newsletter for the project could be an efficient vehicle. It is frequent, based on the project priorities and milestones.
A web site is also a good vehicle for a worldwide implementation as It is a good way to reach many people in a very short period of time.
Email is good for mass delivery of important messages when working in a decentralized environment.
Management information decks are good for communicating project progress to management level employees.
One on one staff town hall meetings are also good for communicating high level project progress as well as confirming project vision and goals.
The Change Agent Structure can also be a delivery method. They are usually selected for using the natural networking and follow the natural communication channel, and
are people from the organization that can assist the change and training team with distributing information, and identifying additional communication training needs that
cannot be easily identified from a remote location. Activities they are typically engaged in are:
Performing Audience Assessments, (Identifying groups at their locations needing specific and targeted information regarding the Project)
Helping to identify communication vehicles, (The best way to communicate these messages, i.e., e-mail, newsletters)
Assist in identifying change and communications needs throughout the project
Providing content for and validate project level communications (verbiage appropriate to specific locations)
Facilitating a swift review/approval process when team members in their location need to review and approve communication
Supporting change management ad communications work stream activities as needed
Delivering the right message at the right time to the right audience is a communication mantra. The Communication Campaign outlines a multi-media approach utilizing
existing communication channels where possible so that interested individuals can easily locate the information. In many cases, a message may be delivered through
several channels to reach a broader base of impacted audiences.
As the project matures, the list of channels, the nature of the key messages, and the frequency of those messages will change. In the early phases of a major transition,
awareness is an acceptable level of commitment for most audiences, and communications can be fairly generic. However, as the program moves toward rollout and
impacted stakeholders need to make strides in the direction of involvement and commitment, the nature and frequency of communication must be adapted to support the
altered requirements.
To summarize, for each Action to Implement:
Identify appropriate and effective communication delivery methods within the project.
Identify how communications are most effectively received within the organization.
Identify key communicators within the organization.
Determine who will be the speaker responsible for the delivery of each key message.
Determine most effective person to deliver targeted messages.
The goal is to ensure that messages with meaning are delivered by the people that matter and that communications are taken seriously.
The organization is responsible for the following:
Creating where are we now messages keeping readers informed on project progress.
Developing key (WIIFM Whats in it for me) messages.
Allowing the organization to feel they have ownership in the change.
Determine Communication Media
Determine the type of content (media) delivered to the audience, as well as the different types of vehicles that will be used to effectively deliver key project messages
(Action to Implement) to the correct audiences, such as:
Project Progress Updates
Specific Change Updates
Focused Group Communications
Company-Wide Group Announcements
Management Updates
To ensure that the right messages are delivered to the right audience in a way that the information can be received and understood, the organizations capability to use
various methods of communication should be considered. The goal is to determine the proper messaging for delivery as well as document the most effective media for
delivery of messages in order to encourage readership and effective delivery of messages by sending the right information to the right audience. Examples of media that
could be utilized throughout the project are:
Corporate web site/intranet
Blog
Email
Newsletter
Management Updates
Face-to-Face Meetings
Each audience may have different preferences or technical capability to receive messages. For example, some employees may not have access to the web or e-mail and
would not be able to access electronically delivered messages. The media will be determined by the organizations communication culture and the audience preferences
or system constraints.
A general rule of thumb for determining which media will be most effective in reaching a particular audience or conveying a key message is to choose the richest medium
possible within the constraints of the situation; richness being judged by the number of information cues it provides. The richest medium is one-on-one communication,
which offers the opportunity to observe visual and auditory cues (for example, tone of voice) and receive immediate feedback. Any medium that creates one-way
communication, such as a poster or a newsletter, is a lean medium.
Creating effective delivery of client communications.
Ensuring that messages are delivered at the right level.
Encouraging readership of key messages.
Develop Key Messages
The Communication Campaign should address the communication needs of the organization. Include just-in-time messaging in a language the organization can
understand and support.
Key messages are a major component of an organizational communication initiative, and the accuracy of these messages is pivotal to success. Key messages are high
level, include a link between the program and the organizations strategic intent, and are generic in that they can live for the entire lifecycle of the program. One or more
of the key messages will be part of every piece of communication that is developed. Key messages answer the following questions:
What is the program or project?
What should I expect?
Why is this happening?
How will my work be affected?
What is happening now?
When is the project happening?
Key message must convince stakeholders that the change is necessary, that the benefits are real, that the project is viable, and that the change is inevitable. While many
messages will be generic in nature, meaning they are intended for a broad audience, there will also be tailored messages to specific audiences that are tailored to
mitigate risks and concerns.
The key messages are built to manage specific situations, decrease fears and concerns and in some situation to manage expectations to avoid deception. The key
messages have to be clear, concise and jargon free. Some major key messages can be used more than one time to increase their understanding. Each message is
created to manage a risk (Impacts/Issues to Manage) selected from the Communication Campaign. They are also adapted to the speaker leadership in the organization
and the role of the speakers in the project.
To help individuals prepare for, understand and accept changes in their work environment, it is crucial to select the most credible speaker to deliver the message.
Who has the credibility for this audience?
Who has the right leadership to leverage the message?
Who can reach more people by carrying this message?
What is the right position level for communicating this message (executives, director, manager or a change agent)?
It is also important to inform and involve all affected groups whose commitment will be required. Key messages should:
Provide accurate information to keep stakeholders focused and reduce rumors and performance dips.
Provide timely information, using a multi-media approach, tailored to various audience groups.
Sustain the interest and energy of the team members and business representatives.
The objectives of the key messages are to:
Manage expectations and reactions.
Increase awareness.
Create buy-in.
Develop targeted just-in-time messages.
Identify critical communication points.
Foster two-way communication.
Providing the calendar for project communication.
Defining events, delivery and audience into a single source executable document.
Moving employees through the stages of commitment.
Create Communication Campaign
The Communication Campaign includes:
Target Group (Audience)
Impacts/Issues to Manage (Risks)
Action to Implement (Mitigation Plan)
Key Messages
Accountability
Timeline (including Status)
The initial Communication Strategy and Change Management Roadmap (OCM.130) defined the timeline and descriptions of activities to be conducted (Action to
Implement) in order to mitigate risk (Impacts/Issues to Manage) and increase the organization's capacity to undertake or sustain the proposed changes. Using the
information gathered, incorporate the necessary communication details to the Communication Campaign.
The Communication Campaign is complete, when:
The audiences are confirmed.
The medium for communicating the message is selected based on the audience preferences.
The impacts are determined.
The actions to put in place are identified and assigned.
The key messages are designed and aligned with the action to put in place.
The speakers are identified and accountable to carry the messages.
A specific date is assigned to each communication initiative.
The status of the message is documented and cataloged.
Back to Top
Change Management
Specialist
Develop Communication Campaign to involve, inform and generate buy-in from the stakeholders. Provide expertise in the
selection of the communication channels that are most compatible with the organization's culture and stakeholders' preferred
sources of information. Drive the design of the Communication Campaign in terms of key messages, timing, repetition,
feedback mechanisms, etc.
100
Specialist
Participate in the creation and development of the Communication Campaign with its key messages and selecting
communication mediums. Act as spokesperson for the project.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Ad Hoc Communications (OCM.010)
/Governance Rules (OCM.030)
Alignment Workshop about project vision, objectives, and success criteria in order to communicate them to the
project team, middle managers, and end users and manage the impact of the project on the organization as well as
to mitigate organizational risks.
Recommendations (OCM.120)
Translate the findings and recommendations in the Change Readiness Assessment Analysis and
Recommendations into an actionable plan that will increase the organization's capacity to undertake and sustain
the proposed changes.
Communication Strategy and Change
Management Roadmap (OCM.130)
The Communication Strategy and Change Management Roadmap were used to start building the Communication
Campaign, which is what you are updating in this task with the communication details. The Communication
Strategy and Change Management Roadmap were used to link communication initiatives with identified risks. This
was done to ensure a proactive approach in the communication delivery process as well as to develop strong and
meaningful messages for the reader.
Back to Top
TEMPLATES AND TOOLS
OCM-
140_COMMUNICATION_CAMPAIGN.DOC
MS WORD - Use the information from the Communication Strategy (OCM.130) to create the Communication Campaign by
adding the essential communication components.
Back to Top
The Communication Campaign is used:
to manage issues and challenges
to conduct the change and communication events around the key communication themes
The Communication Campaign should address the following:
target audience reaction
an approach describing message, objective, events, media, and timeline per audience
communication agents assignment definition
required resources and logistics for deployment
communication schedule
Back to Top
QUALITY CRITERIA
Back to Top
OCM.150 - CONDUCT CHANGE MANAGEMENT ROADMAP /
COMMUNICATION CAMPAIGN
In this task, you deploy the Change Management Roadmap and Communication Campaign by conducting the change and communication events. This is an ongoing task
that is executed at established milestones throughout the project lifecycle.
ACTIVITY
OCM.150.1
OCM.150.2
OCM.150.3
OCM.150.4
OCM.150.5
Back to Top
WORK PRODUCT
Change Management Roadmap / Communication Events - The Change Management Roadmap / Communication Events are change and communication events
conducted at the established key project milestones/phases.
Back to Top
TASK STEPS
You should follow these steps for each change management and communication event activity:
1 Plan logistics. Detailed Change
Management /
Communication Calendar
The Detailed Change Management / Communication Calendar provides the pertinent logistical details
for each change management or communication event (for example, date, location, times, etc.).
2 Prepare coaching templates
and communication delivery
tools.
Coaching Templates /
Communication Delivery
Tools
Coaching Templates and Communication Delivery Tools are any items that are required by the change
and communication agents [person(s) responsible for conducting or delivering the event] to complete
the event.
3 Conduct change
management or
communication event.
Change Management
Roadmap /
Communication Rollout
Roll out the change management or communication event.
Back to Top
APPROACH
The objectives of deploying the Change Management Roadmap and Communication Campaign are:
Mitigate change management issues, challenges and risks.
Execute communications that help individuals prepare for, understand and accept changes in their work environment.
Inform and involve all groups who are affected by the upcoming change.
Keep stakeholders focused, reduce rumors and performance dips.
Build realistic expectations regarding what is really happening on the project.
Provide timely information, using a multi-media approach, tailored to various audience groups.
Deploying the Change Management Roadmap and Communication Campaign is an ongoing task that is executed at established milestones throughout the project. Use
the following approach to conduct each change management or communication event.
Plan Logistics
Organize the event process, logistics, meeting invites and agendas for various focus groups, town halls and other face to face meetings. Some events may not require
any logistics. However, meetings, focus groups, town halls, etc., events require logistical support. Some of the logistical requirements may have already been determined
and just need to be verified. In many cases, the client will arrange the logistics. Help the organizations plan for upcoming communications events. Plan and organize
logistics for on site and off site communication events. Ensure that the correct messages are delivered to the right audience at the right time.
Gather Templates and Tools
In preparation for the actual event, gather, prepare any coaching templates and communication delivery tools that may be needed by the change and communication
agents [person(s) responsible for conducting or delivering the event] to complete the event. Provide any necessary coaching to change and communication agents.
Ensure that the Coaching Templates and Communication Delivery Tools are relevant and adapted to the client situation.
For each change management and communication event, the change agents, or messengers, need to be coached to ensure that their messages reflect status of the
program and the tone desired. The person responsible for the communication activity will provide templates to the change agents to ensure a successful event. The
following items should be covered when coaching change agents and messengers for each change/communication event:
Provided 3-5 short key messages that should be covered.
Provide a list of FAQs and the corresponding answers that they should anticipate during the event.
Provide and updated timeline for the project.
Provide facts to correct what may be on the rumor mill so messages are aligned.
Conduct Change or Communication Event
Based on the established project milestone schedule, roll out each change management or communication event, as appropriate. Deliver project messages using
information from project leadership and functional teams. Deliver key messages that are aligned with project milestones. The events are outlined in the Change
Management Roadmap (OCM.130) and Communication Campaign (OCM.140). As the project progresses, just-in-time communications may be necessary. Additionally,
the communication messages may shift to provide progress on the project and will recognize and reward team members for project success.
manager support each other while the Change Management Roadmap and Communication Campaign are being conducted in order to present cohesive and
collaborative leadership to the organization and address any questions or concerns regarding the Roadmap or Campaign. This collaboration facilitates the agreed upon
execution of the activities in the Change Management Roadmap and Communication Campaign.
Change Management
Specialist
Coach client resources on rolling out the Change Management Roadmap / Communication Campaign. Advise on internal
communication resources of leading practices in the implementation of the Change Management Roadmap / Communication
Campaign and ensure knowledge sharing.
100
Specialist
Act as spokesperson for the project. Typically responsible for implementing activities listed in the Change Management
Roadmap / Communication Campaign.
*
Client Project Manager Sponsor Change Management Roadmap / Communication Events, as needed. *
Back to Top
PREREQUISITES
Prerequisite Usage
Change Management The Change Management Roadmap defines the timeline and descriptions of activities to be conducted in order to increase the
Roadmap (OCM.130) organization's capacity to undertake or sustain the proposed changes.
Communication Campaign
(OCM.140)
The Communication Campaign provides all the details of the communication events and activities you are deploying and conducting in
this task.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Change Management Roadmap / Communication Events are events around the key communication themes.The Change Management Roadmap / Communication
Events should address the following:
an alignment of all targeting communications with the risks identified during the Organizational Readiness Assessment
an approach describes key messages, objectives, events, media, and timeline per target audience
change and communication agent roles and responsibilities
resources required and logistics for deployment
Back to Top
QUALITY CRITERIA
Are the change management and communication events conducted timely and completed successfully as planned in the Change Management Roadmap and
Communication Campaign?
Back to Top
OCM.155 - MONITOR CHANGE MANAGEMENT ROADMAP /
COMMUNICATION CAMPAIGN EFFECTIVENESS
Measuring effectiveness of the change management activities is another opportunity to involved managers and stakeholders. It is also a mechanism to demonstrate that
the project team is taking into consideration the input of stakeholders. Usually, the change agents are involved in this process similar to how they participated in the
Change Readiness Assessment. Their involvement will once again mobilize again the clients networking.
In this task, you monitor the effectiveness of the Change Management Roadmap / Communication Events (OCM.150). Use the information received from the assessment
to update the Change Management Roadmap (OCM.130) and the Communication Campaign (OCM.140). This task is critical to ensuring that the Change Management
Roadmap and the Communication Campaign are focused on identifying areas of risk while maintaining the necessary flexibility to be effective.
This is an ongoing task that is executed as the Change Management Roadmap and Communication Campaign are rolled out.
ACTIVITY
OCM.155.1
OCM.155.2
OCM.155.3
OCM.155.4
OCM.155.5
Back to Top
WORK PRODUCT
Change Management Roadmap / Communication Campaign Effectiveness Assessment - The Change Management Roadmap / Communication Campaign
Effectiveness Assessment measures the overall effectiveness of the Change Management Roadmap(OCM.130) and the Communication Campaign (OCM.140) through
the use of surveys, large group forums, or a series of focus groups in order to improve future change management and communication events.
Back to Top
TASK STEPS
You should follow these steps after each event:
1 Develop feedback loops, for example, surveys, focus groups, etc., that
can be used to measure the effectiveness of your change
management or communication event.
Communications Effectiveness
Survey
Effectiveness Assessment Grid
FAQs
Web Feedback Forums
These assessment tools allow you to gather feedback.
2 Conduct feedback loops to measure the effectiveness of your change Completed Communications These are the completed assessment tools, as
management or communication event. Effectiveness Survey
Completed Focus Group
FAQs
Web Feedback Forums
appropriate.
3 Analyze the survey and focus group responses to assess the change
management or communication event effectiveness.
Change Management Roadmap /
Communication Campaign
Effectiveness Analysis
The Change Management Roadmap / Communication
Campaign Effectiveness Analysis is the analyzed
survey and focus group data.
4 Adjust the Change Management Roadmap (OCM.130) and the
Communication Campaign (OCM.140), as appropriate.
(Updated) Change Management
Roadmap and Communication
Campaign
The Change Management Roadmap and the
Communication Campaign are updated based on the
feedback.
Back to Top
APPROACH
The purpose of monitoring the Change Management Roadmap / Communication Events for effectiveness is to monitor the effectiveness of delivered key messages per
audience, including media, frequency, and delivery resources. It is also designed to verify that messages are received and understood throughout the organization.
Develop Assessment Tools
Determine an effectiveness assessment and objectives strategy for you change management or communication event. Build core questions that allow you to receive
feedback from your audience. The questions should be aligned with the change management and communication objectives and must measure how these objectives
were targeted and if it is necessary to update the Change Management Roadmap and Communication Campaign documents.
Develop feedback loops that can be used to measure the effectiveness of your change management or communication event using one of the following measurement
tools/delivery mechanisms:
Communications Effectiveness Survey
Focus Group Facilitation
FAQs
Web Feedback Forums
The measurement tools are selected based on the organizational culture as well as the effort allocated to get the feedback during project. By monitoring your change
management or communication events, you verify that you are delivering the correct messages to the correct audience at the correct time. The various feedback
components also allow you to proactively uncover underlying messages that may have been missed or not focused on enough. The assessment:
Assists in building a strong relevant and timely communication foundation.
Ensures the correct level of messaging is reaching the appropriate audiences.
Allow you to modify and create messages that are relevant to the client audience.
Validate that the right people are getting the right message at the right time.
Use the Change Agent Structure to validate your assessment tools. If that is not available, use a representative group of people from the target group to validate the
assessment tools. This adds credibility and value to your assessment tools.
Communication Effectiveness Survey - The Communication Effectiveness Survey is a customized survey designed and tailored to gather information on the
effectiveness of a change management or communication event. The survey covers the following topics:
Was the content relevant?
Did you receive the information?
What is the best way for you to get information?
What was your knowledge level before/after the communication?
What was missing from the communication?
Effectiveness Assessment Grid - The purpose of an Effectiveness Assessment Grid is to gather input from the the participants of a focus groups. This assessment tool
allows the stakeholders to directly provide their input. Topics to discuss include:
Readability of the communication
Quality of the communication
Accuracy of the communication
Quality of the communication vehicle
Timeliness of the communication
Improvement suggestions
Recommendations
FAQs - FAQs are used to answer any questions related to the measurement effectiveness activity. The FAQ is sent with the survey to secure the stakeholders on the
initiative in place.
Web Feedback Forms - Web Feedback forums are very similar and are sometimes used in the same manner as the Communication Effectiveness Survey. This is
especially true when the Communication Effectiveness Survey is delivered via the web.
Conduct Assessment
Begin your assessment. Conduct your focus group. Deliver your developed assessment tools (survey) to the designated user group. At this time, you put your survey on
the web or you deliver the paper survey by using the Change Agent Structure or by following the management cascade. When using a survey, it is typical to send a
reminder to complete it after twenty- four or forty-eight hours. Confidentiality of the assessment is important in order to get the most relevant information. If a paper survey
is used and a name is required on the survey, consider using the following rules with respect to confidentiality:
Must be closed and sealed in a envelope
Must be delivered to the survey administrator only
Administrator must keep personal data confidential
Administrator must use survey data for the purpose of improving communication efforts
Comments are to be used only to improve communications and are not used for punitive actions
Analyze Responses
Analyze, catalog and organize the survey and focus group responses to assess the effectiveness or the event. Analyze data from your survey population or focus group to
validate your Change Management Roadmap / Communication Event. The analysis of the data should also be assessed against the initial group that validated the
assessment tool. The group can also make comments and recommendations for updating both the Change Management Roadmap and Communication Campaign
documents.
Analyze the assessment data for the following
Inconsistent messages
Lack of understanding of current or past project phases
Lack of clarity of project vision mission or scope
Signs of active or passive resistance in key stakeholder groups
Evidence of communications not received
Some mediums are not reaching enough specific audiences
The schedule of some communication events is not well aligned with the stakeholders needs
Change agents are not deploying efficiently the messages
Adjust the Change Management Roadmap and the Communication Campaign
The Change Management Roadmap and the Communication Campaign are both living documents that need constant attention. It is critical to keep them flexible and
proactive. Therefore, you need to make adjustments to both documents based on the information received from your surveys or focus groups. Types of feedback and
information that require adjustments to these documents include:
New project resource information
Change in scope
Timeline changes
New information uncovered during project
As appropriate, based on your analysis of the assessment, add or delete components to the Change Management Roadmap and the Communication Campaign to
address any gaps. Communicate any changes to the change agents or any other appropriate stakeholders.
manager support each other in monitoring the Change Management Roadmap and Communication Campaign in order to ensure that the activities are on schedule and
effective for the organization and that any issues are addressed. This collaboration facilitates the agreed upon goals and that the project management and change
management teams are successful in managing the organizational change.
Back to Top
Change Management
Specialist
Provide topics to include in the survey and assist in updating the Change Management Roadmap and Communication
Campaign. Create the survey and any other assessment tools, analyze the results and make appropriate adjustments to the
Change Management Roadmap and Communication Campaign documents.
100
Specialist
Act as a spokesperson for the project. Support the assessment of the effectiveness of the Change Management Roadmap and
Communication Campaign.
*
Client Project Manager Support effectiveness assessment activities as needed. *
Back to Top
PREREQUISITES
Prerequisite Usage
Change Management Roadmap (OCM.130) The Change Management Roadmap provides all the details for the events and activities that are being
monitored in this task.
Communication Campaign (OCM.140) The Communication Campaign provides all the details for the communication activities that are being
monitored in this task.
Change Management Roadmap / Communication Events
(OCM.150)
The Change Management Roadmap / Communication Events are the actual events that are being
assessed for effectiveness.
Back to Top
TEMPLATES AND TOOLS
OCM-155_CMRCC_EFF_ASSESSMENT.DOC MS WORD
Back to Top
The Change Management Roadmap / Communication Campaign Effectiveness Survey is used in the following ways:
to determine the effectiveness of the Change Management Roadmap / Communication Events
to solicit feedback from the target audiences included in the Change Management Roadmap and the Communication Campaign
Back to Top
QUALITY CRITERIA
Back to Top
OCM.160 - PREPARE BUSINESS PROCESS IMPACT
INVENTORY
In this task, you identify the impact to the current business processes as a result of the new system. These impacts to business processes can involve tasks and activities
for the process, end-user roles and responsibilities and level of knowledge needed for the process. They are captured in order to anticipate the amount of change to each
business area thus affecting the requirements for communications, training and support during transition.
ACTIVITY
B.ACT.PBPII Prepare Business Process Impact Inventory
Back to Top
WORK PRODUCT
Business Process Impact Inventory - The Business Process Impact Inventory shows how the various functional business processes will be impacted by the changes. It
identifies the gap between the way the business process works today and the way that it will work in the future.
Back to Top
TASK STEPS
1 Confirm the resources with
information on the
business processes.
Contributor
List
The Contributor List is a list of contributors who have information about the processes which are expected to be
impacted with changes to the systems environment. These Contributors include workstream leads involved with the
project who are the most knowledgeable of the potential impact of the changes
2 Create the Business
Process Impact Inventory
Grid.
Business
Process
Impact
Inventory
Grid
The Business Process Impact Inventory Grid is used to show the business process impact criteria and amount of
impact anticipated.
3 Collect process change
data.
Business
Process
Impact
Inventory
Grid
The Business Process Impact Inventory Grid captures the following information:
1. Workstream
2. Workstream Lead
3. Roles Impacted
4. Current process
5. Future process
6. Frequency of process
7. Severity of change
8. Degree of change
9. Number of functions impacted
10. Name of functions impacted
11. Impact score (calculated based on items 5-8)
4 Analyze and validate
change data.
Analysis
Report
An Analysis Report shows the ranked list of impacted business processes based on the impact score. It can be used to
validate the business processes that will be impacted in order to develop further recommendations for the transition.
Back to Top
APPROACH
This task aims at identifying the business process impacts that are expected from implementation of the new system including tasks and activities for the process, end-
user roles and responsibilities and level of knowledge needed for the process. It will also contribute to reducing the loss of productivity during transition by identifying the
process changes as early as possible and by planning the most effective ways to make the transition smoother.
The collection and analysis of business process impacts starts towards the end of the Elaboration phase as high-level changes start emerging. The identification of
impacts is dynamic and continues through the Construction phase as business process changes become more specific while the solution is being built.
Identify Impacted Business Processes
Identify business processes where the new technology will apply and have significant impacts on the way people are doing work. Resources such as functional
workstream leads (business line managers) can identify the most impacted processes as they are the key players who know the current business processes and already
understand the new business processes due to their involvement during the Elaboration (design) phase of the implementation.
Compile a Contributor List including everyone who may have input regarding the changes that will occur with the new system and processes in the scope of the project.
Based on each business process that is part of the scope of the project, identify contributors. These contributors will likely come from:
the project team (workstream lead or team members)
subject matter experts (SME)
business analysts
Contributors will be invited to a working sessions or will be scheduled for an interview to discuss each process, procedure and related groups of activities being impacted.
The list should contain the following elements:
all process and procedures in scope
for each process and procedure, the name of contributors along with their respective:
group (their role on the project, the business unit they belong to in the organization)
area of expertise
timeframe available
Ultimately, the finalized list becomes a list of participants to include in working sessions or to conduct an interview to discuss business process impacts.
Create Business Process Impact Inventory Grid
The Business Process Impact Inventory Grid represents the first collection point for impacted business process and of the amplitude of the changes for each of them.
Facilitate working sessions or interviews with Workstream Leads and Contributors to discuss impacts. Brainstorm first level of input on processes and potential impacts.
Determine elements to include in the Business Process Impact Inventory Grid. For each process, consider asking contributors the following questions.
1. How is the process done today?
2. How do we anticipate the process will be done in the future?
3. What aspects of the change will be perceived as positive?
4. What aspects of the change will be perceived as negative?
5. How frequently will this process be performed?
6. How severe of a change is expected (low, medium, high)?
7. What is the degree of change (minimal, some, all)?
8. How many functions are involved with this process change?
9. What are these functions?
Consider the answers to these questions while capturing data in the Business Process Impact Inventory Grid.
Collect Business Process Impact Data
Facilitate working sessions or interviews to outline the major changes in the processes and tasks associated with the implementation of the new technology. Identify the
functional areas that are affected by the changes. This will allow you to identify the impact of the changes and ultimately, provides information how the functional areas
will potentially be impacted by the technology implementation.
Use a Business Process Impact Grid to collect the data captured including as much detail as possible about the current and future processes. This grid allows you to
analyze the each impacted workstream.
The Business Process Impact Grid will comprise for each process and procedure the following information:
Functional Workstream
Workstream Lead
Roles Impacted by the Change
Process as it is currently Performed The way we do it today.
Process as it will be Performed with the new system in place The way we will do it in the future.
Frequency the Process is Performed based on the following scale:
1 = Process is performed infrequently (i.e., less than once per week).
3 = Process is performed moderately frequently (i.e., several times per week).
5 = Process is performed frequently (i.e., more than once per day).
Severity of change based on the following scale:
1 = Low Change - there is little or no change to the work or to how it is performed (for example, user interface changes)
2 = Medium Change - changes to who or how work is performed (for example, manual activity that will be automated).
3 = High Change - significant change to how and/or whom performs the work (for example, How work is done, Where work is done, New or enhanced skills)
Degree of change based on the following scale:
10% = Some aspects of the process will change, but most activities required are familiar.
50% = About half the process will require new activities and/or new skills.
100% = Process is all or almost entirely new. New activities and new skills are required.
Number of Functions Impacted
Name of Functions Impacted
Impact Score calculated based on (Frequency + Severity + Number of Functions Impacted) x Degree of Change %.
Analyze and Validate Business Process Impact Data
Organize and analyze the information gathered during the working sessions and interviews to create an analysis report that contains a summary of impacts by functional
workstream including roles and activities. This information will be used to identify high-risk sectors such as functional areas which will experience numerous and/or major
changes to processes and activities. Validate the information with the leadership and project teams.
By doing this analysis and validation, it will now be possible to more fully focus on the business areas which will be exposed to the greatest amount of change with the
transition. The information captured during the working sessions and interviews can be used to update the Change Management Roadmap (OCM.130) and
Communication Campaign (OCM.140). Based on the validated data, recommendations can also be developed for the Job Impact Analysis (OCM.170) and User Learning
Needs Analysis (TR.060).
Back to Top
Change Management Specialist Lead the effort to introduce and complete the Business Process Impact Inventory. 100
Business Analyst Confirm business processes to be included in the Business Process Impact Inventory. minimal
Business Line Managers (Functional
Workstream Leads)
Participate in working sessions or interviews to complete the sections of the Business Process Impact Inventory
related to their workstream (or area of expertise).
*
Back to Top
PREREQUISITES
Prerequisite Usage
(High-Level) Future Process Model
(RD.011)
The Future Process Model provides the details of the future processes for change impact assessment on the organization.
Also use it to determine new workflows for jobs potentially impacted.
Structures (RD.012)
The Present and Future Organization Structures identifies how the work environment may be impacted by the new roles and
responsibilities.
Current Process Model (RD.030) Defines the current in scope processes for the business
Organizational Risk Assessment Data Use this data to confirm the identified risks and target populations.
(OCM.130
Communication Campaign (OCM.140)
Use the Change Management Roadmap and Communication Campaign to validate the list of target process areas. If
additional processes are included, make sure the Change Management Roadmap and Communication Campaign are
updated accordingly.
Back to Top
TEMPLATES AND TOOLS
OCM-160_BUSINESS_PROCESS_IMPACT_INVENTORY.DOC MS WORD
Back to Top
The Business Process Impact Inventory is used:
to help the leadership and project team understand the business processes which will have the greatest amount of change impact with the system implementation
to refine information for the Change Management Roadmap and Communication Campaign
to provide input into the Job Impact Analysis and User Learning Needs Analysis
Back to Top
QUALITY CRITERIA
Back to Top
OCM.170 - COLLECT AND ANALYZE JOB CHANGE DATA
In this task, you identify the impact of the new system on the organization structure, end user roles, responsibilities, knowledge and work requirements in order to reduce
the amount of productivity loss experienced during transition.
ACTIVITY
Back to Top
WORK PRODUCT
Job Impact Analysis - The Job Impact Analysis shows how the various groups will be impacted by the changes. It identifies the gap between the current job and the new
job.
Back to Top
TASK STEPS
1 Confirm the impacted
employee groups.
Representative
List
The Representative List is a list of representatives from the impacted groups that are the most knowledgeable of
the potential impact of the changes.
2 Create Data Collection Grid. Data Collection
Grid
The Data Collection Grid shows the impact criteria and percentage of impact.
3 Collect change data. Data Summary
Grid
The Data Summary Grid includes the following information:
list of employees
job title
type of impact
degree of impact
4 Analyze and validate change
data.
Data Analysis
Report
The Data Analysis Report shows the most impacted groups and the degree of impact.
5 Validate conclusions. Diagnosis Grid The Diagnosis Grid contains validated data and the recommendations for the transition.
Back to Top
APPROACH
This task aims at identifying the impacts of the new system on the organization its structure, end user roles and responsibilities, knowledge and work requirements. It will
also contribute to reducing the loss of productivity during transition by identifying human impacts and by planning the most effective ways to smoother the transition.
The collection and analysis of job changes starts right from the Construction Phase as high-level impacts start emerging. The identification of impacts is dynamic and
continues through the Production Phase as impacts become more specific to both the job and to the individual level.
Identify Impacted Employee Groups
Identify organizational units where the new technology will apply with significant impacts on the way people are doing work. Key contributors will identify the most
impacted groups. They are the key players who already know the new business processes due to their involvement during the implementation. In addition, one
representative of the Human Resource department is required to identify the potential impacts on the job role definitions.
Compile a Representative List including all contributors capable of defining the changes that derive from the new system and processes in the scope of the project, as
well as identifying employees whom will be impacted by those changes.
This task starts with a listing of all processes and procedures that are part of the scope of the project. For each of the processes and procedures, identify contributors.
These contributors will likely come from:
The project team (team lead or team members)
Subject matter experts (SME)
HR Representatives
Training specialists
Contributors will be invited to a working session(s) to discuss each process, procedures, and related groups of employees being impacted. The Representative List
should contain the following elements:
All process and procedures in scope
For each process and procedure: the name of contributors along with their respective:
Group (their role on the project, the business unit they belong to in the organization)
Area of expertise
Timeframe available
Ultimately, the finalized Representative List becomes a list of participants to include in a working session to discuss impacts and related impacted groups.
Update the Change Management Roadmap / Communication Campaign (OCM.140) with information related to job impact analysis.
Align the initiative with HR services, management model and performance rules.
Create Data Collection Grid
Create a Data Collection Grid. The Data Collection Grid represents the first assessment of the population impacted by the project, and of the amplitude of the changes
affecting them.
Facilitate working sessions with with client team leads and contributors to discuss impacts. Brainstorm first level of input on categories of potential impacts. Brainstorm
first level of input on impacted groups. Determine elements to include in the Data Collection Grid. For each process and procedure, ask contributors the following
questions.
1. How is the basic procedure changing?
2. Which employee groups/job roles will be impacted?
3. What is the demography of each employee group (location, # per job role, age, unionized (Y/N), etc.
4. What aspects of the change will be perceived as positive?
5. What aspects of the change will be perceived as negative?
6. How critical is this procedure?
7. How frequently will this procedure be performed?
8. What degree of change does this revised procedure represent?
Capture the answers to these questions in the Data Collection Grid.
Collect Change Data
Facilitate workshops to outline the major changes in the tasks and organization of work associated with the implementation of the new technology. Identify the job title and
the organizational sectors that are really affected by the changes. Identify the number of employees with their job title and location. This allows you to identify the degree
of change, i.e., the number of impacts on the daily work, level of reskilling needs, change on work environment, etc., and select the most impacted groups. Ultimately, this
provides high-level information from the team leads on how they will potentially be impacted by the technology implementation.
Use a Data Summary Grid to collect the data captured to date, but take it to a lower level of detail where each process and procedure is analyzed further. This grid allows
you to analyze the workflow for each impacted job. Tutor can be used for accelerating this analysis.
The Data Summary Grid will comprise for each process and procedure the following information:
Process description
Procedure name (and number). It is referring to the job workflow
Initial observation (e.g., this is a new task handled by a certain employee group, a merged task, obsolete task, etc.)
Use of Oracle Application (e.g., no more yellow sheet required; an electronic form will be generated and forwarded automatically to the approver)
Percent of Actual Workload increase of decrease (e.g.,. this tasks is no longer performed in remote offices; it is 100% handled by the new Shared services center)
Consequences of impacts on job roles (e.g., senior financial clerks are no longer required in any remote office for this task; the employee will no longer capture
data but will have to analyze the data which mean more responsibilities)
Impacted employees this information comes from the Data Collection Grid; employee name are now identified in each location and employee group / job role)
Required skills (e.g., truck drivers will now be required to capture pick up and delivery data and signature using an electronic device as opposed to paper forms
training on the end-to-end process and on the electronic devices required)
Physical set up (e.g., truck equipped with special tray / charging device)
Organizational Set Up (e.g., a new Shared services center with 22 employees will need to be set up in City X)
IT Requirements
Required HR Support (transition activities required in preparation for the announcement of the roll-out)
Leaders support required
Communication actions required
Training actions required
HR Department actions required (e.g., employees to be relocated will need to be taken care of)
Analyze and Validate Change Data
Organize and analyze the information gathered during sessions and workshops. Make links between the qualitative and quantitative data.
Create a Data Analysis Report that contains a summary of impacts per job role. This data will be used to communicate to the managers the impacts on job role within their
business unit. The level of information will help them prepare their direct reports for the transition. Identify each impacted job role, along with the list of processes and
procedures affecting each job role, and the description of impacts. Impacts should be described in terms of role or responsibility changes, tasks (new, eliminated,
changing location, or other changes), benefits, challenges (e.g., terminology, new tools or procedures), classification, new skills and ability required along with
recommended training to be followed, number in this role and location.
Determine tasks or responsibilities that may be:
added and integrated into new units or departments
redrawn
divided among different divisions
obsolete
grouped to optimize time
accomplished through real-time telecommuting to facilitate international/global collaborations
Identify high-risk sectors, numbers of people per job role.
The main objective is to organize the data and summarize the qualitative and quantitative impact to people, positions and organization structures.
Validate Conclusions
Present the conclusions to key players in the organization in order to validate their:
accuracy,
relevance
Create a Diagnosis Grid presentation that contains all the data to be validated in terms of the population that is impacted by the project as well as concerns and
recommendations based on the characteristic of each group. With all the information captured, the diagnosis will bring the conclusion on how each job will be impacted,
in how many places and knowing the number of employees impacted. The Diagnosis Grid presentation is used during a validation session to inform middle and first line
managers, end users and HR representatives on impacts. For each impact (slide), include the following information to be validated:
Process
Procedures within each process
The list of impacted groups
The number of persons in each job role
The location of persons being impacted
Potential issues and recommendation While facilitating the session, key stakeholders should be asked the following questions in order to capture issues and
recommendations:
What are your major concerns regarding each impacted group?
What is the change experience with each of these groups positive/negative?
How would you approach each group in order to address impacts affecting each one of them?
By communicating this information, it will be now possible to identify the potential reactions of employees to these changes. The information captured during these
sessions will be used for OCM.190. Discuss the "how" of integrating these conclusions with the other change management activities. Validate conclusions and gain
commitment from the client change management lead or client project manager to take actions. Build recommendations based on the validated data.
Back to Top
Change Management
Specialist
100
Business Analyst minimal
Training Specialist minimal
Client HR Specialist *
Client Functional Specialist *
Back to Top
PREREQUISITES
Prerequisite Usage
High-Level Business Process Model (RD.011) The Future Process Model provides the details of the future processes for change impact assessment on the
organization. Also use it to determine new workflows for jobs potentially impacted.
(RD.012)
The Present and Future Organization Structures identifies how the work environment may be impacted by the
new roles and responsibilities.
Organizational Risk Assessment Data Use this data to confirm the identified risks and target populations.
Campaign (OCM.140)
Use the Change Management Roadmap / Communication Campaign to validate the list of target groups. If
additional target groups turn up, make sure the Change Management Roadmap / Communication Campaign is
updated.
Back to Top
TEMPLATES AND TOOLS
OCM-170_JOB_IMPACT_ANALYSIS.DOC MS WORD
Back to Top
The Job Impact Analysis is used in the following ways:
to communicate the information to HR, middle managers and end users
to define the HR Transition Plan structure
to prepare the most impacted groups for the transition
Back to Top
QUALITY CRITERIA
Back to Top
OCM.180 - DETERMINE IMPACT OF JOB CHANGES
In this task, you determine the potential impact of the technology change on tasks, roles, responsibilities, competencies, work environments and policies and identify
activities to transition the impacted groups, potential pre-training needs and impacts on the hiring process.
ACTIVITY
Back to Top
WORK PRODUCT
Job Impact Diagnosis - The Job Impact Diagnosis provides recommendations to prepare end users for the day-to-day work using the new processes. It identifies who
will be impacted, how they will be impacted and at what level they are impacted.
Back to Top
TASK STEPS
1 Confirm the target groups. Target Group List The Target Group List is a list of the impacted groups on which you are
focusing.
2 Evaluate the relevance of current workflows and lines of
accountability.
Job Descriptions This component is a list of jobs impacted.
3 Review job profiles including descriptions of tasks and
responsibilities and required competencies.
Completed Job
Impact Grid
Completed job descriptions for the jobs impacted.
4 Identify the gaps between the new job profiles and the current
ones.
Job Impact
Diagnosis
The Job Impact Diagnosis documents the new way to do work based on the
criteria provided and includes the changes needed.
5 Identify who will be the most impacted, their locations and
their specific pre-training needs.
Recommendations This component selects the most impacted groups and provides
recommendations on how to transition them.
Back to Top
APPROACH
The objective of this task is to determine the potential impacts on job roles in preparation for new processes and technology that will be introduced. Potential impacts are
numerous; they could comprise the followings types of changes: different roles and responsibilities or change of emphasis of job tasks, current tasks no longer required
and new tasks required, new skills and abilities, new policies and performance metrics being introduced. Impacts will need to be managed in preparation for Go-Live;
therefore specific activities will need to be performed such a way to ensure a smooth transition between the current and the new work environment. The information
developed in this task leads into the preparation of the HR Transition Plan (OCM.190).
This task is executed in the Construction Phase. Once impacts have been identified and analyzed at the job level throughout the Production Phase, recommendations
can be developed in order to insure an adequate preparation of employees to adopt the new work environment.
Confirm Target Groups
Confirm the target groups. The Assessment Tools Assessment Strategy contains a Stakeholder Assessment that will provide a list of the target groups. You can also
validate the target groups using the Change Management Roadmap / Communication Campaign (OCM.140).
Create a Target Group List that aims at providing a broad perspective of all departments and employee groups impacted by the project, along with their location, the name
of a contact person. It then becomes easier to assess rapidly the magnitude of the impacted population and their location. This is a build up process to capture the
information; it starts with the confirmation of the target groups; to this list, we add the job role description associated to an individual within a target group. Finally the new
job role for this individual is associated to the employee name.
Create a Target Group List. For each of the impacted groups of employees, capture the following information:
Their location
A contact person (e.g. a manager or an HR representative)
The contact phone number
Evaluate Current Workflows
Evaluate the relevance of current workflows and lines of accountability. Create a Job Description grid that completes the Target Group List by providing the list of all job
roles for each impacted group along with all impacted employees within each job role. For each target group, create a Job Descriptions grid with the each job role and the
names of all employees within each job.
It might be necessary to make multiple employee lists within each employee group as there might be more than one job role impacted by the project in any employee
group.
Review Job Profiles
Review job profiles including descriptions of tasks and responsibilities and required competencies. Create a Job Impact Grid that capitalizes on the previous grid and
provides the description of the new job role.
Identify the Gaps
Identify the gaps between the new job profiles and the current ones. Create a Job Impact Diagnosis that takes the information from the Job Impact Grid and focuses on
describing job changes between the current and the new work environment.
Make Recommendations
Identify who will be the most impacted, their locations and their level of impact. Make recommendations to transition the impacted groups.
Capitalizing on the description of job changes from the Job Impact Diagnosis, it now becomes possible to start developing recommendations in preparation for the
transition.
Most transition activities will consist of any or a mix of the following activities: communication activities to prepare employees and their management to the changes, a
description of training and pre-training activities per job role, specific transition activities to prepare employees to the new working environment using new processes and
technology. These activities also include cases of dismissal when that applies; related organization approach and policy should be followed and included the
recommendations. This situation should apply after giving consideration to updating the skills or assigning any person in this situation to another job.
Create a Recommendation Grid containing the following information that meets the need of each employee group and for each job role impacted by the project:
The description of changes affecting each job roles and each employee within job roles.
Recommended communications and change activities to inform middle and first line management first, and then impacted employees. These activities that are
developed as part of the Transition task should be integrated and enhance the Communication and Change plan for coordination, integration, reporting and
management purposes.
Training and pre-training recommendations should be developed in coordination with the Training team, for the same reason as above.
HR transition activities should also be planned to address issues like those with unions, or others, such as, job relocation, classification, updates to the
performance measurement, job description and other integration/updates to HR programs.
Other transition activities might be required like: the physical preparation of an office or a location (specifically if some processes are changing location like
de/centralization, a shared services center), an upgrade to the computer stations, enhancement to the communication equipment, setting up a new computer
station in a production area, installing devices in mobile equipment, moving a group of employees into other locations, etc.
Update the Change Management Roadmap / Communication Campaign (OCM.140) with any risks identified during this task.
Back to Top
Change Management
Specialist
Prepare the Job Impact Diagnosis and facilitate the workshops. 80
Business Analyst 10
Training Specialist 10
Back to Top
PREREQUISITES
Prerequisite Usage
Assessment Tools (OCM.110) The Assessment Tools Assessment Strategy contains a Stakeholder Assessment that will provide a list of the
target groups.
Change Management Roadmap /
Communication Campaign (OCM.140)
The Change Management Roadmap / Communication Campaign provides information regarding target populations
and any concerns or issues related to the implementation.
Job Impact Analysis (OCM.170) Use the information gathered in the Job Impact Analysis (OCM.170) as a starting point on how the various groups
will be impacted by the changes. It identifies the gap between the current job and the new job.
Back to Top
TEMPLATES AND TOOLS
OCM-180_JOB_IMPACT_DIAGNOSIS.DOC MS WORD
Tool Comments
processes.
Back to Top
The Job Impact Diagnosis is used in the following ways:
as input into the HR Transition Plan (OCM.190)
to determine opportunities for pre-training
Back to Top
QUALITY CRITERIA
Back to Top
OCM.190 - PREPARE HR TRANSITION PLAN
In this task, you prepare the HR Transition Plan. The HR Transition Plan provides recommendations and steps to prepare end users for their new roles and
responsibilities. It also provides directions to the client on how to adjust their HR criteria to match the new profiles.
ACTIVITY
Back to Top
WORK PRODUCT
HR Transition Plan - The HR Transition Plan provides recommended step-by-step actions and processes needed to transition people and teams regarding new job
responsibilities as well as opportunities for pre-training recommendations and guidance for adjusting hiring criteria.
Back to Top
TASK STEPS
1 Define activities to prepare end users for their new roles
and responsibilities.
Transition
Activities
This component is a list of activities to put in place to transition end users for their
new roles and responsibilities.
2 Determine new guidance for hiring criteria for new roles and
responsibilities for employees and managers.
New Hiring
Criteria
This component provides new guidance for the client for hiring criteria for the new
roles and responsibilities.
3 Using the Recommendations from the Job Impact Analysis
(OCM.180), meet with the client training specialist and
provide information for pre-training needs.
Pre-Training
Recommendations
The Pre-Training Recommendations are opportunities for supplemental training
per impacted population, if needed. This is not training that is directly associated
with the job, but that is helpful to the job, e.g., how to use a computer.
4 Prepare a transition plan. HR Transition
Plan
The HR Transition Plan defines the actions and processes needed to transition
people and teams regarding new job responsibilities.
5 Validate HR Transition Plan Validated HR
Transition Plan
The Validated IT Transition Plan has been validated and reviewed by key
stakeholders.
6 Create an Implementation Plan. Implementation
Plan
The Implementation Plan contains step-by-step activities to transition the users.
7 Integrate into the Change Management Roadmap /
Communication Campaign the necessary communication
activities/events to support the plan.
Key Messages Key Messages for the transition are designed to support the HR Transition Plan.
8 Assist the client HR specialist in deploying the HR
Transition Plan.
Implemented HR
Transition Plan
The client is responsible for implementing the HR Transition Plan.
Back to Top
APPROACH
The objective of this task is to transition all impacted employees through the changes they will be exposed to, while migrating from the current to the new working
environment featuring new Oracle technology, enhanced processes, and potentially other changes being introduced at the same time. The ultimate objectives of this task
are to insure a seamless transition to the new environment, thus minimizing the disruption to the business while end users adopt the changes that affect them.
This task also covers the identification of employees whose job will be eliminated as part of the transformation of the organization. Transition activities will insure these
employees are taken care of and treated fairly, in compliance with the policies that apply in this case within the organization.
Define Activities to Prepare End Users
Define Transition Activities to prepare end users for their new roles and responsibilities. The objective of Transition Activities is to prepare end users to their new role and
responsibilities by planning activities that will insure a successful transition to the new working environment featuring new technology and enhanced processes. In this
component, employees whose job will be relocated or eliminated are identified; transition activities should integrate the process that applies within the organization in this
case. Attention should be given to informing those employees, to insuring that they are treated fairly and with dignity, and that employees keeping their job around those
#TOP #TOP
leaving are kept informed and their morale monitored to avoid a chain reaction that could be detrimental to meeting the benefits of the project. In all cases, HR
representatives should be involved in order to insure the compliance to the organization policy, and to protect labor relations in those employees should be unionized.
Create a Transition Activities grid for end users with the following information for each stakeholder group:
Stakeholder group
Activities to put in place
Accountability
Input to the Change Roadmap and Communication Campaign
Activities related to the relocation or the dismissal process should be imbedded to transition activities
Help employees understand and integrate their new responsibilities and provide them a process to transition as smooth as possible. Support managers as they coach
employees who must make the greatest adjustment. Encourage senior HR staff to introduce rewards, administrative practices and training aimed at cost-
effective/creative uses of the solution.
Determine New Hiring Criteria
Provides guidance to help the client establish new hiring criteria that reflect the new roles and responsibility as a result of the new system and processes set by this
project. Create a New Hiring Criteria grid with the following information:
The impacted job role
The job level or classification (same or new one)
Job description
New skills and abilities required
Experienced necessary to perform in this job role
Other: this may consist of new accountability standards and job conditions such as mobility, union or labor contract considerations
The title to which the job role is reporting.
Human Resource Services will apply the new job and hiring criteria. If applicable, HR will also ensure discussions with union leaders to avoid potential issues and obtain
their support to those changes.
Make Pre-Training Recommendations
Using the Job Impact Diagnosis, Recommendations (OCM.180), make Pre-Training Recommendation to enhance the knowledge that is required by end users before they
attempt their system and process training. Without these pre-requisite training, end users may experience a longer training curve or require more support to master the
information they will receive to perform in their new job role. Pre-training activities may also contribute to reducing anxiety in preparation for a successful transition
Highlight the knowledge required by end users in preparation for their system and process training. This may consist of any of the following elements that apply to
impacted employees according to their new job role:
Job roles and employees into each job role
Pre-requisite computer literacy that is required to use computer and receive their training
Additional skills and ability required by employees in any job role (e.g., if the job role changes from entering data to providing support to those who will now be
entering data at the source)
Pre-training recommendations (e.g., walkthrough of the new process and tasks/activities underneath)
A confirmation that impacted employees have been informed of the new skills and related training that applies in their case
A confirmation of the enrolment to pre-training activities. Sometimes this could consist of a self-paced course using a computer or a CD-Rom/DVD
Prepare a Transition Plan
The HR Transition Plan defines actions and processes needed to ensure the transition of people and teams to their new job role and responsibilities. It is prepared by the
OCM team with the support from the Change Agent Structure, project team leads and most informed team members and subject matter experts. A specialist from the
Human Resources Department is also part of this team. The HR Transition Plan follows the Human Resource Department policies and respects the agreement with the
union if one is in place. The VP of Human Resource should also approve the HR Transition Plan. The HR Transition Plan takes into account the impacts on the day-to-
day work, on the working environment, on the pre-training that precedes the system/software training; it will also involve the managers as part of the validation process.
An HR Transition Plan contains the following information:
Stakeholder groups: Targeted groups of employees or individuals and/or their management
HR activities
Management activities
Pre-Training
Job Role updated
Date
Validate the HR Transition Plan
The HR Transition Plan needs to be validated by the management in order to obtain the support and commitment from the management to be executed. The VP of HR
Services will also have to provide direction or be personally involved with union representative(s) if that applies.
All the components of the HR Transition Plan need to be validated through working session(s) with the management teams that are responsible for each
employee/stakeholder group. The agenda of those sessions corresponds to the elements from the HR Transition Plan that require validation. The discussion around
these elements will contribute to confirm or refine them and, most importantly obtain the commitment that they will put into action.
Usually the validation is done with the managers of each impacted group of employees. During the work session, the change management specialist will:
Summarize the major impacts on employees under the manager accountable for a sub-process. Assess impacts on the day-to-day work.
Assess impacts on the employees skill set.
Impacts on the work environment.
Summarize how those employees will be transition.
Solicit the participation of the Human Resource Department in the transition plan.
Work with the communication specialist to customize the messages that need to be carried:
The level of commitment that is required by the organization toward the transition plan.
The details around the way the organization will support the transition plan.
The alignment that is required to comply with HR policies and rules set by the labor contract.
The change management specialist will validate the transition plan and capture the following:
Potential reactions expressed by each group of impacted employees.
Potential reactions and risks.
Create Implementation Plan
Once the validation session is completed and revisions made to the HR Transition Plan, it becomes the Implementation Plan. The approved Implementation Plan is rolled
out and actions committed to action. A responsible person has been identified and the timeline confirmed.
It is important to update the Change Management Roadmap / Communication Campaign (OCM.140). This integration will contribute a coordinated effort of change
management and communication activities at the project level and ensure the availability of the project team to support all employee groups. This will also secure the
involvement from executives and project sponsor as required implementing and following with actions posted in the Implementation Plan.
Assist the Client with Implementing the HR Transition Plan
The execution of the HR Implementation Plan remains the responsibility of the client management team, with the support from the change management team and the
project team responsible for the coordination and the successful roll out of the project.
To further assist the client, create an Implementation Plan with step-by step activities to transition the users.
Integrate into the Change Management Roadmap / Communication Campaign the necessary communication activities/events to support the plan.
Back to Top
Change Management
Specialist
Responsible for documenting the HR Transition Plan. 90
Business Analyst minimal
Back to Top
PREREQUISITES
Prerequisite Usage
Job Impact
Diagnosis
(OCM.180)
The Job Impact Diagnosis provides recommendations to prepare end users for the day-to-day work using the new processes. It identifies who
be impacted, how they will be impacted and at what level they are impacted.
Back to Top
TEMPLATES AND TOOLS
OCM-190_HR_TRANSITION_PLAN.DOC MS WORD
Back to Top
The HR Transition Plan is used in the following ways:
as an input into the Managers' Unit/Department Impact Workshop
Back to Top
QUALITY CRITERIA
Back to Top
OCM.200 - DESIGN MANAGERS' UNIT/DEPARTMENT IMPACT
WORKSHOP
In this task, you prepare for the Managers' Unit/Department Impact Workshop. The Managers' Unit/Department Impact Workshop is delivered after the new workflow has
been developed in order to prepare the managers for the changes that are going to occur. It is specifically designed to support managers to transition the end users. The
purpose of the workshop is to:
Prepare managers for the new management model.
Provide the managers with the tools and coaching that they need to transition their people to the new processes, tasks and procedures.
Keep the managers actively engaged.
Support the managers in generating a collaborative and problem-solving approach for their direct reports.
ACTIVITY
Back to Top
WORK PRODUCT
Managers' Unit/Department Impact Workshop Materials - The Managers' Unit/Department Impact Workshop Materials consists of all the materials necessary to
conduct a successful Managers' Unit/Department Impact Workshop.
Back to Top
TASK STEPS
1 Review Job Impact Analysis
(OCM.170) to determine the level
of changes.
Job Impact
Analysis
The Job Impact Analysis provides recommendations to prepare end users for the day-to-day work using the
new processes. It identifies who will be impacted, how they will be impacted and at what level they are
impacted.
Logistics
The Workshop Logistics provide the pertinent logistical details for the workshop (e.g., date, location, times,
etc.).
3 Identify and invite participants. Participants List
Invitation
Memorandum
The Participants List is a list of the participants.
The Invitation Memorandum is used to invite the participants to the workshop.
Presentation
Materials
The Workshop Presentation Materials consist of any materials that need to be prepared for use during the
workshop.
5 Prepare Workshop Tools and Key
Messages
Workshop Tools
and Key
Messages
The Workshop Tools and Key Messages support the presentation content that will be utilized to conduct the
workshop.
6 Build a Facilitation Grid. Facilitation Grid
Workshop
Activities
The Facilitation Grid includes selected exercises and activities that will be implemented during the workshop
to accomplish the workshop objectives.
Specific Workshop Activities will be used during the workshop.
7 Validate Facilitation Grid with the
client.
Validated
Facilitation Grid
The Validated Facilitation Grid will ensures that the client accepts and is aligned to the content that will be
presented in the workshop.
8 Prepare Session Planning
Checklist(s).
Session
Planning
Checklist
The Session Planning Checklist provides a checklist to verify that all necessary details for the workshop
have been addressed.
Back to Top
#TOP #TOP
APPROACH
The managers are one of the most important groups to receive buy-in from and to get engaged early in the project. There needs and interests in terms of driving the
change and addressing the human issues that arise must be addressed. They are typically the first to face resistance from the end-user community and are often directed
by the executives to take ownership in ensuring that the new technology and processes will be adopted by all those who are affected by the change. As the managers
work to improve overall change readiness, manage points of resistance and model the change they must be made aware of the impacts that will occur in their specific
departments. Therefore it is very important to provide them with project related details early on in the project.
The Managers' Unit/Department Impact Workshop requires at least a half day meeting.
The Managers' Unit/Department Impact Workshop is specifically designed to support managers to transition the end users.
Ensuring that the managers are aware of what changes will impact their departments is very important. They must be the first to understand the components of these
changes and they will be tasked with the responsibility of continuing to support the project.
Review Job Impact Analysis
The Managers' Unit/Department Impact Workshop is delivered after the new workflow has been developed in order to prepare the managers for the changes that are
going to occur. The Job Impact Analysis (OCM.170) provides recommendations to prepare end users for the day-to-day work using the new processes. It identifies who
will be impacted, how they will be impacted and at what level they are impacted. Review the Job Impact Analysis to determine the level of changes. The Collect and
Analyze Job Change Data (OCM.170) and this task are closely related and may be conducted in parallel or at the very least this task will closely follow the Job Impact
Analysis.
Ensure that you have a clear understanding of the job impacts and work with the functional leads to gain additional insight so you are prepared to address questions that
will arise from the managers during the session.
Reinforce the significance of their support and continued corporation
Introduce what initiatives are in place to support the managers during this transition
Training Plan
HR Transition Plan
IT Transition Plan
Schedule Workshop
Along with the Oracle and client project managers, determine the Managers' Project Alignment Workshop logistics, including:
date
location
times
Collect the names and contact information of those managers that will be required to attend the workshop from the Oracle and client project managers. The invitation
should be sent by the project sponsor to ensure that the workshop will be well attended. The impact of people missing will push out the timeline as each designated
manager s input is required. Include an RSVP so that set up, materials, food, etc. is sufficient.
Ensure that all presentation materials along with tools and templates are printed and appropriately packaged prior to the Managers' Unit/Department Impact Workshop.
Reserve all items that are necessary to run the workshop and ensure that they are in the room prior to the start of the workshop. Such items include pens, markers,
whiteboards, easels, paper, projectors etc. Additional items may include name tags, badges and security passes.
presentation.
Prepare any presentation materials that will be used during the workshop:
handouts
booklets, etc.
new processes impacts on the personnel grid
Prepare Workshop Tools and Key Messages
The Workshop Tools and Key Messages support the presentation content of the workshop. Prepare tools for managers in order to actively engage them in the project.
These tools may be used during the workshop as well as by the managers after the workshop so that they can continue to mitigate specific risks. Ensure that all
workshop tools and key messages are timely and accurately based on the project schedule. Confirm with the Oracle project manager that this information is correct and
accurate. Ensure that all tools are printed and appropriately packaged prior to the Managers' Unit/Department Impact Workshop. If there are marketing costs assigned to
the project, ask the Oracle project manager to see if key messages that are branded to the project can be created as posters, banners, etc. Possible key messages to
serve as a rallying point may include:
The right way to the right people creates a positive momentum for change
Manage issues
Feed the hunger for information avoid rumors
Running an effective and well regarded workshop requires a professional setting where all workshop tools and key messages are prepared and made available at the time
of the presentation.
A successful Managers' Unit/Department Impact Workshop depends on a well-planned and well-structured timetable. The Facilitation Grid includes selected exercises
and activities and topics for discussion that will be implemented during the workshop to accomplish the workshop objectives presented in a well-planned and well-
structured timetable. It is a timetable for the entire time of the workshop showing what activities or exercises will be accomplished at what time. It should include time
allocated for breaks and meals.
Involve the project sponsor from the executive level to open the workshop and communicate the alignment that is required. Identify key issues to address. Create specific
exercises and activities (or, if available, select from a directory or repository of exercises and activities) that will be implemented during the workshop to accomplish the
workshop objectives. Develop a Facilitation Grid and timetable that ensures that the discussion focuses on the need to support managers and their responsibilities in
transitioning their people to adopt to the new technology and processes.
Managers' Project Alignment Workshop Objectives
Assumptions
Background
Validate the Managers' Unit/Department Impact Workshop Facilitation Grid with the project sponsor. Obtain the signoff on the completed workshop materials including the
Facilitation Grid with the project manager and required client representatives. Socialize the materials with the Oracle project manager so he can promote cooperation,
provide input and validate work products. This collaboration facilitates the agreed upon organizational change. Revise and re-socialize where and when required. Do not
conduct the workshop without the validation and required signoff.
prior to conducting the Managers' Unit/Department Impact Workshop to make sure last minute preparations have been accomplished.
In order to be successful, the change management specialists work closely with the project manager. The project manager promotes cooperation, provides input and
validates work products. This collaboration facilitates the agreed upon organizational change.
Back to Top
Change Management
Specialist
Design and prepare the materials for the Managers' Unit/Department Impact Workshop. 100
Client Project Manager Assist with the workshop preparation. Support the managers and encourage their ability to share information openly and
honestly in order to support the project's initiatives and the affected end users.
*
Back to Top
PREREQUISITES
Prerequisite Usage
Job Impact Analysis
(OCM.180)
The Job Impact Analysis provides recommendations to prepare end users for the day-to-day work using the new processes. It identifies who will
be impacted, how they will be impacted and at what level they are impacted.
HR Transition Plan The HR Transition Plan defines the actions and processes needed to transition people and teams regarding new job responsibilities. This is the
(OCM.190) plan that the managers' will be using to transition their end users.
Back to Top
TECHNIQUES
Technique Comments
Workshop Techniques
Handbook
projects.
Back to Top
TEMPLATES AND TOOLS
OCM-200_MGRS_UNIT_DEPT_IMPACT_WORKSHOP_MATERIALS.DOC MS WORD - Use this template to prepare for the workshop.
Back to Top
The Managers' Unit/Department Impact Workshop Materials are used in the following ways:
to conduct the Managers' Unit/Department Impact Workshop
Distribute the Managers' Unit/Department Impact Workshop Materials as follows:
Back to Top
QUALITY CRITERIA
Back to Top
OCM.210 - CONDUCT MANAGERS' UNIT/DEPARTMENT IMPACT
WORKSHOP
In this task, you conduct the Managers' Unit/Department Impact Workshop. The Managers' Unit/Department Impact Workshop is delivered after the new workflow has
been developed in order to prepare the managers for the changes that are going to occur. It is specifically designed to support managers to transition the end users. The
purpose of the workshop is to:
ACTIVITY
Back to Top
WORK PRODUCT
Enabled Managers - Enabled Managers are prepared to transition their people to the new processes, tasks and procedures.
Back to Top
TASK STEPS
1 Prepare for the workshop Session Planning Checklist(s) Use the Session Planning Checklist(s) from the Managers' Unit/Department Impact
Workshop Materials (OCM.200).
2 Facilitate the workshop. Aligned Managers Aligned Managers have knowledge of the project vision, direction and strategies and know
their individual roles and responsibilities.
3 Perform post-workshop wrap up
and tool hand-off.
Updated Materials, Workshop
Results and Tools
Update any materials, if necessary. Prepare tools for Aligned Managers. Document results.
4 Provide ongoing coaching. Ongoing Coaching Ongoing Coaching is provided during the project to support the managers.
Back to Top
APPROACH
The managers are one of the most important groups to receive buy-in from and to get engaged early in the project. There needs and interests in terms of driving the
change and addressing the human issues that arise must be addressed. They are typically the first to face resistance from the end-user community and are often directed
by the executives to take ownership in ensuring that the new technology and processes will be adopted by all those who are affected by the change. As the managers
work to improve overall change readiness, manage points of resistance and model the change they must be made aware of the impacts that will occur in their specific
departments. Therefore it is very important to provide them with project related details early on in the project.
The Managers' Unit/Department Impact Workshop requires at least a half day meeting.
Use the Session Planning Checklist(s) from the Managers' Project Unit/Department Impact Materials (OCM.200). Ensure that all of the work from the task, Design
Managers' Unit/Department Impact Workshop (OCM.200) has been preformed.
Facilitate the workshop according to the prepared Facilitation Grid that has been approved by the client. Park issues that are lingering and require further discussion
ensure that those issues are addressed immediately. Take into consideration that the managers will experience personal changes as well that may include:
#TOP #TOP
On their management model
The new information available in the system
Some decisions will be visible in the system by their own manager
Coach a team who will have to perform differently and sometimes operate with new tasks
So, it is important to consider that the managers may also be resistant as well. The facilitator will have to listen carefully to reactions of managers before discussing the
impacts for their employees. Manager must feel that they will be supported during the transition as they handle the employee issues but they must be prepared to handle
the transition on an everyday basis.
Ensure that the managers have the tools and know-how to support the project and lead the end users to adopt the technology and processes that result. Leverage the
skill sets and intellectual capital of middle management.
Upon completing the workshop, the managers be aligned and understand their role in addressing the department-specific impacts. They will act in accordance based on
the Job Impact Analysis (OCM.170). By the end of this workshop, the managers are prepared for the new management model, they have the tools and coaching that are
required in order to transition their people to the new processes, tasks and procedures, and to remain actively engaged. Ensure that you have supported the managers in
generating a collaborative and problem-solving approach for their direct reports.
At this time, the managers should have the right tools in hand that to provide ample support. Some additional tools may follow as the project evolves. Examples may
include but are not limited to communication tools, facilitation tools or direct coaching.
Update any materials, if necessary and document results.
Just because the workshop is over does not mean the support ends. Ongoing coaching is provided to the managers, as required. It is vital for the managers to know that
they are supported. Ensure that an executive provides communication to the managers so that their influence and challenges are recognized and their efforts will be
supported. Reach out to the managers on a consistent basis to address their department-specific questions and concerns so they can support the change effort and be
able to manage the impacts their department will face. Depending on the communication guidelines of the project, provide the necessary resources that are readily
available to them in order to build and sustain the change momentum. Drive the managers to the project web site for accurate project related information. Have them
utilize the network of their peers and ensure that the project news letters are read and understood by the end-user community. Always enforce that the managers have
the support and can utilize the change agents as required.
Back to Top
Change Management
Specialist
Facilitate the Managers' Unit/Department Impact Workshop. 100
You will also want to involve business analysts (functional specialists) to participate in the workshop.
Back to Top
PREREQUISITES
Prerequisite Usage
Managers' Unit/Department Impact
Workshop Materials (OCM.200)
The Managers' Unit/Department Impact Workshop Materials consists of all the materials necessary to conduct a successful
Managers' Business Process Changes and Job Impacts Alignment Workshop.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
Tool Comments
processes.
Back to Top
Enabled Managers are prepared to adopt the new management model and support the transition. They:
have learned the consequences of the implementation
understand how people will be impacted
have learned how to help facilitate the transition
Back to Top
QUALITY CRITERIA
Back to Top
OCM.220 - PREPARE ASSESSMENT OF IMPACT ON IT GROUPS
In this task, you review the current organizational and job structures, workflows and culture, as well as determine the future vision, mission and levels of performance that
IT aims for after implementation and assess the impact of the technology changes on specific jobs, roles, resources and reporting structures, and compare the findings
with leading practices and benchmarking data.
ACTIVITY
Back to Top
WORK PRODUCT
IT Alignment Diagnosis Grid - The IT Alignment Diagnosis Grid shows how the IT groups will be impacted by the changes and presents data on benchmarks and
leading practices.
Back to Top
TASK STEPS
1 Prepare assessment
materials.
List of Employees Impacted
Interview Grids
Focus Group Grids
These components provide a grid listing key people/focus groups to interview and capture potential
changes.
2 Communicate the initiative. None Inform all impacted people about the initiative, the objectives and goals.
3 Conduct interviews and
focus groups.
None Capture the data that is needed to identify the gap between the new requirements and the current
organizational structure, roles, resources and workflows.
4 Define the new IT vision. IT Vision The IT Vision is the new vision for the IT organization.
5 Compile and analyze data
and findings.
IT Alignment Analysis Grids
IT Alignment Diagnosis
Grid
The IT Alignment Analysis Grids are used to compile and summarize the data.
The IT Alignment Diagnosis Grid contains validated data on how the IT groups will be impacted, how to
redesign the organization structure, revisit the mandate and roles, number of changes, the locations,
etc.
6 Gather data on
benchmarking and industry
leading practices.
Benchmarking and Leading
Practices
Benchmarking and Leading Practices include benchmarking data on organizational structure, resources
and roles from organizations within the industry, which are reputed for best utilization of the technology
and people.
7 Make revisions to workflows,
structures, resources and
roles.
Revised Strategy,
Structures and Roles
Recommendations
The Revised Strategy, Structures and Roles include recommendations for revising organizational
structures and role definitions.
8 Validate analysis grid and
recommendations.
Validated Analysis Grid and
Recommendations
The Validated findings and recommendations of the assessment of impact on IT groups has been
reviewed and approved by the CIO and other key IT personnel.
Back to Top
APPROACH
When an organization takes on large technological changes, the information technology groups often experience significant change in the way they provide services and
do work. An IT alignment is often required to evaluate the impacts on the technology changes on the departments vision, structure, and roles and responsibilities of IT
specialists. It updates the IT groups workflows, job structures, and organizational structures to reflect changes initiated by the implementation. In many situations, it is
necessary to revisit the mandate and the role of the IT group to better serve the organization with the rollout of the new technology.
The purpose of this task is to describe the design of the new IT organization structure and revisit the mandate and roles of IT groups. Capture an assessment of the
current situation, roles, responsibilities, and reporting structure for the new technology Support Groups and Information Technology Groups. This task includes technical
and functional areas. The assessment leads to identification of major issues and challenges and recommendations for improvement.
This task is executed during the Transition phase and its findings are used to create the IT Transition Plan (OCM.230), which is then implemented in the Production phase
(OCM.260).
Prepare Assessment Materials
Research and review any background materials, previous assessments, organizational direction etc. Obtain the first read into specific information regarding the IT groups'
concerns and challenges. Get an overview of the IT organization, e.g., check if a union is in the place and how to involve them.
Use a grid format to identify key people/focus groups to interview in order to capture potential changes. The people involved in this process are the CIO or the Director of
IT, managers and representative employees. To identify these people, it may be necessary to start interviewing the core project team leaders who know the organization
and the new business processes.
LIST OF EMPLOYEES IMPACTED
Use a grid to compile the job titles of people in the IT and other supporting groups who will be impacted, their roles, locations and the names of their managers. In large
organizations, it is possible that more than one job title is associated to the employees, so capture all job titles.
Based on the type of the technology change, it is possible that only IT group or one group of IT in one location is impacted. In that case, only the list of employees who
will be impacted will be required.
When the impacted employees are located in different places, you may need to schedule a meeting with key players from the core project team who are capable of
defining the changes that will result from the new system as well as identifying employees whom will be impacted by those changes.
INTERVIEW GRIDS
In order to capture the information required for the IT alignment, some interviews will be conducted. Interviews will be face-to-face personal interactions that will enable
open sharing of information and concerns. Managers and employees from IT and other business units will participate in the interviews, based on the type of technology
change. The topics to be covered with in these interviews are identified in the following sections.
Key Considerations
To prepare the interview/focus group grid of Information Technology groups from their current computing/technology structure to one that better supports the new
technology, the following considerations need to be addressed. This listing is not exhaustive; it is only intended as a guide.
Whats the current mode of operation?
Who is on the IT support team?
How many are on the team?
What are their skills?
How does the current mode of operation support the current Information Technology vision?
What types of user support is provided?
Who owns the business processes?
How are system changes and upgrades introduced?
The purpose of the interviews is to analyze the current situation, concerns and the effectiveness of the present organizational structure, as well as to understand the other
supporting elements of an effective organization. The following topics will have to be covered to capture the data:
FOCUS GROUP GRID
In large organizations, it is not possible to complete this task with interviews; focus group approach will be useful to capture more information in less time. Focus groups
can be used to supplement information collected from individual interviews.
Focus Group Facilitation
There are a few rules to follow for the facilitation of focus groups:
Get approval from the CIO or IT Director to conduct focus groups.
Identify who can participate in focus groups.
Send an invitation signed by the leader.
Request and assure confidentiality of focus group discussions.
Identify a suitable physical facility.
Communicate the Initiative
The initiative assessment of impact in IT groups will be communicated to all relevant groups of employees.
It is necessary for the leader to communicate this initiative to his management team and employees. It will be a great opportunity to demonstrate the leaders' commitment
to this initiative.
Most often, the communication will target to spread the following messages:
the importance for the organization to undertake the initiative at this time
the process
the kind of involvement that is needed from relevant groups
the potential impacts on people
reassurance to IT groups about the organizations commitment to its employees
Communicate via a large medium, such as email, to increase the awareness level. Create awareness among the stakeholders about the assessment objective in order to
gain their cooperation.
Conduct Interviews and Focus Groups
Interviews and focus groups will be conducted as per a pre-validated schedule. Use the prepared Interview Grids and Focus Group Grid.
Capture in the grids, the needed data to identify the gaps between the new requirements and the current organizational structure, roles, resources, and workflows. Collect
Information on major challenges and risks facing the IT organization. Assess the current skills and skills required for the new technology.
Take notes during interviews. Use flipcharts to capture important information shared by the participants during the focus groups. This data will be used to populate the
data compilation grids.
Define IT Vision
In addition to the interviews and focus groups, meet with the CIO and other IT leaders to capture the new IT vision and goals. During these meetings discuss the current
vision and future vision for IT organization; and how the IT vision will support the clients organization. These interviews will focus on articulating the new vision,
identifying major challenges to achieve the new vision, and identifying how the new technology will support the new vision. The topics of discussion will also include
business drivers, motivators and organization structure.
It is recommended to evaluate if a benchmark activity is required to guide the leaders in their decisions. The benchmark will cover the following elements:
IT organization structure
Resources
Collaboration with other Business Units
Performance Metrics
Efficiencies
Define the new vision. Make recommendations on the vision statement based on the leading practices on articulating the vision.
Identify strategic objectives that will enable transition from the vision to an operational achievable goal.
BUSINESS DRIVERS
Identify key business drivers and motivators for IT alignment activities in order to best serve the clients goals. Include the following business drivers in the discussions:
cost reduction expected
level of efficiencies now required
level of quality of service provided
the IT structure needed to support the IT
Compile and Analyze Data and Findings
IT ALIGNMENT ANALYSIS GRIDS
Use grids to compile the data captured during the interviews with the CIO, key IT leaders, managers, employees and the focus groups. This data will make it possible to
identify the gaps between the new requirements and the current organizational structure, roles, resources, and workflows.
IT ALIGNMENT DIAGNOSIS GRID
The summarized and compiled data in the IT Alignment Analysis Grids can be used to analyze the IT organization regarding the structure, roles, resources and workflows.
Recommendations for the IT organization can be made based on this analysis.
Gather Data on Benchmarks and Industry Leading Practices
Gather data to identify what others in the industry are doing, where does the client stand in comparison, what are the existing standards. This data will be gathered on
organizational structure, roles, resources and performance metrics.
Benchmarks will be identified and data will be collected. It will be used to identify, understand and compare the leading practices and processes of other organizations and
target problem areas and develop solutions to achieve best levels of performance. In addition, it will be used as a framework, structure, and methodology to propose
structures, roles and resources.
Make Revisions to Structures, Roles and Workflows
Create a new strategy for the IT Vision and propose new structural models and roles. These proposed solutions should be based on the data and findings presented in
the IT Alignment Diagnosis Grid and the Benchmarks and Leading Practices data.
Recommend specific revisions to the existing structure, roles and responsibilities.
Validate Analysis Grid and Recommendations
The Grids and Recommendations need to be validated in terms of internal organizational situation. The Recommendations need to be validated in terms of both internal
organizational situation and feasibility. With all the data captured and analyzed, the Grids identify major issues and challenges. Specific recommendations are made
regarding how to resolve the issues and handle challenges mostly through solutions related to organizational design, resource management, roles and responsibilities.
During a validation session (e.g., in a PowerPoint presentation), present the major issues, challenges and recommendations to the CIO, IT Directors and Managers. The
presentation should contain the following information to be validated:
new IT Vision
findings from interviews and focus groups on IT organizational diagnosis, major concerns and challenges
criteria for an effective structure and feedback on roles and responsibilities
suggestions on improving the structure, roles, responsibilities and resource management
potential issues and recommendation While facilitating the session, key stakeholders should be asked the following questions in order to capture issues and
recommendations:
How would you assess the current situation?
What is an effective organization?
What are your major concerns regarding future IT roles and required IT skills?
Which one of the solutions recommended will better facilitate the organization to achieve its vision and mission?
How would people react to the various solution
By communicating this information, it is now possible to identify the potential reactions of IT organization to these changes. It is also possible to finalize the solutions that
can best serve the clients interest. The information captured during these sessions will be used to prepare the IT Transition Plan (OCM. 230).
Back to Top
Change Management
Specialist
100
Client IT Director *
Back to Top
PREREQUISITES
Prerequisite Usage
These prerequisites define the business expectations enabled by the new technology.
Managers' Unit/Department Impact Workshop Materials (OCM.200) These materials contain performance requirements by business units.
Job Impact Analysis (OCM.180) The Job Impact Analysis defines the user support requirements.
Back to Top
TEMPLATES AND TOOLS
OCM-220_IT_ALIGNMENT_DIAGNOSIS_GRID.DOC MS WORD
Back to Top
The IT Alignment Diagnosis Grid is used in the following ways:
to capture impacts on IT department vision/mission/goals
to capture impacts on work, roles, procedures and skill sets
to prepare the IT department to best support the new technology
Back to Top
QUALITY CRITERIA
Back to Top
OCM.230 - PREPARE IT TRANSITION PLAN
In this task, you work with the IT leader (CIO) to update the IT group workflows, job structures and IT Department organizational structures to best support the new
application and reflect changes initiated by the implementation, and validate the accuracy, relevance, feasibility and acceptability of the conclusions.
ACTIVITY
Back to Top
WORK PRODUCT
IT Transition Plan - The IT Transition Plan finalizes the proposed changes to organizational structures, roles and resources based on the findings and recommendations
of the IT groups assessment, benchmarking data and industry leading practices presented in the IT Alignment Diagnosis Grid (OCM.220) and includes a plan for
achieving the IT organization transformation with minimal negative impact.
Back to Top
TASK STEPS
1 Prepare IT
Transition
Plan.
IT Transition
Plan
The IT Transition Plan focuses on achieving the IT organization transformation with minimal negative impact. It includes finalizing the
recommendations made in OCM.230. The IT Transition Plan details the specific actions and steps that need to be undertaken in order to
put in practice the recommended changes.
2 Validate IT
Transition
Plan.
Validated IT
Transition
Plan
The Validated IT Transition Plan has been validated and reviewed by key stakeholders in the IT organization.
Back to Top
APPROACH
When an organization takes on large technological changes, the information technology groups often experience significant change in the way they provide services and
do work. An IT alignment is often required to evaluate the impacts on the technology changes. The IT Alignment Diagnosis Grid (OCM.220) provides an analysis of the
current situation, identifies impacts of new technology on IT groups and workflows and makes recommendations. In this task, the IT Alignment Diagnosis Grid (OCM.220)
is used to prepare the IT Transition Plan. The IT Transition Plan is essential to identify potential solutions and evaluate each one of these solutions. It presents
benchmarking and leading practices data, identifies major issues and includes a step-by-step action plan to implement the changes recommended to proactively plan IT
transition and manage challenges.
The IT Transition Plan (OCM.230) is implemented in the Production phase (OCM.260).
Prepare a Transition Plan
The IT Transition Plan is a step-by-step action plan that details specific actions and processes that are needed for adapting the new structure, workflows, roles and
responsibilities. The change management specialist prepares it with support from the IT leadership, management and a representative from Human Resources. The IT
Transition Plan respects and follows the organizations policies and practices. It takes into account the impacts on the culture, on the work environment, day-to-day work
and the training needs.
The IT Transition Plan should contain the following information:
Customer Analysis: different customer groups, needs and prioritization
Stakeholder Groups: targeted groups of employees or individuals and/or their management.
Updated Organizational Strategy, Structure, Job Role and Responsibilities
Management Activities: activities that need to be performed by managers
Individual Activities: activities that need to be performed by each individual employee
Success Measures: criteria used for rating the success of the IT groups
Training
Specific Activities: e.g., social skills for a group of employees who were working alone and will now work as a member of a team
#TOP #TOP
Strategic Resource Management Plan: a proactive plan to achieve strategic objectives and address cyclical workloads and employee turnover that also identifies
the bottlenecks for workload and resources and proposes a plan to deal with the bottlenecks
PREPARE MANAGERS
A successful transition requires support from the managers on a daily basis. They must understand the Why-When-How of this plan and be involved at every stage. If
needed, conduct a workshop or a session with the managers to create a common understanding of the transition plan and answer any questions.
NEW HIRING CRITERIA
With the IT Transition Plan comes the new criteria to apply for selecting new employees. Include the following:
level of knowledge for the new technology
skill set required
match the candidates profile to the organizational culture
Validate the IT Transition Plan
Present the IT Transition Plan to the IT leader and other key stakeholders in the organization in order for them to validate it for:
feasibility
acceptability
Prepare a presentation to be used during a validation session to present the IT Transition Plan to the CIO, IT Directors and Managers. The following information should be
validated:
new structure, roles and responsibilities
resource management plan
training needs
Summarize the impact on culture, work environment and day to day work. Discuss potential issues and recommendation. While facilitating the session, key stakeholders
should be asked the following questions in order to capture issues and recommendations:
How would you assess each recommended solution?
What are the possible reactions and risks?
What are your major concerns regarding each stage of the transition plan?
By communicating this information, it is possible to identify the potential reactions of IT organization to the changes. The information captured during these sessions will
be used to execute the task, Implement IT Transition Plan (OCM.260).
Back to Top
Change Management
Specialist
100
CIO *
Back to Top
PREREQUISITES
Prerequisite Usage
IT Alignment Diagnosis Grid
(OCM.220)
The IT Alignment Diagnosis Grid shows how the IT groups will be impacted by the changes and presents data on benchmarks and
leading practices.
Back to Top
TEMPLATES AND TOOLS
OCM-230_IT_TRANSITION_PLAN.DOC MS WORD
Back to Top
The IT Transition Plan is used in the following ways:
to re-design the IT department to ensure ROI of the new technology
to describe a step-by-step transition process
to prepare the IT specialists for their new roles and responsibilities and to support the new technology
to involve the IT specialists in the re-design of their services
Back to Top
QUALITY CRITERIA
Back to Top
OCM.250 - MEASURE ORGANIZATIONAL CHANGE
EFFECTIVENESS
In this task, you determine how well the organization met the objectives set at the beginning of the project as well as identify any potential future risks and develop the
Post Go Live Recommendations to target the return on investment (ROI).
ACTIVITY
Back to Top
WORK PRODUCT
Organizational Effectiveness Assessment - The Organizational Effectiveness Assessment captures the efficiency of the work done during the project and highlights the
change management work to continue after the Go Live to allow for a shorter transition.
Back to Top
TASK STEPS
1 Reuse the Change Management Roadmap / Communication
Campaign Effectiveness Assessment (OCM.155) to solicit
feedback.
Survey Feedback The Survey Feedback provides issues such as areas for
improvements and/or problem areas that require further
investigation.
2 Identify additional Information and/or develop data collection
tools. Identify existing tools or develop new collection tools.
Data Collection Tools Data Collection Tools are used to gather the assessment
information.
3 Collect additional information (gather the data). Use
whatever data collection tools you have developed to gather
data.
Utilized Data Collection Tools
4 Analyze the information collected. Organizational Change
Management Effectiveness
Analysis
The Organizational Change Management Effectiveness Analysis
is the analysis of the data.
5 Prepare Post Go Live Recommendations. Post Go Live Recommendations The Post Go Live Recommendations are recommendations to
mitigate any potential existing risks that were uncovered in the
assessment.
6 Prepare report. Organizational Change
Management Effectiveness
Assessment Report

Back to Top
APPROACH
The objective of this task is to determine the level of achievement that has been accomplished based on the objectives that were set at the beginning of the project. It also
aims at identifying any future risks that would prevent the organization from achieving those objectives; recommendations will be developed for implementation beyond
Go-live. This task starts and ends during the Production Phase.
The scope of this task does not include the assessment of the performance of the system neither of the benefit gaps in relation with the business case that was put
together at the beginning of the project. Although the Oracle Change Management (OCM) team might be invited to support the benefit realization assessment, another
group is likely responsible for this deliverable. The OCM team will assess the level of adoption of changes by end users/managers and the outcomes of the project from a
human and organizational perspective, as opposed to the financial or system perspective. As an example, this task will measure the adoption of standard processes
throughout the organization and the compliance to instructions end users have received during their training. Recommendations will be developed in order to achieve this
type of benefits and organizational changes that were part of the original vision of this project. This task comprise the following components:
Review of Change Roadmap and Communication Campaign effectiveness.
Identification of additional information required and development of data collection tools.
Collection of additional information (data gathering).
Data analysis and risks assessment.
Post go-live recommendations (to mitigate those risks).
OCM effectiveness report.
Reuse the Change Management Roadmap / Communication Campaign Effectiveness
Assessment (OCM.155)
Reuse the Change Management Roadmap / Communication Campaign Effectiveness Assessment (OCM.155). Add to this assessment to assess the level of comport
with the processes and tools represents, the training efficiency and the capacity to use the system on a daily bases as well as applying the new processes.
Review the Change Management Roadmap / Communication Campaign Effectiveness Assessment Communications Effectiveness Surveys. Attention should be given to
any group of employees who felt they had not been sufficiently informed on their new role and responsibilities, or those that do not fully understand or agree with the
changes affecting their business unit and/or job role. Data should be analyzed such a way to identify opened issues such as areas for improvements and/or problem
areas that require further investigation.
Identify Additional Information and/or Develop Data Collection Tools
Give attention to the amount and the nature of the information that is required in order to fully document opened issues; the scope of information that is required will
determine the best approach to obtain additional information. The scope of the research is determined by the number of employee groups to be investigated, the number
and variety of job role and employees per job role, their geographic dispersion, the disparity/homogeneity of the information to be documented (e.g., the number of
processes activities/tasks to be analyzed, the complexity of issues per employee group), etc.
The starting point before to investing effort into any data collection activity is to review the information already available, such as: questions addressed to the Helpdesk, to
project team members, via forums or the project web site. If additional information is required, consider using tools that have been used throughout the different phases of
the project in case they are applicable. Time is the essence here as issues cannot remain unsolved due to the risk of institutionalizing improper behaviors or the other risk
that employees resolve themselves issues due to the lack of coordinated guidelines.
If determined, develop additional data collection tools (surveys and /or facilitation grid for focus groups and other forms of feedback loops to measure the effectiveness of
the Organizational Change Management effort.)
Collect Additional Information (Gather Data)
Once the scope of the collection effort and the data collection tools determined, you start gathering the data you need in order to document issues. Conduct surveys and
focus groups or any other forms of feedback loops to measure the effectiveness of the Organizational Change Management effort.
There is obviously more than one approach that can be used depending on the nature of the information needed, the size and the variety of the sample population(s), and
the complexity of the information that is required to be collected. Consider the following guidelines:
Survey using questionnaires for factual and quantitative information. Surveys often need to be followed by focus groups in order to validate the understanding of
data.
Two-way communication media, like focus groups or working sessions, for detailed and complex information.
One-on-one interviews in order to validate information, or to collect sensitive information or, to deal with complex situations.
Attention should be given to metrics that often need to be captured, especially in those cases where there are benefits to be realized.
Analyze the Information Collected
Catalog and organize the data captured. The data captured should be analyzed in such a way to highlight findings that contain factual information. This way, it becomes
easier to identify specific employee groups/job role, a clear description of issues, along with the supporting data in term of number (frequency, occurrences, number of
errors or discrepancies, etc.). The analysis should be pushed further to identify the risks associated with the issues.
Data should also be analyzed at the light of the vision and the benefits that prevailed at the beginning of the project. This activity will add considerable value to the project,
as you will tend to close the loop with the original rational for the project to be approved at the beginning.
Part of the analysis, your observations and risks should be validated with project team members, change agents, management team and the project sponsor. Objectives
of the validation activity are to obtain further clarification and the proper level of support before you develop recommendations to address and mitigate those risks.
Prepare Post Go Live Recommendations
Once the analysis is validated, recommendations should be developed in order to mitigate the risks identified, and ultimately achieve the benefits that were anticipated at
the beginning of the project. Develop recommendations in regard to the risks being addressed. Each recommendation should specify the following elements:
Actions to be put in place and the employee groups, job role and employees that each action is targeting.
Recommendations should comprise a specific measurement or performance objective to determine the level of satisfaction that is expected. Attention should be
given to the issues that we were addressing in the previous components and the benefits the organization are pursuing with this project.
A person should be named responsible to execute each recommendation.
If required, additional resources should be identified in order to insure the proper support to the person responsible. Additional resources could also be asked to
validate/control that the recommendations have resolved the issue or produced the outcome expected.
A timeline should be set in order to close the issue at the earliest and avoid the situation to deteriorate.
Prepare Report
The OCM Effectiveness Assessment Report aims at closing the loop after the project went live, and summarize the issues and actions that were put in place in order to
optimize the benefits from the project, and ensure that the organizational and human aspects of the projects have all been addressed.
The OCM Effectiveness Assessment Report report should contain the following section:
Assessment of the Change Roadmap and Communication Campaign Effectiveness
Summary of open issues after go-live along with associated employee groups
Highlights of the data collection effort that has been performed
Findings and potential risks
Post go-live recommendations (to mitigate those risks)
Back to Top
Change Management
Specialist
100
Back to Top
PREREQUISITES
Prerequisite Usage
Change Management Roadmap / Communication Campaign
Effectiveness Survey (OCM.155.4)
Review the latest Change Management Roadmap / Communication Campaign Effectiveness Survey
(OCM.155.4) to see how effective the Change Management Roadmap / Communication Events
(OCM.150) were.
Back to Top
TEMPLATES AND TOOLS
OCM-250_ORG_EFFECTIVENESS_ASSESSMENT.DOC MS WORD
Back to Top
The Organizational Effectiveness Assessment is used in the following ways:
identify any potential future risks
make Post Go Live Recommendations to ensure that the ROI will be targeted
Back to Top
QUALITY CRITERIA
Back to Top
OCM.260 - IMPLEMENT IT TRANSITION PLAN
In this task, you implement the IT Transition Plan (OCM.230) with the client HR specialist to facilitate the transition within the IT organization, securing the right level of
sponsorship in order to deploy the plan recommendations.
ACTIVITY
E.ACT.DTRTP Deploy IT Transition Plan
Back to Top
WORK PRODUCT
Aligned IT Organization - An Aligned IT Organization is effectively integrated with the overall business strategy and reflects their new capability.
Back to Top
TASK STEPS
1 Review the IT Transition Plan (OCM.230) with the client HR
specialist.
IT Transition
Plan
The IT Transition Plan proposes changes to organizational structures and role
definitions and includes a plan for achieving the IT organization
transformation with minimal negative impact.
2 Create an Implementation Plan. Implementation
Plan
The Implementation Plan contains step-by-step activities to re-design the IT
service.
3 Integrate into the Change Management Roadmap / Communication
Campaign the necessary communication activities/events to
support the transition.
Key Messages Key Messages for the transition are designed to support the IT Transition Plan
rollout and for the mobilization of the IT specialists.
Back to Top
APPROACH
The objectives of this task are:
Facilitate the retention and effectiveness of the team by preparing them to effectively deal with changes.
Facilitate the transition with the IT organization.
Align IT groups with the project objectives, vision and goals.
Ensure the ROI.
Put in place the right criteria of performance for the IT service.
Back to Top
Change Management
Specialist
100
CIO *
Back to Top
PREREQUISITES
Prerequisite Usage
IT Transition Plan (OCM.230) The IT Transition Plan is being implemented in this task.
Back to Top
TEMPLATES AND TOOLS
Back to Top
An Aligned IT Organization is effectively integrated with the overall business strategy and reflects their new capability.
Back to Top
QUALITY CRITERIA
Back to Top
[TR] TRAINING
The objective of the Training process is to make sure that the project team is adequately trained to begin the tasks necessary to start the project and the users are
adequately trained to take on the tasks of running the new application system.
In a commercial off-the-shelf (COTS) application implementation, the project team may also need to be trained on the applications being installed in order to bring the
project team up to a level of application proficiency in order to complete the process of developing and testing the Business Procedure Documentation.
Back to Top
PROCESS FLOW
#TOP #TOP
Back to Top
APPROACH
The Training process ensures that the project team is adequately trained to begin the tasks necessary to start the project and the users are adequately trained to take on
the tasks of running the new application system. The Training team may also train the companys applications maintenance personnel, help desk personnel, and the
acceptance test team.
The Training process encompasses the following areas:
Training Materials
Education andTtraining
Training Methods
Training Administration
Training Environments
Training Materials
Training courses are role- and process-based. When the custom applications require custom developed training material, existing project artifacts should be utilized as
source documents. Training materials should follow the use cases and business process models that are carried forward into the Documentation and Training processes
and used to develop the documentation and training materials, as appropriate. The User Guide and User Reference can be used for training users; the systems
operations documentation for training administrators; and the Technical Reference for training systems administrators, analysts, designers, and IS operations staff. Help
desk training may require some additional documentation, such as frequently asked questions and answers. Trainers and courseware developers should orient their
material toward roles and jobs, and not components. To retain the students attention and avoid overwhelming them with information, break training sessions into
manageable pieces that focus on clear objectives. Include labs that provide hands-on interaction with the system and encourage confidence in the students ability to use
the system.
Achieve substantial savings in time and resources by designing the Documentation approach in such a way that, if need be, you can revise the documentation in later
project phases. For example, you can use refined business process flow diagrams in the user manuals and in user training.
For most commercial off-the-shelf (COTS) software, the provider offers standard classes covering the basic product features and functions. Create custom classes or
other types of training, as necessary, to suit the needs of each project.
Education and Training
OUM distinguishes between education and training. Education provides an understanding of the fundamentals of how the business operates in a certain type of
environment. Training is about learning the standard or developed applications and skills courses.
Use education when preparing project team members, users, or analysts to tackle implementation challenges and accept ownership of new business processes. It
provides guidance on industry reference and leading practices information while clarifying the operational and financial flow of the company. More importantly, it explains
why and how the company expects to achieve success, and if relevant to the project team how successful companies in similar industries have achieved success and
thereby encourages the use of proven practices, concepts, and business process metrics.
Training provides the basis for setting up and using the application(s). For large organizations, OUM encourages the use of the train-the-trainer approach; the project staff
or software provider staff trains the company instructors who in turn teach the users. OUM concentrates on providing information on the setup, technical, and functional
aspects of the application(s) and tools to the project team.
Training Methods
Two training techniques are available: direct training and train-the-trainers.
In direct training, members of the project team should staff the trainer positions. However, if there are large numbers of users to train, the trainer should be someone
experienced in providing training.
In-house trainers teaching the courses is called the train-the-trainer approach. In this case an instructor, who should be a member of the team, trains the trainer. The
trainer then trains the users and has assistance from an outside resource with strong knowledge.
Training versus Learning
The field of andragogy (adult learning) makes a clear distinction between training and learning. Whereas training is often a one-time occurrence, driven by the trainer
rather than the learner, it stops short of providing the actual performance results expected from a skilled performer. Learning expands the concept of training so it applies
to an entire process where a learner participates in learning events organized in a structured path that favors gradual learning from simple to more complex. Learning
here is better mapped to the ways adults learn and is generally self-driven by the learner. It includes repetition activities, reinforcement and measurement to ensure that
the learning has actually occurred and is now translated into the expected behavioral performance. It is also delivered in a variety of formats to cater to the variety of adult
learning styles.
Training Administration
If you have many students to train, hold multiple classes and limit each class size to 20 or fewer. Make sure the equipment available in the training environment is similar
to the equipment students will use at their normal work sites. Only being trained in those functions relevant to their job would allow students to retain more, but logistical
constraints do not always permit this degree of specialization. You must balance factors such as distance to the training site, number of classes, covered material, and
class duration.
Make sure you have the highest level of training retention. Aim to train the users as close as possible to the date of their start with the production system, so they can
exercise their new knowledge immediately.
Efficient training administration demonstrates a high level of commitment to the success of the new system.
Training Environments
Just as it is important to use final documentation as a tool in training, it is very important to construct training environments that reflect real production data and system
configuration.
Since the creation of training environments is often on the critical path, it is very important to plan ahead and train users with scenarios that were successful during
business system testing. In this way, training stays focused on real business flows and information.
Multi-Site and Iterative and Incremental Approach Considerations
Deploying applications to multiple sites at different points in time can have major impacts on training as follows:
repeating classes periodically over a long period of time
possibly having to tune material if different business units have varying policies and procedures
classes occurring at various sites simultaneously, requiring database instances for each site for all student exercises to occur without conflict
updating training materials based on lessons learned from previous deployments and production use of the new applications
Tools
Oracle Tutor
Oracle Tutor provides users with relevant process documentation and learning materials. These materials are process- or role-based, easy to update, cost-effective and
developed in conjunction with the implementation. Oracle Tutor helps apply functionality specific to Oracle Applications within the context of the organizations unique set
of policies and procedures. The product is comprised of three components: an authoring tool, a publishing tool, and a repository of Oracle Application courseware and
procedure document objects.
Back to Top
Inception Phase
TR.020 Prepare Project Team Learning Plan Project Team Learning Plan
TR.030 Prepare Project Team Learning Environment Project Team Learning Environment
TR.040 Develop Project Team Learningware Define Training Strategy
TR.050 Conduct Project Team Learning Events Skilled Project Team
Elaboration Phase
Construction Phase
TR.060 Conduct User Learning Needs Analysis User Learning Needs Analysis
TR.070 Develop User Learning Plan User Learning Plan
TR.080 Develop User Learningware User Learningware
TR.090 Prepare User Learning Environment Configured User Learning Environment
Transition Phase
Back to Top
OBJECTIVES
The objectives of the Training process are:
Train the project team to begin the tasks necessary to start the project.
Provide users with the skills and knowledge to use the features and functions of the system within their respective job roles.
Achieve a smooth transition from the old system to the new system.
Assist in gaining company-wide acceptance of the new system.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
Specialist
BA Business Analyst Obtain sample business cases, and load demo data. Conduct interviews and prepare list of proposed courses and the roles of attendees.
Research availability of standard courses. Schedule courses.
Specialist
Assist in conducting the learning needs analysis.
DBA Database Administrator Provide database administration for setting up the training environments. Install and configure the training database. Ensure all users
have access to the database. Provide support during training.
SAD System Administrator Assist in administering the project team and user learning environments, including ensuring hardware is correctly configured: installing,
configuring, maintaining operating and development software, and controlling access to the environments. Install and configure
hardware and operating system. Install and configure application code. Ensure that login IDs and responsibilities exist for the students.
Provide support during training. Install training environment. Convert data and package and test training database. Provide support
during training.
TW Technical Writer Help develop and edit training materials.
TRS Training Specialist Define learning requirements, prepare learning plan, produce learning material, and deliver courses. Review sample business cases and
demo data. Perform class dry-runs. Train the users, administrators, and other trainers. Provide and evaluate course evaluations.
Client (User)
BLM Business Line Manager Provide information about organizational performance measures, and ways in which the units operate and respond to events in order to
achieve those objectives. Describe requirements for organizational acceptance. Participate in events.
CPM Client Project Manager Ensure availability and commitment of company personnel. Ensure availability of hardware, software, and facilities.
CPS Client Project Sponsor
CSM Client Staff Member
SS IS Support Staff Assist in installing and configuring environments needed during the project and maintaining database access controls. Provide
information on current expertise level and roles performed. Provide availability information.
USR User Provide information on computer literacy level and roles performed. Provide availability information. Participate in Training events.
Back to Top
clear and detailed strategy
early involvement of trainers
committed user involvement
Back to Top
TR.010 - DEFINE TRAINING STRATEGY
In this task, you assess the education and training needs of the project team and user community and plan the delivery of the necessary training based on common areas
of responsibility, interests, and skills. This training could be accomplished in classes, through online self-study training, or a combination of both. The types of training you
need to provide depends on the type of project. Depending on the type of project, you may need to provide training for some or all of the following:
Commercial Off-the-Shelf (COTS) Software - Training for any vendor COTS software product (including Oracle applications and other Oracle products, as well as
non-Oracle vendors) that are being installed.
Custom-Built Software - Training for any custom extensions built to accommodate COTS software integration or training for an entirely custom built application.
Technical Issues - Training for anything needed to assist in understanding the technology involved (i.e., how integration works - workflow from one system to
another, how the technology is operating behind the scenes to control access - especially in the area of Security, how the ownership of documents and publishing
points work - specifically in the area of Enterprise Content Management, etc.)
Support Issues - Training for how to maintain the system, what kinds of maintenance are required (that is not already specified in the standard vendor product
manuals), what happens for specific events (monthly close, nightly back up, etc.). Also, training for what do do if specific problems come up (i.e., user cannot log
in, user account locked, etc.) during operation of the system.
This task is performed in both the Inception and Elaboration phases. The first iteration in the Inception phase addresses the education needs and training strategy for the
project team. The second iteration in the Elaboration phase adds the strategy for training the end user community.
ACTIVITY
TR.010.1
TR.010.2
Back to Top
WORK PRODUCT
Education and Training Strategy - The Education and Training Strategy helps you evaluate the training requirements for your project team and user community and
plan the delivery of relevant standard and custom training.
For most commercial off-the-shelf (COTS) software, the provider offers standard classes covering the basic product features and functions. Create custom classes or
other types of training, as necessary, to suit the needs of each project.
For projects that involve custom application development, consider providing training for the custom components covered through use cases, as well as specific
operational and technology training. Training may be focused around groups of actors with similar needs from the custom system, or based on groups of stakeholders
that maintain the system including, for example, Operations and IT Development.
Back to Top
TASK STEPS
1 Determine the training
requirements. Identify the types of
personnel (roles) and type of
training that is needed for the new
application and products.
Training
Requirements
The Training Requirements documents the groups of personnel and other types of users that need to be
prepared for the new system. It also lists who needs to receive that training. It does not list individuals but
rather the roles personnel perform and the number of people in each role. It also describes what kind of
interaction each group will have with the new system. Finally, it provides a list of suggested training modules to
meet the training needs of he various groups.
2 Assess need, source, location, and
sequence of vendor-provided
general education classes for each
planned iteration (if multiple
iterations occur).
Education
Planning
Worksheet
For the Educational Planning Worksheet, consider the following:
types of classes
class providers
skill sets required
existing skill sets
location of education classes
#TOP #TOP
cost of education classes, including travel expenses
3 Determine the COTS software,
technical issues, and support
issues training classes required,
location preferred, and sequence
desired.
Standard
Training
Planning
Worksheet
The Standard Training Planning Worksheet contains the following information:
name of training and/or education coordinator
recommended classes
training budget
logistics, such as location, rooms, and equipment
data to be used
special instructions (if any)
development of customized class materials (if required)
make-up classes (if available)
attendees for each class
style, techniques, or approach to deliver training
location of training
prerequisites
4 Determine custom classes required
and estimate necessary
preparation time.
Custom
Training and
Education
Request
Custom Training should be based on existing documentation of the custom development effort, including use
cases and business process models. Visual modeling artifacts can be used as appropriate.
Title of custom training and name of coordinating ambassador user
recommended custom classes
custom training development budget
logistics, such as location, rooms and equipment
data to be used
development of customized class materials (including functional groupings, and intended audiences
based on system actors and key stakeholders)
attendees for each class
style, techniques, or approach to deliver training (simulations, scenarios, based on use cases, or
business process models)
location of training
COTS training prerequisites
5 Determine other types of training
required and estimate the
preparation time.
Other
Training
Other types of training are typically online training, such as web casts. This is often the only type of training that
can be used for external users, but may also be effective for some internal users. The training should be based
on existing documentation of the system, including use cases and business process models. Visual modeling
artifacts can be used as appropriate.
Title of training and name of responsible ambassador user
recommended type of training
development budget
required trainingware (required software to product and use training)
date to be used
development of materials (including functional groupings and intended audiences based on system
actors and key stakeholders)
attendees/types of users for each type of training (internal users in name, external users in types of user)
style, techniques or approach to deliver training (simulations, scenarios, based on use cases or business
process models)
6 Review class preparation checklist. Training
Preparation
Checklist

7 Secure approval for plans. None
8 Schedule initial training classes,
instructors, and attendees.
Standard
Training
Planning
Worksheet
Scheduling resources for training is only one aspect of planning education and training. If you are conducting
on-site training, you should also consider the necessary classroom resources, such as:
hardware requirements
room capacity
software installations
user IDs and passwords
reference documentation
classroom equipment
contingency plan
Back to Top
APPROACH
Education and Training Philosophy
One of the most important aspects of the entire implementation process is the effective (skills are mastered) and efficient (resources utilized and costs incurred are
reasonable) education and training of the work force and possible external users. Education provides an understanding of the fundamentals of how the business operates
in a certain type of environment. Training is about learning the standard or developed applications and skills courses. To facilitate a successful implementation, education
and training must begin at the very top of the organization and include everyone affected by the new system. The best business process design in the world will be of little
value without fundamental understanding and strong support from top-level management.
Use education when preparing project team members, users, or analysts to tackle implementation challenges and accept ownership of new business processes. It
provides guidance on industry reference and leading practices information while clarifying the operational and financial flow of the company. More importantly, it explains
why and how the company expects to achieve success, and if relevant to the project team how successful companies in similar industries have achieved success and
thereby encourages the use of proven practices, concepts, and business process metrics.
Training provides the basis for setting up and using the application(s). For large organizations, OUM encourages the use of the train-the-trainer approach; the project staff
or software provider staff trains the company instructors who in turn teach the users. OUM concentrates on providing information on the setup, technical, and functional
aspects of the application(s) and tools to the project team.
Training Requirements
The requirements should be related to roles rather than individual staff members, including external roles. Review the High-Level Business Process Model (RD.011) to
see what roles (actors) within the organization will likely interact with the new system and the Present and Future Organization Structure (RD.012) for the locations. The
Business and System Objectives (RD.001) might also help to identify the best appropriate training. Having identified the different interactions with the new system, the
system can be broken down into a set of logically-related modules. These sets of modules can then be combined to provide the syllabus for training events such as
courses or modules of training.
If the level of computer literacy and technical expertise is low within the user organization, then introductory courses or modules should be run before specific training on
the new system is provided.
The scope of training must be assessed to make sure that IS operations and support staff as well as users are trained. Also when determining the scope of the training,
consider the various groups of users. These can vary widely depending on scope and purpose of the project. Consider the following cases:
a system for a single user
a system for a single-site organization, in which different user groups perform different roles with different skills
a system for a multi-site organization, in which different sites follow different business procedures, with a division of labor appropriate to the size and staffing of the
office
a system for several organizations, each of which will contribute resources and requirements to the system development effort
a system to be used in all 57 branches of a large bank, that will only be used by bank staff
a system to be used in all 57 branches of a large bank, that will also be used by customers of the bank
a system for amazon.com that will be made available to many thousands of users world-wide over the Internet
a system used by users with disabilities
This is also the time to identify any special training or information needs during the project. For example, if there is resistance expected in certain user groups, it is
recommended to start early with informing these groups about what is going to happen so that they will feel more involved in the whole process.
Source General Education Courses
After assessing the education and training needs of the project team, there are two basic options to deliver training: develop a custom curriculum that umbrellas the broad
education courses identified or use prepared education courses from educational service providers, where possible. Although the latter appears ideal for reduced
overhead and immediate delivery, it is in the best interest of the company to tailor the standard educational courses to relate to project objectives, implementation
techniques, and other business initiatives.
Delivery of Commercial Off-the-Shelf (COTS) Software, Technology, and
Administration Training Courses
Training delivery can be as important as content.
COTS SOFTWARE PROVIDER EDUCATION SERVICES
Cost, availability of the class in the timeframe desired, and location of the centers determine the choice of on-site training versus training at a COTS software providers
education service center. Training at a COTS software providers education service center makes financial sense where the audience size is small. Often the client incurs
less expense when using such a center if the class size has fewer than eight attendees. The actual break-even point can vary by project based upon associated travel
costs. Use COTS software providers education service centers for small numbers of attendees who missed the on-site training.
Attention: COTS software providers typically offer standard product training courses and not general education courses as described above. The client should seek other
professional education services to deliver more generalized fundamentals courses, such as those offered by the American Production and Inventory Control Society
(APICS), or the American Management Association (AMA). However, in some cases, internal resources may have background experience in specific disciplines and can
create custom classes.
CONSULTING SERVICES
The client may request that the implementation consultants teach the COTS software courses to ensure that company-specifics are carried forward to the implementation
tasks. If the client chooses this option, the consulting project manager should notify the appropriate education services manager immediately. This person is usually
responsible for supplying the training materials and invoices the successfully completed classes.
CUSTOM TRAINING AND EDUCATION CLASSES
The client may also request custom courses. If the custom course requires the modification of standard COTS software training material, contact the appropriate
education services manager. Should the request require the development of new training materials, contact the appropriate consulting resource to determine scope and
cost.
CONVERSION, PERFORMANCE ASSURANCE, AND ARCHITECTURE TRAINING
You may have to hold special training sessions to communicate the detailed steps with subprojects like data conversion, performance testing, and technical architecture.
Because the subproject does not require all project team members to attend they are often informal training sessions.
Development of Custom Application Training
The custom developed application may require extensive custom training. Project scope should be reviewed to determine responsibility for development and delivery of
custom training components. When there is a request for the development of additional training materials beyond what was included in the original scope of the project,
contact the appropriate consulting resource to determine scope and cost.
In some cases, training may be done by ambassador users who have participated throughout the lifecycle of the custom development effort. In this case, the developers
role may be predominately that of a reviewer.
When the custom applications require custom developed training material, existing project artifacts should be utilized as source documents. Use cases and business
process models should be carried forward into the Documentation and Training processes and used to develop the documentation and training materials as appropriate.
Use the work product for this task to catalog the list of courses that are planned for development, and their primary audience. When doing this, you should consider the
key stakeholder groups, and the list of actors. Training of the custom developed components is very important to the long term success of the system in meeting the
needs of the business.
Iterative and Incremental Approach Considerations
Often times, to minimize project risk, new systems are deployed using an iterative and incremental approach. This means you must train subsets of users at various
locations and at different points in time. Such an approach complicates Training planning and execution. It also provides the opportunity to optimize classes based on
early delivery experience. The Education and Training Strategy needs to reflect the iterations planned for the project and may need to be adjusted as the workplan
evolves.
Back to Top
Back to Top
Back to Top
PREREQUISITES
TR.010.1
Prerequisite Usage
Project Management Plan (PJM) The Project Management Plan defines the scope, objectives, and approach for the project and refers to the detailed standards
and procedures employed during the execution of the project. The Education and Training Strategy is strongly influenced by
the scope (organizations and users affected) and approach (level of technological change).
Structure (RD.012)
Use the Present and Future Organization Structure (RD.012) to see what current and future roles within the organization will
likely interact with the new system.
TR.010.2
Prerequisite Usage
Education and Training Strategy The initial Education and Training Strategy serves as input into this version.
(TR.010.1)
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Education and Training Strategy is used in the following ways:
to evaluate the training requirements
to plan the delivery of relevant standard and custom classes
Back to Top
QUALITY CRITERIA
Back to Top
TR.020 - PREPARE PROJECT TEAM LEARNING PLAN
In this task, you assess the learning requirements for the entire project team based on the project vision, charter, and scope in order to develop the learning paths aligned
to the project roles. This task builds on the Staff Training Plan (STM.020) developed during the PJM Start Up phase.
In a commercial off-the-shelf (COTS) application implementation, the project team may also need to be trained on the applications being installed in order to bring the
project team up to the level of application proficiency needed to fulfill their role on the project.
ACTIVITY
Back to Top
WORK PRODUCT
Project Team Learning Plan - The Project Team Learning Plan contains the schedule of learning events for all the project team members to prepare them to fulfill their
project roles. The learning focuses on technical, product, functional, project management, team management, and any other skills required of the project team members.
It should address the following:
gaps between current and required skills per role (technical, functional, project management, tools, products, people skills)
learning option selections
learning paths per role
high-performance team development module selections
measurement mechanisms
inventory of learning materials/events and need for customization
delivery of learning event logistics
confirmation of education providers (Oracle University, contract resources, organizations training group)
schedule of learning events
Back to Top
TASK STEPS
1 Review prerequisites for the impacts
associated with business processes
or organizational changes and
organize the work product.
Introduction This component gives an overview of the Project Team Learning Plan.
2 Determine the learning scope by
identifying the required skills per
role. Include technical, functional,
project management, tools, product
content as required.
Project Team
Learning Scope
This component gives an overview of the process and input required from each participant. Using the list of
all known project team members and their role on the project, compare their existing skills to the required
skills and determine the gap. Include technical skills, functional skills, project management skills, use of
tools, and team building.
Web Site: For a list and description of the latest Oracle Education offerings, such as the curriculum paths,
course details, and interactive seminars refer to Oracle Universitys web site (http://education.oracle.com/).
3 Review learning options and
determine learning paths per
individual/role.
Project Team
Learning Scope
Learning paths per individual/role include a relevant variety of learning options, such as instructor-led
onsite training learning, computer-based learning, coaching, tutorial, and video. Also include measurement
activities to determine the effectiveness of the learning.
4 Select high-performance team
development modules and add to
content lists.
Project Team
Learning Scope

5 Put in place the measurement
mechanisms to verify the
effectiveness of the learning events.
Project Team
Learning Scope

6 Create inventory of learning
materials/events and need for
customization.
Administration of
Project Team
Learning
Materials/Events
This component inventories the existing learning materials and events by content. The inventory includes
materials/events from Oracle University and other parties; for example, partners, third-parties (education
providers), and the organizations own training group. Based on this inventory, we can derive the need for
customization and development of project specific materials. This component also includes the schedule
#TOP #TOP
of learning events and administration of logistics.
7 Identify the logistics for delivery of the
learning events.
Administration of
Project Team
Learning
Materials/Events

8 Secure approval for plans and obtain
confirmation from Oracle Education
and others (contract resources,
organizations training group).
Administration of
Project Team
Learning
Materials/Events

9 Schedule learning events,
instructors and attendees.
Administration of
Project Team
Learning
Materials/Events

10 Organize data gathered. Appendix This component contains a data gathering tool for project team skill inventory.
11 Publish the learning plan to the entire
team.

12 Coordinate technical site visit by
technical operations.

Back to Top
APPROACH
During this task, the project team identifies the learning requirements of the team members and puts in place learning paths by project team role. They determine who
needs what learning, when, in what form, what sequence, and deployed in what ways.
The focus of the learning plan is multifold and can apply to only a subset of roles, or to all roles. The learning plan focuses on product and tool knowledge as applicable;
on technical, functional, and project management skills; and on the people skills required by the project team to function smoothly as a cohesive work group, throughout
the phases of the project.
The audience for the learning plan includes all members currently identified, as well as all members who may join the team in the future (might not be identified yet by
name but are identified by planned role).
Project Team Learning Scope
Based on the skills required from the project team, the attendees determine the skills requirements by comparing required and existing skills for all project team members,
by role. They then develop learning paths per individual or role, taking into consideration all learning options, and the need to develop or customize learning materials.
Finally, they identify the requirements to administer the learning events for all team members.
Web Site: For a list and description of the latest Oracle Education offerings, such as the curriculum paths, course details (Reusable Content Object Matrix), and interactive
seminars refer to Oracle Universitys web site (http://education.oracle.com/).
Attention: Each team member is responsible for reading the strategy documents generated from other processes. By doing this they are ready to provide input to the
Project Team Learning Plan and make sure it is exhaustive in that it reflects all the requirements derived from the various process strategies.
Back to Top
Back to Top
Business Analyst 30
Back to Top
PREREQUISITES
Prerequisite Usage
Project Management Plan (PJM) The Project Management Plan defines the scope, objectives, and approach for the project and refers to the detailed
standards and procedures employed during the execution of the project.
Client's Organizational Change
Management Strategy (PJM.OCHM.010)
These prerequisites provide a clear idea of the scope of the implementation, and an indication of the training required
for the project team members.
Staff Training Plan (PJM.STM.020) The Staff Training Plan defines the learning requirements to deliver knowledge to the project team. The Project Team
Learning Plan builds on this plan.
Education and Training Strategy (TR.010.1) The Education and Training Strategy helps you plan the delivery of relevant standard and custom classes.
Back to Top
TEMPLATES AND TOOLS
TR-020_PROJECT_TEAM_LEARNING_PLAN.DOC MS WORD
Tool Comments
processes.
Back to Top
The Project Team Learning Plan is used in the following ways:
to guide the project team members on the development of the learning plan that allows all members of the team to acquire the skills and knowledge (for example,
applications, tools, and project management) they require to fulfill their respective roles on the project and to work efficiently and perform as a team
to help the project team set up the best administrative infrastructure for the learning; for example, preparing participation in onsite and outside learning events.
Back to Top
QUALITY CRITERIA
Back to Top
TR.030 - PREPARE PROJECT TEAM LEARNING ENVIRONMENT
In this task, you establish the technical and physical infrastructure required for the actual project team learning, including either installing a new application environment or
preparing an existing application environment. Upon completion of this task, this environment is ready for the project team to use.
ACTIVITY
Back to Top
WORK PRODUCT
Project Team Learning Environment - The Project Team Learning Environment includes the setup of learning centers and production requirements for learning
materials, and specifies the application servers, configuration, and set ups containing a controlled set of data for the project teams learning events. It includes newly
installed standard components, plus all setups and data required to support project team learning events. It should address the following:
separate or existing environment selection
application setups
demonstration data
learning facilities reservation and preparation
backup and contingency plans
Back to Top
TASK STEPS
1 Review and update
checklists.
Preparation
Checklist
This component provides checklists to guide the preparation of the physical and technical learning environments, such
as setting up the desktop clients, printers, and other facilities.
2 Install Working Learning
Environment (if necessary).
Systems
Environment
This component describes the application installations, application server and database server instances needed to
support the learning environment.
3 Set up applications. This task step represents any unique configuration parameters for the Working Learning Environment (for example,
accounts payable vendor payment terms and sales order types).
4 Review baseline (current
system) user procedures.

5 Obtain actual baseline
business scenarios (if
necessary).

6 Gather necessary sample
data.
This component includes sample data from the business in order to make examples and exercises more meaningful,
such as customers, vendors, and part numbers. It focuses on relevant products, processes, and roles as much as
possible.
Back to Top
APPROACH
This task provides a system for the project team to practice what they have learned. This includes hardware, software, sample data, and documentation. This environment
is separate from the testing environments in order to preserve the integrity of learning administration, such as starting points. In addition, the learning facilities have
protection from interruptions and the distractions of ongoing business. You can install a new environment or modify the existing environment for the learning activities. It
is useful to construct learning environments that reflect some real production data and system configuration.
Preparation of Learning Environment
Project team learning is critical to the success of the project. Without proper understanding of supported application functions, business requirements may be incomplete,
resulting in reduced traceability from business solutions to requirements.
Engage key project team members who have subject matter expertise in gathering relevant information to drive the learning events; they have credibility with users who
possess such information, and by asking them, you involve them in the learning effort.
Modification of the Demonstration Environment for Learning
Use the standard applications demonstration database for learning. As part of learning preparation, gather information from analysis sessions or briefly interview key
users to collect data such as commonly used part numbers, terms and conditions, and priority codes. Use organization-specific data as examples during learning. Make
sure to adapt the discussion to the organizations particular business needs.
Attention: Examples in the demonstration database may conflict with the new data that is set up for the organization. Practice demonstrations and labs that use new data
before the learning events. Make sure that you allow some time for making modifications to the demonstration environment as required.
Back to Top
System Administrator Provide operating system and network support for setting up the training environment. 35
Database Administrator Provide database administration for setting up the training environment. 25
Business Analyst Obtain sample business cases, and load demo data. 15
Training Specialist Review sample business cases and demo data. 15
Application/Product
Specialist
User *
Back to Top
PREREQUISITES
Prerequisite Usage
Established Team Work Environment
(PJM.IFM.020)
Physical Resource Plan (PJM.IFM.030)
The Infrastructure is established in the PJM Project Start Up phase in the Infrastructure Management process. It includes
hardware systems that are the foundation for all project support environments including the learning environment.
Technical Architecture Workshop
Results (TA.010)
During the Technical Architecture Workshop, the requirements for the Working Learning Environment are defined.
Staff Training Plan (PJM.STM.020) The Staff Training Plan defines the learning requirements to deliver knowledge to the project team.
Project Team Learning Plan (TR.020) The Project Team Learning Plan defines additional learning requirements that are not found in the Staff Training Plan.
Back to Top
TEMPLATES AND TOOLS
TR-030_WORKING_LEARNING_ENVIRONMENT.DOC MS WORD
Back to Top
The Project Team Learning Environment is used in the following ways:
to support project team learning events
Back to Top
QUALITY CRITERIA
Back to Top
TR.040 - DEVELOP PROJECT TEAM LEARNINGWARE
In this task, you develop the learningware for the project team training. This includes the following:
preparing the training aids
securing a training facility
confirming attendees
assembling reference and training notes
preparing training system for demonstrating exercises
preparing class evaluation forms
ACTIVITY
Back to Top
WORK PRODUCT
Project Team Learningware - Project Team Learningware includes all the materials to be used during training of the project team and for administering learning events.
Back to Top
TASK STEPS
1 Review the Project Team Learning Plan (TR.020). None
2 Prepare for project team training. Training
Preparation
Checklist
Class Attendance
Listing
The Training Preparation Checklist helps you plan the delivery of
required standard and custom classes to the project team.
3 Coordinate and confirm resources for functional and technical training. None
4 Assemble training materials. Training Materials
5 Review Custom Training and Education Request and adapt training
sequence, depth, and special training needs as required.
None
6 Develop custom training materials (if required). Custom Training
Materials

7 Develop custom exercises and handouts (if needed). Custom Exercises
and Handouts

8 Configure training environment for custom training. Configured
Training
Environment

Back to Top
APPROACH
Project team training prepares the project team for process design and mapping activities. This training needs to be at a tactical level such that team members can
recommend solutions to business requirements based on their knowledge of the commercial off-the-shelf (COTS) software products being implemented.
You need the following information to complete this task:
list of training classes
training agenda
list of resources providing training
class attendance list
demonstration data to use during training
class handouts
list of decisions made during classes
list of unresolved issues
class evaluation form
If you are planning custom training, you need standard COTS software product expertise. Consider the following elements when you prepare custom training:
class handouts
lab exercises
self-help tools
partially implemented solutions (if applicable)
guidelines
workshops
company-specific data
Suggestion: Contact your local COTS software provider representative for more information on how their education services group can help you with your project team
training.
Attention: Too often training development in not allowed appropriate time. The industry standard is 20 to 30 days of development time for one day of training. Also,
frequently overlooked is the need to test training labs and activities. This results in confusion on the part of the training participants. Training should have greater
emphasis because it affects the ongoing success of the implementation and the attitudes of the users.
In a COTS application implementation, the high-level applications overview class helps generate critical early support from key project team members and management,
Adapt Standard Training Courses
Before training begins, review the training material agenda with the project manager or team leaders. Eliminate or add to the materials as required for the audience.
Begin with Navigation Classes
Begin each series of COTS software training with a navigation class and allow time for the users to get familiar with the commands, menu style, keyboard mapping, and
user interface. Make sure the users have sufficient preparation before going to the next level of training.
Provide Commercial Off-the-Shelf (COTS) Software Product Overviews
Commercial Off-the-Shelf software product overviews must provide an integrated perspective of all the products within the scope of the project. These overviews
introduce the family of application products and highlight how information passes from one application to another. In order to cover all products, the duration of this
overview class ranges from two to four hours.
Assemble materials using process diagrams from standard presentation materials. In some cases, the overview covers fundamental business functions rather than how
standard software products support these functions. The objective is to provide a broad view of inputs and outputs to the products. This technique increases team
awareness of how information is used before and after specific processes.
Configure a Custom Training Environment
Release-specific demonstration databases are the basis for the standard training courses. The standard training materials reference a business situation and system
setup in the demonstration environment; however, multiple-site and large accounts find it beneficial to create a company-specific training environment. The project team
and end-users have an easier time grasping the concepts presented in class when data, such as customers and part numbers, are familiar.
To configure a custom training environment, start with a fresh installation of the standard COTS software and configure the environment according to information you
gathered about the companys business during analysis sessions. Allow ample time to collect company-specific data. Developing a custom class always takes longer, but
usually pays off.
Suggestion: As a rule of thumb, allow at least one day set up for each COTS software product. You should also set up preconfigured examples to illustrate the
transaction process.
Warning: Ensure that data can pass through application interfaces by running a series of integration tests. These are usually the most difficult areas to teach, so do not
leave this area to chance.
Attention: Carefully consider the impact of an iterative and incremental approach where you may have to repeat some classes periodically at various sites to subsets of
users over a six to twelve month period.
Back to Top
Business Analyst 45
Technical Writer 25
IS Support Staff *
User *
Back to Top
PREREQUISITES
Prerequisite Usage
(TR.020)
The Project Team Learning Plan defines the learning requirements.
Working Learning
Environment (TR.030)
The Working Learning Environment includes the setup of learning centers and production requirements for learning materials, and
specifies the application servers, configuration, and set ups containing a controlled set of data for the project teams learning events.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Project Team Learningware is used in the following ways:
to accomplish the planned project team learning events
The Project Team Learningware should address the following:
user-friendly, attractive, interactive documents for learning as per the planned path, by role
custom developed software and custom extensions to the applications
materials to reinforce learning, measuring the success of the learning, administering the learning events, and preparing the learning agents
Back to Top
QUALITY CRITERIA
Back to Top
TR.050 - CONDUCT PROJECT TEAM LEARNING EVENTS
In this task, you facilitate the learning events for the project team. These learning events cover tools, applications, and all knowledge and skills areas deemed necessary
for the effective functioning of the team as described in the Project Team Learning Plan (TR.020).
ACTIVITY
Back to Top
WORK PRODUCT
Skilled Project Team - This team represents all members of the team who have participated in the learning events intended to give them the knowledge and skills they
need to perform their roles on the team. These learning events address functional, technical, general, and high-performance learning requirements.
Back to Top
TASK STEPS
1 Create a document to support the
project team learning events. Prepare
for on-site learning.
Introduction This component provides an overview of the project team learning events administration.
2 Provide functional and/or technical
learning to current project members.
Administration
of Learning
Events for
Project Team
This component is used to prepare for and carry out the learning events planned for the project team. It
helps to track, reinforce, and measure the effectiveness of the learning.
3 Facilitate high-performance team
development sessions.
Appendices This component includes appendices A, B, and C to support the teams ability to cohesively work together.
Appendix A, Ice Breakers, suggests icebreakers. Appendix B, Team Building Interludes, describes team
building interludes. Appendix C, High Performance Team Development Modules, lists facilitation guidelines
for high-performance team development modules.
4 Conduct orientation sessions using
the Project Orientation Guide
(PJM.STM.040) for new project team
members as they join.

5 Guide new team members through
their learning path per role as
described in the Project Team
Learning Plan (TR.020).

Back to Top
APPROACH
Functional, Technical, and General Learning
Align the project teams functional, technical, and general learning content with the project objectives. In addition, include content to help the project team members to
complete the required tasks, such as process mapping and modeling. If you are using business process models, include them in the learning content. If you are using a
procedural documentation software tool, such as Oracle Tutor, include the software workshops for the process owners to learn the tools. These skills are leveraged
during the Develop Future Process Model tasks (RD.011.1 and RD.011.2). Throughout the life of the project, you may also need to consider providing addition learning,
as applicable.
High-Performance Team Learning
Each project team has its own collective personality, its own areas of strength, and its own areas needing improvement. As the need arises, select the team development
activity best suited to help the team accelerate its growth toward becoming a high-performing team. These modules are facilitated as work sessions, for example, using
actual issues experienced in the project team. Some of the topics covered in the modules include: communication, meeting management, leadership, supportive team
climates, goal alignment, and managing conflict. (Reference: Scholtes, Joiner and Streibel, The Team Handbook, Second Edition, Oriel. ISBN: 1-884-73111-2.)
New Team Members
As new members are added to the project team, it is important to orient them to the project. The project manager or project lead (if applicable) should personally invite
each new member to join with a one-on-one interview. If the new team members are added one at a time, the orientation can simply be an extension of the one-on-one
interview that covers an induction checklist. If several members join at once, you might consider conducting the process in a group setting. Whether individually or in a
group setting, facilitate the process in an interactive way. You might consider assigning a project team member specifically to the new member (buddy) to help the new
member quickly become productive on the project.
Following the induction, the new member should then acquire the required skills identified in the Project Team Learning Plan (TR.020) by following the learning path
associated by roles.
Back to Top
User *
Back to Top
PREREQUISITES
Prerequisite Usage
Project Orientation Guide
(PJM.STM.040)
The Project Orientation Guide contains a collection of key project information for team members. This information includes, but is
not limited to, standards, policies, and procedures.
(TR.020)
The Project Team Learning Plan includes the plan that is executed in this task for all project team members.
(TR.030)
The Training Preparation Checklist helps you plan the delivery of required standard and custom classes to the project team.
Project Team Learning
Environment (TR.040)
The Project Team Learning Environment provides a system on which the project team can learn and practice. This includes
hardware, software, sample data, and documentation.
Back to Top
TECHNIQUES
Technique Comments
projects.
projects.
Back to Top
TEMPLATES AND TOOLS
TR-050_PROJECT_TEAM_LRNG_EVENTS_ADMIN.DOC MS WORD
TR_TRAINING_PREPARATION_CHECKLIST.DOC MS WORD - Use this template to prepare for the training sessions.
Tool Comments
This task has supplemental guidance for Oracle User Productivity Kit Professional (UPK Pro) and Oracle Tutor are complementary Oracle tools that are used
processes.
Back to Top
The Skilled Project Team should be able to perform in the following areas:
as a cross-functional project team
as contributors to the team per their roles
Back to Top
QUALITY CRITERIA
Back to Top
TR.060 - CONDUCT USER LEARNING NEEDS ANALYSIS
In this task, you gather insights on the learning needs of all audiences of users.
ACTIVITY
Back to Top
WORK PRODUCT
User Learning Needs Analysis - The User Learning Needs Analysis builds on the Job Impact Diagnosis (OCM.180) and describes the gaps in knowledge, skills, and
aptitudes between the current and future states for all audiences of users.
Back to Top
TASK STEPS
1 Organize the work product. Introduction Provide the overview of the work product.
2 Identify respondent groups and
conduct learning needs analysis
interviews.
Scope and
Objectives
Describes the steps and people involved in the conduct of the learning needs analysis, for example, list
of respondents and interviewers, sampling techniques, interview guides, and so on.
3 Consolidate interview data. Consolidated
Findings
Capture the high-impact findings on the Skills, Knowledge and Aptitudes (SKA) gaps and readiness for
the project. Highlight the gaps between existing and required SKAs, as per the findings derived from
the input collected from the respondent groups. Organize the findings per groups of performers/roles
and highlights common learning needs.
4 Map findings to competencies for each
role found in the Human Performance
Support Systems. Determine gaps
between current and desired skills.
User Profiles by
Role
List the current system literacy, procedural and business SKAs compared to the required SKAs per
group of performers/roles, as defined in the User Guide (DO.070) and HR Transition Plan (OCM.190)
work products. Include key findings and recommendations related to the target groups receptivity and
readiness for the project. Position the findings around the eight guiding principles for effective change
leadership.
5 Derive user learning
recommendations.
User Learning
Recommendations
Capture the recommendations derived from the findings and the skills gap analysis. Include
recommendations for target groups of learners, timing, learning approach, and so on.
6 Tailor interview guide for the learning
needs analysis.
Appendix A -
Interview
Guide
The Interview Guide contains the interview guide for the User Learning Needs Analysis data gathering.
7 Provide list of respondents. Appendix B - List
of Respondents
by Group
List respondents by group.
Back to Top
APPROACH
During this task, gather information about the knowledge, skills, and aptitudes of all categories of users. You record current knowledge, skills, and aptitudes, compare
them to the new competencies and identify the gaps between the present and the ideal. Those gaps mark the parameters of the needed learning. The profile is a
snapshot in time, which serves not only as a guide for creating learning paths, but also as a baseline against which gains can be measured. In addition, the User
Learning Needs Analysis provides insights in these audiences readiness for the project.
For representation, you interview a cross-section of users who are selected based on their ability to impact the business results anticipated as a result of the
implementation. Choose people who represent a large number of stakeholders, such as super-users.
Back to Top
#TOP #TOP
Change Management
Specialist
30
User *
Back to Top
PREREQUISITES
Prerequisite Usage
Business Procedure
Documentation (RA.055)

User Guide (DO.070) The User Guide describes the new procedures users will be following in their new roles.
Job Impact Diagnosis
(OCM.180)
The Job Impact Diagnosis provides recommendations to prepare end users for the day-to-day work using the new processes. It identifies
who will be impacted, how they will be impacted and at what level they are impacted.
HR Transition Plan
(OCM.190)
The HR Transition Plan defines the actions and processes needed to transition people and teams regarding new job responsibilities.
Back to Top
TEMPLATES AND TOOLS
TR-060_USER_LEARNING_NEEDS_ANALYSIS.DOC MS WORD
Back to Top
The User Learning Needs Analysis is used in the following ways:
to assess the gaps in knowledge, skills, and aptitudes between the current and future competencies for all audiences
The User Learning Needs Analysis should understand the following:
cross-section sampling of stakeholders among users
profiles of users knowledge, skills, and aptitudes
gap assessment between required and existing skills (system literacy, procedural, and business skills)
project acceptance assessment
Back to Top
QUALITY CRITERIA
Back to Top
TR.070 - DEVELOP USER LEARNING PLAN
In this task, you create learning path approaches that allow users to become skilled in the new technologies, apply new/updated procedures, and fulfill their new roles.
ACTIVITY
Back to Top
WORK PRODUCT
User Learning Plan - The User Learning Plan describes a customized approach for reskilling those employees whose knowledge, skills, and aptitudes need to change to
embrace the full benefit of the new technologies being implemented.
Back to Top
TASK STEPS
1 Review and select approved
recommendations from the User
Learning Needs Analysis (TR.060),
if available.

2 For each targeted role, select the
role-based procedure knowledge
from the Present and Future
Organization Structures (RD.012)
and the Business Use Case Model
(RA.015), or Oracle Tutor, if
applicable.

3 For each targeted role, select the
role-based content related to
product skills from the standard
applications courseware (or Oracle
Tutor, if applicable).
Introduction Provide an overview for the work product.
4 Organize the work product.
Opt
5
For each group of learners, create
learning objectives by role.
Learning Objectives by Role Document the learning objectives by role, such as
enabling and learning objectives in each of the Skills, Knowledge, and Aptitudes (SKA)
categories. It ties to the materials around learner verification.
Opt
6
Tailor learning content for each role. Learner Profiles Describe the logical flow of the content to be learned by groups of performers. The content to
be learned is outlined in a modular format or reusable content objects, for optimal leveraging
of content across groups of learners. This content is articulated in a learning flow in the next
component.
Opt
7
Select the learning approach and the
delivery method for each group of
learners.
Learning Paths by Role Convert the logical flow of the content to be learned into a learning flow, describing how a
learner is first be exposed to the content, understand it, observe it, practice it, and so on. It
builds the flow from more simple to more complex and includes interactive learning and
reinforcement activities in the flow.
Opt
8
Finalize the measurement methods. Learning Measurement
Methods
Describe the methods to measure the effectiveness of the learning, as defined in the user
learning strategy. The Learning Measurement Methods component provides the following
benefits:
It helps to select methods that are compatible to the culture of the organization and the
selection of learning paths, from self-administered measurement, for example, self-
assessment, learner verification, to more formal methods such as, use of a control
group.
It assists in looking for leveraging opportunities.
It links the administration of measurement methods to the update of the learningware
and the final evaluation of its effectiveness.
It specifies who will administer the measurement methods and what preparation they
will need. The general goal of describing measurement methods is to specify how the
success of the learning will be measured against the desired outcome, and compared
to data collected during the User Learning Needs Analysis (TR.060).
Opt
9
Describe the learning reinforcement
methods and rewards and
recognition process.
Learning Reinforcement,
Rewards and Recognition
Methods
Describe the methods to reinforce the performers learning of the new content, how they
complement one another, who administers them, for example, self-administered, included in
the learning paths (for example, learner verification), administered by the performers learning
agent, manager. It reflects the reinforcement activities in the learning paths per role. The
reinforcement methods encourage users to transfer the skills acquired in the work place. The
learning reinforcement, rewards and recognition methods component provides the following
benefits:
It describes the methods to encourage, reward and recognize the performers
participation and involvement in the learning events.
It specifies how they complement each other, who administers them, and how to
prepare those administrators.
It suggests guidelines for recognition for each target group of learners and the time
frames in which they should be given.
It integrates with the Human Performance Support Systems for the impacted roles.
Opt
10
Describe the approach for creating
needed learning materials.
Material Development
RecommendationsResource
Requirements
Provide recommendations required to support the learning flows by role. Include material for all
parties involved in the learning process, for example, the learner, the learning agent (for
example, coach, instructor, and manager), and the administrator. Consider developing
learningware on the model of reusable content object for leveraging material development
across groups of learners. Wherever possible, available courseware should be used in order
to minimize the effort required; the focus is on modifying existing courseware and on
producing those materials needed to support self-guided learning.
11 Determine resource requirements
such as facilities, equipment,
materials, and supplies, including
learning environment.
Details the requirements in terms of people, money, equipment, facilities, and so on, for the
development and the delivery of the learningware. When appropriate, specify the skills
required from the people, for example, instructional design, knowledge of authoring software,
and so on. Provide provisions for learningware in multiple languages if appropriate.
12 Describe the plan for learning
logistics and administration.
Learning Administration
Process
Describe the processes to schedule learning, distribute materials, and communicate with
learners. Specify the tools required, the procedures, and people involved in the administration
of the learning, for example, logging learning events, tracking participation in learning events,
consolidating measurement data, offering catch-up learning to those who missed an offering
of a learning event, and so on.
13 Organize material. Appendix A - Medial
Selection Flowchart
Appendix B - Electronic
Performance Support
Systems (EPSS)
Appendix C - Legal
Implications for Learner
Verification
Appendix A - Medial Selection Flowchart contains a decision flowchart to select learning
media.
Appendix B - Electronic Performance Support Systems (EPSS) describes electronic
performance support systems (EPSS).
Appendix C - Legal Implications for Learner Verification describes legal implications for learner
verification.
Back to Top
APPROACH
The general goal of the User Learning Plan is to provide guidelines for the development of the curriculum and to create criteria for measuring the effectiveness of the
learning approach. The starting point for creating a learning approach was the identification of target groups of learners and the gaps in their knowledge, skills, and
aptitudes. The learning objectives define the ending point for example, where we want to be when the learning is complete. The Learner Profiles component forms the
bridge between the two, by defining what it is that people need to know, or learn, or do in order to reach those objectives. Each Learner Profile covers the three areas of
learning: system literacy (which includes computer skills), procedural skills, and business skills.
The learning path combines the content, the media, and the sequence to create a flow of learning events for each targeted learning group. In creating the learning path,
you consider the optimal methods for transferring the needed skills to each group of learners, given their unique needs and the constraints or the opportunities provided
by the organization environment. The goal is to focus on the full range of the learning experience for example, the preparation, the support offered during learning, and
the follow up when the learners return to the job.
Back to Top
Back to Top
User *
Back to Top
PREREQUISITES
Prerequisite Usage
User Reference Manual
(DO.060)
The User Reference Manual contains the final description of the detailed functionality of each custom module and extension, to be used
by users. If the final version of the User Reference Manual is not available, a draft of this document is acceptable to use as input.
User Guide (DO.070) The User Guide describes the final set of procedures for using the application system in response to business events and is a guide for
new users.
(OCM.180)
HR Transition Plan
(OCM.190)
The HR Transition Plan defines the actions and processes needed to transition people and teams regarding new job assignments and is
the plan on which the User Learning Plan is built.
Enabled Managers
(OCM.210)
Enabled Managers are prepared to transition their people to the new processes, tasks and procedures.
User Learning Needs
Analysis (TR.060)
The User Learning Needs Analysis details the skills gaps for the various groups of users.
Back to Top
TEMPLATES AND TOOLS
TR-070_USER_LEARNING_PLAN.DOC MS WORD
Back to Top
The User Learning Plan is used in the following ways:
as the blueprint of learning events covering what users need to know to fulfill their new roles and achieve their new performance expectations
The user groups represent all stakeholders who need to use the new technology, from executives who will read reports to the clerks who will enter data. This plan is
based on the Job Impact Diagnosis (OCM.180) and reflects any new findings, issues, and requirements that were added or occurred since the roadmap was initially
developed.
The User Learning Plan should address the following:
learning objectives per role
learning content per role
reinforcement and learning paths per role that provide variety and foster effective performance
required learningware materials development plan
resource requirements, including staff, space, equipment, materials, and supplies
learning effectiveness measurement plan
Back to Top
QUALITY CRITERIA
Back to Top
TR.080 - DEVELOP USER LEARNINGWARE
In this task, you develop the learningware defined in the User Learning Plan (TR.070) to support the reskilling of employees.
ACTIVITY
Back to Top
WORK PRODUCT
User Learningware - User Learningware includes materials for preparing learning agents; for assisting user learning, reinforcement, and measurement; and for
administering learning events.
Back to Top
TASK STEPS
1 Organize the work product. Introduction Document an overview of the User Learningware.
2 Develop the Learning Materials per
learning path by role.
Learning Materials Develop the learning materials specified in the User Learning Plan (TR.070), as per the learning paths
by role. This helps guide piloting materials before full deployment.
3 Develop the Learning
Reinforcement, Rewards and
Recognition Materials.
Learning
Reinforcement,
Rewards and
Recognition
Materials
Develop materials to reinforce, reward, and recognize learning as specified in the User Learning Plan
(TR.070).
4 Develop the Measurement
Materials.
Measurement
Materials
Develop the measurement tools as specified in the User Learning Plan (TR.070).
5 Develop the Learning
Administration Materials.
Learning
Administration
Materials
Develop the tools to help the administration of learning events, as specified in the User Learning Plan
(TR.070). It includes materials for announcing and logging learning events, tracking participation, and
so on.
6 Develop the Learning Agents
Materials.
Learning Agents
Materials
Develop the materials to skill the learning agents in their role related to the success of the learning
events, for example, coaching skills/plans for super-users, and so on.
7 Organize extraneous material. Appendix A -
Development
Checklist
Appendix B -
Communications
Template
Appendix C - Learning
Event Participation
Event
Appendix A - Development Checklist is a checklist to develop user learning materials.
Appendix B - Communications Template is a template to communicate about the learning events.
Appendix C - Learning Event Participation Event lists participants who partake in the learning events.
Back to Top
APPROACH
In this task, you tailor learningware and other skills-change materials to meet the learning objectives developed in the User Learning Plan (TR.070). Tailor the existing
learningware to reflect the new procedures derived from the business process changes and the custom extensions if appropriate. Organize the content around the new
roles if the role-based approach is selected in the User Learning Plan. The general goal of this task is to support the reskilling of those employees whose knowledge,
skills and aptitudes need to change, to achieve optimal benefit from the new technology.
Use templates (as provided by Oracle Tutor or other authoring software) for ease of development and consistency across work products. Focus on developing materials
that are user-friendly, attractive, and meet good communication standards.
Back to Top
Back to Top
Business Analyst 10
User *
Back to Top
PREREQUISITES
Prerequisite Usage
User Reference Manual (DO.060) The User Reference Manual defines the functionality and use of applications extensions. If the final version of the User
Reference Guide is not available, a draft of this document is acceptable to use as input.
User Guide (DO.070) The User Guide represents the final user documentation that the users need when working with the system. If the final
version of the User Guide is not available, a draft of this document is acceptable to use as input.
System Management Guide (TA.100) The System Management Guide represents the final system management documentation that the information technology
resources need when working with the system. If the final version of the System Management Guide is not available, a draft
of this document is acceptable to use as input.
Job Impact Diagnosis (OCM.180) The Job Impact Diagnosis provides recommendations to prepare end users for the day-to-day work using the new processes.
It identifies who will be impacted, how they will be impacted and at what level they are impacted.
HR Transition Plan (OCM.190) The HR Transition Plan defines the actions and processes needed to transition people and teams regarding new job
assignments and is the plan on which the User Learning Plan is built.
User Learning Plan (TR.070) The User Learning Plan details the materials required to support the learning project.
System Operations and Management
Strategy (TA.060)
The System Operations and Management Strategy defines the operations and management approach for the new system.
Back to Top
TEMPLATES AND TOOLS
TR-080_USER_LEARNINGWARE.DOC MS WORD
Tool Comments
processes.
Back to Top
The User Learningware is used in the following ways:
to accomplish the planned learning events, as defined in the User Learning Plan (TR.070)
The User Learningware should address the following:
user-friendly, attractive, interactive documents for learning as per the planned path, by role
custom developed software and custom extensions to the applications
updated roles and procedures
system literacy and business skills
materials to reinforce learning, measuring the success of the learning, administering the learning events, and preparing the learning agents
Back to Top
QUALITY CRITERIA
Back to Top
TR.090 - PREPARE USER LEARNING ENVIRONMENT
In this task, you create the technical and physical infrastructure required for the actual user learning, including preparing an environment that reflects the production
business flow environment.
ACTIVITY
Back to Top
WORK PRODUCT
Configured User Learning Environment - It includes the computer systems and networks for web-based learning, production of paper-based support materials, and
setup of learning facilities. In addition, it covers the application servers, configuration, and setups containing a controlled set of data that is synchronized with the
learningware.
Back to Top
TASK STEPS
1 Review the Infrastructure Management Plan (PJM.IFM.010), Application
Setup Documents (MC.050), if applicable, Installation Plan (TS.030), and
User Learning Plan (TR.070).

2 Review and update checklists. Preparation
Checklists
Develop checklists to help guide the preparation of the physical
and technical learning environment.
3 Install User Learning Environment Systems
Environment
Describe the application installations, application server and
database server instances needed to support the learning
environment.
4 Set up applications.
5 Set up support infrastructure
6 Convert or add necessary sample data.
Back to Top
APPROACH
The environment needs to be configured so it fully supports the user learningware and learning plan. Use the checklists provided to set up the technical and physical
infrastructure, such as learning centers and web-based learning.
Preparation of Technical Environment
As part of preparing the user technical learning environment, make sure you test the client desktop devices and other hardware, such as printers.
User Learning Environment
Existing environments may be appropriate for user learning. Use the Infrastructure Management Plan (PJM.IFM.010) to guide you in the creation of learning
environments.
In a Business Flow-based approach, end users usually become involved in Conference Room Pilot evolutions during the project. In those cases, end user training may be
performed in a Conference Room Pilot environment.
Separate Learning Environments
A separate environment is the preferred choice for learning because it can contain clean setups and actual data and remain unaffected by concurrent testing and mapping
#TOP #TOP
activities. Create an export of the target live environment with additional data entered manually or converted from the legacy system. This scenario assumes that
conversion programs are complete and tested at this point.
A refreshed separate environment is important if many groups learn on the same modules and the learning database includes required examples or exercises for specific
setups.
If you cannot create a separate user learning environment, the best choice is one that closely resembles production and offers the most stability. The alternatives include
the following:
Demonstration Database
Requirements Mapping Environment
System Test Environment
Demonstration Database
Project team learning often uses the demonstration database shipped with the standard applications. This environment is most appropriate if you plan to use the standard
learning materials for user learning, because all examples in the standard notes reference this database. However, it is not ideal because the data and scenarios will not
be familiar to users.
Requirements Mapping Environment
The environment that the project team used for mapping business requirements should contain the appropriate setups and adequate sample data, but it also includes
many invalid setup codes and data. Install customizations in this environment. If you do not have enough room for a separate environment, this requirements mapping
environment
might be your best choice.
System Test Environment
The system test environment should contain sample production data and include all custom modules and extensions. By using this environment, you are more likely to
include all current modules in the learning.
Back to Top
Database Administrator 25
Business Analyst 20
User *
Back to Top
PREREQUISITES
Prerequisite Usage
Infrastructure Management Plan
(PJM.IFM.010)
The Infrastructure Management Plan details the approach to the learning environments early in the project. Follow this plan to
maintain consistency with expected resource allocations and schedules.
(MC.050.2)
The Application Setup Documents include description of setups captured during mapping activities that can be used in learning.
Installation Plan (TS.030) The Installation Plan lists the requirements for installation.
Strategy (TA.020)
The Architecture Requirements and Strategy helps define the requirements for Project Team Learning Environment.
Systems Integration Test
Results (TE.100)
The Integration-Tested System contains an environment that has had the new applications, custom extensions, and interfaces to
remaining legacy applications tested in its entirety.
User Learning Plan (TR.070) The User Learning Plan lists the requirements for user learning.
User Learningware (TR.080) The User Learningware dictates the amount and type of data that must be available for learning.
Back to Top
TEMPLATES AND TOOLS
TR-090_CONFIGURED_USER_LEARNING_ENVIRONMENT.DOC MS WORD
Tool Comments
processes.
Back to Top
The User Learning Environment includes existing or newly installed standard applications, physical and technical setups, and data required to support user learning.
The User Learning Environment should address the following:
application setups
demonstration data
learning facilities reservation and preparation
desktop client for testing and other hardware such as printers
usage plan for shared concurrent learners environment
Back to Top
QUALITY CRITERIA
Back to Top
TR.100 - CONDUCT USER LEARNING EVENTS
In this task, you conduct the training developed in the User Learning Plan (TR.070), as well as track and document the progress.
ACTIVITY
TR.100.1
C.ACT.TEUC Train End Users-Construction
TR.100.2
D.ACT.TEUT Train End Users-Transition
Back to Top
WORK PRODUCT
Skilled Users - Skilled Users have learned what they need to succeed in their new roles. This knowledge covers system literacy, procedural, and business skills.
Back to Top
TASK STEPS
1 Organize the work product. Introduction Document an overview of the user learning events administration.
Opt
2
Create human performance support
communications.

3 Create user learning
communications.

Opt
4
Conduct human performance support
orientation and learning events.
Human
Performance
Support
Orientation
and Learning
Administration
Materials
Create and document materials to manage the orientation and learning events dedicated to the human
performance support systems tools.
5 Hold user learning events. User Learning
Event Log
Create a log to track the learning events, as per the administration procedures specified in the User
Learning Plan (TR.070).
Opt
6
Monitor human performance support
deployment progress.
Human
Performance
Support
Orientation
and Learning
Administration
Materials

Opt
7
Monitor skills-change progress. Skills-Change
Measurements
Consolidate the data from the measurement deliverables to determine whether corrective action is required,
for example, adjusting the User Learning Plan (TR.070) and User Learningware (TR.080).
Back to Top
APPROACH
The general goal of the user learning events is to conduct and track the skills-change events designed to provide the groups of learners with the skills they need to meet
the performance objectives of their new roles. You monitor the pulse and progress of the user learning events as they unfold, to make sure that the momentum and
quality are maintained.
New/Updated Human Performance Support Systems Learning Events (Optional)
For learning events around the new/updated human performance support systems, you provide communication, orientation, and learning to help the managers learn how
to use the new tools to manage the performance of the new roles reporting to them. Target any individual who will be using the human performance support materials.
First-line managers in turn will orient target job group incumbents to the new performance expectations. Human Resource personnel may also be included in the learning
target groups.
Learning Events Communication
As a success factor for the learning events, you develop communications on the purpose, value, context, and overall logistics for the learning events. Tailor the messages
to the various groups of learners. The communications set the proper tone for the learning, for example, important effort, tailored to the learning styles, providing variety,
reinforcement, and so on. Position the learning events in the context of the whole project and the expected business benefits. Ideally, develop a highly interactive
campaign to address the changes in roles and performance expectations in a positive and motivational manner. Link to ongoing communications dedicated to the project.
Back to Top
User *
Back to Top
PREREQUISITES
Prerequisite Usage
User Reference Manual
(DO.060)
The User Reference Manual should be used as a complement to the learningware during the learning events.
User Guide (DO.070) The User Guide should be used as a complement to the learningware during the learning events.
System Management Guide
(TA.100)
The System Management Guide should be used as a complement to the learningware during the learning events.
(OCM.180)
HR Transition Plan
(OCM.190)
The HR Transition Plan defines the actions and processes needed to transition people and teams regarding new job assignments and is
the plan on which the User Learning Plan is built.
User Learning Plan
(TR.070)
The User Learning Plan details the events planned to support the learning project.
User Learningware
(TR.080)
The User Learningware includes the materials for the learning project.
User Learning Environment
(TR.090)
The User Learning Environment provides the physical and technical infrastructure required to support the learning events.
Return On Investment
(ROI) Analysis
A Return On Investment (ROI) analysis, such as Oracle Benefits Assessment, can document the business case and the return that the
executive management team can realistically expect from its investment in technology. If an ROI, such as Oracle Benefits Assessment
has been performed, you will need it as an input.
Back to Top
TEMPLATES AND TOOLS
TR-100_USER_LEARNING_EVENTS_ADMINISTRATION.DOC MS WORD
TR_TRAINING_PREPARATION_CHECKLIST.DOC MS WORD - Use this template to prepare for the training sessions.
Tool Comments
processes.
Back to Top
Skilled Users represent users from across the organization who, by going through the learning paths associated to their roles, are able to take advantage of the new
technology and to use the system, and meet their new performance expectations.
Skilled Users should understand the following:
learning paths organization for users and managers
learning content (systems literacy, procedure and business skills) as associated to their new role(s)
new human performance support systems and performance management tools for managers, job incumbents, and HR personnel
Back to Top
QUALITY CRITERIA
Back to Top
[TS] TRANSITION
The goal of the Transition process is to install the solution (which includes providing installation procedures) and then take it into production. It begins early in the project
by defining the specific requirements for cutover to the new application system. It then includes tasks to carry out the elements of that strategy such as developing an
Installation Plan, preparing the Production Environment, performing the cutover, and decommissioning any legacy systems. Legacy system decommissioning is
performed when a legacy system exists that is being replaced by the new solution that is now in production.
Back to Top
PROCESS FLOW
Back to Top
APPROACH
#TOP #TOP
During the Transition process, we focus on installing the solution (which includes providing installation procedures) and then going production. It begins early in the project
by defining the specific requirements for cutover (TS.020.1 and TS.020.2) to the new application system. It then includes tasks to carry out the elements of that strategy
such as developing an Installation Plan (TS.030), preparing the Production Environment (TS.050), performing the cutover (TS.060), and decommissioning any legacy
systems (TS.070).
In a project using the OUM approach, the business organization becomes familiar with, and progressively accepts, the new system as it is developed. Transfer of
knowledge about the system to the business staff is an integrated part of the development process. The Transition team should involve the same ambassador users who
have been involved from the start.
The Production/Hosting Environment (TS.050), which is designed in the Technical Architecture process, is constructed as part of the Transition process. This includes
installation and configuration of all servers, network hardware, operating systems, test and monitoring systems in time to accommodate launching of the new system on
the Internet.
Production Preparation
The Transition process has the following requirements in the period before production starts:
continued use of the problem reporting and tracking system
close monitoring and resolution of risks and issues
a common commitment to a successful production start
When an existing system is being replaced, there are three techniques for going production.
phased
parallel
replacement
In the phased technique, partitions of the new system enter production use one at a time, while the legacy system's corresponding subsystems are shutdown in the same
sequence. This allows for a gradual move to the new system causing disruption in fewer internal user groups at once. This is not common but may be appropriate for
some solutions which have clearly-defined partitions that are not interdependent. This approach can also allow newly-trained users to use their part of the system while
other users are still being trained. A downside to this technique is that you may need to develop temporary solutions to make the old and new parts work together as a
whole.
In the parallel technique for going production, the new system goes production while the old system is still running. This is not a common approach for Internet solutions
that replace another Internet solution as it would be very difficult to keep two different stores running simultaneously, particularly at the same URL. However, for other
types of replacements, this might be an option. The users use both systems at once. This can cause consistency problems if data is not consistently entered in both
systems. However, running the legacy system in a read-only mode is a common practice. This also contributes to lowering risk as there is a backup option available if
something should go wrong.
Another parallel option is to pick a single user, a group of users or a few officers to be a pilot for the new system, while other groups still use the old system. This may be a
good option when there is a large number of user groups that work as separate units. This may also be a benefit when converting data as you may not need to convert all
data immediately, only the data that is relevant for that user group. A downside of this method is that you may need to build new interfaces between the old and the new
system, similar to the phased technique.
With the replacement technique, the legacy system is shut down when the new system goes production. This saves resources since you do not need both the new and
old systems at the same time. This is riskier than the other two options because it means that you do not have access to the old system if anything should go wrong. The
Cutover Strategy could provide for a series of test launches where the new system replaces the old for short periods of time.
The type of rollout that you plan affects the design of the data conversion programs. A phased rollout requires data to be converted in steps a different problem than
converting all data at once. If the Cutover Strategy is not stable, it is better to proceed with a phased Transition approach, either by business unit or geographical location.
This approach still leaves open the possibility of a replacement rollout.
Back to Top
Elaboration Phase
Construction Phase
TS.030 Develop Installation Plan Installation Plan
TS.040 Design Production Support Infrastructure Production Support Infrastructure Design
Transition Phase
TS.050 Prepare Production Environment Production Environment
TS.052 Implement Production Support Infrastructure Production Support Infrastructure
TS.054 Perform Pre-Upgrade Steps Pre-Upgrade Checklist
TS.055 Upgrade Production Environment Upgraded Production Environment
TS.056 Perform Post-Upgrade Steps Post-Upgrade Checklist
TS.057 Revise Application Setups Configured Applications
TS.058 Verify Production Readiness Production-Ready System
TS.060 Go Production System In Production
TS.070 Shut Down Legacy System Legacy System Shut Down
Back to Top
OBJECTIVES
The objectives of the Transition process are:
Install the new system into the Production Environment system.
Set up support functions.
Take the new system smoothly into production .
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
BA Business Analyst For application implementations, you may need a business analyst to set up and configure the application software. If not doing an
application implementation, you may not need a business analyst and you can allocate this effort equally to the system administrator,
database administrator and system architect.
DBA Database
Administrator
Define installation procedures for installing the database and set up and configure the production database. Ensure that all users have
proper access to the database.
DV Developer Define installation procedures for installing the application software.
QM Quality Manager
SAD System
Administrator
Install and configure system software, tools and application code. Coordinate and manage the Go Production effort and decommission the
existing system.
SAN System Analyst Define Cutover Strategy, identify resources, and plan for cutover. Gain information from users, technical and managerial staff and prepares
the Cutover Strategy.
SA System Architect Review installation procedures and provide input. Set up and configure the production application server and ensure that all users have
proper access to the application server. Coordinate and manage any offshore Go Production effort. Decommission any offshore existing
system.
TE Tester
TRS Training Specialist
Client (User)
BLM Business Line
Manager
Provide information for the Cutover Strategy.
CPM Client Project
Manager
Provide information for the Cutover Strategy. Review possible cutover techniques and resource requirements. Ensure availability and
commitment of personnel, and the availability of hardware, software and facilities.
CSM Client Staff
Member

ISM IS Manager
OS IS Operations Staff Define installation procedures for installing hardware and system software and install and configure hardware, network, etc.
SS IS Support Staff Provide information for the Cutover Strategy. Start providing production support for the new application system.
USR User Provide information throughout the process. Use the new application system.
Back to Top
The critical success factors of this process are as follows:
Project Team Commitment to the Time and Resources Required to Produce Transition: The Transition process may be the most critical part of the whole
project, and you are dependent on the client's own resources to make it a successful Transition into Production. Ensure that the client chooses a time to go into
production where everyone required is available.
On Time and Successful Delivery and Installation of Externally Provided Components (Hardware, Software): Naturally, it is critical that both the hardware
and software that should be used in Production is available and installed on time. Ensure that the client makes preparation for any purchase/renting of the
Production Environment on time, and plan sufficient time for installing the application.
Available and Committed Support Staff Who Are Able and Willing to Implement the New Solution: When the new system goes into Production, the support
staff must be prepared for this task. Ensure that the support staff is appointed at an early stage in the project so that they get proper training before the system
goes into Production.
Committed User Involvement and Sense of Ownership: Users have been involved during the whole project and should feel an ownership of the new
application. However, there is a larger user mass out there that should use the system. The client's own users should be informed well in advance about what is
coming, why it is coming, and about decisions that have been made and why, to ensure that there are no surprises. This is definitely a challenge if a new system is
replacing an old one.
On Target Technical Architecture to Support the Expected Data Volumes and Number of Users: The chosen technical architecture must reflect the expected
data volumes and number of users. A well thought through capacity plan must reflect this. If the volumes are uncertain or are expected to grow, you should
consider building a technical architecture that is easily expanded.
Successful Testing and Validation: The system should not go into Production unless it has been properly and successfully tested. Ensure that sufficient test
cases are built and run through and that critical bugs are fixed.
Adequate Slack Time to Allow for Unexpected Situations: This is the time where "everything that can go wrong, will go wrong." The point is that there are
always unexpected fallbacks. Therefore you should have a good contingency plan.
Well-Understood Problem Tracking and Resolution System: When the system goes into Production, you should use some mechanism for the users to get
support and to report problems. This mechanism must be well understood by both the users and the support staff.
Back to Top
TS.020 - DEFINE CUTOVER STRATEGY
In this task, you state how the transition is to be made from the old system to the new system. Define your plans for taking the new system into production. This task may
need to be performed several times over the course of the project as you go from an initial Cutover Strategy to a final Cutover Strategy.
For projects that involve the upgrade of Oracle products, this task is used to define the strategy that will be used during the cutover from the existing production version to
the new software release.
For upgrade type projects this is a particularly important task because in most cases the clients Production Environment will need to be taken offline in order to complete
the upgrade process. Therefore, the timing and duration of this downtime, along with the creation of mitigation and contingency plans are critical.
ACTIVITY
TS.020.1
TS.020.2
Back to Top
WORK PRODUCT
Cutover Strategy - The Cutover Strategy documents how the new system is to be introduced. This work product is not a plan but describes the approach that is being
taken to place the new system into production. The primary issues you address in the Cutover Strategy are planning for the execution of data take-on and conversion,
and how to phase in the new system. It provides the following information:
if parallel running is to be performed
how systems being replaced are to be switched for the new system
how interfaces between the new and current systems are to be run for the first time
how the live data conversion is to be performed
how training is being performed for the changeover
Back to Top
TASK STEPS
1 Write an
Introduction
for the
Cutover
Strategy.
Introduction The Introduction defines the scope, purpose, and review requirements.
2 Determine
the
strategy.
Strategy
Overview
The Strategy Overview includes how and when data take-on and conversion will be carried out. It will also lay out a plan for phasing the
implementation of the new system. Depending on the incremental releases of the system, there may be one or more phases for
implementation. The timescales for implementation are based on the incremental components being released, and user training
requirements, so that the users have the required skills before the new system is implemented. Data Acquisition and Conversion tasks
must be completed before training starts, so that the users are able to be trained effectively.
3 Define the
tasks to be
performed
for
cutover.
Task List The Task List contains the tasks be performed as part of the cutover, as well as assigns a role and a completion date to each task.
4 Detail
tasks.
Task Details The Task Details breaks down each task into specific steps, as well as assigns a role and a completion date to each task step.
Back to Top
#TOP #TOP
APPROACH
The system analyst details how the implementation should be phased, taking into account the training needs of the users, and how data take on is to be accomplished.
Back to Top
Back to Top
System Analyst Define Cutover Strategy, identify resources, and plan for cutover. 100
Business Line Manager Provide information. *
Client Project Manager Provide information. *
IS Support Staff Provide information. *
User Provide information. *
Back to Top
PREREQUISITES
Prerequisite Usage
Requirements (CV.010)
Data Acquisition, Conversion and Data
Quality Strategy (CV.020)
These prerequisites show when the data conversion scripts are to be run live and thus the time at which the system is
available. The Data Acquisition, Conversion and Data Quality Strategy provides the approach to Data Acquisition and
Conversion and planning for data take-on and conversion.
Load) (CV.040)
The Conversion Component Designs (Initial Load) provides the detailed design for conversion tools.
HR Transition Plan (OCM.190) The HR Transition Plan provides recommended step-by-sep actions and processes needed to transition people and teams
regarding new job responsibilities as well as opportunities for pre-training recommendations and guidance for adjusting
hiring criteria.
User Learning Plan (TR.070) A significant part of the Transition process is conducting learning activities for users immediately prior to production
cutover. The number of users to be skilled, conducting learning activities for resources, and scheduling of learning events
must be taken into account when planning transition.
Back to Top
TEMPLATES AND TOOLS
TS-020_CUTOVER_STRATEGY.DOC MS WORD
Back to Top
The Cutover Strategy is used in the following ways:
to plan data conversion
to make sure that the system is in place for trained users
Distribute the Cutover Strategy as follows:
to the project team
Back to Top
QUALITY CRITERIA
Will data conversion take place before training?
Will trained users be in place before cutover?
Does the approach still fit with the business?
Are any necessary external resources aware of their requirement?
Back to Top
TS.030 - DEVELOP INSTALLATION PLAN
In this task, you develop a general installation plan, applicable for the production environment as well as any other test or maintenance environments.
In a commercial off-the-shelf (COTS) application implementation, you also develop a detailed transition plan for moving onto the production system, as well as an
implementation contingency plan.
ACTIVITY
Back to Top
WORK PRODUCT
Installation Plan - The Installation Plan describes in detail the sequence of steps to perform for any successful first-time installation of the application system. It details
what is required for a timely installation of the software, as well as what is to be installed and where. It may include the installation scripts, or these may be provided
separately.
Back to Top
TASK STEPS
1 Write Introduction for Installation Plan. Introduction The Introduction defines the scope, purpose, and review requirements.
2 Define the work products for installation. Work
Products
The Work Products contain the key tasks to be carried out during the
installation.
3 Define any assumptions. Assumptions The Assumptions lists any assumptions made for the installation.
4 Define any distributed requirements. Usage
Requirements
The Usage Requirements lists any usage requirements for the installation.
5 Define any system requirements. System
Requirements
The System Requirements lists any usage requirements for the installation.
6 Provide any software information. Software
Installation
The Software Installation component provides any pertinent information on all
software that is required for the installation.
7 Prepare the transition plan to include name and location of
modification components, database extensions, conversions
programs, and integration components.
Transition
Plan
This Transition Plan identifies all of the needs of the project and operation prior
to cutover, as well as a high-level plan containing the tasks required for
transition of the system into production.
8 Derive the resources and tools required in support of migrating
business systems, software, and hardware.
Transition
Resources
This component lists the individuals (and their role types) that are needed
during transition.
9 Anticipate implementation contingency situations by reviewing
similar implementation projects.
Cutover
Contingency
Plan
This component documents the contingency strategy, support staff procedures,
and project team functions that need to be implemented if cutover has failed or
been postponed.
10 Develop a plan to schedule operations in a manner capable of
support by the information technology and consulting
organizations.
Preparing for
Production
This component provides the organization with a plan to schedule operations in
a manner capable of support by the information technology and consulting
organizations.
11 Develop the initial schedule for production activities. Production
Schedule -
First Week
This component provides a table for the first week production schedule. If no
major problems arise, normal operational procedures can begin as early as the
second day of production.
Back to Top
APPROACH
Installation Plan
Write an Installation Plan detailing the approach to carrying out an installation of the new system. The plan includes details about the products that are to be installed and
where they are to be installed.
Distributed Options
Investigate if the database must be set-up in a distributed mode.
Back to Top
Back to Top
Database Administrator Define installation procedures for installing the database. 40
Developer Define installation procedures for installing the application software. 40
System Architect Review installation procedure and provide input. 20
IS Operations Staff Define installation procedures for installing hardware and system software. *
User Provide information. *
Back to Top
PREREQUISITES
Prerequisite Usage
Initial Architecture and Application
Mapping (TA.070)
This work product is the blueprint for for the logical and physical architecture of the new system. It identifies the specific
software, servers, server configurations, io subsystem configuration and maps the application components to the hardware
components of the architecture.
(MC.050)

Cutover Strategy (TS.020.2) This work product provides the strategy for data take-on and conversion.
Back to Top
TEMPLATES AND TOOLS
TS-030_INSTALLATION_PLAN.DOC MS WORD
Back to Top
The Installation Plan is used in the following ways:
to indicate what will be installed
to indicate the order in which files must be installed
Distribute the Installation Plan as follows:
to ambassador users
to the configuration manager
Back to Top
QUALITY CRITERIA
Are all necessary installations covered?
Are the steps easily repeatable?
Does the timetable still fit with the business?
Will the notified external resources be available when indicated in the plan?
Back to Top
TS.040 - DESIGN PRODUCTION SUPPORT INFRASTRUCTURE
In this task, you identify the operational infrastructure for managing and maintaining the application environment, servers, and network infrastructure in production.
For projects that involve the upgrade of Oracle products, this task is used to review the clients existing Production Support Infrastructure Design. The focus will be on
reviewing new features and technologies that are being introduced with the new release, and ensuring those new items will be effectively managed in the post cutover
production support infrastructure.
ACTIVITY
Back to Top
WORK PRODUCT
Production Support Infrastructure Design - The Production Support Infrastructure Design addresses the operational infrastructure for managing and maintaining the
application environment, servers, and network infrastructure. It should address the following:
communication
support lines
video capability
support platform
test environment
issue tracking system
configuration management system
Back to Top
TASK STEPS
1 Identify the support requirements for
the application, database, and
network administration.
Production
Support
Infrastructure
Plan
This component lists the production support requirements for the enterprise hardware and software, the
production support staff, and the required equipment and materials needed to build and implement the
production support infrastructure.
2 Review software and hardware
providers support programs.
External Support
Procedures
This component documents external support procedures. These procedures define the processes for
interacting with all of the vendor and provider organizations that are associated with the software, platform
hardware, network infrastructure and systems management for the new production system.
3 Review internal support procedures. Internal Support
Procedures
This component documents a step by step processes for obtaining internal support. Usually, users are
directed to initiate their support activities with an internal or internal contract support organization, prior to
escalation to external organizations and agencies.
4 Develop user support levels, with
references to manuals, system-
provided support, and online
support.
User Support
Levels
This component documents the various levels of user support that are available for the production support
infrastructure.
5 Update the Problem Report Log
(PJM.IPM.030)
Problem Report
Log
(PJM.IPM.030)
This component lists the types of problems you may encounter and categorizes them (to help support
personnel determine their root cause).
6 Identify support equipment and
materials.
Production
Support
Infrastructure
Plan
See above.
7 Identify and categorize expected
problems for internal and external
support.
Problem
Identification
Guide
This component lists the types of problems you may encounter and categorizes them (to help support
personnel determine their root cause).
8 Coordinate and plan additional
equipment and support.
Production
Cutover
This component helps to facilitate a smooth production cutover and provide advance notification of the
scheduled go-live date to Oracle Support.
Notification to
External Support
9 Plan production support learning
events.
Production
Support
Infrastructure
Plan
See above.
Back to Top
APPROACH
The Production Support Infrastructure Design includes the human resources, facilities, and system reference materials needed to answer all user requests regarding the
new system. Implement the support infrastructure in parallel with configuring the final production environment during production cutover.
Oracle Support Assessment (OSA)
The establishment of a robust and capable internal and vendor external support infrastructure is critical to the success of your project. Oracle Support provides a unique
service to assess your current support capabilities and assist with planning, updating, and aligning these capabilities to Oracle's support infrastructure.
Suggestion: Contact your local Oracle Support representative to schedule an Oracle Support Assessment (OSA).
Support Process Diagrams
A useful technique to help clarify and communicate the support processes is to create diagrammatic flows of the processes in much the same way that the business
requirements definition and mapping teams create process diagrams for the business and system processes implemented in the new system. These diagrams should
show the owner (or agent) for each step in the process and should indicate the relationship between the various support organizations or individuals that may be called
upon to help resolve an issue. The organizations may include:
help desk/support staff
client staff member
hardware/network vendor support
software vendor support
The support process diagrams need to show how issues are triaged and classified, and may have alternative resolution paths depending on severity. You also need
escalation procedures.
Supplier Support
Hardware and software suppliers often have support lines available to organizations. Identify the level of support available based on the organizations support licenses
and clearly understand the process that must be followed in order to use these services. Often support has some restrictions, such as limited calling hours or support for
specific products only.
You should augment or complement these standard services by:
extending support using independent consultants
enlisting user personnel to support users outside of the standard support hours
developing expertise within the using organization to provide more localized support
Self-Help Materials
As technology becomes increasingly deployed to the desktop, users can become more independent and take on additional responsibility for analyzing and correcting
system problems. Custom documentation, web pages, portable documents (pdf), and online help facilities allow users to investigate the nature of the problems and also
provide recommendations for problem resolution. If the standard suggestions have been followed and the problem still exists, users can turn to supplier or internal
support channels. The key in using self-help materials is to effectively train the users early and have an easily accessible reference library.
Suggestion: Self-help materials should be written in a nontechnical manner. The target audience is for the novice system user. Self-help instructions should include all
details such as keystrokes, prompts, and other navigational paths.
Self-Help Web
You may want to create a web site to house materials frequently referenced by users. Putting frequently asked questions (FAQs), email support information, problem
reporting forms, and other information useful to users on a web site ensures that those materials are readily available to all users.
Support Location and Access
Establish a central location for obtaining help. Publish when, where, and how to access support resources. The following information should be posted either in electronic
mail or in the organization communication directory:
support telephone numbers for suppliers and internal personnel
hours of operation
alternate resources
instructions for online help
information you need to provide support personnel
standard classification of problems
expected response time
Relationship to Information Systems Operations and System Management
This task is related to the tasks that describe the management of the new system by the information systems organization. The key difference is that the system
management tasks relate to the back end of support processes (how the information systems organization manages the systems and resolves issues that are routed to
them for assistance and resolution). The issues that are routed to the information systems organization should be technical in nature and may concern the real or
perceived malfunctioning of some component of the new system.
The System Management Guide (TA.100) should help the client staff to resolve the technical issues and then communicate resolution back to the support help desk for
closure. This task does not need to address the resolution of technical systems problems in detail the resolution should be covered by the System Management Guide
(TA.100). For more information, see Define System Management Procedures (TA.100).
Online Support Log
If the organization does not have an existing online support log, build or acquire one. The online support log assists in managing and tracking calls, and is especially
useful in large organizations.
Back to Top
Back to Top
System Architect 100
IS Manager *
Back to Top
PREREQUISITES
Prerequisite Usage
Strategy (TA.020)
The Architecture Requirements and Strategy addresses standards for hardware and networks, office automation, and system
management.
System Operations and Management
Strategy (TA.060)
The System Operations and Management Strategy provides the level of system availability required by the business and
defines approaches to handling system failures and scheduled downtimes. It also details the server architecture and
configuration for the database, application and desktop client tiers.
System Management Guide (TA.100) The System Management Guide provides information about the tools used to manage the new production systems.
Final Platform and Network
Architecture (TA.150)
The complexity of the platform and network architecture determines the time and resources required to set up and maintain
the production environment and must be taken into account when developing the Production Support Infrastructure Design. It
also provides information on the basic framework of the new application system and details the deployment of applications
across data centers.
IT Transition Plan (OCM.230) Review the responsibilities of the system administrator and other information systems personnel in the new system as
outlined in the Aligned Information Technology (IT) Groups.
Current Support Requirements
(internal)
Review the existing support procedures for the current systems environment.
Back to Top
TEMPLATES AND TOOLS
TS-040_PRODUCTION_SUPPORT_INFRASTRUCTURE_DESIGN.DOC MS WORD
IPM030_PROBLEM_LOG.XLS MS EXCEL
Back to Top
The Production Support Infrastructure Design is used in the following ways:
to identify the need for additional, modified, or upgraded hardware platforms
to identify the need for additional, modified, or upgraded production support software
to document a help desk environment that begins with a key policy statement that addresses types of products supported, method for acquiring support (especially
the technology that is to be employed), response time targets, user self-help routes and methods, window of support, and accessing reference materials
to Steering Committee to gain commitment of human and facilities resources to the system throughout all implementation activities and beyond. Document the
types of problems you expect, so that the proper support
structure is defined. Problems may arise in the following areas; user access, user profile definitions, application setup, system error messages, project
documentation, process flows, user transaction errors, operating system errors, and printer controls.
Back to Top
QUALITY CRITERIA
Back to Top
TS.050 - PREPARE PRODUCTION ENVIRONMENT
In this task, you set up, configure, and install the database and application software for the Production Environment.
In a commercial off-the-shelf (COTS) application implementation, this task also includes the implementation of required setups in all of the applications as part of your
configuration. It also includes the installation of any custom extensions to the COTS application system intended for production use.
ACTIVITY
Back to Top
WORK PRODUCT
Production Environment - The Production Environment consists of everything that is required for the application to be used in production except for the production data.
This includes properly installed and configured hardware, system software and application software.
Back to Top
TASK STEPS
1 Prepare production hardware. Production Environment -
Hardware
The Production Environment - Hardware includes the operating system, file structures
and networking software.
2 Prepare production database. Production Environment -
Database
The Production Environment - Database includes properly installed system software and
application software.
3 Set up the application users in the new
system.
Application User Accounts
4 Set up and compile the key Business Data
Structures.

5 Enter the application setups. Configured Applications
6 Implement the security configuration.
7 Create the custom database objects.
8 Install the custom modules.
9 Start up the database and verify its
operation.

10 Install the system management tools.
11 Install printers and other peripheral
devices.

12 Verify the production system installation.
13 Update the Installation Plan and record.
14 Back up the production system. Production System Backups
Back to Top
APPROACH
This task creates a Production Environment that is available to all potential system users, but cannot actually be used until production readiness is verified.
Production Hardware
The system administrator sets up and configures the required operating hardware. This includes setting up the operating system, file structures and networking software.
This hardware is then be made available to the DBA for preparation of the production database.
Production Database
The database administrator sets up and configures the Oracle database and any additional components (for example, Application Server), to enable the new system to
operate as required. This task does not include the upload of operating data.
In projects where there are complex hardware and software requirements, designing and implementing the architecture begins during Technical Architecture (TA). The
implementation of the Production Environment is based on the assumption that the system architecture has been created and all necessary preparation for the
installation of the applications and custom modules has been performed.
Timing Considerations in Implementing the Production Environment
Although Prepare Production Environment is part of Transition, the installation of the Production Environment may have taken place earlier in the implementation when
other working environments were installed. This is common in cases where management selected, purchased, or sized the hardware prior to or during the database and
application selection process. It is also often true for smaller organizations that can only provide a single machine to support all project environments, including
production. Assuming that the hardware configuration is adequate to support production requirements, this task then serves as a verification that the production
environment is ready for production and that any custom modules have been installed. If the adequacy of the hardware configuration is in question, performance testing
should be considered to identify performance risks and alternatives.
If performance testing has already been performed, portions of the Production Environment may have been installed and configured to support this testing. This task then
serves as an opportunity to apply any configuration changes necessary to reflect recommendations made in the Performance Test Report (PT.110).
This task represents the culmination of many tasks that contributed to the final application and technical architecture that must be implemented in the production system.
The activities that comprise this process may span a wide time frame and be performed in parallel with tasks in other processes.
Custom Modules
When implementing custom modules, you need to be meticulous about linking each of them into the production environment. The basic elements of installing custom
modules follow:
compatibility with application version
submission into source control
appropriate privileges (grants, synonyms, and so on)
placement on standard or other custom menus
registration of modules
program controls
Cutover and Countdown Steps
The term cutover refers to the final steps in transitioning from the former systems to the new system. The cutover execution steps include application setup and data
conversion. The final step in cutover is the data and system validation.
Instance Synchronization
If you have maintained a separate master environment to capture the users final, validated mapping decisions, you need to migrate the application setups from the
controlled master environment into the Production Environment. The overriding concern is that the integrity of the setup data is preserved in the migration between the
two environments. The mechanism for migrating the setup data should have been addressed when the project environment strategy was created, so at this point you
should only need to put the mechanism into operation. The mechanism used may include:
cold backup of the master setups database (the backup files are used to create the initial production database)
extract of all relevant setup data from the master database and load into the production database
use of automated test tools that trap keystrokes or graphical interface events (by replaying the scripts these tools generate, you can effectively automate the
manual reentry of data)
In this situation, the applications setup task belongs to the database administrator or information systems operations and the responsibility for review of applications setup
would fall to the analysts (depending on which role has been most involved in the definition of the applications setups throughout the life of the project). In the case where
the environment that captures the final mapping eventually becomes the production environment, you should verify that this environment is appropriately sized and free of
sample data.
Manual Application Setup
In some projects it may be feasible to manually enter the application setups into the production applications database. The Application Setup Documents (DS.014)
produced during Requirements Analysis serve as a guide for entering setup data and define the correct setups for each application. Although you already have the
application setup recorded, you should also capture the production setup after the data has been entered. This lets you compare the setup from expected to actual as a
form of quality assurance. Use screen shots or standard reports as a means to make a record of production setup.
If you discover that some data should be altered in production, then check with the key process or module owners to determine whether a slight change in setup would
impact other operations. In this situation, the applications setup task belongs to the business analysts who have been most involved in the definition of the applications
setups throughout the life of the project.
Setup and Seed Data Verification
The conversion data that follows relies heavily on the correct application setup data references in the system. Perform a thorough quality check on the application setups
and seed data.
Back to Top
Back to Top
System Administrator Install and configure system software and tools. Install and configure application code. 30
Database Administrator Set up and configure the production database. Ensure all users have proper access to the database. 20
System Architect Set up and configure the production application server. Ensure all users have proper access to the application server. 20
Business Analyst For application implementations, you may need a business analyst to set up and configure the application software. If not doing
an application implementation, you may not need a business analyst and you can allocate this effort equally to the system
administrator, database administrator and system architect.
30
Client Project Manager Ensure availability and commitment of personnel. Ensure availability of hardware, software and facilities. *
IS Operations Staff Install and configure hardware, network, etc. *
Back to Top
PREREQUISITES
Prerequisite Usage
Implemented Database (IM.040.2) The Implemented Database provides the data you need to create database objects in the Production Environment.
Integrated System (IM.080) The Integrated System provides the actual components and subsystems that should be included in the Production
Environment.
Installation Plan (TS.030) The Installation Plan specifies in detail everything that needs to be done to create any installation.
(MC.050.2)
For application implementations, the Application Setup Documents specify the configuration needed for the Production
Environment.
Back to Top
TECHNIQUES
Technique Comments
Service Packaging and
Deployment
If your project involves SOA implementation, use this technique to understand how to carry out SOA services deployment.
SOA Service Lifecycle
If your project involves SOA implementation, use this technique to understand where service deployment fits in the SOA service
lifecycle.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Production Environment is used in the following ways:
to support the new system in operation
Distribute the Production Environment as follows:
to the business
Back to Top
QUALITY CRITERIA
Is the Production Environment ready to accept data?
Back to Top
TS.052 - IMPLEMENT PRODUCTION SUPPORT
INFRASTRUCTURE
In this task, you activate the support personnel and procedures for the new business system and review requirements for support-related services from software suppliers,
contractors, help desks, and other support services.
ACTIVITY
Back to Top
WORK PRODUCT
Production Support Infrastructure - The Production Support Infrastructure involves implementing the operational infrastructure documented in the Production Support
Infrastructure Design (TS.040). It should address the following:
handling of inquiry calls
call and response tracking
system direction to all types of audiences
links to external support mechanisms or sources
understanding of performance metrics by support personnel (response, history retention, follow-up, accuracy, audit, etc.)
backup resources and tools
Back to Top
TASK STEPS
1 Set up a library. Library Index
2 Introduce the help desk to the organization. Help Desk Announcement
3 Install communication equipment.
4 Set up and distribute reference materials.
5 Implement the online help text.
6 Implement the online issue tracking system.
7 Establish a change request and bug reporting procedure. Change Request
8 Establish online support. Online Support Access
9 Review procedures for getting help.
10 Distribute all support materials throughout the organization.
Back to Top
APPROACH
Support Personnel Rehearsal
It is important to rehearse the support procedures. You can simulate various types of support calls and evaluate whether the expected response time, accuracy of the
resolutions, and the general flow of the process are adequate to support the request volume. This is also a good opportunity to test default support mechanisms, after-
business-hours support, and supplier support hotlines.
The establishment of a robust and capable internal and vendor external support infrastructure is critical to the success of your project. Oracle Support provides a unique
service to assess your current support capabilities and assist with planning, updating, and aligning these capabilities to Oracle's support infrastructure.
Suggestion: Contact your local Oracle Support representative to schedule an Oracle Support Assessment (OSA).
#TOP #TOP
Back to Top
Back to Top
IS Manager *
Back to Top
PREREQUISITES
Prerequisite Usage
Production Support Infrastructure
Design (TS.040)
The Production Support Infrastructure Design outlines the operational infrastructure for supporting the application environment,
database, and network communications in production.
Skilled Users (TR.100) Skilled Users are involved in implementing the Production Support Infrastructure.
Back to Top
TEMPLATES AND TOOLS
Back to Top
to users, either during user learning events, or in a special meeting to introduce and review the support process and infrastructure. Documented support
procedures should include the following:
support telephone numbers for suppliers and internal personnel
hours of operation
alternate resources
instructions for online help
information you need to provide support personnel
standard classification of problems
expected response time
Back to Top
QUALITY CRITERIA
Back to Top
TS.054 - PERFORM PRE-UPGRADE STEPS
In this task, you perform the pre-upgrade steps for the production migration process using the Pre-Upgrade Checklist developed during the pre-upgrade steps test
(TE.072).
ACTIVITY
Back to Top
WORK PRODUCT
Pre-Upgrade Checklist - Use the Pre-Upgrade Checklist (TE.072) to record the results of all the pre-upgrade steps as they are being performed for the production
migration.
Back to Top
TASK STEPS
1 Perform each pre-upgrade step as described in the Oracle Application-Specific
Upgrade Instructions along with the project-specific steps documented in the Pre-
Upgrade Checklist (TE.072).
Application-
Specific Upgrade
Instructions
Pre-Upgrade
Checklist
Use the Application-Specific Upgrade Instructions along with
the Pre-Upgrade Checklist (TE.072) to conduct the test.
2 Record the results for each step in the Issue Log. Issue Log The Issue Log provides a table to track issue resolution
activities associated with testing pre-upgrade steps.
3 Update the Pre-Upgrade Checklist with the actual results. Pre-Upgrade
Checklist
The Pre-Upgrade Checklist is used to record the results of all
the pre-upgrade steps as they are being performed for the
production migration.
Back to Top
APPROACH
The standard Oracle upgrade process described in product manuals specifies pre-upgrade steps for each application. Even for simple migrations, the work steps,
recording of results, and follow-up actions are complex enough to justify detailed documentation supported by the work product for this task. For some migration projects,
it may be necessary to add custom steps if the standard Oracle documentation does not cover all required activities. Oracles migration utility will not migrate certain
types of invalid data and will produce entries on an exception report. Production data cleanup should have occurred earlier in the project to enable this task to complete
successfully.
Back to Top
Back to Top
#TOP #TOP
System Architect Perform the pre-upgrade steps and record the results. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Pre-Upgrade Checklist
(TE.072)
The Pre-Upgrade Checklist is used to record the results of all the pre-upgrade steps as they are being performed for the production
migration.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The completed Pre-Upgrade Checklist is used in the following ways:
to formally capture the actual results of the pre-upgrade steps
Distribute the completed Pre-Upgrade Checklist as follows:
Back to Top
QUALITY CRITERIA
Does the Pre-Upgrade Checklist describe all of the steps involved in the pre-upgrade process?
Does the Pre-Upgrade Checklist include a complete list of expected and actual results for each iteration?
Have lessons learned from earlier iterations of the pre-upgrade testing process been included?
Back to Top
TS.055 - UPGRADE PRODUCTION ENVIRONMENT
In this task, you run the standard software upgrade process against the Production Environment as documented by Oracle upgrade instructions relevant to each
application pillar and upgrade path.
ACTIVITY
Back to Top
WORK PRODUCT
Upgraded Production Environment - The Upgraded Production Environment is upgraded to the new software and is ready to have the post-upgrade steps and the post-
upgrade application setup revisions applied.
Back to Top
TASK STEPS
1 Perform each upgrade step as described in the Oracle Application-Specific Upgrade
Instructions along with the project-specific steps documented in the Packaged
Software Upgrade Checklist (TE.073).
Application-
Specific Upgrade
Instructions
Packaged
Software
Upgrade
Checklist
Use the Application-Specific Upgrade Instructions along
with the Software Upgrade Checklist (TE.073) to conduct
the test.
2 Execute any additional steps that need to be added to the Packaged Software
Upgrade Checklist.
Packaged
Software
Upgrade
Checklist
The Packaged Software Upgrade Checklist is a list of
steps to be performed during the upgrade, along with
expected and actual results.
Back to Top
APPROACH
Execute delivered upgrade steps against the Production Environment determined by the application pillar and specific upgrade path as detailed in the related instruction
document.
Back to Top
Back to Top
#TOP #TOP
System Architect Perform the upgrade steps and record the status. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Packaged Software Upgrade
Checklist (TE.073)
The Packaged Software Upgrade Checklist is used to record the results of the steps to be performed during the upgrade.
Completed Pre-Upgrade Checklist
(TS.054)
Use the completed Pre-Upgrade Checklist to verify that all the pre-upgrade steps have been completed and to note any results
that affect the software upgrade process.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The post-upgrade steps and the post-upgrade application setup revisions are performed against the Upgraded Production Environment.
Back to Top
QUALITY CRITERIA
Back to Top
TS.056 - PERFORM POST-UPGRADE STEPS
In this task, you perform the post-upgrade steps for the production migration process using the Post-Upgrade Checklist developed during the post-upgrade steps test
(TE.074).
ACTIVITY
Back to Top
WORK PRODUCT
Post-Upgrade Checklist - Use the Post-Upgrade Checklist (TE.074) to record the results of all the post-upgrade steps as they are being performed for the production
migration.
Back to Top
TASK STEPS
1 Perform each post-upgrade step as described in the Oracle Application-Specific
Upgrade Instructions along with the project-specific steps documented in the
Post-Upgrade Checklist (TE.074).
Application-
Specific
Upgrade
Instructions
Post-Upgrade
Checklist
Use the Application-Specific Upgrade Instructions along with the
Post-Upgrade Checklist (TE.074) to conduct the test.
2 Record the results for each step in the Issue Log. Issue Log The Issue Log provides a table to track issue resolution
activities associated with testing post-upgrade steps.
3 Update the Post-Upgrade Checklist with the actual results. Post-Upgrade
Checklist
The Post-Upgrade Checklist (TE.074) is used to record the
results of all the post-upgrade steps as they are being
performed for the production migration.
Back to Top
APPROACH
The standard Oracle upgrade process described in product manuals specifies post-upgrade steps for each application. Even for simple migrations, the work steps,
recording of results, and follow-up actions are complex enough to justify detailed documentation supported by the work product for this task. For some migration projects,
it may be necessary to add custom steps if the standard Oracle documentation does not cover all required activities. Oracles migration utility will not migrate certain
types of invalid data and will produce entries on an exception report. Production data cleanup should have occurred earlier in the project to enable this task to complete
successfully.
Back to Top
Back to Top
#TOP #TOP
System Architect Perform the post-upgrade steps and record the status. 100
Back to Top
PREREQUISITES
Prerequisite Usage
Upgraded Production
Environment (TS.055)
The post-upgrade steps are performed against the Upgraded Production Environment.
Completed Pre-Upgrade
Checklist (TS.054)
Use the completed Pre-Upgrade Checklist to verify that all the pre-upgrade steps have been completed and to note any results that
affect the software upgrade process.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The completed Post-Upgrade Checklist is used in the following ways:
to to formally capture the actual results of the post-upgrade steps
Distribute the Post-Upgrade Checklist as follows:
Back to Top
QUALITY CRITERIA
Does the Post-Upgrade Checklist describe all of the steps involved in the post-upgrade process?
Does the Post-Upgrade Checklist include a complete list of expected and actual results for each iteration?
Have lessons learned from earlier iterations of the post-upgrade testing process been included?
Back to Top
TS.057 - REVISE APPLICATION SETUPS
In this task, you make revisions to current application setup data in the Upgraded Production Environment before the cutover to the migrated system. The Application
Setup Documents (MC.050) specify the revisions.
ACTIVITY
Back to Top
WORK PRODUCT
Configured Applications - The Configured Applications are production-ready to be used by trained users.
Back to Top
TASK STEPS
1 Revise specific applications as per the instructions described in the Application Setup Documents (MC.050).
Back to Top
APPROACH
Once the automated portion of the production upgrade process has completed, specific applications should be updated as per the instructions described in the Application
Setup Documents (MC.050).
The nature of the application revisions will vary across Oracle products but may include updates to items such as application Profiles and Processing Options.
Back to Top
Business Analyst 50
Application/Product
Specialist
implemented.
40
Back to Top
PREREQUISITES
Prerequisite Usage
(DS.030)
The Application Setup Documents specify the revisions that need to be applied.
Upgraded Production
Environment (TS.055)
The the post-upgrade application setup revisions are made in the Upgraded Production Environment prior to live transaction
processing.
Completed Post-Upgrade
Checklist (TE.056)
Use the completed Post-Upgrade Checklist to verify that all the post-upgrade steps have been completed and to note any results
that affect the software upgrade process.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Configured Applications are used by trained users to begin live transaction processing in the Upgraded Production Environment.
Back to Top
QUALITY CRITERIA
Have all the applications been updated as per the instructions documented in the Application Setup Documents (DS.030)?
Back to Top
TS.058 - VERIFY PRODUCTION READINESS
In this task, you formally verify that the organizations systems, host facilities, local area networks (LANs), wide area networks (WANS), and people are prepared for
production.
ACTIVITY
Back to Top
WORK PRODUCT
Production-Ready System - The Production-Ready System consists of detailed checklists and optionally, a quality assurance review that allows you to verify production
readiness. It should address the following:
readiness verification
quality audit or implementation review
Back to Top
TASK STEPS
1 Review the production readiness verification checklist.
2 Conduct production readiness verification using the checklists
provided in the Detailed Transition Plan component of the
Installation Plan (TS.030).
Transition
Plan
This component uses a series of tasks, or checklists, during transition of the new
system into production.
3 Confirm the production cutover.
4 Prepare the support team Preparing for
Production
This component provides the organization with a plan to schedule operations in a
manner capable of support by the information technology and consulting
organizations.
5 Obtain agreement for the initial production schedule. Production
Schedule -
First Week
This component provides a table for the first week production schedule. If no
major problems arise, normal operational procedures can begin as early as the
second day of production.
6 Verify that users are trained.
7 Verify commitment and readiness of internal and external support
personnel.

8 Verify the completion of Production Environment.
9 Confirm senior management commitment via the steering
committee.

10 Distribute the initial production schedule.
11 Obtain approval for beginning production.
Back to Top
APPROACH
When you Verify Production Readiness, you confirm that the organizations systems and people are prepared for production.
Although the predecessor to this task is acceptance criteria, the true system certification occurs after Perform System Test (TE.070). Success with this task means that
project leadership can request approval for transition activities. This is the final approval step before the cutover to the new production system.
User Readiness
For all business processes, users should demonstrate that they are qualified to fulfill the requirements of the process as well as each downstream process step.
#TOP #TOP
Presentations by users, also known as walkthroughs, can be used to demonstrate competency levels. Finally, users should confirm that they feel prepared and confident
to move to the new system.
NOTIFY OUTSIDE AGENTS AND CUSTOMERS
As part of the overall communication program outlined in the Change Management Roadmap / Communication Campaign (OCM.140), contact partners and suppliers to
let them know when production cutover will occur. Ask for additional support coverage for a set period of time. The organization management may also want to notify its
key customers of the transition to a new system. In this way they can be prepared to deal with any issues, potential delays in service, or changes to procedures or
business documents.
Production System Readiness Verification
The verification process uses the general and detailed task checklists from the Cutover Strategy (TS.020) and the Installation Plan (TS.030). Readiness verification should
be checked on two levels:
business processes
technical components
This is the final step before approving cutover. Verify that all business process owners have conveyed production status and plans to customers, suppliers, other
business partners, and internal resources who will either use or be affected by the new system.
Business preparation should confirm the following:
All system, reference, and manual procedures are distributed to all users.
All system access, support infrastructure, and other necessary connections are available.
All users are fully trained and prepared for the cutover.
Technical considerations include the following:
database operating system
software
peripherals
support personnel process
reference materials
contingency communication process
As another means to confirm that the system is stable, key users should go through the Production Environment setup and data to confirm that every form can be
accessed and all reports print successfully. It is also a good opportunity to test user menus and verify that each user has the appropriate security access and
responsibilities and that their user profiles are set up correctly. Verify that all business system test actions are closed.
Quality Audit or Implementation Review
A quality audit or implementation review provides management with a final opportunity to prevent possible failure when critical issues are discovered during this task. The
goal of the quality audit or implementation review is to identify risks and submit a candid and detailed summary of problems related to production cutover.
Implementation reviews can:
Utilize a structured technical process to evaluate the application environment from a performance and application architecture perspective.
Provide a functional evaluation of organization readiness and acceptance of the new system.
Mitigate risk by identifying common transition problems before production cutover.
Predict and plan for post-production support requirements.
It is important to realize that no project is risk free. Revealing risks to project management provides the project team with the opportunity to correct problems. During
production, potential problems become real problems and business consequences become more apparent. Understanding the relative risk associated with each problem
will help the organizations senior management make the ultimate decision whether or not to postpone production cutover.
Contingency Plan Verification
The Cutover Strategy (TS.020) and Installation Plan (TS.030) for implementing the production system was created prior to beginning the transition to production. It is
important to review these work products with the information systems organization and, in addition, communicate the essence of the fallback plan to the users. In this
case, if there is a production delay, an organization-wide announcement directing users to these work products can be made without having to provide detailed
explanations.
Initial Production Schedule
The initial production week should be carefully managed to control the organizational impact. You should provide additional control over the operational and support flow
for all organizations during the initial week of production. Specific recommendations are as follows:
Determine production schedule for financial, distribution, and manufacturing operations.
Dedicate analysts, super users, or consultants to answer questions, fix problems, or provide real time learning events as needed.
Provide a mechanism to get user feedback.
Set support priorities to manage expectations.
Update internal and external support channels of go-live date.
Distribute the initial production schedule to users and support personnel prior to production cutover. In the schedule, list the departments or processes that can begin
transactions at a set point in time. This allows information systems personnel to provide full support to the specified departments or processes, thereby avoiding
excessive support demands throughout the organization.
Back to Top
Back to Top
Quality Manager 55
System Architect 30
Business Analyst 5
Tester 5
IS Manager *
User *
Back to Top
PREREQUISITES
Prerequisite Usage
Converted and Verified Data (Initial
Load) (CV.065.2)
Converted data should be validated prior to production cutover.
Acceptance Test Results (TE.120) The Acceptance Test Results provide verification that the new application system meets the acceptance criteria specified in
the Project Management Plan (PJM).
Skilled Users (TR.100) Skilled Users should participate in the learning events and be confident that they can execute their job responsibilities at
production cutover.
Cutover Strategy (TS.020)
Installation Plan (TS.030)
The contingency alternatives and the transition schedule should be reviewed and understood by the entire organization prior
to production cutover.
Production Environment (TS.050) The Production Environment should be set up and configured with validated setups and seed data prior to production
cutover.
Production Support Infrastructure
(TS.052)
The Production Support Infrastructure should be implemented prior to production cutover.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.>
Use the following components from the Cutover Strategy (TS.020) and the Installation Plan (TS.030) to support completion of the Production-Ready System:
Transition Plan
Preparing for Production
Production Schedule - First Week
Back to Top
Back to Top
QUALITY CRITERIA
Back to Top
TS.060 - GO PRODUCTION
In this task, you take the new application system and put it into production use. The new system is now part of the business and is being used to solve business needs.
For SOA services, you deploy the services in this task. Refer to the Service Packaging and Deployment Technique for more details.
ACTIVITY
Back to Top
WORK PRODUCT
System in Production - The System in Production is used by trained users and supported by trained administrators. The System in Production replaces any legacy
systems identified for replacement by the new application system.
System in Production certifies that all aspects of the system are operational. Before declaring production status, you should consider the following:
All reports can be generated, printed, and viewed online.
All inquiries can be made from all established terminals.
Users have access to and have used all respective functions and features of the business system.
All automated backup and recovery programs operate according to schedule.
All background programs perform as designed.
No alternate support or business systems are required to run portions of the business.
Supplemental Guidance for Service-Oriented Architecture (SOA) Implementations
If your project involves SOA implementation, you deploy the services in this task. Refer to the Service Packaging and Deployment Technique for guidance.
Back to Top
TASK STEPS
1 Verify pre-production
validation results.
System in
Production
The System in Production is a fully supported and operational new system that is being successfully used in the
business environment for which it was written.
2 Schedule trained users and
support staff.
None None
Back to Top
APPROACH
This task covers a period of time during which the following conditions apply:
The environment is carefully controlled.
Transactions are brought online in a priority sequence (most critical first) to keep support requirements low and focused.
Access to replaced systems is restricted.
The best way to begin using the new system is to control the initial transactions and entries. Bring up departments or sets of related transactions in sequence to permit
focused attention on limited areas until they are stabilized. Use the Production Schedule - First Week component of the Installation Plan (TS.030) to coordinate this
support model. You must anticipate issues and quickly remedy them. Priorities may shift during the production state and therefore you must set expectations with users
on what types of problems to resolve first.
Take advantage of the communications tools, defined in the Change Management Roadmap / Communication Campaign (OCM.140), to make the entire organization
aware that production status has been achieved.
Verify Pre-Production Validation Test Results
Ambassador users check that the test results returned from the pre-production validation test are such that the system administrator can proceed.
Schedule Trained Users and Support Staff
The system administrator makes sure that the trained users and support staff are in place to operate the new system.
Back to Top
Back to Top
System Administrator Coordinate and manage the Go Production effort. 100
User Use the new application system. *
IS Support Staff Start providing production support for the new application system. *
Back to Top
PREREQUISITES
Prerequisite Usage
Acceptance Test Results
(TE.120)
Review the results of the acceptance test indicating that the new application system has met the business acceptance criteria and is now
ready for production.
Clean Legacy Data
(CV.068.2)
The Clean Legacy Data along with the Production Environment includes everything that is required for the application to be used in
production.
Production Environment
(TS.050)
The Production Environment represents all the software, documentation and hardware, including terminals and networks, required to
operate the new application system in production.
Performance Test Report
(PT.110)

Back to Top
TECHNIQUES
Technique Comments
Service Packaging and Deployment Use this technique to understand how to carry out SOA services deployment.
SOA Service Lifecycle Use this technique to understand where service deployment fits in the SOA service lifecycle.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The System in Production is used in the following ways:
to fulfill the business tasks for which it was written
Distribute the System in Production as follows:
to the business
Back to Top
QUALITY CRITERIA
Does the new system work as expected?
Can the users use the system?
Does it appear to operate to the required service levels?
Have all configuration items been properly archived?
Have all data loading and conversion activities been completed successfully?
Back to Top
TS.070 - SHUT DOWN LEGACY SYSTEM
In this task, you remove the old application system from service. The task provides a final snapshot of the code and data of the legacy system for archival. The system
administrators backup the system and then remove all software and hardware that are no longer needed.
At the completion of this task, the legacy system is shut down and only the new application system is available for use. The task involves scheduling the system
administrators and any IS operations and support staff, as well as third party technicians.
ACTIVITY
Back to Top
WORK PRODUCT
Legacy System Shut Down - The work product for this task is the Legacy System Shut Down. This work product indicates that the data from the old system has been
archived and the software and hardware have been removed from service. It represents the conclusion of the conversion from the old system to the new application
system.
Back to Top
TASK STEPS
1 Take existing system out
of production.
Legacy System
Shut Down
The Legacy System Shut Down consists of the existing system being taken out of use, the data being backed up and
then the freed resources being utilized as the business sees fit.
Back to Top
APPROACH
This task is optional and is performed when a legacy system exists that is being replaced by the new solution that is now in production. If performed, it should be
performed once. The system administrator takes the existing system out of production so that the users only have access to the new production system. The resources
freed up by decommissioning the existing system can then be disposed of as the business sees fit.
Decommissioning former systems can begin after the team has decided that the new production environment is stable, and that the Transition Plan and Contingency Plan
found in the Installation Plan (TS.030) are no longer needed.
Decommission Strategy
Usually, the subject of decommissioning former systems is raised during the tasks, Define Data Acquisition and Conversion Requirements (CV.010) and Define Data
Acquisition, Conversion and Data Quality Strategy (CV.020). When preparing the Data Acquisition and Conversion Requirements (CV.010) and the Data Acquisition,
Conversion and Data Quality Strategy (CV.020), you should decide which legacy systems will be decommissioned and the timing of when each system will be
decommissioned. Legacy systems that will be decommissioned at the time the new applications go into production directly impact Transition and specifically the
Installation Plan (TS.030).
Legacy systems that will be decommissioned using a phased approach may increase the complexity of the conversion process due to additional interface points that
need to be built and maintained to keep the legacy system and new applications synchronized. You also need to take into consideration master data identification and
synchronization requirements. Even though the former systems may be decommissioned over more than one year, you should document a detailed plan for performing
the decommissioning.
Decommissioning of Former Systems Timing
Data conversion usually defines a stop and end point for transactions. It is common to find that the production date does not correspond to a fiscal period. Legal
requirements may require some data to exist in the former systems. Therefore, the timing of the decommission activity depends on when the need to report on data
crossing over two systems (in this case, a fiscal period) no longer exists.
Transition Plan
Create an action plan to remove the former systems. The original transition plan may need to be revised after the production cutover. You should revisit and revise this
action plan, expanding on the steps to remove the former systems, if necessary. You may want to perform this task in stages although online transaction capabilities
should be removed, history inquiries may still be useful until sufficient histories are built up in the new system.
Some considerations for decommissioning the former systems include:
reliance on and access to historical data not converted over in the new system
returning rented, contracted, or licensed hardware or software
physically removing equipment and closing all connections to the former systems
disposing of obsolete documentation
cleaning out system space occupied by the former application
transitioning key users supporting the old system
Data Archiving
Storing
If you do not want to maintain historical data in the former systems beyond the already converted data, use tape or other media to store historical data.
Retrieving Data Test
Before completing this task, you should perform a test of stored data retrieval. If third-party storage has been contracted, follow their procedures for retrieving data and
determine how efficient it is to obtain information whenever there is an unexpected need. This may help you decide whether to convert and maintain a longer period of
history on the new system. You may find that long delays in data retrieval can cause serious operational problems downstream.
Back to Top
Back to Top
System Administrator Decommission the existing system.
Back to Top
PREREQUISITES
Prerequisite Usage
System in Production (TS.060) Once the new system is in production and running smoothly, the legacy system is no longer needed.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Legacy System Shut Down is used in the following ways:
to make sure that the new replacement system is not being used at the same time as the system being replaced
Distribute the Legacy System Shut Down as follows:
to the business
Back to Top
QUALITY CRITERIA
Have all users access rights been revoked?
Has it been decommissioned according to business policy?
Back to Top
[PS] OPERATIONS AND SUPPORT
The goal of the Operations and Support process is to monitor and respond to system problems via a help desk, to upgrade the application to fix errors and performance
problems, to evaluate the System in Production, and to plan enhancements for increased functionality, improved performance and tighter security.
The development project does not come to an abrupt end when the team installs the application system into Production. In fact, the months following that milestone can
determine the real success or failure of the project. Internal auditors have not yet produced the System Evaluation, and users most likely still have a few problems to
uncover. There are certain to be requirements with lower priorities that have not been implemented. The Could Have requirements and any remaining Should Haves can
now be reprioritized into a Future MoSCoW List (Enhancement Plan), from which upgrades can be defined.
Back to Top
PROCESS FLOW
Back to Top
APPROACH
Depending on your project (for example, large, complex, etc.), the project manager may designate an Operations and Support team leader. If the project manager
designates an Operations and Support team leader, they are responsible for leading the Operations and Support process and reviewing the work products. The team
leader plans, directs, and monitors the day-to-day work of the team. The team leader assigns work packages to the team members and makes sure they understand the
requirements. The team leader is responsible for building team cohesion, motivating the teams, and providing assistance and encouragement to the team members.
Each team leader performs the final quality control and quality assurance for the team by reviewing all work products. The team leader also signs off on team work
#TOP #TOP
completion and quality. Work that is not up to quality standards is returned. Team leaders review work products from other teams when these work products may impact
aspects of the system. The team leader reports the team's progress to the project manager. Refer to Project Management in OUM for additional information on team
leaders.
Warranty Support
The contracts for most development projects specify a required warranty period. This is the length of time following system acceptance that the project team is obliged to
address problems and fix any faults that are found. A typical warranty period is ninety days. The specified warranty period usually determines the character of the
Operations and Support process. A short or absent warranty period means a very short time to hand over the crucial jobs of application support and maintenance. A
longer warranty period allows a more gradual handoff.
System Audit
Some customers require an audit of the system (PS.010). During the audit, the success of the application system development project is measured against the original
goals set out in the Quality Plan. This audit usually includes validation of the system against non-functional requirements. Increasingly, such audits focus on security
issues, such as the prevention of unauthorized access to data. Therefore, it is important to address such issues and to involve the internal auditors in the Technical
Architecture process. Audits should be repeated as the system is upgraded.
Performance Validation
Some of the tasks in the Operations and Support process (PS.050-PS.060) involve evaluating the system's performance in relation to the performance requirements
documented in the Technical Architecture process. If the product team has not built hooks into the application to capture exact response times and transaction
frequencies, these tasks require gathering subjective feedback from the users.
Future Enhancements
In the period after the system has gone into Production, it is often necessary with a number of small fixes or patches to upgrade the application. However, there might be
larger functional areas that should be added to the System in Production, and there are certain requirements with lower priorities that have not been implemented. The
Could Have requirements and any remaining Should Haves can now be reviewed again, together with any new requirements, to determine any future enhancements
(PS.135) and be reprioritized into a Future MoSCoW List (PS.140) from which larger upgrades or even new projects can be defined.
Back to Top
Production Phase
PS.010 Audit System System Evaluation
PS.050 Analyze Problems Fault Corrections
PS.060 Monitor and Respond To System Problems Problem Log
PS.135 Determine Future Functional Enhancements Future Functional Enhancements
PS.140 Plan Enhancements Future MoSCoW List
Back to Top
OBJECTIVES
The objectives of the Operations and Support process are:
Fulfill warranty obligations.
Monitor system performance, log any problems and make corrections, if necessary.
Verify that security requirements have been satisfied.
Provide agreed on levels of support.
Propose and plan future system enhancements.
Back to Top
KEY WORK PRODUCTS
Back to Top
Role
ID
Name Responsibility
AU Internal Auditor Audit financial and business controls and system security.
DBA Database
Administrator
Upgrade the production database, if necessary, by applying the upgraded DDL and database procedures.
DV Developer Analyze open problem reports. Determine faults. Specify fault corrections. Periodically, review list of fault corrections to ensure that they
are within the scope of the application system. Provide support for model integration tests by reconciling differences between design
specifications and built application. Represent the project team.
IQA Independent Quality
Auditor
Evaluate application system.
SAD System
Administrator
Provide any requested information to auditor. Provide access to all audit materials.
SAN System Analyst Analyze performance statistics with the user management to determine the Performance Exceptions. Present and discuss performance
statistics with the user management to determine the Performance Exceptions. Compile and prepare list of enhancement requests.
Interview users and user management. Determine effort necessary to implement each set of enhancements. Work with business
management to assign priorities, present alternatives and develop the proposal including the work and financial plans.
Client (User)
KEY Ambassador User Check that the upgrade has adequately addressed each of the agreed Fault Corrections and Performance Corrections.
CPM Client Project
Manager
Arrange and review audit. Review performance statistics and determine Performance Exceptions. Provide enhancement priorities, and
review and approve proposal including the work and financial plans.
CPS Client Project
Sponsor
Arrange audit. Provide access to application system users and administrators. Provide enhancement priorities. Review alternatives and
approve proposal.
SS IS Support Staff Provide technical support.
USR User Provide any requested information to auditor. Provide feedback on perceived application performance. Relate details of problem reports to
analyst.
Back to Top
Effective Change-Control Tools and Procedures: Strict change-control procedures are critical to the success of the Operations and Support process.
Procedures for logging faults and performance exceptions must be explicit and well understood. The project manager and client project manager must have a very
good operational understanding of the definition of a system defect, a performance exception, and an application enhancement. Any misunderstanding directly
contributes to scope expansion.
Commitment to High Levels of Service: When the application has gone into Production, it is critical to deliver proper service to the users who start using the
system. As the users do not know the application very well at this point of time, there is a relatively large need for support. Therefore, a commitment to a proper
service level may be vital to ensure that the system is perceived well by the users. Poor (or no) service, even when the system itself is a success for the project
participants, may result in dissatisfied users blaming the new system.
Continued Involvement of Users and Administrators: The development project does not come to an abrupt end when the team installs the application system
into Production. In fact, the months following that milestone can determine the real success or failure of the project. The users that have been involved in the
project should be involved in supporting the new users. In addition, there are certain to be requirements with lower priorities that have not been implemented. The
users must be involved in determining any new functionality that should be implemented, and to determine new priorities of the left-out requirements.
Communication to Users: The users that start using the system for the first time should have received any necessary training. In most situations, new releases
are planned with additional and enhanced functionality. To prevent users becoming dissatisfied with the system because of a lack of functionality, it is important
that the plans for enhancements are communicated to the users. Also, the users should be encouraged to report any enhancement requests that they see
necessary.
Back to Top
PS.010 - AUDIT SYSTEM
In this task, you have an independent quality auditor review the application system. You should perform this task after cutover, when the application system has reached a
steady state.
ACTIVITY
Back to Top
WORK PRODUCT
System Evaluation - The System Evaluation measures the success of the application system development project against the original goals set out in the Quality Plan.
Back to Top
TASK STEPS
1 Review objectives and top level requirements. None None
2 Review Security and Control Strategy. None None
3 Review technical and system operational
documentation.
None None
4 Examine the System in Production. System
Evaluation
The form and scope of the System Evaluation should be defined by the project
sponsor.
Back to Top
APPROACH
This is a core task. It is especially important in organizations that require conformance to internally or externally defined standards (for example, security standards). It is
performed once and is singly instantiated. The scope of the System Evaluation depends upon the corporate information technology (IT) requirements. For many
organizations, these requirements are minimal. For other organizations, (for example, the Government and Financial sectors), there may be stringent rules to which the
system is required to conform. Usually these are strictly enforced, in particular for mission-critical systems. Early involvement of relevant stakeholders can reduce the risk
of delays.
Back to Top
Back to Top
System Administrator Provide any requested information to auditor. Provide access to all audit materials. 100
Independent Quality
Auditor
Evaluate application system. *
Internal Auditor Audit financial and business controls and system security. *
Client Project Sponsor Arrange audit. Provide access to application system users and administrators. *
Client Project Manager Arrange and review audit. *
User Provide any requested information to auditor. *
Back to Top
PREREQUISITES
Prerequisite Usage
(RD.001)
The audit should refer to the original objectives of the project and consider whether the system, as delivered, has met these
objectives.
MoSCoW List (RD.045) The audit should refer to the original requirements for the project and consider whether the system, as delivered, satisfies
these requirements.
Security and Control Strategy
(TA.090)
This work product describes the strategy for security and control. The audit should verify that this strategy has been
implemented.
System in Production (TS.060) You can begin to audit the application system after it has gone into production, and after it has reached a steady state.
Managed Production System (PT.120)
Back to Top
TEMPLATES AND TOOLS
Tool Comments
processes.
Back to Top
The System Evaluation is used in the following ways:
by the project sponsor to verify that system and business objectives have been met
Distribute the System Evaluation as follows:
Back to Top
QUALITY CRITERIA
Have any new requirements been introduced by the auditor?
Did the audit adequately cover each of the areas specified?
Back to Top
PS.050 - ANALYZE PROBLEMS
In this task, you analyze each open problem report from the Problem Log (PS.060). You determine which open problems represent faults in the application system.You
determine the changes that are necessary to resolve the set of faults.
Perform this task in parallel with the task Monitor and Respond to System Problems (PS.060), post production, if this is within the scope of the project.
ACTIVITY
Back to Top
WORK PRODUCT
Fault Corrections - The Fault Corrections is a specification of the changes that are necessary to address each verified fault.
Back to Top
TASK STEPS
1 Examine daily (if possible) all open problem reports in the Problem
Log (PS.060).
None None
2 Contact problem originators to discuss the nature of problems. None None
3 Determine which open problems represent nonconformances (faults,
defects) by consulting the list with prioritized requirements (MoSCoW
List).
None None
4 Verify the faults by reproducing them, if possible. Closed Non-
Reproducible
Problems
The Closed Non-Reproducible Problems describes the problems that
have been closed after unsuccessful attempts to reproduce them.
5 Compile weekly (perhaps) the list of faults. Defect List The Defect List displays the verified non-conformances.
6 Determine corrective action for each problem listed. None None
7 Compile the list of Fault Corrections, cross-referenced to the Problem
Log and to the MoSCoW List, for delivery to the business.
Fault
Corrections
The Fault Corrections describes the changes necessary to correct each
of the verified non-conformances. An estimate should be given in each
case.
Back to Top
APPROACH
This task is ongoing, from Production start until the end of the warranty period.
Although all items on the list of Fault Corrections originate from the Problem Log, there is no need to wait until the Problem Log is completed before beginning to address
them. You can begin to address obvious faults immediately. Always cross-reference the Fault Corrections back to the originating item in the Problem Log and to relevant
requirements in the MoSCoW List. It is critical that you are able to determine whether a problem is a the result of a non-conformance. You should use the MoSCoW List
to determine what is in or out of the scope of the current increment.
Back to Top
Back to Top
System Analyst Analyze performance statistics with the user management to determine the Performance Exceptions. Present and discuss
performance statistics with the user management to determine the Performance Exceptions.
If an Operations and Support team leader has been designated, 10% of this time would be allocated to this individual, leaving
90% allocated to the system analyst. The team leader would then present and discuss performance statistics with the user
management to determine the Performance Exceptions.
100
Client Project Manager Review performance statistics and determine Performance Exceptions. *
User Provide feedback on perceived application performance. *
Back to Top
PREREQUISITES
Prerequisite Usage
MoSCoW List (RD.045) Use the refined MoSCoW List to identify any performance-related requirements.
(RA.180.2)
This work product represents the functional scope of the application system.
(AN.110.2)
This work product represents the functional scope of the application system, including their priorities.
System in Production
(TS.060)
You cannot begin compiling the defect list until the application system is in production.
Problem Log (PS.060) The Problem Log and Fault Corrections are closely related as the tasks that create these work products are executed in parallel. The
Problem Log is analyzed to determine which open problems represent faults (defects) in the application system. Both work products
should be maintained as new problems are found and addressed.
System Evaluation (PS.010) The System Evaluation may uncover problems that need to be analyzed and corrected.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Fault Corrections is used in the following ways:
to plan upgrades
Distribute the Fault Corrections as follows:
to the project manager for planning
Back to Top
QUALITY CRITERIA
Have the changes been estimated accurately?
Have the consequence of each change been identified?
Back to Top
PS.060 - MONITOR AND RESPOND TO SYSTEM PROBLEMS
In this task, you must monitor and respond to problems and issues throughout the post-production support period.
When service-oriented architecture is involved, it is best practice to also monitor service level agreements and report breaches.
This is an ongoing task that may not be full-time.
ACTIVITY
Back to Top
WORK PRODUCT
Problem Log - The Problem Log is the list of all problems that users and administrators reported during the post-implementation support period, and the way in which
they were responded to or resolved.
Service Monitoring Report - In SOA systems where contracts and service level agreements (SLAs) are enforced, the Service Monitoring Report is used to report
breaches.
Back to Top
TASK STEPS
1 Record and acknowledge problem
reports from users and administrators.
None None
2 Compile and maintain the Problem Log. Problem Log The Problem Log lists all problems that users and administrators reported during the post-
implementation support period, and the way in which they were responded to or resolved.
For SOA systems, follow these additional steps:
3 Monitor Service SLAs. None None
4 Record SLA breaches and compile into a
report.
Service
Monitoring
Report
The Service Monitoring Report is used to report breaches in the service level agreements.
Back to Top
APPROACH
Back to Top
Back to Top
Developer Analyze open problem reports. Determine faults. Specify fault corrections. Periodically, review list of fault corrections to ensure
that they are within the scope of the application system.
80% allocated to the developer. The team leader would then periodically, review the list of fault corrections to ensure that they
are within the scope of the application system.
100
IS Support Staff Provide technical support. *
User Relate details of problem reports to analyst. *
Back to Top
PREREQUISITES
Prerequisite Usage
System in
Production
(TS.060)
You should begin logging problem reports as soon as the application system is in production.
Fault Corrections
(PS.050)
The Fault Corrections and Problem Log are closely related as the tasks that create these work products are executed in parallel. Both work
products should be maintained as new problems are found and addressed.
Back to Top
TECHNIQUES
Technique Comments
Service Packaging and Deployment Use this technique for guidance on monitoring service usage and SLA, and monitoring reports.
Back to Top
TEMPLATES AND TOOLS
Use a good Issue Tracker software to log and track problems.
Back to Top
The Problem Log is used in the following ways:
as input to problem analysis
Distribute the Problem Log as follows:
to developers for problem analysis
to the project manager for reporting purposes
Back to Top
QUALITY CRITERIA
Do the end users have a clear understanding of the scope of the system as delivered?
Is there a need for better end-user documentation or more end-user training?
Back to Top
PS.135 - DETERMINE FUTURE FUNCTIONAL ENHANCEMENTS
In this task, you compile a list of future enhancements to the application system. It should be performed following cutover, during the entire agreed upon support period.
This can be a very important task for leveraging new opportunities for enhancements.
This task is done when subsequent projects are being planned.
ACTIVITY
Back to Top
WORK PRODUCT
Future Functional Enhancements - The Future Functional Enhancements is a compilation of enhancement requests to the application. A MoSCoW List with unattended
user requests during the project is a valuable input for this task.
Back to Top
TASK STEPS
1 Record new requirements. Functional Enhancements The Functional Enhancements is a compilation of requested enhancements.
2 Prioritize new requirements. Prioritized Requirements The Prioritized Requirements is simply the Functional Enhancements prioritized.
Back to Top
APPROACH
This task is mandatory. Enhancements should be added to the MoSCoW List and prioritized by the ambassador users.
Back to Top
Back to Top
System Analyst Compile and prepare list of enhancement requests. Interview users and user management. 100
Back to Top
PREREQUISITES
Prerequisite Usage
MoSCoW List (RD.045.3) Use the refined MoSCoW List to identify any performance-related requirements.
Organizational Effectiveness
Assessment (OCM.250)
The Organizational Effectiveness Assessment captures the efficiency of the work done during the project and highlights the change
management work to continue after the Go Live to ensure a shorter transition.
System in Production (TS.060) You do not begin formally compiling the list of enhancements until after the cut-over.
System Evaluation (PS.010) The System Evaluation may indicate the need for functional enhancements.
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Future Functional Enhancements is used in the following ways:
to define the scope and top-level requirements of future increments
Distribute the Future Functional Enhancements as follows:
to the ambassador users
Back to Top
QUALITY CRITERIA
Are the enhancements adequately defined?
Back to Top
PS.140 - PLAN ENHANCEMENTS
In this task, you take the Future Functional Enhancements, prioritize it and then analyze the amount of work necessary to implement each set of enhancements.
You then work with the business management to plan follow-on development.
ACTIVITY
Back to Top
WORK PRODUCT
Future MoSCoW List - The Future MoSCoW List is a listing of prioritized enhancement requirements that are to be developed, a workplan for those enhancements, and
a financial plan indicating costs and payments.
Back to Top
TASK STEPS
1 Confirm prioritizations. Prioritized
MoSCoW List
The Prioritized MoSCoW List is a list of enhancements to be included in one or more specified
future increments.
2 Define scope and objectives for the next
increment.
Scope and
Objectives
The Scope and Objectives is a workplan for the development of one or more future increments.
Back to Top
APPROACH
This task is mandatory. The remaining requirements from the current increment plus the post-production requirements should be grouped by functional area. From these
groupings, the ambassador users define one or more future increments (projects) and recommend actions to the project sponsor.
Back to Top
Systems Analyst Determine effort necessary to implement each set of enhancements. Work with business management to assign priorities,
present alternatives and develop the proposal including the work and financial plans.
60% allocated to the system analyst. The team leader would then work with business management to assign priorities, present
alternatives and develop proposal including the work and financial plans.
100
Client Project Sponsor Provide enhancement priorities. Review alternatives and approve proposal. *
Client Project Manager Provide enhancement priorities, and review and approve proposal including the work and financial plans. *
Back to Top
PREREQUISITES
#TOP #TOP
Prerequisite Usage
MoSCoW List (RD.045.3) Use the refined MoSCoW List to identify any future enhancements.
System Evaluation
(PS.010)
The System Evaluation may contain suggestions for non-functional enhancements.
Future Functional
Enhancements (PS.135)
The outstanding requirements from the current increment, plus new requirements that have been defined from enhancement requests after
the system entered production, define the requirements to be satisfied in future increments (projects).
Back to Top
TEMPLATES AND TOOLS
Back to Top
The Future MoSCoW List is used in the following ways:
to obtain a budget for future increments
to plan staffing of future increments
Distribute the Future MoSCoW List as follows:
Back to Top
QUALITY CRITERIA
Does the Future MoSCoW List cover all of the prioritized enhancements?
Back to Top
OUM 6.2
Planning a Project using the Oracle
Unified Method (OUM) - An Iterative and
Incremental Approach
Planning a Project using the Oracle Unified Method (OUM) - An
Iterative and Incremental Approach
EXECUTIVE OVERVIEW
The Oracle Unified Method (OUM) uses the Manage focus area - Project Management Method (OUM Manage) to provide a framework in which projects can be planned,
estimated, controlled, and tracked in a consistent manner. OUM is based on the Unified Process and is therefore both iterative and incremental. The intent of this
approach is to provide you with a high-level guide for planning an OUM project.
Back to Top
INTRODUCTION
Iterative development using OUM provides many benefits: major risks are identified and addressed early in the project; requirement changes are identified and prioritized
efficiently; project team utilization is optimized; and progress and quality are continuously monitored and corrected.
Back to Top
PLANNING AN OUM PROJECT - A LAYERED APPROACH
OUM is designed to be a scalable method that can be applied to any kind of Oracle project. Plans need to be scalable for different project sizes and complexity and
contain the right level of detail for the current planning horizon. Plans that are too detailed are almost instantly inaccurate and obscure key objectives. On the other hand,
plans that are too high level will not allow for measurement of project progress nor keep the project team focused on their day-to-day activities.
Plans need to display the appropriate level of detail and planning horizon for specific audiences. For example, C-level executives, business area managers and external
stakeholders are rarely interested in the fine details of the project. Their focus is on the release date, major milestones, business impacts, points at which major decisions
must be made. On the other hand, the project team needs the details on the lower level plans to plan their daily work and measure progress.
Therefore, a layered approach to planning OUM projects is recommended. As shown below, there are two plans active in the project at any given time on an OUM project
the implementation and the Iteration Plan.
Back to Top
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 represents the lowest and most detailed layer of planning. An individual Iteration Plan 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.
Back to Top
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.
The planning starts in the OUM Manage Project Start Up phase where 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.
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
Back to Top
IMPLEMENTATION PLANNING
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, as shown in the example below.
Keep in mind, that because OUM utilizes a top-down/bottom-up approach to planning, the task of developing the Implementation Plan requires the Implementation Plan
and current Iteration Plan to be worked on concurrently.
Compile the Implementation Plan
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.
Secure Agreement on the Implementation Plan
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.
Evolve the Implementation Plan
Keep in mind that Implementation Planning, as with the other planning efforts, is done in an iterative manner. Information will be uncovered during the planning process
that will necessitate amending the Implementation Plan as well as the current Iteration Plan. As the project progresses phase and iteration assessments will be
conducted and feedback will be gained, which will lead to the need to adjust the plan(s).
Back to Top
ITERATION PLANNING
Iteration planning is where the bulk of the planning for a project occurs. Each iteration should be planned such 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.
Assess the Current State of Project Risks
Risk management on any project is a dynamic process since project risks will be eliminated and additional risks will be exposed as the project progresses.
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.
Establish the Scope of the Current Iteration
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 Burndown Chart.
The Burndown 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.
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
Map the Iteration's Deliverables to OUM Tasks
The Iteration Plan needs lay 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 OUM 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.
For more information on building the Iteration Plan, refer to the following:
Develop Baseline Project Workplan (WM.010)
Assign Resources and Produce Estimates
Resources need to be associated with each OUM task included in the Iteration Plan. 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 Iteration Plan. These estimates should be verified against broader
estimates completed as part of the initial planning effort for the iteration.
Identify Dependencies
OUM strives to minimize dependencies within the detailed Iteration Plans 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.
Establish Success Criteria 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.
Determine the Assessment Milestones for Each 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.
Compile the Iteration Plan
The Iteration Plan information should be compiled into a simple document. The first section of the plan should reflect the scope and objectives of the iteration. The primary
goal of the scope is to make clear the iterations objectives, priorities and evaluation criteria. This information can be used to track the iterations progress and drive the
iteration assessment. The rest of the plan captures the detailed plan for the execution of the iteration.
Iteratively Evolve the Plan(s)
OUM project planning requires the project manager to plan the iteration by specifying the goals and then allowing the team to determine how best to achieve the goals.
More information will be brought to light during the execution of an iteration that will impact the current Iteration Plan as well as the plan for the next iteration.
The Iteration Plan may need to be adjusted to account for a previously unknown requirement and/or risk. However, it is recommended that rather than re-planning the
current iteration, it is important to keep the team focused on the goal of the current iteration and remove as many barriers as possible to allow the team to move forward.
Also, keep in mind that each of the layers implementation and Iteration Plans must be kept in synch. The degree to which an iteration achieves its objectives will impact
future iterations as well as milestones on the Implementation Plan. As the phase and iteration assessments are conducted, feedback will be gained which will lead to the
need to adjust the plan(s).
Back to Top
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
CONCLUSION
OUM recommends a layered approach to project planning rather than a single, highly detailed plan. Planning and managing at each layer (implementation and iteration)
frees the project manager and project team from the need to create and feed detailed plans that have a tendency to quickly become out of date and unwieldy. The
layered planning is scalable and empowers the team to focus on the key goals, measurements, milestones and controls that enables effective project management.
Back to Top
REFERENCES
This page was made possible through the collaboration with numerous OUM contributors as well as the conglomeration of information from several outstanding books and
websites:
Bittner, Kurt. 2007. Managing Iterative Software Development Projects. Boston, MA: Pearson Education, Inc.
Boehm, B. and R. Turner. 2004. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley
Cockburn, A. 2002. Agile Software Development. Boston, MA: Addison-Wesley.
Larman, Craig. 2004. Agile and Iterative Development: A Managers Guide. Boston, MA: Pearson Education, Inc.
Cohn, Mike, 1962 -. Agile Estimating and Planning, Upper Saddle River, NJ: Pearson Education, Inc.
A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition, Newton Square PA: Project Management Institute, Inc.
http://www.agilemanifesto.org
http://alistair.cockburn.us
http://www.controlchaos.com/
http://martinfowler.com/articles/itsNotJustStandingUp.html
http://Agilesoftwaredevelopment.com/scrum
Back to Top
OUM 6.2 Tailoring OUM for Your Project
INTRODUCTION
The Oracle
Unified Method (OUM) provides support for the entire Enterprise IT lifecycle, including the successful implementation of every Oracle product. However it is unlikely that
any given project will involve the implementation of every Oracle product; therefore, it is important to tailor OUM to suit project-specific profiles.
Tailoring refers to the creation of a project-specific work breakdown structure (WBS) coupled with guidance around the depth to which OUM activities and tasks should be
executed. Within OUM, most of this approach is specific to the task, Develop Baseline Project Workplan (WM.010).
This tailoring approach is applicable for projects of any size led by Oracle Consulting, clients, or partners.
Back to Top
OUM TAILORING PROCESS
The following diagram represents a high-level view of the OUM tailoring process. Each of the numbered tasks is described in more detail within this document.
1.1 Estimating Process
For projects led by Oracle Consulting, the estimating process typically occurs during the sales cycle. For client or partner-led projects, an alternative pre-planning process may be
used. From a project work planning perspective, the key outputs of the estimating or pre-planning process should include:
List of Assumptions
List of Activities by Phase
Effort by Phase / Activity / Role
Approximate Number of Iterations
2.0 Template Project Workplan Available?
The process of creating a Project Workplan is simplified by using a template as a starting point. An OUM Project Workplan is available with pre-tailoring capability for most
Implement views. Other views have example Project Workplans (MS Project) included that can be found in the Key Components section of the view. Consider using one of these as
a starting point for creating a project-specific Project Workplan after determining which best matches the project profile.
Alternately, you may have access to a Project Workplan based on another OUM project with characteristics similar to your project profile.
3.1 Create Project Workplan from OUM Method Pack Template
If a suitable Project Workplan template is available, make a copy of the template to use as the basis for your Project Workplan.
3.2 Create Project Workplan from Estimated Activities
When tailoring begins with an estimating or pre-planning process, the starting point for the creation of the Project Workplan is typically a list of activities and associated work effort.
For low-risk, low-complexity, short duration types of projects that do not begin with an estimating or pre-planning process, you should select the OUM activities that apply to your
project profile. Refer to supplemental guidance within OUM for a list of recommended tasks and activities applicable to specific project types.
4.0 Eliminate Activities That are Not Needed
If you are using a Project Workplan template as the basis for your Project Workplan, review the list of OUM activities within the template and remove any that are not needed.
Remember it is better to build-up than to tailor down. One way to decide which activities to include in your Project Workplan is to review the supplemental guidance, within OUM,
that is applicable to your project profile.
For projects led by Oracle Consulting, you will need to compare the list of activities derived from the estimating process with those in the Project Workplan template. Consider
deleting those activities from the Project Workplan which are not included in the estimate. Take note of all activity and task dependencies before deleting any activity.
For client or partner-led projects, the Project Workplan creation process may begin with an OUM Project Workplan template. In this situation the concept of build up rather than
tailor down needs to be deployed. In practice this means starting with a core set of activities or tasks and only adding additional activities or tasks when it is truly necessary.
5.0 Activity- or Task-Based Project?
Regardless of the starting point for the creation of the Project Workplan, at this step within the process, you should have a list of activities for your project. The next decision point is
to determine whether to plan and manage your project at an OUM task or activity level. The most common approach is the task level. Tasks generally last longer than one day and
have clearly defined work products. However, for some low-risk, low-complexity, short duration types of projects, it may be feasible to plan and manage the project at the activity
level.
To help make this determination, review the key work products guidance available from the Key Components section of the OUM views.
If you elect to plan and manage the project at an OUM activity level, then review each task within an activity and decide which work products the project team will generate at the
activity level. This can be accomplished using the Activities and Task list available from the Key Components section of the OUM views.
5.1 Build Up Tasks Within Each Activity
If you elect to plan and manage your project at the task level, then the next step is to add tasks to the required activities. OUM employs a concept of building up rather than
tailoring down. In terms of creating a Project Workplan, this essentially means including the minimum number of tasks required to meet the project objectives and quality criteria.
When determining which tasks to include in the Project Workplan, review the supplemental guidance, within OUM, that is applicable to the project profile. Pay particular attention to
the list of recommended and optional tasks. Recommended tasks should be included in your Project Workplan. Inclusion of optional tasks depends on the specifics of your project
profile.
If you used a Project Workplan template as a starting point for your Project Workplan, then the build-up process essentially involves deleting those tasks which are not required
from each activity of your Project Workplan.
If you used the list of activities from the estimating or pre-planning process as a starting point for your Project Workplan, then the build-up process involves adding those tasks
required to each activity of your Project Workplan.
5.2 Add Project-Specific WBS Activities/Tasks
The output of the estimating or pre-planning process may include additional project-specific WBS activities and tasks. These activities and tasks should be added to the Project
Workplan.
6.0 Perform Initial Iteration Planning
The next step is to consider iteration planning. Refer to Planning a Project Using the Oracle Unified Method (OUM) An Iterative and Incremental Approach.
7.0 Combine Activities / Tasks Where Appropriate
There are certain situations where it may be appropriate to combine tasks or activities. For example, a Project Workplan may include a contracted deliverable which includes the
output from two or more tasks, executed by the same project workgroup, in a relatively short amount of time.
Consider this example:
TE.005 Determine Testing Requirements
TE.010 Develop Testing Strategy
If the project in question includes a contracted deliverable called Testing Requirements & Strategy, then these two tasks could be combined into a single piece of work reflected on
the Project Workplan as a single task called, Define Testing Requirements & Strategy."
Refer to the applicable supplemental guidance and key work products within OUM.
8.0 Consider Execution Depth for Each Activity / Task
A task within OUM is defined as the lowest unit of work. Another way to think of a task is that it acts as a placeholder for a piece of work. One of the most critical considerations
when tailoring OUM for any given project is the depth or rigor to which tasks should be executed. Before deciding on the depth of task execution, the project manager needs to
understand the characteristics of the project and whether that project will be executed in an agile or disciplined manor (or somewhere in between).
Consider this example:
OUM task, RD.011 Develop Future Process Model, is scheduled to occur on Project A which is being conducted in an agile fashion. In this type of environment, the standard
Oracle business process flow diagrams are shown to the client and are manually annotated with marker pens in order to highlight any changes. The marked up diagrams are then
scanned and stored on the project server and act as the agreed definition of the future business process.
OUM task, RD.011 Develop Future Process Model, is scheduled to occur on Project B which is being conducted in a disciplined fashion. In this type of environment, the project
team consultants review the standard Oracle business process flow diagrams and then update the diagrams with known client specific changes. The business process flow
diagrams are then used in a client-facing workshop environment where the future process is agreed. Finally, the completed diagrams are electronically updated to reflect the
changes and published for approval.
As you can see from this example, while the same OUM task is being executed, the depth to which the task is executed is determined by the level of agility or discipline that is
applied to the project. For additional guidance, refer to the Flexible and Scalable section of OUMs Method Overview.
Once the project manager understands the depth of execution for each task, then the appropriate amount of work effort can be assigned to that task (or summary task) within the
Project Workplan.
9.0 Assign Resources and Durations to Activities / Tasks
The final step is to assign duration to the activities or tasks. Perform this step in conjunction with iteration planning.
Back to Top
CONCLUSION
The Oracle Unified Method (OUM) provides support for the entire Enterprise IT lifecycle, including the successful implementation of every Oracle product. It is very unlikely that any
given project will involve the implementation of every Oracle product; therefore, it is important to tailor OUM to suit project-specific profiles.
The starting point for a Project Workplan is the list of activities and associated work effort generated from the estimating or pre-planning process.
Use the OUM Project Workplan templates in conjunction with the list of activities derived from the estimating or pre-planning process.
Review the Supplemental Guides and Key Work Products.
Consider combining tasks, where appropriate.
Consider the depth to which tasks should be executed. Remember that the output of a task is not necessarily a physical work product.
If a task is not needed, remove it from the Project Workplan.
Tasks and work products should be scaled to suite project specific need.

Back to Top
OUM 6.2 From Business Process to Use Case
UNIFIED METHOD
INTRODUCTION
The purpose of this guidance is to help the reader discover how the process from specifying business processes, going to use case descriptions and resulting in the
implementation of services (in this example using BPEL) might look like in practice in the context of the Oracle Unified Method (OUM).
Two of the most frequently asked question about OUM are:
How do business processes relate to use cases?
What actually happens as you develop use cases through the phases of OUM?
The following content explores both these important and often misunderstood topics. It moves from business requirement to business processes to business use cases to
narrower types of use cases and illustrates how detail gets added along the way. Many important aspects of how SOA relates to OUM are also illustrated.
The case used is of moderate complexity. When specific features that are not covered in the case but for which it turns out at they need to be addresses as well, the case can be
extended to include them. An obvious example would be business rules.
After you have reviewed the "discovery" scenario below, It is recommended that you also review the Traceability of Requirements through the Inception, Elaboration, and
Construction Phase Model diagrams of OUM to understand the flow of Requirements through the various models provided by OUM. You will also want to reference the RA.024
Develop Use Case Details task guideline, work product template and sample use cases.
Back to Top
REQUIREMENTS DEFINITION AND REQUIREMENTS ANALYSIS
The Business Process
The following activity diagram documents a business process concerning the application of a parking permit by a resident of some municipality.
This is a true business process, as it only concerns business level actors like people, or organization units, and totally abstracts from any system supporting it. The whole
process could be manual, for all you know.
Transformation to Use Case
The same business flow can be documented as a use case description, typically of the scope enterprise. In this case, it also concerns a business use case, as it describes how
the resident communicates with Parking Services, which in this context is an organization. As a use case the same business process would look something like the following:
PRIMARY ACTOR Resident LEVEL
STAKEHOLDERS
Resident (wants to be able to park his car near his house)
Parking Services (wants to make sure that permits are only granted to eligible residents, and that
sufficient parking lots are available)
Neighbor (does not want too many cars in the street)
GOAL
A Resident Applies for a Parking Permit, and gets rejected with justification or receives a Parking Permit
(which could be after having been put on a waiting list).
1. Resident applies for a parking permit
2. Parking Services validates if the Resident is eligible for a Parking Permit
3. Parking Services verifies that sufficient parking lots are available
4. Parking Services creates the Parking Permit
5. Parking Services notifies the Resident that the permit is ready for collection
6. Resident collects the Parking Permit
Extensions
2a Resident is not eligible
2a1 Notify the Resident of the rejection with justification
2a2 scenario ends
3a No parking lots available
3a1 Parking Services notifies the Resident that the Application has been put on the waiting
list.
3a2 The Resident notifies Parking Services of its decision to accept the waiting list.
3a3 Return to step 4
3a2a application withdrawn
3a2a1 Parking Services removes the application from the waiting list
3a2a2 scenario ends
TRIGGERS A Resident applies for a Parking Permit
PRECONDITIONS The resident owns a car and does not have a parking permit for that location.
MINIMAL SUCCESS
GUARANTEE
It should be clear what the state is of the Parking Permit Application.
SUCCESS
GUARANTEE
The resident has obtained his parking permit or has obtained a proper justification for rejection of
the request.
BUSINESS RULES
When the resident does not accept the waiting list explicitly he is assumed to have done so,
beginning two working days before the Parking Permit has been created.
The Resident is obliged to pay the fee for at least the first quarter, unless the application has been
withdrawn at least two working days before printing.
The Resident is eligible for a parking permit only when he owns the concerning vehicle, when he is
enlisted in the Electoral Register, and when he actually is a Resident of the municipality.
P.M. the rules that specify how the waiting list is being processed
SUPPLEMENTARY
REQUIREMENTS
All notifications from Parking Services to other parties must allow for multi-channel handling
(written in letter, email, SMS, messages on a Resident Portal).
During requirements capturing with use cases, initially it might suffice to document only the stakeholders, goal and main success scenario together with some business rules.
This is where the Business Requirements process normally is limited to. The example use case has been worked out to a greater level of detail, which would typically be done in
the Requirements Analysis process.
Although there is a thin line between Business Requirements and Requirements Analysis, it is good to recognize the difference as doing so offers better opportunities to develop
use cases in iterations.
How Use Cases Add Value
Compared for example with the situation where only a business process diagram is available, adding use cases adds value in that a (detailed) use case description provides the
opportunity to specify aspects of the business process that goes beyond that of what you can express with only a diagram.
One of those aspects is stakeholders that are not directly involved in the process. In some cases identifying such stakeholders might give reason to extend the scope of the use
case, like identifying the stakeholder Neighbor might have lead to considering to include in the business process a step that notifies them as well.
Other aspects that the diagram does not cover are the goals, the triggers, preconditions, and postconditions of the use case. All of them helping to validate the use case and
some of them providing useful input for the next step in which the use case is going to be analyzed.
An advantage of putting it down in writing that may not be so clear at first sight is that by forcing yourself to express the business process in words might help you to discover
flaws and omissions in the original process.
The value of putting effort in converting a business process into a use case description is not always easy to determine. It depends on many factors like the ability of people
reviewing the business process to identify flaws in it, or how easy it is to correct errors later in the process. Probably the best advice would be: when in doubt, dont hesitate and
just do it. In case of the example the business process has been converted into a use case description in less than half an hour. The total process took much more time, but that
was because the business process model needed to be corrected, because of errors found while describing the use case.
Drilling Down
When looking at the business process you might notice that each activity actually is a use case of its own, most of them being at the level of user goal use cases (which is a use
case for which the user can execute it in one session and walk away happily after that). The only exception might be the Validate Parking Permit use case, that for that reason
has been drilled down further to investigate.
The result is the following Validate Parking Permit Application business process model:
As illustrated above, a couple of other organizations are involved in the validation, possibly making it a lengthy process, and initially suggesting that the upper level activity indeed
is not a user goal level use case. But what if the other organizations have automated services available that respond within minutes? What this shows is that the level of a use
case in some cases depends on the options for implementing it. This certainly is true in case of a Service Oriented Architecture.
For the following it will be assumed that such services do exist, making the Validate Parking Permit Application activity indeed an activity at the level of user goal use cases. In
the context of the Oracle Unified Method this automatically classifies the diagram above part of the use case details rather than a business process.
However, the question if it is a business process model, or just use case details, is just an academic one. What is important is that you have a clear idea of when a business
process needs to be further detailed. It is advisable to drill them down to the level of user goals, for the following reasons:
User goals provide the most effective level to start from and create system use cases from business use cases to describe what the system should do (*). For example, it
is at the level of user-goal business use cases that you will decide whether a goal will be kept manual or supported by a system.
You typically either implement a user goal level use case or you do not implement it at all, making the optimal unit to estimate and trace requirements from there.
(*) Business use cases have the business as subject and are written by business analysts to document business processes. System use cases have the system as subject and
are written by system developers to document how actors communicate with the system to achieve their goals.
Service Discovery
Assuming that the requirements so far point to a solution using a Service Oriented Architecture, it is important to discover the services in the requirements. This is not only
important for creating the application architecture but also provides important input to the estimating process.
One of the reasons to do business process modeling in the first place is that it relates very well to a Service Oriented Architecture, which makes implementation of the business
process itself possible. You can imagine that the Parking Permit process is implemented as a longer running process that may take weeks to complete. But that will not be the
only service involved, as the Parking Permit process itself needs other services to complete.
There are several approaches to discover services. One of them being by reviewing a business process and identify where the transitions are from an activity of one actor
(swimlane) to that of another. In general this indicates a candidate service. In the example the candidate services are in the activities:
Apply for Parking Permit
Notify Resident of Waiting List
Notify Parking Service of decision
Notify Resident Permit Ready for Collection
Collect Parking Permit
Verify Vehicle Ownership
Verify Electoral Register
Verify Residence
The Apply for Parking Permit obviously is the starting point for the Parking Permit process itself. You can imagine that the web site of the municipality provides some form that
the resident can fill out and on submit calls the Parking Permit process.
The Notify Resident of Rejection, Notify Resident of Waiting List and Notify Resident Permit Ready for Collection (from Parking Services to the Resident) are candidate services
whereby the Parking Service process needs to call out some provider that handles multi-channel notifications to third parties. Whether this will be one service that can handle
some generic notification, or three different services that each handle a specific notification type, or any other combination, is a design decision and at this stage is yet to be
determined.
The Notify Parking Services of Decision points to yet another candidate service that the Resident can call to get the application removed from the waiting list.
The Verify Vehicle Ownership, Verify Electoral Register and Verify Residence already have been indicated as existing services. However, if they were not, creating them would
have been outside the scope of the Parking Permit process, as those services would then have to be created by third parties not involved in the project.
From the last example above, we can conclude that transitions to activities within the scope of secondary actors that are not within the scope of the project, only indicate calls to
external services.
Any use case that has a user interface associated with it, might be detailed with a conceptual screen layout. Note that a conceptual screen layout is not a design, as it does not
specify an actual screen layout, let alone aspects like styling. Its main purpose is to specify which data should be shown, and should be validated during the review.
For example the use case Apply For Parking Permit could be detailed with a screen layout as follows:
Prompt Attribute
Social Security Number [socialSecurityNumber]
Name [firstName] [lastName]
Address [house number] [street] [city] ([state] or [province]) [postal code] [country]
License Plate Number licenseplateNumber
Comments comments
Legend: [ ] = display only, __ = input fields.
Other use cases that may require some conceptual layout are the following:
Notify Resident of Rejection (mail/email/SMS)
Notify Resident of Waiting List (mail/email/SMS)
Notify Parking Services of Decision (mail, screen)
Notify Resident Permit Ready for Collection (mail/email/SMS)
When analyzing the Validate Parking Permit Application use case, you may find that the Parking Services wants to be able to override the decision that comes out of the
verification, for example by blocking a parking permit for someone that appears to hire a garage box (which none of the external organizations would note). In that case that use
case also would require a conceptual screen layout.
Back to Top
ANALYSIS
Analysis Model
What kind of artifacts should be created during the Analysis process depends on the nature of the use cases and the architecture that is going to be used to implement them. The
most apparent candidates for adding detail are activity or sequence diagrams, class diagrams and (where useful) collaboration diagrams (used to describe how various
components work together). For SOA projects also message descriptions and message transformations are obvious candidates.
For services that support more than one operation you also need to specify the names of each individual operation, as well as the types of their input and output messages.
Depending on its granularity, a service supports a summary use case (like the Parking Permit process), a user goal use case (like Apply for Parking Permit) or a subfunction use
case. No example of the latter has been included, but you can imagine that for each separate channel (letter, email, SMS) a subfunction use case could be created that
describes a generic notification services that can be used to send all kind of notifications to third parties.
Unless parallel development is be done where other (parts of the) system(s) depend on a service to be build, at this point there is not much value in specifying the exact WSDL of
the service. For any external service you use, you need to have at least the WSDL location if not the WSDL itself.
Activity Diagrams
When there is a flow involved, it might be useful to create an activity diagram. An obvious example would be a use case for a service that will be implemented as a BPEL
process. As already noted, the activity diagram for the Validate Parking Application is an example of that. But use cases that involve a user interface with a complex screen flow,
also are good candidates.
Class Diagrams
When there is data involved, a class diagram seems to be the obvious choice to document that. Many people doing SOA projects never seem to make a class diagram. Realize
though that class diagrams add as much value to SOA projects as they for example do to pure Java/XML projects, as messages are about handling data as well. Having class
diagrams available can add great value to optimizing the process of defining message formats and transformations.
When analyzing the Parking Permit use case the following classes can be recognized: Resident, Parking Permit Application, and Parking Permit. A distinction has been made
between Parking Permit Application and Parking Permit, as not all applications will result in a permit, and the application follows a process with statuses that do not apply to the
permit itself and vise verse.
Not very explicit in the description but obviously needed if you think about it, is a notion of an Area. You will need this in the process of determining if there are sufficient parking
lots available. You might argue that the reason for not having discovered this earlier is because the way the waiting list is being processed has not been worked out to the proper
level of detail.
The class diagram for the Parking Permit use case could look as in the following figure:
Message Descriptions
What format to use for a message descriptions probably foremost depends on who needs to validate it. Some people will prefer more logical descriptions in Word, while more
technical oriented people probably have no problems with XSDs.
Mind that to be able to create XSDs that translate 1:1 to an implementation, it is important to understand the technique of implementing messaging. For example, initially one
XSD has been created for the Resident and one for the Parking Permit Application, only to discover that it was more practical to create one XSD containing both and use that as
the format for the message going from the resident to the Parking Process service. If you pay more attention to detailing the Apply for ParkingPermit use case, you probably
would find that out up front.
For the sake of example the response message has been kept simple by returning a string stating that the application has been received successfully. The description of the
request message looks as follows:

<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://xmlns.oracle.com/ParkingPermitProcess"

targetNamespace="http://xmlns.oracle.com/ParkingPermitProcess"
elementFormDefault="qualified">
<xsd:element name="parkingPermitApplication">
<xsd:annotation>
<xsd:documentation>
Message format to be used to call the Apply for
Parking Permit service.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="applicationDate" type="xsd:date"/>
<xsd:element name="areaCode" type="xsd:string"/>
<xsd:element name="licensePlateNumber"
type="xsd:string"/>
<xsd:element name="status" type="xsd:string"/>
<xsd:element name="comments" type="xsd:string"/>
<xsd:element name="resident" type="resident"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="resident">
<xsd:sequence>
<xsd:element name="socialSecurityNumber"
type="xsd:string"/>
<xsd:element name="firstName" type="xsd:string"/>
<xsd:element name="lastName" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="houseNumber" type="xsd:string"/>
<xsd:element name="postalCode" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="email" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

Other message descriptions that need to be made are the request and response messages for the Verify Ownership, Verify Electoral Registers and Verify Residence use cases.
You should keep the message descriptions separate from the use case descriptions, to support reuse. Refer to them from the use case descriptions instead.
Message Transformations
How messages are transformed from one format to the other depends on the situation. For example, in case of BPEL, transformations can be done by doing one or more assign
operations or by using an XSLT transformation, which in both cases may involve complex XPath queries or regular expressions.
For this reason transformations probably are best described in text, as has been done in the following example:
Parking Permit Application Ownership Validation
Source/Transformation Target
SocialSecurityNumber SocialSecurityNumber
LicensePlateNumber LicensePlateNumber
The example is trivial in that transformation consists of using a subset of the fields of the source and mapping those 1:1 on fields of the target message.
You can image than in practice often more complex transformations need to be done, for example in case of n:m mappings. In practice using a two-column format often suffices,
where the (left) Source/Transformation column specifies which source fields are involved and any logic that needs to be applied to that, and where the (right) Target column
specifies what the (single) target field is.
As with message formats you should keep the message transformations separate from the use case descriptions to support reuse.
Where to Stop
Once the analysis model has been worked out to a sufficient level of detail, you are ready for the design. What sufficient means in this context, depends on many factors, the
most important ones being the following:
Nature of Engagement
In some cases a formal process needs to be followed that requires every change of the specifications to be approved up-front. On the other side of the spectrum there is the agile
approach by which part of the (detailed) requirements are captured while validating iterations of a working program.
Skills and Habits of Developers
Developers are most comfortable with what they are used used to working with. However, you should be aware that when every developer involved needs to get used to one
broadly accepted way of creating specifications almost always outclasses the situation in which developers need to get used to as many different styles as there are other
developers. Not to mention the effort that needs to be put into the validation process involved with that.
For most projects that involve requirements analysis, class models are very useful to developers, even in the case of BPEL development.
Application and Technical Architecture
The development of data-oriented systems that depend on a well-structured database can highly benefit from creating a detailed class diagram. In case of use cases that involve
a user interface, activity diagrams normally only add value when there is a complex dialog involved.
For SOA projects that primarily deal with messaging it probably suffices to detail classes to the level that all attributes and their types are known. Message formats and
transformations often need to be worked out in detail. In general, activity or sequence diagrams add great value to business processes and services, as they support a more
effective implementation.
Other architectures, for example identity management/security, on their turn require yet other details.
A final remark that needs to be made at this point is that use case analysis should not be confused for a technical design. Although some people state that class models, and
activity diagrams that describe system-internal behavior, are technical they actually only capture detailed requirements or validate higher-level requirements from a different
angle.
Back to Top
DESIGN
Project Review
The design involves mapping the analysis to artifacts that actually are implemented. Assuming that the Technical Architecture dictates a Service Oriented Architecture that uses
BPEL to implement services and service orchestration, the design would at least include the following:
XSDs
WSDLs
A diagram design of the BPEL processes to implement
A database design (that supports retrieval of resident information and storage and retrieval of parking permits and their applications)
An example of an XSD already has been provided. Including WSDLs in this case would not add much value, and a database design is too obvious. A design of the BPEL
process to implement, in this case sufficiently has been provided by the activity diagrams already created. This probably will often be the case.
To show how the implementation might look like the following two BPEL process diagrams are included.
A part of the ParkingPermitProcess looks as follows:
Not surprisingly the initial business process diagram and the implementing BPEL process flow look very similar.
The same holds true for the user goal level Validate Parking Permit use case that looks as in the following picture (that actually zooms in on the ValidateParkingPermitApplication
step of the previous picture):
In practice, you can imagine a human workflow step to be included that supports manual intervention of the outcome by Parking Services.
Back to Top
OUM 6.2 Requirements Traceability
REQUIREMENTS TRACEABILITY IN OUM
INTRODUCTION
The purpose of this guidance is to show the transition of Business Requirements into Business Models and Use Cases to provide an understanding of the traceability of
Requirements throughout the lifecycle of an OUM Project.
You should use the diagrams below in conjunction with the OUM Phase Overview Diagrams for Inception, Elaboration and Construction, to drill down into the additional tasks that
support these diagrams in detail.
You should review the From Business Process to Use Case with OUM for a specific example of how the transition of requirements works in a specific scenario.
Back to Top
INCEPTION
The following diagram shows the flow of requirements into OUM Inception.
Back to Top
ELABORATION
The following diagram shows the flow of requirements into the Elaboration phase, and into the design models.

Back to Top
CONSTRUCTION
The following diagram shows the flow of requirements into the Construction phase. Detail requirements gathered through Use Case Details can be used to prepare test scenarios,
test cases, and User Guide.

Back to Top
OUM 6.2 Project Roles
Method Navigation
A
Ambassador User (KEY)
The ambassador user participates in workshops. This project role is empowered by the project sponsor to refine and prioritize requirements. The ambassador user provides information
about their business objectives and the ways in which their units operate and responds to events in order to achieve those objectives. The ambassador user describes the problems they
face and requirements for the computer system. This project role writes the initial user guide.
Application/Product Specialist (APS)
The application/product specialist provides knowledge and guidance regarding application and other product functionality and implementation strategies. This project role also supports
and provides interpretation for tools, templates and methods.
Back to Top
B
Bid Manager (BM)
The bid manager prepares the bid, negotiation, and award. This project role assists in the hand over of materials and information accumulated during the bid to the project manager at the
start of the project.
Business Analyst (BA)
The business analyst should be familiar with the business area that the system covers and the terminology and practices.
The business analyst performs many activities that define the scope of the project. They examine the client's business and define what the system should do. They obtain information from
existing documentation, when available. The business analyst identifies interviewees who might be representative client staff, management, and technical support staff. The business
analyst obtains information by conducting interviews, working sessions, and site visits. These analysis activities determine the technical, interfacing, and operational requirements and
constraints.
In most cases, the business analyst is responsible for modeling the client's existing business processes and capturing relevant process data.
Business Line Manager (BLM)
The business line manager participates in interviews and working sessions providing information about business objectives and ways in which the units operate and respond to events in
order to achieve those objectives. The business line manager hosts site visits with staff in order to collect information. Additionally, this project role is responsible for allocating staff time
to provide detailed information about the day-to-day business. Also, this project role describes problems the business unit faces and requirements for the computer system.The business
line manager should review the content of the analysis documentation to make sure it accurately describes the business and requirements. The business line manager role should be filled
by someone who will manage one of the business units that uses the system.
Back to Top
C
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.
Change Management Specialist (CMS)
The change management specialist provides the client with expertise in the human and organizational facets of change management. Change management specialists support the
Organizational Change Management (OCM) process by identifying and mitigating risks, generating change momentum, fostering effective communication, and supporting end-user
acceptance. The change management specialist works directly with executives to gain their commitment and put in place a project governance model.
Depending on your project (for example, large, complex, etc.), various change management specialists focused in specific areas may be involved (for example, communication, leadership,
human performance, organization development, and risk assessment).
In many cases, the change management specialist role may be fulfilled by a consultant with advanced facilitation skills and the ability to relate and effectively communicate with senior
executives.
Client Data Administrator (CDA)
The client data administrator ensures that data structures and data quality meet the needs of the business in the context of the Information Systems Strategy. The data administrator also
evaluates team findings regarding legacy data quality and ensures that corrective action is taken where legacy data is inadequate.
Client Executive (CE)
The client executive participates in the strategic decisions regarding implementation and project strategy and defines business performance expectations and metrics. The client executive
also appoints steering committee members and is involved in measurement of business results.
Client Project Manager (CPM)
The client project manager is responsible for the daily management of the client's contractual commitments to the project. This project role must understand the client's business
objectives for the project to form the basis for resolving problems, conflicts of interest, and making compromises.The client project manager obtains physical resources such as space
accommodation, office equipment, computer equipment, and materials. The client project manager assists in the availability of users and endeavors to gain user commitment. Additionally,
this project role assists in the allocation of client time to the project. The client project manager introduces the consulting staff to the other client staff. This project role monitors the
project's performance, progress against milestones, appropriateness of work, quality of work, and seeks to resolve any problems with work or relationships between the development and
business staff. The client project manager assists in obtaining user review and sign off of work products. This role usually performs intermediate and phase-end acceptance.
Client Project Sponsor (CPS)
The client project sponsor controls the budget and finances the project. This project role is usually a member of senior management. On large, cross-functional projects the project
sponsor may be a board member. This project role must have a clear understanding of the project objectives, particularly concerning delivery of the business benefits. The project
sponsor empowers the key users to refine and prioritize requirements. The project sponsor is the ultimate arbiter on conflicting business requirements and scope changes. The project
sponsor makes sure the project is delivered on time and within budget. The project sponsor is responsible for ensuring other members of the management share commitment to the
project. This project role may provide the resources, particularly staff time, required to make the project a success. The project sponsor usually performs the final approval on the
recommendation of the verification coordinator, internal auditor and data administrator.
Client Staff Member (CSM)
The client staff member reports directly to either the project manager or client project manager.This project role may be responsible for technical support of the client's systems. The client
staff member may provide information about existing systems with which the new system is to interface or replace. This project role provides information about any IS standards with which
the project must comply, supports the business' software systems, and takes over support of the system during production. Finally, a client staff member may participate in training
programs for the system initially as consumers and later, possibly as providers.
Consulting Business Manager (CBM)
The consulting business manager is the practice manager in the consultant's organization responsible for the successful execution of the project. This role manages the practice which
makes the consulting staff available and coordinates resources needed by the project with other practices. The consulting business manager represents the consulting organization in the
contractual agreement with the client and resolves business issues with the project sponsor. The consulting business manager participates in project reviews with the client as well as
internal practice reviews of project progress.
Back to Top
D
Database Administrator (DBA)
The database administrator installs and configures database software for the development environment; creates the various databases required during the development lifecycle (for
example, the data dictionary, unit testing, system testing, training); and maintains database access controls. Additionally, this project role provides consultation on performance; monitors
growth and fragmentation of the development database; and provides database backup and recovery.
Depending on your project (for example, large, complex, etc.), various database administrators focused in specific areas may be involved (for example, development database
administrator and production database administrator).
During system development, the development database administrator works closely with the system administrator. This person is responsible for installing and configuring database
software for the development environment, creating the various databases required during the development lifecycle (for example, the data dictionary, unit testing, system testing, training),
and for maintaining database access controls. This role also provides consultation on performance, and is responsible for monitoring growth and fragmentation of the development
database, and for ensuring database backup and recovery. The development database administrator should involve the production database administrator as soon as this person has
been identified, and ensure the transfer of the practical skills needed to manage the production database. This does not replace the need for DBA training and certification, but provides
specific guidance on monitoring of the new system during transition into production.
Once the system is ready for production, the production database administrator installs and configures the production database and maintains database access controls. After the system
"go live" this person provides consultation on performance, monitors growth and fragmentation of the production database, and ensures database backup and recovery.
Database Designer (DD)
The database designer produces the Logical and Physical Database Designs. This project role reviews the module designs to provide efficient access to the database.The database
designer must understand how to translate application logic into a System Data Model and have a thorough understanding of the System Data Model. The database designer is
responsible for producing the System Data Model, the Logical Database Design, and the Physical Database Design.The database designer reviews the application design to check
database access efficiency. Additionally, an understanding of the technical architecture and functionality of the system is required so that trade-offs in the design can be made where
different functions place conflicting requirements on the database. The database designer may make design suggestions in order to mitigate conflicts between the application design and
the technical requirements.
Designer (DES)
The designer defines and maintains the responsibilities, attributes, relationships and special requirements of the classes making sure that each class fulfills its requirements. The designer
is also responsible for the analysis of packages within which the classes are maintained. There may be several designers with varying areas of expertise depending on the size and needs
of the project (for example, object designer, SOA designer), each of which may be responsible for certain classes and packages assigned to them.
Depending on your project (for example, large, complex, etc.), various Designers focused in specific areas may be involved (for example, object designer, module designer, user interface
designer).
If your project involves Object Oriented (OO) design, you may require an object designer. The object designer is responsible for translating a subsystem analysis object model into a
subsystem design object model. The object designer takes the technical architecture and technical requirements and fashions a design object model that meets these requirements.
The module designer produces the application and module designs. This person communicates closely with the database designer to make sure the database design meets the data
requirements of the module functionality and module access data efficiently. The module designer also produces module and link test plans. During the various testing activities and the
Production phase, this person diagnoses faults and determines corrections.The module designer understands the requirements from the business analysis and how to meet these
requirements using the technical and system architectures and System Data Model. The module designer is responsible for production of the end-user layer, query, and report module
designs. The module designer also designs the version control module for the data access component of the data warehouse and technical specifications for data, governor limits, and
user project role access. The module designer communicates closely with the database designer to make sure the database design meets the data requirements of the module
functionality and that the modules access data efficiently. The module designer also produces module and link test plans. During the various testing activities and the production phase,
this person diagnoses faults and determines corrections. The module designer must understand the data access requirements and how to meet these requirements using the technical
and data warehouse architectures and data warehouse, data mart, and metadata data models.The module designer understands both the application model and the legacy system
requirements. The module designer may be responsible for creating a seamless architecture for the transfer of data to and from the legacy system. The module designer may translate a
subsystem analysis object model into a subsystem design object model. The module designer takes the technical architecture and technical requirements and fashions a design object
model.
User-interface designers are responsible for visually shaping the user interface. They are responsible for developing the user interface prototype for the use cases assigned to them.
Developer (DV)
The developer understands the requirements from the business analysis and how to meet these requirements using the Technical Architecture and Data Model.The developer produces
application and module designs and generation of modules. This project role interfaces closely with the lead system developer to make sure the database design meets the data
requirements of the module functionality and module access data efficiently. The developer may create the object structure, the database object logic, and the test scripts for the
database. The developer produces working code that meets the module specifications and diagnoses and corrects faults found by tests. The programmer must have a thorough
understanding of the specifications for the modules to produce the appropriate code.The developer also produces partition integration test plans and performs testing of partitions and
system. During the various testing activities and the production phase, this project role diagnoses faults and determines corrections. Developers produce the initial versions of online help
text, user reference, and technical reference documents. There may be several developers with varying areas of expertise depending on the size and needs of the project, for example, a
J2EE developer or a SOA developer.
Depending on your project (for example, large, complex, etc.), various Developers focused in specific areas may be involved (for example, Lead Developer, Lead System Developer, J2EE
Developer).
A lead application developer may be assigned to coordinate the development efforts across functional areas of the application. The lead application developer is responsible for examining
the client's business and defining what the system should do. This person obtains information by participating in workshops and may also obtain information from existing documentation.
The lead application developer must understand the business objectives and requirements and documents the analysis and creates the high-level business models. The lead application
developer also determines the technical, interfacing and operational requirements and constraints and conducts reviews of their findings with client management and their staff.It is
preferable that an lead application developer already be familiar with the business area that the system is to cover and generally understands its terminology and practices. The lead
application developer leads the application development.
The lead system developer is a cross-team designation, responsible for defining the system and technical architectures, including the major software components of the system and their
interfaces, and the hardware configuration and software foundation. The lead system developer is generally the senior or lead technical designer on the project. The lead system developer
must understand the business and technical requirements for the system. The lead system developer is responsible for producing the Logical and Physical Database Designs. This
person also reviews the module designs to ensure efficient access to the database. The lead system developer must have a thorough understanding of the Data Model and the technical
architecture and functionality of the system. The lead system developer makes tradeoffs in the design where different functions place conflicting requirements on the database. The lead
system developer is responsible for the production and maintenance of the Capacity Plan and for reviewing all aspects of the design to ensure that it performs within any capacity
constraints. This person is also responsible for performing any benchmarking exercises required to measure the performance of hardware or software.

OUM 6.2 Full Method View

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OUM 6.2 Full Method View

Uploaded by

Copyright:

Available Formats

OUM 6.

2Full Method View

UNIFIED METHOD (OUM) OVERVIEW

Application Development Framework (ADF) or some kind of

SOA Suite or the Oracle

Application Development Framework (ADF).

JHeadstart User Guide.

that can be used on top of ADF

) using Oracle JDeveloper

to quickly generate your prototype pages.

You might also like