OUM 6.2 Full Method View
OUM 6.2 Full Method View
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 [email protected].
OUM Approach
OUM is built on five main principles derived from the Unified Process, the Dynamic Systems Development Method (DSDM), and Oracle's legacy methods. Those are:
Iterative and Incremental
Business Process and Use Case-Driven
Architecture-Centric
Flexible and Scalable
Risk-Focused
For further reading on the Dynamic Systems Development Method, see DSDM: Business Focused Development.
Iterative and Incremental
OUM, like the Unified Process (UP) from which it has been derived, employs an iterative and incremental approach to implementing software systems. In the Unified
Process, and therefore in OUM, the result of an iteration is an increment. It is important to note that the OUM definition of an increment, while consistent with UP, differs
from the definition used in DSDM. For further reading on iterations and increments, see The Unified Software Development Process.
In OUM, the terms iteration and increment are defined in a way that is consistent with these concepts. An increment is the difference between the release of one iteration
and the release of the next iteration. An iteration is a distinct set of activities conducted according to a devoted (iteration) plan and evaluation criteria that results in a
release, either internal or external.
Rather than breaking the software implementation process into steps such as requirements, analysis, design, implement, and test; the OUM Implement focus area breaks
the process into major milestones called the Lifecycle milestones. These milestones were defined by Barry Boehm and initially published in the article "Anchoring the
Software Process". The milestones occur at the phase boundaries;and serve to anchor the software implementation process. For further reading on milestones, see
"Anchoring the Software Process."
Each OUM Implement phase may also be broken down into several iterations. These iterations represent the minor milestones of the project. OUM suggests nominal
iteration counts for each phase, but the project team must develop the actual iteration plan based upon the project's characteristics. The total number of iterations in a
project may range from as few as 4 to more than 12, but is generally in the range of 4 to 10.
Remember that Parkinsons Law states that Work grows to fill available time. Therefore, OUM recommends planning iterations to be 2 to 6 weeks in length, with a bias
toward shorter lengths. The optimum length for a given iteration is based on the ability of the project team to segment or partition the work. This is normally a factor of the
solution being implemented and the structure of the project team. Project teams less experienced with an iterative approach tend to be biased toward longer iterations
because they doubt their ability to deliver value in shorter periods. This tendency should be resisted. The value of an iterative approach is to focus the project team on
specific objectives and addressing the most important risks within each iteration. As such, iterations should almost never exceed 7 or 8 weeks and typically shorter is
better.
An iteration can be thought of as a mini-project that runs through a group of tasks and activities. These activities perform a complete requirements-analysis-design-
implementation-test cycle to produce an incremental improvement to the project's active outputs that is, an increment. Each iteration also includes planning, at the front,
and preparation for release, at the end.
As illustrated in the OUM Implement overview diagram, early iterations emphasize requirements-analysis-design. These may also include implementation-test activities
(of a prototype, for example). In the Inception and Elaboration phases an iteration is most likely to result in an incremental improvement to models, documentation, and
prototypes. Later iterations have a greater emphasis on implementation and test, but will also likely include some refinement of the requirements-analysis-design outputs.
Therefore, during the Construction phase, an iteration will more likely result in an internal release of software.
OUMs iterative and incremental approach means that projects will be managed somewhat differently. OUM proposes controlled iterations, meaning that the content
and objectives of each iteration are planned early in the project and that the plan is adhered to throughout the project. The project team determines the content of the
iterations by identifying project risks and addressing the highest priority risks in the early iterations.
OUM provides extensive guidance related to managing such projects as part of the Manage focus area. Generally speaking, however, at the beginning of an OUM project,
a high-level Project Workplan is created. This workplan documents the phases, iterations, and other significant milestones of the project. The project manager uses the
high-level plan as a framework for planning successive iterations that will each result in an increment of work. Just prior to the beginning of each iteration, the project
manager develops the detailed iteration plan that will be used to manage that iteration.
Typically, each iteration is related to one or more software components and also addresses the most significant risks. The components can be defined by business
process, use case, or other groupings related to the software being implemented. During the iteration, each task and component is completed to the level agreed to at the
start of the iteration. Project teams may choose to implement component by component, to develop parts of the requirements in one iteration and complete them in
another, or to use a mixed approach. Completed components are continuously integrated into systems and subsystems through the iterations.
Rapid development techniques such as workshops and prototyping are frequently employed. User involvement is encouraged early in the process and throughout the
project. Requirements are not frozen, but rather changes are handled through the prioritized requirements (MoSCoW) list developed early in the process. As with other
Oracle method approaches, requirement changes that results in changes to the overall scope, or that fall outside of the project scope, are addressed by the normal
change control process that includes client sign-off.
Finally, it is important to note that an iterative approach does not imply that requirements are out of control or are in a state of flux. It has been shown time and again, that
properly planned and executed iterations allow for the most effective control of the changing requirements that are an inevitable, yet important part of all but the very
simplest software implementation projects.
Business Process and Use Case-Driven
Business processes and use cases are used as the primary artifacts for establishing the desired behavior of the system and for communicating this behavior among the
stakeholders.
OUM projects are able to document requirements through business process models, through use cases, and through written supplemental and quality of service
requirements. OUM guidance helps implementers to understand where each technique is appropriate and how they fit together.
Business processes modeling helps stakeholders and implementers to understand the business processes of an organization, and look at the business requirements that
are addressed by a particular business process.To complement business process models, use case models and use cases;may be used to:
Provide a consistent mechanism to link system requirements to design and test tasks
Bridge the gap between business modeling, business processes, and software system functionality
Provide a consistent thread through OUM use cases help amplify and consolidate the many other benefits of the method
Identify implicit or unstated requirements
Manage traceability of requirements through testing
Often business process models for predefined solutions exist and contain some form or description of how the user interacts with the system or how a system interacts
with another system. Where these business process models already exist, they should be reviewed as a means of gathering business requirements. The need for
additional use case modeling would depend on how well the business process models have captured the requirements of the business. Use cases become particularly
important where there is a significant gap between the functionality required by the business and the functionality provided by the predefined solution or software product
that is being employed. OUM proposes that implementers develop only the set of models and artifacts required to understand and document requirements and trace
those requirements through the implementation lifecycle.
As the project progresses and where the need to develop use cases arises, the use cases are analyzed and the system is designed and implemented to meet the
requirements captured in the use cases. The implemented components are tested to verify that they provide the business benefit described by the use cases. All of the
models (Use Case Model, Analysis Model, Design Model, Architectural Implementation, and Performance Test Transaction Models) are related to each other through
trace dependencies. Use cases are prioritized to:
Define the architecture before committing too much resource
First deliver the components with the highest value to the user
Architecture-Centric
In the context of the software lifecycle, architecture-centric means that the systems architecture is used as a primary artifact for conceptualizing, constructing, managing
and evolving the system that is being implemented.
Architecture refers to the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the
system is composed, together with their behavior as specified in the collaboration among those elements, the composition of these structural and behavioral elements
into progressively larger subsystems, and the architectural style that guides this organization.
The architecture is the collection of models that describe the system. It contains the most significant static and dynamic aspects, and an executable architecture is the
product of successive refinements. This is usually accomplished in the form of a models and prototypes, and is developed before full-scale development starts. It contains
the organization of the software system to build with structural elements and interfaces, and their behavior.
OUM is architecture-centric from the beginning of the project. An architectural baseline is defined in the initial phases and expanded in the subsequent phases to produce
high quality software systems in a cost effective way. The architectural baseline provides an infrastructure, often a framework that supports continuously adding or
replacing components through the iterations to minimize the effect on the rest of the application. For further reading on architecture-centric, see The Unified Software
Development Process.
Flexible and Scalable
Traditionally, projects have been focused on addressing the contents of a requirements document or rigorously conforming to an existing set of artifacts. Often, especially
where iterative and incremental techniques have not been employed, these requirements may be inaccurate, the previous deliverables may be flawed, or the business
needs may have changed since the start of the project. Fitness for business purpose, derived from the Dynamic Systems Development Method (DSDM) framework,
refers to the focus of delivering necessary functionality within a required timebox. The solution can be more rigorously engineered later, if such an approach is
acceptable. Our collective experience shows that applying fit-for-purpose criteria, rather than tight adherence to requirements specifications, results in an information
system that more closely aligns to the needs of the business.
In OUM, this principle is extended to refer to the execution of the method processes themselves. Project managers and practitioners are encouraged to scale OUM to be
fit-for-purpose for a given situation. It is rarely appropriate to execute every activity within OUM. OUM provides guidance for determining the core set of activities to be
executed, the level of detail targeted in those activities and their associated tasks, and the frequency and type of end user deliverables. The Project Workplan should be
developed from this core. The plan should then be scaled up, rather than tailored down, to the level of discipline appropriate to the identified risks and requirements. Even
at the task level, models and other outputs should be completed only to the level of detail required for them to be fit-for-purpose within the current iteration or, at the
project level, to suit the business needs of the enterprise and to align with the contractual obligations that govern the project.
OUM provides well defined templates for many of its tasks. Use of these templates is optional as determined by the context of the project. Task outputs can easily be a
model in a repository, a prototype, a checklist, a set of application code, or, in situations where a high degree of agility is necessary, simply the tacit knowledge contained
in the brain of an analyst or practitioner. For further reading on agility, see Balancing Agility and Discipline: A Guide for the Perplexed.
Risk-Focused
A key focus of each iteration in OUM is to attack and reduce the most significant project risks. This helps the project team address the most critical risks as early as
possible in the project lifecycle.
Why Use OUM?
More Focused Effort
OUM enables projects to clearly define business scope as well as the need to create architectural models of the enterprise. This planning results in tighter scope control,
more accurate business understanding, and a firm foundation to align with client expectations.
Built-In Flexibility
By combining activities and tasks in different ways, OUM can be applied to many types of information technology software development and implementation projects.
Saves Time
Seasoned information technology practitioners representing years of experience have contributed their knowledge to OUM. Project teams can take advantage of this
experience by leveraging these leading practices along with industry standards.
Higher Quality
OUM subscribes to an iterative approach that incorporates testing and validation throughout the lifecycle, rather than testing for quality only at the end of the project.
More Cost Effective
OUM facilitates improved control of project expenses by using a flexible work breakdown structure that allows you to perform only necessary tasks.
Reduce Project Risk
Implementing an iterative, broadly applicable method mitigates requirements mismatch. A key focus of each iteration in OUM is to identify and reduce the most significant
project risks. This allows for the most critical risks to be addressed as early as possible in the project lifecycle, which results in a measurable reduction of schedule and
budget risks.
Back to Top
KEY CONCEPTS
OUM has several key concepts and significant milestones that are used to manage the implementation cycle. These key concepts and milestones are demonstrated in the
Microsoft Project OUM Project Workplan. This example workplan provides a template for the partitions, phases, processes, milestones, and concepts used in an OUM
project.
This section provides a brief overview of the following concepts and significant milestones used to manage an OUM project:
Partitions
Iterations/Increments/Releases
Iteration Groups
Activities
Outputs
Partitions
The functionality that is targeted to be implemented within a project may be split into smaller pieces, known as partitions that are then implemented in parallel or serially
depending on project-specific factors. Partitioning is done to break down the complexity of a system, reduce risks, provide an earlier return on investment or business
value or inhibit scope creep on a project.
These partitions (sometimes also known as subsystems) may be implemented using the same approach or a different approach, depending on project-specific factors. A
partition is one defined part of the total functionality that will be developed in a project. If the functionality is split into partitions, then each partition is developed in a
number of iterations, or even as a separate OUM sub-project with its own set of OUM phases and iterations.
When defining partitions, it is important to consider the dependencies between the partitions. When splitting the total functionality into partitions, look for high cohesion
within a partition and low coupling between partitions.
Iterations/Increments/Releases
Projects based on OUM are carried out in an iterative fashion. Each iteration is concluded by the release of an executable product or set of artifacts, or both, that may be
a subset of the complete vision, but is useful from some engineering or user perspective. Iterations in the early phases of OUM typically produce project models or
documentation, though prototypes may also be involved. Iterations in the later phases of OUM typically produce working software, ready for test or production.
The OUM definition of an iteration is an increment. At the end of each iteration, the active set of outputs or artifacts are released to form the current baseline. A release is
therefore defined as a relatively complete and consistent set of artifacts possibly, but not necessarily including a software build delivered to an internal or external
user. An internal release is used only by the implementation organization, as part of a milestone, or for a demonstration to users. An external release is delivered to the
end users.
A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. Releases act
as a forcing function that drives the implementation team to get closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome.
At each iteration, artifacts are updated and released. It is said that this is a bit like "growing" software. Instead of developing artifacts one after another in a pipeline
fashion, they are evolving across the cycle, although at different rates.
Iteration Groups
Iteration groups represent a subset of the requirements of a system or of a partition that have been grouped using four factors Risk, Complexity, Priority, and
Dependency. Iteration groups are then used to break down the work to allow it to be completed iteratively.
During analysis, we can and should break the requirements functionally into subsystems. However, a functional break down does not always provide the correct grouping
to define increments. It is preferable to define prioritized groups of functionality based on the factors mentioned above, so that the highest priority, riskiest, most complex,
etc. work is done early in a project.
Like partitioning, the circumstances on each project dictates the prioritization approach to be taken for the project. In some cases, the most complex items will be
developed first. In other cases, the team will decide to first implement functionality that demonstrates certain capabilities that require user feedback. In still other cases,
the iteration groups will be developed using some combination of these factors.
Activities
In OUM, tasks are grouped into Activities. Activities do not cross phases. They occur as a group of related tasks within the phase that result in the completion of a
substantial milestone or deliverable. Activities then are spread within the project phases according to the time and ordering where they occur during the life of the project.
One example would be all of the tasks that relate to gathering business requirements. Tasks from one process and one from another process are grouped into an Activity
called Gather Business Requirements.
Outputs
In OUM, the output of a task or activity is called a work product or simply output to eliminate the risk of having method deliverables confused with contractual deliverables.
Contractual deliverables are specifically referenced in the contract and often have a payment schedule associated with their acceptance. Contractual deliverables may be
method outputs, but they may also reference additional deliverables not documented by the method.
Not every task referenced in the method material is required for a given project. The required tasks are based on specific project scope. In this case, the "optional" tasks
are part of the OUM method material, but are not included in the Project Workplan.
Back to Top
CRITICAL SUCCESS FACTORS
Critical success factors may affect the selection of a project service. The following are typical critical success factors and their impact on the success of the
implementation
Project Size: OUM projects are most ideal for projects of less than 900 man-days. It is not a problem that the project is larger, but then you should consider
partitioning the project into a smaller projects each of less than 900 man-days.
Project Duration: OUM is built for rapid delivery of business benefits. Therefore, it is recommended that OUM projects have a duration of less than nine months.
Ideally, projects that initially need a longer duration for completion should be partitioned into a sequence of projects each of less than nine months duration.
Type of Organization: The organization culture can be of vital importance to the success of the project. Organizations with a lot of bureaucratic procedures and
work methods may not be able to participate and work using an OUM approach. Participants in an OUM approach must be able to make quick decisions that will
not be overruled on a higher organizational level. If you are planning to perform an OUM project in such an organization, make certain that the users involved in
the project are empowered to make decisions (within the project scope), that they are accepted by the rest of the organization, and that the users themselves feel
comfortable being in that role, taking on that responsibility and to making decisions (as they might not be used to doing exactly that).
Time-Critical Development: OUM is well suited for time critical development. However, if the end date easily can change, then many of the benefits of OUM will
be lost (for example, delivery of the highest prioritized use cases to quickly fit the business needs). If a fixed-end date is not critical for the business, it will still help
to agree on a fixed-end date as it aids control and motivation. It is a Manage task to hold on to this date and make the users understand the importance of keeping
the date fixed.
Availability and Commitment of Ambassador Users: OUM uses iterations as a basic principle of development and implementation; the ambassador users
provide input for determining the requirements as well as for verifying the end result of each iteration. Therefore, the project is dependent on the availability of well-
skilled ambassador users who must believe in the approach and this way of working, otherwise they may not prioritize their activities on the project. Ambassador
users must also be empowered to take decisions that affect the project. There is nothing more deleterious to progress on a project than to have the project
decisions require constant escalation and to have the authority of the ambassador users be undermined and countermanded.
Skilled Development Team: OUM is an approach with short delivery timescales where there is little time for learning on the job. Therefore, the project is more
dependent on the current skills of the team. If there is a lack of appropriate skills in the development team, at least one skilled resource should be included to
support the team. This resource time and effort must then be planned and estimated accordingly.
Visible User Interface: It is easier for the users to validate the result from the iterations through a user interface like a page or a screen. If the system being
developed does not have a visible user interface that covers a large portion of the software system, it will be necessary to find other means to validate the system
(for example, by showing flow diagrams, creating simulations of integration, etc.).
Baseline High-Level Requirements: OUM recognizes that requirements will change throughout the process, however, to be able to determine a well-defined
scope for the project, you need to be able to baseline the requirements on a high-level. If this is not possible, define the scope related to the Business and System
Objectives, but agree on a maximum effort that should be used to deliver a system related to these objectives.
Prioritizing of Requirements: To be able to deliver the most critical requirements first and to steer the development effort throughout the project, you need to
prioritize the requirements. It is important that the ambassador users understand this concept so that they realize the impact and importance of prioritizing at the
beginning as well as during the whole project.
Back to Top
REUSE STRATEGIES
Reuse is almost self-explanatory, and is a very simple but general concept and can be summed up as "not reinventing the wheel". All phases should make use of reusing
intellectual capital (IC). To make sure that Oracle is taking advantage of past projects and capturing the best from current projects, project and program managers should:
Plan and record reuse decisions and activities (Reuse Plan). If reuse is to be managed, it needs to be planned and monitored and therefore reuse intentions,
decisions, actions and results should be documented in a Reuse Plan. The Reuse Plan could either form part of the Quality Plan or be a separate document, as
appropriate. In either case, the Reuse Plan should be added to and amended during the course of the project and be reviewed during project reviews and in the
phase-end reports.
Create a task step for each task to assess whether there are assets which might be reused.
Perform a task to assess whether there is the possibility to package an aspect of the project for reuse.
Establish standards and guidelines for the generation of reusable assets and their reuse.
Make sure roles to monitor and manage reuse are part of the Project Workplan.
Potential Assets Assessment Task
Even though it makes sense to consider reusable assets during each task, it is probably more appropriate to create a task to evaluate any potential assets at the start and
end of each process or phase. The assessment of the reuse potential of assets in the phase or process should be recorded in the Reuse Plan. A proposal should be
created for reuse asset development (Reuse Packaging Proposal) for any candidate reuse assets that includes the following information:
a description of the asset to be packaged
the rationale for proposing the packaging of the asset
an estimate of the total effort and incremental effort involved in packaging the asset
The project reuse coordinator is responsible for executing this task as well as for developing the Reuse Packaging Proposal(s).
Reuse Standards and Guidelines
For an asset to be easily reusable, it must adhere to certain standards. Documents should adhere to a standard composition and make use of common elements and
project-specific variables. Code should adhere to the Oracle coding standards for the appropriate tool or language and perhaps fit into a technical or application
framework (for example, HeadStart for Applications). Some of these standards exist formally, but most exist informally or not at all. Each project will need to develop
these standards to make sure that assets are designed from the outset for maximum reuse
Back to Top
PUBLICATIONS AND WEBSITES
Please review the Bibliography page for further reading and information.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Focus Area Overview
Method Navigation Current Page Navigation
MANAGE
INTRODUCTION TO MANAGE (FORMERLY THE PROJECT MANAGEMENT METHOD-
PJM)
Any first attempt at converting folklore into knowledge, and a guessing game into a discipline, is liable to be misread as a downgrading of individual ability and its
replacement by a rule book. Any such attempt would be nonsense, of course. No book will ever make a wise man out of a donkey or a genius out of an incompetent.
The foundation in a discipline, however, gives to todays competent physician a capacity to perform well beyond that of the ablest doctor of a century ago, and enables
the outstanding physician of today to do what the medical genius of yesterday could hardly have dreamt of. No discipline can lengthen a mans arm. But it can lengthen
his reach by hoisting him on the shoulders of his predecessors. Knowledge organized in a discipline does a good deal for the merely competent; it endows him with
effectiveness. It does infinitely more for the truly able; it endows him with excellence.
From Managing for Results, by Peter F. Drucker
The Project Manager's Responsibilities
The fundamental responsibility of the project manager is to manage delivery of an agreed upon level of solution quality while planning for and controlling the "triple
constraints" (scope, cost and schedule). If a project is represented as a triangle, then the project manager's responsibility is to make sure that the target level of quality
is actualized while keeping the three sides of the triangle in balance.
Managing project scope, cost, schedule and quality is the primary objectives of a project manager. If any one of these components change, then the imbalance will result
in the change of one or more of the other components.
Managing the triple constraints to maintain an agreed to level of quality sounds fairly simple. Unfortunately, it is anything but simple. In No-Nonsense Advice for
Successful Projects, Management Concepts
17
, author Neal Whitten provides the following list of project manager responsibilities:
Directs the project as if it is his or her own business
Is fully accountable for the project
Applies lessons learned from past projects
Establishes well-defined project roles and responsibilities
Leads the project planning (Project Start Up) activities
Leads the project tracking and problem management activities
Promotes project management leading practices
Manages the project to an acceptable level of risk by balancing scope, time, cost and quality
Manages daily to the project's top three priorities
Empowers others: drives decision making to lowest level reasonable
Establishes the proper level of client involvement
Is a catalyst to resolve project problems and conflicts
Provides project status is timely communication to project stakeholders
Enforces effective change control
Promotes good working relationships
Makes things happen
The Manage focus area provides guidance to the project manager across all these responsibilities.
Back to Top
PHASES
The Manage focus area (formerly PJM) has three phases:
[A] Project Start Up Phase
[B] Project Execution and Control Phase
[C] Project Closure Phase
Each of these phases is intended to support the project manager during the traditional lifecycle phases of the project as well as to be easily used with an appropriate
execution method (specifically OUM Implement, however OUM Manage can be used with other execution methods).
[A] Project Start Up Phase
As implied by its name, the Project Start Up phase targets the beginning of the project. The goal of this phase is to conduct the necessary project start up. The project
manager will define the project with respect to scope, quality, time, and cost. The overall Project Management Plan and the plans for each Manage process will be
developed. The Project Start Up phase also includes establishing the project infrastructure and securing project resources.
[B] Project Execution and Control Phase
The Project Control and Execution phase is directly associated with the project lifecycle phases in OUM Implement (or another execution method). The purpose of this
phase is to manage the execution of the project. This includes using the policies, standards, and procedures delineated in the Project Start Up phase, and perform the
necessary reviews, and measurements to confirm that the project is being executed according to the published plan. It is also the process of comparing actual
performance with planned performance, analyzing variances, evaluating possible alternatives, and taking appropriate corrective action as needed. Corrective actions are
changes made to bring expected future performance of the project into line with the plan. The Project Execution and Control phase tasks are repeated for each execution
method lifecycle phase (for example, Inception, Elaboration, etc.).
Planning of each phase of the execution method is an integral step in the Project Execution and Control phase. The change in the organizational structure of the Manage
focus area does not eliminate the need to accomplish these tasks.
[C] Project Closure Phase
During the Project Closure phase, the project is "closed" from an administrative and contractual standpoint. This includes validating the project outputs are complete and
align with the organizations expectations, gaining final confirmation and securing all documents for reuse, collection and retention.
Integration with Implement Focus Area
The integration of Manage with Implement is illustrated below:
In general, the Manage Project Start Up phase is conducted prior to the first phase of the Implement focus area. The Manage Execution and Control phase runs
concurrently with the Implement focus area phases, and the Project Closure phase begins once the project execution is concluded.
Back to Top
ACTIVITIES
Manage tasks are further refined into activities to better represent the Project Management lifecycle.
Project Start Up Activities
Review Bid and Contract
Review Project Assets with Client
Validate Scope, Stakeholders, and Organization Change Management (OCM) Strategy
Develop Workplan
Develop Staff Plan and Budget
Complete Project Management Plan
Establish Project Infrastructure
Project Execution and Control Activities
The Project Execution and Control phase is made up of many ongoing tasks. An ongoing task is defined as a task that occurs continuously throughout a project, rather
than at a specific known time. The ongoing tasks occur as needed and do not include dependencies among the tasks or with the execution method tasks. The ongoing
tasks in Project Execution and Control are organized into the following activities:
Manage Scope, Acceptance and Approvals
Manage Project Finances
Manage Project Workplan
Manage Risks, Issues and Problems
Orient and Manage Team
Manage Communications and Organization Change Management (OCM) Plans
Manage Project Quality
Create and Execute Configuration and Release Management
Manage and Maintain Infrastructure
Administer Procurement of Goods and Contracted Services
Project Closure Activities
Gain Acceptance
Close Processes and Contract
Document Lessons Learned and Archive Project
In the Project Start Up and the Project Closure phases, there are dependencies among the activities which further define the Project Management lifecycle. The Project
Execution and Control phase is made up of ongoing tasks. In general, ongoing tasks are conducted as needed and not dependent on other tasks in the workplan.
Back to Top
PROCESSES
The Manage focus area is organized into thirteen (13) processes:.
Bid Transition
Scope Management
Financial Management
Work Management
Risk Management
Issue and Problem Management
Staff Management
Communication Management
Quality Management
Configuration Management
Infrastructure Management
Procurement Management
Organizational Change Management
The following diagram illustrates how the processes are executed across the three Manage phases.
Collectively, these processes form a comprehensive set of tasks required to manage an Information Technology project. Every project includes most, if not all, of these
processes, whether they are the responsibility of a consulting organization, a client organization, or a third party.
Relationships Among Manage Processes
There are many "touch points" among the Manage processes. In other words, the outcome or output(s) from one process often affect the output(s) of another process.
The relationships among processes in the Project Start Up phase illustrate this point. For example, Review and Analyze Bid Materials influences the Define and Confirm
Scope task of the Scope Management process which, in turn, influences development of the Project Workplan in the Work Management process which, in turn, helps
determine the Approved Project Budget and Financial Management Plan in the Financial Management process.
Another example of process relationships is stakeholder management. Preliminary stakeholder analysis begins in the Bid Transition process during Project Start
Up. Conducting stakeholder communications should be included as part of the Communications Plan developed in the Communications Management process and
this plan will be carried out during the Execution and Control phase. Additional stakeholder analysis and stakeholder alignment activities are also addressed as
appropriate in the Organizational Change Management process.
Back to Top
THE PROJECT MANAGEMENT PLAN
The Project Management Plan (PMP) is the single most important output produced by the project manager. It is initially created in the Project Start Up phase and
maintained throughout the project as needed.
The purpose of the Project Management Plan (PMP) is to define the overall project management strategies and approaches that will be applied to the project. The
Project Management Plan begins during Bid Transition with the creation of the Project Management Framework. The Project Management Framework is the first step in
addressing the components of the Project Management Plan at a high, strategic level. This document is created by the project manager in conjunction with the client. The
Project Management Framework is a prerequisite to creating the plans that support the thirteen Manage processes. The PMP is conceptual with its various components
made up of the thirteen plans of the Manage processes.
The PMP should not be a huge document. Rather it provides an overall project management roadmap (or framework) and should reference the detailed project
management process-level plans. Accordingly, where appropriate, the project manager should create a separate planning and management documents for individual
processes or process components. The Project Workplan, which is a major component of Work Management, should be maintained in the scheduling tool used on the
project (for example, MS Project) and not included in the overall PMP. The project manager should reference the location of the Project Workplan. The same approach
should be used for Financial Management, Risk Management, Issue Management, etc.
The figure below depicts the overall PMP and the process-level management plans that comprise it.
Back to Top
DELIVERABLE VS. WORK PRODUCT OR OUTPUT
The output of a Manage task is called a work product, or simply, an output. In past method releases, the output of a task was referred to as a deliverable. The term
deliverable has been changed to eliminate the risk of having the method deliverables confused with the contractual deliverables. A contractual deliverable is specifically
referenced in the contract and often has a payment schedule attached to its acceptance.
Contractual deliverables are typically method outputs, but they can also reference additional deliverables not documented in the method. In addition, not every task
referenced in the method material is required for a given project. The required tasks are based on specific project scope. In this case, the "optional" tasks are part of the
Manage method material, but are not included in the Project Workplan.
It is important for the project manager to understand and distinguish between these concepts in communications with clients.
Back to Top
SCALING MANAGE TO THE INDIVIDUAL PROJECT
Although it has been developed for moderate to large-scale projects, the Manage focus area is also applicable to smaller efforts as well. The philosophy behind Manage
is that the principles of sound project management, do not change with project size. Rather, the sophistication, structure and procedural approach should scale as
appropriate. For example, a large, multi-team, multi-site program will require a sophisticated Issue Management system and database while a small single location
project team may find a simple Excel spreadsheet sufficient for capturing and tracking issues. In line with this philosophy, each Manage task should be considered a
required, core task. However, the depth to which these tasks are performed on smaller projects may vary substantially from larger projects.
As part of scaling the Manage focus area to the project, the project manager must determine which, if any, Manage tasks should be expanded, reduced, or consolidated
based upon the scope, objectives, approach and risks of the project.
The Manage focus area is a scalable, flexible tool. It is comprised of well-defined processes that can be managed in several ways to guide a team through an
implementation project. Teams frequently tailor Manage to match the projects expertise, complexity, requirements and scope .
Note: Manage tasks within the processes, depending upon the scope, objectives and approach of the project, can be both linear and concurrent.
Back to Top
REUSE STRATEGIES
Reuse is almost self-explanatory, and is a very simple but general concept and can be summed up as "not reinventing the wheel." All phases should make use of reusing
intellectual capital (IC). To make sure that Oracle is taking advantage of past projects and capturing the best from current projects, project and program managers should:
Plan and record reuse decisions and activities (Reuse Plan). If reuse is to be managed, it needs to be planned and monitored and therefore reuse intentions,
decisions, actions and results should be documented in a Reuse Plan. The Reuse Plan could either form part of the Quality Plan or be a separate document, as
appropriate. In either case, the Reuse Plan should be added to and amended during the course of the project and be reviewed during project reviews and in the
phase-end reports.
Create a task step for each task to assess whether there are assets which might be reused.
Perform a task to assess whether there is the possibility to package an aspect of the project for reuse.
Establish standards and guidelines for the generation of reusable assets and their reuse.
Make sure roles to monitor and manage reuse are part of the Project Workplan.
Potential Assets Assessment Task
Even though it makes sense to consider reusable assets during each task, it is probably more appropriate to create a task to evaluate any potential assets at the start and
end of each process or phase. The assessment of the reuse potential of assets in the phase or process should be recorded in the Reuse Plan. A proposal should be
created for reuse asset development (Reuse Packaging Proposal) for any candidate reuse assets that includes the following information:
a description of the asset to be packaged
the rationale for proposing the packaging of the asset
an estimate of the total effort and incremental effort involved in packaging the asset
The project reuse coordinator is responsible for executing this task as well as for developing the Reuse Packaging Proposal(s).
Reuse Standards and Guidelines
For an asset to be easily reusable, it must adhere to certain standards. Documents should adhere to a standard composition and make use of common elements and
project-specific variables. Code should adhere to the Oracle coding standards for the appropriate tool or language and perhaps fit into a technical or application
framework (for example, HeadStart for Applications). Some of these standards exist formally, but most exist informally or not at all. Each project will need to develop
these standards to make sure that assets are designed from the outset for maximum reuse
Back to Top
PROJECT MANAGEMENT EFFORT
Estimating and organizing project management involves three factors:
Project Management Effort
Consulting-Client Relationship
Project Management Staffing
Oracles project experience indicates that total project management effort typically ranges from 15% of project effort for small projects to as much as 25% for the largest
projects. Project management effort increases as the project size increases because of increasing phase control complexity and coordination among full time project
management team members. Project duration also affects project management effort relative to total project effort, since Project Execution and Control occurs during the
entire project.
Back to Top
PROJECT DELIVERY ORGANIZATION
Consulting-Client Relationship
The people who have influence over the products and conduct of the project may be drawn from within the organization, supplied by an outside organization, or a
combination of both.
A contract may or may not be involved. In the Manage focus area, the consultant and the client represent the two parties which together form the project management
team responsible for the projects success. The client represents the customer organization, or primary beneficiary of the project, as well as the acquirer, or funding
source for the project. The client is also assumed to be capable of providing both physical and human resources for the project. The consultant represents an information
services provider organization with management structure and systems. This organization may be either a profit center, performing the project for a profit, or a cost
center, sharing project costs with the client. It is made up of practices, or business units that supply consulting staff resources and sub-contractors to the project. Note
that the tasks performed in reaching and maintaining a contractual agreement between the client and consultant are not covered in the Manage focus area. The Manage
focus area assumes that a contract may be established prior to the start of the project, and identifies where contractual impacts can occur during the project A contract is
not a prerequisite for the use of Manage. It also assumes that both the client and the consultant have internal management policies governing project conduct. Tailor
these aspects of the client-consultant relationship to your projects specific situation.
Key Project Management Roles
The key management roles performed by the client in the Manage focus area are the project sponsor and client project manager. The project sponsor is the client role that
holds the budget for the project, and may be an individual or a committee. The project sponsor establishes organizational commitment to the project and validates project
objectives. The client project manager is expected to be assigned to the project where client commitments or business interests require a daily client management
presence. This role is responsible for providing client resources, resolving problems, and monitoring the consultants progress. The key management roles performed by
the consultant in Manage are the consulting organization's (for example Oracle) project sponsor and the project manager. The consulting organization project sponsor
role represents the consulting manager whose practice is responsible for the successful execution of the project. The project manager is held ultimately responsible for
the projects success or failure. The project manager must manage the various aspects of time, cost, scope, and quality to align with client expectations and meet the
business objectives of the consulting practice, while providing challenging opportunities to project staff.
Back to Top
PROJECT MANAGEMENT STAFFING
The roles depicted in the organization chart are those that are assigned responsibilities to perform the Manage tasks.
Staffing involves two factors:
Role Allocated to Staff
Multi-Site Project Considerations
Roles Allocated to Staff
Each role defined in the project management support team will only be assigned to different people on medium-sized projects or larger. On the largest projects, there
may even be more than one person performing each of these roles, and the team will be organized into a project office, with a manager.
On smaller projects, the project manager assumes most of the responsibilities of the project support team. The first responsibility the project manager should relinquish as
project size increases is that of configuration manager. This role is frequently assigned to a senior person performing a technical support role, such as a system
administrator.
The responsibility for quality management is only a full-time position on large-scale projects. The quality auditor should not report to any of the project team due to a
potential conflict of interest. The quality auditor is a role independent of the project as shown on the staffing chart. There are other organizations that are commonly
employed on larger projects to facilitate management communication and decision-making:
Steering Committee
The steering committee represents the business objectives associated with the project, guides the overall project review, adopts the recommendations, and provides
sponsorship for implementing the changes. The steering committee includes high-level stakeholders, along with the project sponsor. Regular meetings should be held to
review progress and resolve outstanding issues. The steering committee members are responsible for the project approach buy-in, funding, issue resolution, and sign-off.
Change Control Board (CCB)
The CCB is an internal, formally chartered project organization responsible for reviewing, evaluating, approving, delaying, or rejecting change requests, and for recording
and communicating such decisions. The CCB is chaired by the project manager and includes the client project manager, project administrator, configuration manager,
and team leaders. The CCB normally escalates changes affecting scope to the steering committee.
Issue Review Board (IRB)
The IRB is organized to review and provide recommendations in order to address escalated issues and risks in situations where a regular, dedicated meeting is deemed
necessary. It is staffed similarly to the Change Control Board (CCB), and can be combined with it. It may also be part of a weekly project progress review team that would
meet to discuss project progress as well as issues and risks.
Multi-Site Project Considerations
Multiple site projects require a higher level of project administration and control to coordinate the tasks and to leverage common outputs between projects. In a multiple
site project, you will need to position site coordinators as part of your project management team. These people also establish consistency in the delivery and
presentations of work, use of techniques and approach, use of standards and guidelines, and interpretation of enterprise-wide strategies.
Another important role that coordinators perform is facilitating the technical strategies between related sites. This role calls for a more formal exchange of technical
information and status review. These site coordinators will also distribute software and documentation to multiple data centers.
Back to Top
MANAGEMENT
Please read Project Management in OUM. It describes how the OUM Manage focus area and Implement focus area work together.
If you have never managed a project with a Unified Process approach, or are not familiar with the terms "iterative" or "incremental, read the Tips for Project Managers and
Planning a Project using the Oracle Unified Method (OUM). For further information on managing iterative projects, see Managing Iterative Software Development
Projects.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[PS] PROJECT START UP
The purpose of the Project Start Up phase is to provide strong and clear directions for producing a product or service which delivers identified benefits or purpose for the
business. During the Project Start Up phase, resources are allocated to accomplish specific objectives, satisfy needs, and set expectations through a planned and
organized approach.
A key output of the Project Start Up phase, the Project Management Plan, provides the necessary objectives, strategies, plans, methods, tools, resources and procedures
to achieve the expected benefits or purpose in the business. The Project Start Up phase is considered the most important phase in the project. The tasks within the
Project Execution and Control phase are built on the foundation established in Project Start Up.
There must be a strong commitment to perform the project from the business and the prime supplier. A forum should be established to share the project's status, risks and
issues with the key stakeholders and obtain feedback.
The following lists contains prerequisites that must exist in the project organization in order to deliver the solution completely and satisfactorily. These prerequisites must
be in place prior to the Project Execution and Control phase.
Funding of the project is documented and signed-off
Statement of the work is documented and signed-off
Required financial approvals achieved
Required resources received
When subcontracting, subcontractor agreement is documented and signed-off
Project planning is completed
Infrastructure is established
Required project training is prepared
Project team orientation is prepared
Project control-cycle is developed and documented including tracking and taking corrective actions
Configuration Management and scope change procedures are developed
Quality Management including project acceptance procedures are developed
Back to Top
OBJECTIVES
The following is a list Project Start Up phase objectives:
Objectives, needs and expectations allocated to the project are documented, controlled, and baselined for project planning and control.
Project plans, work products, and tasks are kept consistent with the agreed upon objectives, needs and expectations allocated to the project.
Project estimates are documented for use in planning and control of the project.
The prime contractor selects and secure qualified subcontractors and resources.
The prime contractor and the subcontractor agree to their commitments to each other.
Affected parties agree to their commitment related to the project.
Quality assurance tasks are planned.
Configuration management tasks are planned.
Project infrastructure is established.
Project acceptance procedure and criteria is documented and agreed between parties.
Project control cycle is documented and approved between parties.
Project training and project orientation is prepared.
Obtain sponsors approval to proceed.
Back to Top
PROCESSES
The Manage context diagram illustrates the processes within the Project Start Up phase.
Back to Top
TIPS AND TECHNIQUES
Best practice suggests the key Project Start Up activities are shown on the project plan. These activities are generally short term, lasting no longer than four to six weeks
even on the largest of projects.
The level of granularity of Project Start Up tasks shown on the Gantt chart cannot be prescribed. This level depends on many factors. Factors include the role of all
involved during Project Start Up and the size and complexity of the project. It is recommended that key activities arising from Project Start Up are shown as discrete tasks
on the Gantt chart.
See the Manage example workplan (in MS Project) for an example of the Project Start Up activities and sequence.
An objective of the Project Start Up phase is to understand and influence the expectations of key project stakeholders. Document and communicate your vision of the
project to the Project Sponsor, key stakeholders, management, and the project team. Evaluate the project proposal as your starting point for Project Start Up. How have
expectations been set? Have there been changes since the project proposal was accepted?
Set Expectations Early
The initial scoping in the Project Start Up phase covers all areas of known risk, working policies, agreed approaches, communication, and implementation strategies.
Original project proposals or Project Charter may already include some of these topics. However, in creating the original project proposal, assumptions may have been
used. During Project Start Up, you must verify all the documented and undocumented assumptions.
Note: The main objective of the Project Start Up phase is to prepare the Project Management Plan. To conduct the project without the Project Management Plan, you risk
not having a point of reference for change control, and must rely heavily on verbal commitments, which can often lead to serious misunderstandings and disputes about
what was agreed to.
In some cases, clarification and justification may be needed before approving work products. The Project Management Plan can be used to explain why certain methods,
approaches, and techniques were used. If organized correctly it can serve as the vehicle for justifying why and how project tasks are being performed. Within this context,
the planning for reuse should be established to increase productivity and reduce costs as well as risks. Reuse of work products will help to reduce the risk of the project
since these provide actual examples of previous project work.
The following illustrates the key project management components of the Project Management Plan
Obtain Initial Approvals
Arrange for a review with key stakeholders, if possible upon starting the project. The purpose of the review is to determine the overall health of a project and its prospects
for success, check the completeness of plans, and ensure a clear understanding of project control and completion procedures.
Suggestion: Use start up meetings to communicate the plans to the project stakeholders. Consider separate meetings for management and project staff. A formal
presentation should be delivered to the project sponsor, as a minimum.
The primary techniques you use in this process during Project Start Up are stakeholder analysis, risk assessment, interviewing, negotiation, and presentation. Use these
techniques to discover and cater to all factors which could ultimately jeopardize the projects success.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. Use this link to access the phase-specific guidance for Scrum.
Back to Top
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product Key Type
Review Bid and Contract
BT.010 Review and Analyze Bid Material Reviewed Bid Material Core
BT.020 Review and Confirm Business Case Reviewed Business Case Core
BT.030 Identify Project Stakeholders Identified Project Stakeholders Core
BT.040 Review and Accept Project Budget Accepted Project Budget Core
RKM.020 Conduct Baseline Risk Assessment Baseline Risk Assessment Y Core
Review Project Assets with Client
BT.050 Review Contract with Client Reviewed Contract Y Core
BT.060 Review Project Approach with Client Reviewed Project Approach Y Core
BT.070 Create Project Management Framework Project Management Framework Y Core
Validate Scope, Stakeholders and OCM Strategy
SM.010 Define and Confirm Scope Validated Scope Y Core
CMM.010 Conduct Project Stakeholder Analysis Project Stakeholder Analysis Core
OCHM.010 Understand Client's Organization Change Management Strategy
Understanding of Client's Organization Change Management
Strategy
Y Core
Develop Workplan
WM.010 Develop Baseline Project Workplan Baseline Project Workplan Y Core
Develop Staff Plan and Budget
FM.010 Refine Project Budget Approved Project Budget Y Core
STM.010 Plan Resource Requirements Resource Requirements Core
STM.030 Staff the Project Staffed Project Y Core
STM.040 Prepare Project Orientation Guide Project Orientation Guide Core
Complete Project Management Plan
SM.020 Develop Scope Change Management Processes Scope Change Management Processes Y Core
FM.020 Develop Financial Management Plan Financial Management Plan Y Core
WM.020
Develop Work Management Execution and Control Processes and
Policies
Work Management Plan Y Core
RKM.010 Develop Risk Management Plan Risk Management Plan Y Core
IPM.010 Develop Issue Management Strategy Issue Management Strategy Y Core
IPM.020 Develop Problem Management Strategy Problem Management Strategy Y Core
STM.020 Develop Staff Management Plan Staff Management Plan Y Core
CMM.020 Develop Project Team Communication Plan Project Team Communication Plan Y Core
QM.010 Develop Quality Management Plan Quality Management Plan Y Core
QM.020 Develop and Document Quality Control and Reporting Process Quality Control and Reporting Process Core
CM.010 Develop Configuration Management Strategy and Processes Configuration Management Strategy and Processes Y Core
CM.030 Create Project Documentation Management Plan Documentation Management Plan Core
IFM.010 Develop Infrastructure Management Plan Infrastructure Management Plan Y Core
PCM.010 Develop Procurement Strategy and Process Procurement Strategy and Process Y Core
OCHM.020 Identify Change Management Warning Signs Change Management Warning Signs Core
Establish Project Infrastructure
FM.030 Set up Time and Expense Tracking Time and Expense Tracking Core
RKM.030 Develop Risk Management System Risk Management System Core
IPM.030 Develop Issue and Problem Management System Issue and Problem Management System Core
CM.020 Obtain Configuration Management Tools Configuration Management Tools Core
IFM.020 Establish Team Work Environment Established Team Work Environment Core
IFM.030 Establish Technical Infrastructure Established Technical Infrastructure Core
PCM.020 Procure Goods and Contracted Services Service Orders Core
Back to Top
ACTIVITY FLOW DIAGRAM
Back to Top
RISK MANAGEMENT
The most likely areas of risk during Project Start Up are the following:
External
Lacking of project sponsor
Insufficient resources available
Interfaces between projects not considered
The facilities are not conductive for project work
Management
Low management attention, or management does not hold the project team accountable
Missing contingency
Planning
Unclear objectives
Unclear scope and work products
Insufficient number of milestones
Plan is too informal
Not an appropriate project organization
Adequate control cycle is not developed
Resources
Anticipated resources fail to appear
No organized approach for sharing information
Methods and Tools
Employing different, incompatible tools
Back to Top
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
The business objectives, scope and work products are understood by the project team and documented in the Project Management Plan.
There is a committed project sponsor from the organization who makes sure that other members of the company share this commitment to the project.
Effective hand over of the engagement from the bid manager.
The necessary resources have been identified and committed to the project in order to complete it within the planned time frame.
A realistic and achievable project and financial plan has been developed including all project activities, tasks and resources.
Project infrastructure is completely and correctly implemented before the majority of the project team are on site.
The project plan and procedures have been communicated to the organization and project team and are well understood by all.
The project team provides input to the project workplan and is committed to the success of the workplan.
There is committed sponsorship for the project.
Risk assessment has been completed with plans for mitigation.
Change control is implemented.
Configuration management has been implemented.
Expectations have been discussed, understood, and the management of expectations is part of the Project Team Communication Plan.
Scope, objectives, and approach are agreed on and understood by all parties.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.RBC - REVIEW BID AND CONTRACT
This activity is the first activity that the project manager will conduct after being assigned to the project. This activity bridges the gap between the Bid Preparation process
and Project Start Up.
Back to Top
OBJECTIVES
The objective of this activity is to have the project manager accept "ownership" of the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
BT.010 Review and Analyze Bid Material Reviewed and Analyzed Bid Management Reviewed and Analyzed Bid Material
BT.020 Review and Confirm Business Case Confirmed Business Case Confirmed Business Case
BT.030 Identify Project Stakeholders Identified Project Stakeholders Identified Project Stakeholders
BT.040 Review and Accept Project Budget Accepted Project Budget Refer to the Task Overview for guidance.
RKM.020 Conduct Baseline Risk Assessment Baseline Risk Assessment Baseline Risk Assessment
Risk Mitigation
Back to Top
ITERATIONS
This activity is conducted as the first step in the Project Start Up phase.
Back to Top
APPROACH
The approach to this activity is:
Review bid material.
Gain background information from bid team and sales team.
Identify the project stakeholders.
Conduct a Baseline Risk Assessment for the project.
Back to Top
PREREQUISITES
You will need the following for this activity:
Bid Material
Contract
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.RPAC - REVIEW PROJECT ASSETS WITH CLIENT
This activity finalizes the gap between the Bid Preparation process and Project Start Up.
Back to Top
OBJECTIVES
The objective of this activity is to review the contract and project approach with the client and create the framework for the Project Management Plan. This includes
making any necessary updates to the contract and project approach prior to the project kickoff.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
BT.050 Review Contract with Client Reviewed Contract Reviewed Contract
BT.060 Review Project Approach with Client Reviewed Project Approach Reviewed Project Approach
BT.070 Create Project Management Framework Project Management Framework Project Management Framework
Back to Top
ITERATIONS
The individual tasks should be iterated until approval is achieved.
Back to Top
APPROACH
The approach to this activity is:
Review contract and project approach.
Adjust contract and project approach as appropriate and gain necessary approvals.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.RBC Review Bid and Contract
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.VSSOS - VALIDATE SCOPE, STAKEHOLDERS AND
ORGANIZATIONAL CHANGE MANAGEMENT (OCM) STRATEGY
This activity occurs after the bid and contract have been reviewed with and approved by the client. Then the next key activity for the project manager is to validate the
scope.
The project manager will also conduct the project stakeholder analysis. Having an understanding of the project stakeholders and understanding the organizational change
management strategy are important steps that play a key role in creating the Communication Plan and understanding the communication needs of the project.
Back to Top
OBJECTIVES
The objective of this activity is to have a clear understanding of the project scope. In addition, understanding stakeholders and OCM strategy will both help to further
define the scope and will be a key input into the communication plan.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.010 Define and Confirm Scope Validated Scope Validated Scope
CMM.010 Conduct Project Stakeholder Analysis Project Stakeholder Analysis Project Stakeholder Analysis
OCHM.010 Understand Client's Organizational Change
Management Strategy
Client's Organizational Change Management
Strategy
Client's Organizational Change Management
Strategy
Back to Top
ITERATIONS
This activity is conducted once.
Back to Top
APPROACH
The approach to this activity is to:
Clearly identify all application modules, enhancements, reports, interfaces, conversions and locations in scope.
Define what is out-of-scope.
Define key project assumptions as part of the scope definition.
Define how much contingency (i.e., management reserve is going to be withheld for risk, issues, problems, and unplanned work).
Document all assumptions concerning scope, resources, user participation, sign-off, issues resolution, QA.
Ensure that the concerns of key stakeholders are addressed and that the efforts of these stakeholders are aligned with the project's business objectives.
Clarify the scope of the project Organizational Change Management work with the client.
Back to Top
PREREQUISITES
You will need the following for this activity:
Bid Material
PS.ACT.RBC Review Bid and Contract
PS.ACT.RPAC Review Project Assets with Client
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.DW - DEVELOP WORKPLAN
The project manager creates a complete, detailed Project Workplan. The Project Workplan denotes all the tasks and activities to be performed by the team within the
projects scope, objectives, and approach and should align directly to the governance approach as described in the Project Management Plan (PMP). It should include
client activities that are dependencies for project success (including Configuration, Infrastructure Management, Communications, Organizational Change Management
and Training). The Baseline Project Workplan should include a detailed (task-level) workplan for the current iteration with a high-level (activity-level) workplan for the
remainder of the project.
Back to Top
OBJECTIVES
The objective of this activity is to create a complete, detailed workplan.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
WM.010 Develop Baseline Project Workplan Baseline Project Workplan Implementation Plan
Iteration Plan Summary
Refer to Appropriate View Example Project Workplan
Back to Top
ITERATIONS
This activity is conducted in conjunction with the Develop Staff Plan and Budget activity. Both activities are iterated until a detailed Baseline Project Workplan is created.
Back to Top
APPROACH
The approach to this activity is to:
The workplan is verified against the contract and the Validated Scope. Keep in mind that any changes to the WBS must be approved by both the client and the
business line.
Decompose workplan to the lowest level of activity.
Develop task level estimates.
Sequence activities and tasks.
Assign and level resources.
Refine and baseline the workplan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.DSPB - DEVELOP STAFF PLAN AND BUDGET
This activity is conducted in conjunction with the Develop Workplan activity. Using the workplan as input, the project manager develops the staff plan and the project
budget. In addition, orientation guides are prepared in order to prepare for the project kickoff.
Back to Top
OBJECTIVES
The objective of this activity is to create a staff plan and a project budget and prepare the orientation guides for project kickoff.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
FM.010 Refine Project Budget Approved Project Budget Refer to the Task Overview for guidance.
STM.010 Plan Resource Requirements Resource Plan Project Team Organization Chart
Resource Plan
STM.030 Staff Project Staffed Project Refer to the Task Overview for guidance.
STM.040 Prepare Orientation Guide Orientation Guide Project Orientation Guide
Back to Top
ITERATIONS
This activity is conducted in conjunction with the Develop Workplan activity. Both activities will be iterated until a staff plan and budget is created.
Back to Top
APPROACH
The approach to this activity is to:
Obtain and apply the rates to derive the labor budget that relates to the planned effort and resources required to perform the project.
Calculate a project non-labor expense budget.
Validate the budget.
Cost burden the workplan
Verify that project is funded properly (labor and expenses) in the relevant company financial systems.
Verify that services invoicing processes are in place for the service provider, client and sub-contractors.
Develop and agree to a policy for use of non-billable codes.
Define labor and expense tasks for recording actuals in accordance with project requirements and procedures.
Work with operations to set up labor tasks.
Identify, document, and assign roles, responsibilities, and reporting relationships for the project team members.
Prepare Orientation Guides.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.CPMP - COMPLETE PROJECT MANAGEMENT PLAN
This activity prepares the key plans that are used to manage the project. The Project Management Framework, created as part of the Review Project Assets with Client
activity, created the initial, high-level view or framework of the Project Management Plan (PMP). This activity takes each of the Project Management Plan components
and provides the necessary details. The PMP is a conceptual work product with its various components made up of the thirteen plans of the Manage processes cataloged
within the Project Management Framework.
The purpose of the Project Management Plan (PMP) is to verify and confirm the projects scope and then to define the governance approach to project management by
identifying how the critical, strategic areas of the project will be planned, executed and controlled, and monitored and reported on. Project scope needs to be validated
and specified in detail. This is especially critical where the scope has been vaguely written into the contract. Important background information such as related source-of-
authority documents, project objectives, and critical success factors should be documented.
This activity takes each component of the Project Management Framework and provides necessary details on key plans for managing the project, such as the Change
Control process. This activity is conducted in conjunction with the Develop Workplan, Develop Staff Plan and Budget and Establish Project Infrastructure activities.
It is not necessary to include detailed planning/process documents focused on normal implementation activities and doing so may reduce the effectiveness of the
document by making it unreadable. The PMP, itself, should not be a huge document. Rather it provides an overall project management roadmap or framework and
should reference the detailed project management process-level plans. Accordingly, where appropriate, the project manager should create a separate planning and
management document(s) for individual processes or process components. For example, your Project Workplan, which is a major component of Work Management
should be managed in the scheduling tool used on the project (e.g., MS Project) and not cut and pasted into the overall PMP. In the overall PMP, the project manager
should reference the location of the Project Workplan, key workplan maintenance standards, and responsibilities for its maintenance. The same approach should be
used for Financial Management, Risk Management, Issue Management, etc.
The PMP is a living document that is updated periodically as key changes in the project occur.
Back to Top
OBJECTIVES
The objective of this activity is to complete the Project Management Plan to use as a baseline for executing and controlling the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.020 Develop Scope Change Management Processes Scope Change Management
Processes
Scope Change Management Process
Scope Change Management Checklist
FM.020 Develop Financial Management Plan Financial Management Plan Financial Management Plan
WM.020 Develop Work Management Execution and Control
Processes and Policies
Work Management Plan Work Management Execution and Control Processes
and Policies
RKM.010 Develop Risk Management Plan Risk Management Plan Risk Management Plan
IPM.010 Develop Issue Management Strategy Issue Management Strategy Issue Management Strategy
IPM.020 Develop Problem Management Strategy Problem Management Strategy Problem Management Strategy
STM.020 Develop Staff Management Plan Staff Management Plan Staff Management Plan
Staff Training Plan
Staff Management Procedures
Project Roles and Responsibilities Presentation
CMM.020 Develop Project Team Communication Plan Project Team Communication Plan Project Team Communication Plan
Client Profile
Steering Committee Presentation
QM.010 Develop Quality Management Plan Quality Management Plan Quality Management Plan
Quality Management Procedures (Generic)
Quality Management Procedures (Modified for OUM)
QM.020 Develop and Document Quality Control and Reporting
Process
Quality Control and Reporting Process Quality Control and Reporting Process
Quality Control Checklist
Quality Review Report (Generic)
Quality Review Report (Modified for OUM)
CM.010 Develop Configuration Management Strategy and
Processes
Configuration Management Plan and
Processes
Configuration Management Plan and Processes
Configuration Management Procedures
Configuration Item Index
Configuration Item Status Record
CM.030 Create Project Documentation Management Plan Documentation Management Plan Documentation Management Plan
Document Index-Word
Document Index-Excel
Document Update Notice
IFM.010 Develop Infrastructure Management Plan Infrastructure Management Plan Infrastructure Management Plan
Installation Plan and Record
PCM.010 Develop Procurement Strategy and Process Procurement Strategy and Process Procurement Strategy and Process
OCHM.020 Identify Change Management Warning Signs Change Management Warning Signs Change Management Warning Signs
Back to Top
ITERATIONS
This activity is iterated until all of the Project Management Plan components have been completed and signed-off by the client.
Back to Top
APPROACH
The approach to this activity is to:
Develop Scope Change Management Processes
Develop Financial Management Plan.
Develop Work Management and Execution and Control Processes and Policies.
Develop Risk Management Plan.
Develop Issue Management Strategy.
Develop Problem Management Strategy.
Develop Staff Management Plan.
Develop Project Team Communication Plan.
Identify which quality standards are relevant to the project and determine how to satisfy them.
Develop and Document Quality Control and Reporting Process.
Develop Configuration Management Strategy and Process.
Create Project Documentation Management Plan.
Develop Infrastructure Management Plan.
Develop Procurement Strategy and Process.
Identify Change Management Warning Signs.
Ensure that the Project Management Plan is straight to the point, avoid boilerplate text and keep it as concise as possible it has little value if it is unreadable. Consider
putting standard text or excessive detail in separate documents, e.g., procedures or using a summary-level presentation.
PREREQUISITES
You will need the following for this activity:
PS.ACT.RPAC Review Project Assets with Client
PS.ACT.DW Develop Workplan
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.EPI - ESTABLISH PROJECT INFRASTRUCTURE
This activity sets up the system and tools needed to conduct the project.
Back to Top
OBJECTIVES
The objective of this activity is to set up the technical and environmental infrastructure for the project. The Project Management Plan will determine the appropriate tools,
systems, and technical and environmental infrastructure to be used on the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
FM.030 Set Up Time and Expense Tracking Time and Expense Tracking Expense Tracking Spreadsheet
Project Team Time Sheet
RKM.030 Develop Risk Management System Risk Management System Risk Form
Risk Log
Risk/Issue/Problem Log
IPM.030 Develop Issue and Problem Management System Issue and Problem Management System Issue Form
Issue Log
Problem Form
Problem Log
Risk/Issue/Problem Log
CM.020 Obtain Configuration Management Tools Configuration Management Tools Refer to the Task Overview for guidance.
IFM.020 Establish Team Work Environment Team Work Environment Refer to the Task Overview for guidance.
IFM.030 Establish Technical Infrastructure Established Technical Infrastructure Physical Resource Plan
PCM.020 Procure Goods and Contracted Services Service Orders Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Set up Time and Expense System.
Develop Risk Management System.
Develop Issue and Problem Management System.
Obtain Configuration Management Tools.
Establish Technical Infrastructure.
Establish Team Work Environment.
Procure Goods and Contracted Services.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.DW Develop Workplan
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[PEC] PROJECT EXECUTION AND CONTROL
The purpose of the Project Execution and Control Phase is to provide adequate visibility into actual progress so that management can take effective actions when the project's
performance deviates significantly from the project plans.
The Project Execution and Control Phase includes tracking and reviewing the projects accomplishments and results against documented WBS-dictionary, project estimates, time
schedule, resources plan and cost budget, and adjusting these plans based on the actual accomplishment and results.
To be able to perform this phase, the following must be in place:
All work products agreed with the organization must be identified and documented in a WBS-dictionary.
The development time schedule for the project must be documented and approved.
The project manager explicitly assigns responsibilities for the necessary work.
Adequate resources and funding are provided for execution and control of the project.
A cost control cycle, preferably based on 'earned value' concepts is developed.
The project management team is experienced/trained in managing the technical and personnel aspects of the project.
The project management team has received orientation in the technical aspects of the project.
Project structuring is the basis for good project control. Structuring the project into several dimensions provides the framework for project control. For example several dimensions
can combine WBS-elements with project organization elements and cost elements. The intersection of these dimensions and a time schedule is essential to effective project
management.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Track project performance against the Project Workplan.
Monitor and control project work by taking corrective action and managing to closure when actual results and performances deviate significantly from the Project Workplan.
Communicate all changes to project commitments by documenting and obtaining agreement by the affected parties.
Maintain ongoing communication with all parties.
Track subcontractor's actual results and performance against its commitments (when a subcontractor is used).
Objectively verify adherence of work products and tasks to the applicable standards, procedures, and requirements. Noncompliance issues that cannot be resolved within
the project are addressed by senior management.
Inform affected parties of quality assurance tasks and results.
Perform configuration management on identified work products.
Manage and control changes to identified work products.
Communicate status and content of project baselines to all affected parties.
Provide the mechanisms to enable the project team to function in a proactive mode.
Anticipate possible risks and issues to the project and take preventive measures to contain them.
Consistently promotes and employs the policies, standards and procedures for the capture and reuse of project intellectual capital.
Back to Top
PROCESSES
The Manage focus area context diagram illustrates the processes within the Project Execution and Control phase.
Back to Top
TIPS AND TECHNIQUES
Best practice suggests the key Project Execution and Control tasks should be shown on the Project Workplan. While these tasks are generally short in duration, many will recur
during each phase of the execution method, e.g., OUM, AIM, Compass.
The level of granularity of the Project Execution and Control tasks shown on the Gantt chart cannot be prescribed. This depends on many factors. Factors may include the role of
consulting during project execution and the size and complexity of the project.
This section discusses techniques that may be helpful in conducting Project Execution and Control phase.
Monitoring and Reporting
Tasks are managed in this process to control the direction of the project and maintain a solid partnership with the implementing organization and the business. The key
techniques you employ during Project Execution and Control phase are leadership, communication, motivation, conflict management, analysis, and risk/issue resolution.
Monitor and Report Progress Regularly
One of the most critical activities during Project Execution and Control phase is monitoring and reporting. If properly employed, the regular progress reporting and review cycles
can provide a solid forum from which you can stay in control of project work. You will receive and create a wealth of qualitative and quantitative information in these reviews to
help you and your project leaders find issues/risks and fix them before they become uncontrollable.
Attention: The following are suggested management reviews for your project. Make sure that you distinguish between these and project technical reviews, such as design
reviews, by controlling the attendance, contributions, and agenda of the meetings. For example, a progress review attended by many users can turn into a design review if not
controlled.
Team Progress Reviews. You will need to determine who comprises the "team". It could be the group of people in one organizational leg in the project organization, or it
could consist of all team leaders on the project.
Team Progress Reviews should be held on a weekly basis to assess the progress of each team and to plan for the following week or weeks. They also include a discussion
of any changes, issues/risks, problems and lessons learned. Workplans and resource plans are updated in preparation for the Team Progress Review based on
completion of timesheets by staff. The meeting should be chaired by the project manager or a team leader on the specific team.
Weekly Project Progress Reviews could be without any financial implications i.e. a review where schedule performance and effort (hours) performance is communicated
compared to baselines, included changes and the resource situation. Managing risks and issues should be the main objective in the meeting. This meeting could be held
on weekly bases and based on team reports and team members weekly time reports.
Monthly Project Progress Reviews are normally held at monthly intervals, covering each financial reporting month. A report is given by the project manager to
management, summarizing project performance (including financial status), risks/issues and relationship. Current project status prepared by the project manager will be a
key input to the meeting.
Steering Committee Meeting. The project steering committee meets at an interval usually determined by the project sponsor to review the progress of the project and
discuss business issues relevant to the project. The implementing organization and business project managers represent the project at these meetings.
Note: Never be pressured into changing estimates or direction during a review meeting. Take time away from the meeting environment to make a decision.
The success of your project depends on a good level of communication within your project team. You must facilitate and encourage good communication by constant concern and
effort. No amount of formal review can substitute for spending time informally chatting with your project members, and walking around your project work area. You will gain
invaluable information about individuals, their work, and rate of progress. You will also be able to pick up on personal or political problems that can impede or are already
affecting project work.
Suggestion: The qualitative information you gain, along with your own experience, should be used to corroborate the quantitative information in your project reviews. You need to
feel satisfied that the figures are telling you the same thing as your impressions when you present your own progress reports.
Control the Workplan
The Work Management Control and Financial Management Control activities are usually synchronized with the status monitoring and reporting activities but they can have
different structures. Project Execution and Control phase techniques you employ in Work Management will be a combination of those used during planning, plus performance
measurement and variance analysis.
Keep the Workplan Realistic
Project manager or an assigned resource control the work progress against the workplan for the phase by iterating through a regular tracking cycle which results in a comparison
of actual progress to workplan. You follow up by directing replanning to adjust the workplan to reality where necessary, and by assigning corrective actions to bring future
performance in conformance with the Workplan.
Warning: Watch for the following pitfalls when performing Workplan Control:
Too much replanning, insistence on a perfect workplan inconsistent with the way the project is being controlled
workplan too general or too detailed to be useful for control stretching the planning baseline to match results
Project activity, but not enough tasks being completed to permit assessment of progress management tasks on the critical path
Task effort on workplan differs from the real assignment in a resource plan. Resources cannot be thrown out if they do not have tasks for few days. This means that the
resource plan should be updated as well with actuals to have a safe approach forward
Good workplan control begins with a workplan against which project members can accurately charge their time at the task level. Each project member should submit a time
record, either in the planning tool or on a separate worksheet, once each week. The total hours recorded against the project should add up to the number of hours charged to the
project in the project accounting system.
Suggestion: Encourage project members to keep an ongoing record during the week of how they spent their time, rather than waiting until the day the time record is due.
Using Earned Value Analysis
Earned value analysis is a technique which is commonly used to add objectivity to financial performance measurement. Earned value method can be used with only hours, days
etc. When you use earned value analysis, your project budget, actuals, and estimates-to-complete are tied closely to project work products giving you a more realistic view of
project work. Earned value analysis involves calculating the value of a work product at a particular point in time, based on the budget and rules that define when the value of a
work product is earned. You use the earned value, budget, actuals, and estimates-to-complete to provide indicators of whether or not work is being accomplished as planned.
Staff Management
During the Project Execution and Control phase, you manage the staff and infrastructure you have already put in place to ensure that your project can efficiently accomplish the
assigned tasks. The techniques you will use most frequently during Staff Management deal with your project staff. In addition to the planning techniques you use to adjust your
project organization, you will need to apply performance management, team building, motivation, leadership, and conflict management skills.
Actively Monitor Your Resources
Repeat the exercise of going through your workplan to check which physical resources will be needed at frequent intervals. As you progress through the phase, you learn more
about it, and better identify your critical resource needs. Keep careful watch over tasks that depend on a resource supplied by the business or a vendor in order to begin. Put
these tasks and milestones on your Workplan to help you monitor them with the client project manager. Act decisively if a project member cites the lack of a physical resource as
the reason for not completing a task on time.
Suggestion: Identify the person responsible for the resource and hold them to their commitment. Ensure that the person actually understands the need and is willing and able to
provide you with the goods and services you expect. Be prepared to encounter dramatic examples of bureaucracy. It can require skillful negotiating and tenacity to acquire or
control things over which you may have no direct authority.
Be a People Manager
As the project manager, the way you utilize your staff will have a profound impact on your project, as well as influencing their professional development. There is a substantial and
dynamic body of knowledge on building, motivating, and leading project teams. Keeping current on these techniques should be a key focus area of your own professional
development.
Suggestion: Do not forget yourself and your project management staff when you plan training for your project. Schedule management training or directed team building sessions
using current training offerings available to you, either internally or commercially.
Document the roles and responsibilities of your team members to clarify goals. If possible, integrate these assignment terms of reference with your organizations performance
management system. When you institute regular reviews of your staffs performance, you can focus your team on project goals and also provide valuable feedback to them and
the consulting practice.
The Project Orientation Guide has been developed to communicate the basic project information to the project team. Update and redistribute it to team members as the
requirements change to maintain consistent performance throughout the project.
Quality Management
Quality Management tasks during the Project Execution and Control phase should be carefully coordinated with execution tasks. Product quality assurance techniques should
include walkthroughs, inspections, technical reviews, and work product reviews. Process quality assurance techniques you will use include auditing, healthchecks, measurement,
and analysis.
Follow the quality assurance process and quality control guidelines documented in the Quality Plan.
Enforce Quality Measures
Integrate quality measurement into every task in some way. Schedule quality reviews to provide visibility and focus management attention on your phases key work products.
Warning: Follow the Project Management Plan on all levels, and do not compromise, even if the project is on a tight schedule. Once you begin to cut corners on delivering quality,
you will ultimately absorb the consequences. Avoid making these types of compromises. It is important that the level of quality measures on the project be appropriate and
accounted for in the Project Management Plan.
Improve the Process
Every quality measure should be able to communicate a message back, whether the message is positive or negative. In any case, the feedback should be constructive and
informative. The recipients of the feedback should never feel like they are being policed by some governing body. Also, your feedback should never be just an identification of
problems. It should always include examples, approaches, and techniques for improving the process, as implemented by the project. A Quality Plan is only effective if you can
take the results and improve the process directly on your project. If you merely measure results, then you have missed the whole point of instituting quality measures.
Configuration Management
During Phase Execution and Control and throughout the project, use Configuration Management tasks to protect the integrity and content of your previous phase baselines and
current phase work products. Configuration Management is a project management process, because it implements policies you establish to safeguard your work products. On an
information technology project, software often represents a large portion of the value your project delivers. Software configuration management (SCM) is especially important to
project managers, because it provides visibility and organization to highly intellectual, intangible software work products.
Make SCM a Natural Part of Project Work
SCM controls are meant to protect much more than damage to work products. Software configuration control includes implementing the appropriate software change, but also
making sure to update any previous or existing work product affected by the change. For example, analysis and design specs/documents must be updated to reflect changes
implemented "downstream". SCM includes managing change and enforcing consistency.
Suggestion: Try to make the SCM system on your project a natural extension of your software development or implementation environment. By doing this, you can enforce SCM
standards while at the same time fostering teamwork, confidence, and security.
Allow Time to Prepare Intellectual Capital
Cleansing of sensitive, proprietary, or confidential information from project work products may require significant effort if the work products are to retain the value of cumulative
project experience. It is important to include an adequate amount of effort in the project workplan to support the effort of identifying what, if anything, should be edited for a larger
viewing audience. As the inventory of reusable components grows, the business will benefit from the reduced effort in the earlier phases of the project since previous knowledge
and work products will be available to offset the cleansing effort. Refer to the contractual requirements prior to scheduling Knowledge Management. Schedule a knowledge
review at the end of each major milestone or phase to facilitate work product preparation.
Attention: Scheduling and conducting a knowledge review helps the project manager facilitate gathering reusable work products and helps ensure that they are properly
cataloged. Knowledge reviews also allow the project team to become aware of other similar projects and the potential use of intellectual capital from those projects.
Managing Project Iterations/Phases
Most projects are divided into multiple units of work resulting in a key milestone. Project phases and project iterations are common examples of how we divide project tasks during
Project Execution and Control.
Iteration/Phase Start Up
At the beginning of each iteration or phase, the Project Management Plan (the key output from the Project Start Up phase) should be revisited and updated as appropriate. The
same process for obtaining approvals will apply during Iteration/Phase Start Up as applied during Project Start Up.
Key areas that are important to revisit/revise during Phase Start Up or iteration start up include (but are not limited to) the project scope, key iteration/phase work products, work
breakdown structure, and staffing.
Iteration/Phase Control
All the tasks in the Project Execution and Control phase are conducted when controlling an iteration/phase. There is no distinction between executing and controlling the project
and executing and controlling an iteration/phase.
Iteration/Phase Completion
At the end of an iteration/phase, the following key Project Execution and Control phase tasks should be conducted.
STM.006 Manage Project Team
QM.050 Perform Quality Assurance
WM.050 Gain Approvals
CMM.030 Manage Project Team Communication
Other Project Execution and Control tasks may be performed as necessary.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. Use this link to access the phase-specific guidance for Scrum.
Back to Top
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product Key Type
Manage Scope, Acceptance and Approvals
SM.030 Manage Scope Managed Scope Y Core
SM.040 Manage Acceptance Managed Acceptance Y Core
WM.050 Manage Approvals Managed Approvals Y Core
Manage Project Finances
FM.040 Manage Project Finances Managed Project Finances Y Core
Manage Project Workplan
WM.030 Manage Project Workplan Project Workplan Y Core
WM.040 Track Schedule Performance Schedule Performance Core
Manage Risk, Issues and Problems
RKM.040 Manage Risk Managed Risk Y Core
RKM.050 Monitor and Control Risk Assessed Risk Core
IPM.040 Manage Issue and Problems Managed Issue and Problems Y Core
Orient and Manage Team
QM.030 Conduct Project Team Quality Management Orientation Project Team Quality Management Orientation Core
STM.050 Conduct Team Orientation Oriented Team Y Core
STM.060 Manage Project Team Managed Project Team Y Core
Manage Communications and OCM Plans
CMM.030 Manage Project Team Communication Project Team Communication Y Core
OCHM.030 Execute Change and Communication Plan Executed Change and Communication Plan Y Core
Manage Project Quality
QM.040 Perform Quality Control Quality Control Y Core
QM.050 Perform Quality Assurance Managed Quality Assurance Y Core
Create and Execute Configuration and Release Management
CM.040 Create and Execute Software Configuration Management Plan Software Configuration Management Plan Y Core
CM.050 Create and Execute Software Release Management Plan Software Release Management Plan Y Core
CM.060 Create and Execute Environment and Patch Management Plan Environment and Patch Management Plan Y Core
CM.070 Create and Execute Configuration Control Plan Configuration Control Plan Y Core
Manage and Maintain Infrastructure
IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Y Core
Manage and Maintain Infrastructure
PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Y Core
Back to Top
ACTIVITY FLOW DIAGRAM
The Project Execution and Control phase is made up of ongoing tasks. In general, ongoing tasks are conducted as needed and not dependent on other tasks in the workplan.
Some tasks, such as reporting tasks, are performed based on a predetermined schedule. This schedule is normally determined and agreed on during the Project Start Up phase.
Tasks that are expected to occur at specific time (i.e., the first Friday of every month), should be added to the project plan.
Back to Top
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
Scope, objectives, and progress of the phase are agreed on and understood by all parties.
All policies, standards, and procedures are incorporated into the tasks comprising the work breakdown structure for the project.
All forms of project communications comprising meetings, reports, documents whether physical or electronic are clear, concise, accurate, and timely to all project team
members.
Commitment from project stakeholders to the projects objectives is maintained.
Continued management of organization and team expectations.
Ensure alignment of project direction and business objectives.
Issues, change requests, problems, and risks are recorded, tracked, reviewed and resolved on a timely basis with clear communication of these items to all parties, and
especially the project sponsors.
Change requests are recorded in a formal way, e.g., documented with analysis of the impact of each change and presented to both organization and implementing
organization sponsors as well as the project change control board.
Project workplans and finance plans accurately capture the work effort and reflect approved change requests.
Project estimate to complete is regularly and consistently updated based upon actual progress against planned progress.
Project management supports and enforces quality measures.
Project work products are protected from unauthorized change and baselines are fully compliant with project requirements.
Back to Top
QUALITY CRITERIA
At the end of this phase, the following criteria should be met or exceeded
Are regular status meetings conducted with project sponsors, and the project teams as well as executive management?
Are change requests recorded, assessed and when appropriate, reviewed with the Change Control Board?
Were project progress reporting requirements gathered? Are these practices followed consistently and on a timely basis?
Have these procedures been incorporated into the projects standards and procedures?
Have all reusable work products been sanitized, reviewed for "leading practices," and harvested for reuse?
Were Healthchecks conducted? Were the results acknowledged and closed out?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MSAA - MANAGE SCOPE, ACCEPTANCE AND
APPROVALS
This activity includes all of the ongoing Manage tasks for managing scope, acceptance and approvals.
Back to Top
OBJECTIVES
The objective of this activity is to manage scope, acceptance and approvals.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.030 Manage Scope Managed Scope Change Request Form
Change Request Log
SM.040 Manage Acceptance Managed Acceptance Acceptance Criteria
Acceptance Certificate
WM.050 Manage Approvals Managed Approvals Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the processes documented in the Scope Change Management Processes and manage any possible scope changes (Change Requests) as
defined.
Gain acceptance from the client on the completed work products.
Manage the approval of project work products based on the procedures defined in the Work Product Approval Process component of the Work Management Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MPF - MANAGE PROJECT FINANCES
This activity includes the ongoing Manage task to manage the project financials during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is execute and control the project to deliver within budget and on-time.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
FM.040 Manage Project Finances Managed Project Finances Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The task within this activity is ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the processes documented in the Financial Management Plan and the Time and Expense Tracking and manage the financial aspects of the
project.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MPW - MANAGE PROJECT WORKPLAN
This activity includes all of the ongoing Manage tasks to manage the Project Workplan and track the scheduled performance during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is put into practice the strategy, processes and procedures documented in the Work Management Plan to engage resources to execute the
Project Workplan as well as periodically measuring actual project accomplishments against what was planned.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
WM.030 Manage Project Workplan Project Workplan Assignment Request
Deliverable Tracking Spreadsheet
Unplanned Activity Log
Iteration End Report
WM.040 Track Schedule Performance Schedule Performance Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the strategy, processes and procedures documented in the Work Management Plan to engage resources to execute the Work Management Plan
and regularly review and update the Project Workplan with the actuals.
Track scheduled performance in order to measure actual project accomplishments against what was planned.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MRIP - MANAGE RISKS, ISSUES AND PROBLEMS
This activity includes all of the ongoing Manage tasks for managing risks, issues and problems.
Back to Top
OBJECTIVES
The objective of this activity is to manage risks, issues and problems.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
RKM.040 Manage Risk Managed Risk Refer to the Task Overview for guidance.
RKM.050 Monitor and Control Risk Assessed Risk Monitor and Control Risk
IPM.040 Manage Issues and Problems Managed Issues and Problems Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Execute the process detailed in the Risk Management Plan for the potential risks identified in the Identified Risks Watch List.
Executing the procedures detailed in the Risk Management Process for unplanned or NEW risks that were not already identified in the Identified Risks Watch List.
Put into practice the processes documented in the Issue Management Strategy and Problem Management Strategy and manage any issues/problems as defined.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.OMT - ORIENT AND MANAGE TEAM
This activity includes all of the ongoing Manage tasks to conduct the team orientation(s) and manage the project team during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to conduct the team orientation(s) and manage the project team during the execution of the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
QM.030 Conduct Project Team Quality Management
Orientation
Project Team Quality Management
Orientation
Project Team Quality Management Orientation
Presentation
STM.050 Conduct Team Orientation Oriented Team Project Kickoff Presentation
STM.060 Manage Project Team Managed Project Team Individual Status Report
Assignment Request
Assignment Terms of Reference
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Conduct Project Team Quality Management Orientation. This orientation can be conducted as part of the Project Kickoff meeting.
Plan and conduct a Project Kickoff meeting to orient the team to the project. If necessary, similar orientation meetings can be given for new team members that join
the project after kickoff.
Put into practice the procedures documented in the Staff Management Plan and manage the staff.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MCOP - MANAGE COMMUNICATIONS AND OCM
PLANS
This activity includes all of the ongoing Manage tasks to communicate with the project team and the client organization that are performed during the execution of the
project.
Back to Top
OBJECTIVES
The objective of this activity is to effectively communicate with the project team and the client organization.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
CMM.030 Manage Project Team Communication Project Team Communication Meeting Minutes
Weekly Project Status Report with Instructions
Weekly Project Status Report
OCHM.030 Execute Change and Communication Plan Executed Change and Communication Plan Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the reporting requirements, scheduled meetings and procedures documented in the Project Team Communication Plan and manage
communication.
Execute the Change and Communication Plan developed as part of the Client's Organizational Change Management Strategy.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MPQ - MANAGE PROJECT QUALITY
This activity includes all of the ongoing Manage tasks to manage quality control and perform quality assurance during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is manage quality control and perform quality assurance.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
QM.040 Manage Quality Control Quality Control Review Comments List
Review Leader Form
QM.050 Perform Quality Assurance Managed Quality Assurance Audit Action Report
Audit Report
Quality Report
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Execute the Quality Control and Reporting Process.
Apply the planned, systematic quality activities and any ongoing processes documented in the Quality Management Plan to ensure that the project employs all
delivery processes needed to meet requirements.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.CECRM - CREATE AND EXECUTE CONFIGURATION
AND RELEASE MANAGEMENT
This activity includes all of the ongoing Configuration Management tasks that are performed during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to establish the Software Configuration Management Plan, the Software Release Management Plan, the Environment and Patch
Management Plan and the Configuration Management Control Plan as well as monitor the key elements of configuration management identified in the Configuration
Management Control Plan and making any adjustments, as necessary.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
CM.040 Create and Execute Software Configuration Management Plan Software Configuration Management Plan Software Configuration Management Plan
CM.050 Create and Execute Software Release Management Plan Software Release Management Plan Software Release Management Plan
Release Note
CM.060 Create and Execute Environment and Patch Management Plan Environment and Patch Management Plan Environment and Patch Management Plan
CM.070 Create and Execute Configuration Control Plan Configuration Management Control Plan Configuration Management Control Plan
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Create and execute the Software Configuration Management (SCM) Plan.
Create and execute the Software Release Management Plan.
Create and execute the Environment and Patch Management Plan.
Create and execute the Configuration Management Control Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MMI - MANAGE AND MAINTAIN INFRASTRUCTURE
This activity includes the ongoing Manage task to manage and maintain the infrastructure during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to manage and maintain the project infrastructure.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Equipment Fault Record
Back to Top
ITERATIONS
The task within this activity is ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Monitor Infrastructure Management activities using the processes, procedures, controls and metrics defined in the Infrastructure Management Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
#TOP #TOP
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.APGCS - ADMINISTER PROCUREMENT OF GOODS
AND CONTRACTED SERVICES
This activity includes the ongoing Manage task to administer the procurement of goods and contracted services during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to administer the procurement of goods and contracted services.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Incoming Item Record
Rejection Note
Back to Top
ITERATIONS
The task within this activity is ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Manage the procurement of goods and services based on the previously defined Procurement Strategy and Process.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[PC] PROJECT CLOSURE
The purpose of the project closure phase is to validate that the project work products or task outputs are complete and are aligned with the accepting organizations
expectations, gain final acceptance and close the project. The team must also review the project work products for examples of leading practices. These work products
should be secured for reuse, collection and retention of empirical data.
A project or phase of a project will be considered closed when all Project Management and work products have been completed, approved by necessary approving
bodies and archived.
Two types of closure activities are described in Manage:
Administrative Closure:
Administrative closure is classified as the mechanical and analytical steps associated with the closure activities associated with either the conclusion of a phase or project.
These steps are clerical, organizational, and diagnostic in nature and are meant to serve as a vehicle to bring to a successful conclusion (with the appropriate level of
rigor) all aspects of project operations.
Typically tasks associated with administrative closure procedures are:
Completing closure checklists
Completing proper signoff documentation
Archiving all project documentation
Reviewing final project work products with project stakeholders
Completing lessons learned documentation and review sessions
Completing project acceptance reports
Closing or transitioning all outstanding issues
Closing or transitioning all outstanding risks
The Project and Phase Close-Out procedures are comprised in the following steps and are administrative in nature:
Closeout Checklists - There are checklists, to be completed throughout the lifecycle of the project, which are at the Project level, the Phase level, and at the
Contractual level.
Conduct Lessons Learned - The Project Manager conducts the Lessons Learned process with the project team and documents all findings.
Project Acceptance Report - At the conclusion of a project there is a requirement to produce a project acceptance report which assembles all the key information
related to the project operations.
Operational Sustainment Report - At the conclusion of the project and when the project team transfers operational support duties to the sustaining operational
organization there may be a requirement to develop an operational sustainment report. This report is intended to provide key information to the sustaining
organization regarding unique support and operation requirements of the solution and key developments during the post-production support and stabilization
period.
Archive All Project Documents - It is prudent for all documentation to be archived
Contractual Closure:
Contractual closure is classified as the obligatory steps associated with the completion of contractual requirements. Contractual closures can be with external vendors or
internal through service level agreements. Typical tasks associated with contractual closure procedures are:
Review all contractual obligations.
Secure sign-off on all contractual obligations.
Secure payment for final invoices.
Obtain written acceptance.
Learn new ways to improve satisfaction and thus the number of references.
The following represent the contractual closeout procedural requirements for external vendors:
Review all contractual deliverables to enable acceptance and address all open items.
Review prior, current, and pending invoicing activities.
Review all approved change requests for completeness.
The following represents the service level agreement closeout procedural requirements:
Secure hardcopy or electronic version of all sign-off forms
Review all service level agreement deliverables to enable acceptance and address all open items.
Review all approved change requests for completeness.
Review all service level incidences.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Make sure that the business requirements and expectations have been aligned to the organization's expectations.
Record all project data and metrics as well as lessons learned from the project.
Obtain formal acceptance of the project.
Pay all invoices.
Capture and submit project intellectual capital.
Close out the project by following an exit plan.
Release staff and physical resources.
Gain final acceptance of all project work products.
Close out the contractual agreement, if any, with the accepting organization.
Hand over project work products and environments to the production support team (as appropriate).
Document and archive project results.
Back to Top
PROCESSES
The Manage context diagram illustrates the processes within the Project Closure phase.
Back to Top
TIPS AND TECHNIQUES
This section discusses techniques that may be helpful in conducting Project Closure including the managing the administrative and contractual closing of the project with
the accepting organization and the delivery organization. Techniques you find most useful are communicating, negotiating, and conflict resolution. The general approach
recommended for Project Closure is to make the accepting organization responsible for conducting agreed upon acceptance tasks, such as testing. However, specific
terms and conditions may be detailed in the contractual agreement and should be reflected in project management plans.
Manage Acceptance Expectations Carefully
When conducting Project Closure, remember to continue to manage changes, issues, and problems throughout acceptance. Last minute issues and problems can be
quite common, as client stakeholders realize that they have only a short time remaining to influence project results. The project sponsor and project manager, from the
accepting organization, should take a leadership role at this point in the project to control the introduction of new issues which may be more accurately classified as future
enhancements. Use of the MoSCoW list and conducting incremental reviews, throughout the engagement can assist in avoiding such issues
Feed Back Results to the Delivery Organization
It is easy to focus on contractual and resource issues during the final days of a project. However, do not forget that your project has advanced the capabilities of the
delivery organization and has hopefully produced a product that the delivery team and the accepting organization are proud of. While you have the time, staff, and
accepting organization contacts available, make sure to feed project results back to the delivery organization. Use the Project End Report to capture information about
the project for future use and to benefit future projects. The Satisfaction Report will provide objective information about project results to the delivery organization
management team.
Staff Management
Coordinate closely with your delivery organization business manager about resource needs after the project closes (or the engagement is considered complete). There
may be uncompleted negotiations regarding a support or ongoing maintenance requirements which could retain some of the project staff. Ideally, post-project
commitments have been established before the project begins. Depending on the length of the project requirements may have changed regarding what happens after the
project. Once post-project commitments to the accepting organization have been refined, staff can be reallocated. In practice, as the project is in the completion phase,
then reallocation can be started.
Physical resources can easily become lost or intermixed in a project infrastructure shared with the accepting organization. If you have maintained accurate equipment
records, you should be able to sort out which equipment, licenses, and materials are to be retained by the delivery organization and which will be retained by the
accepting organization. The project agreement or contract contains this information and should be reviewed as part of this closing phase.
Quality Management
At this point in the project, previous phase acceptances should have already established a clear pattern of quality compliance. Use the final Quality Report as a tool to
support your final approval, or to help resolve any contractual disputes or issues regarding the quality of your project work products
Configuration Management
The transfer of the Configuration Management environment to the accepting organization should be coordinated with transfers of other project environments, specifically
those for development, maintenance, and testing. The amount of transfer is project-specific, and should be worked out well in advance, ideally as part of the contractual
agreement.
Archive Project Work Products
Configuration Management is also responsible for transferring archive copies of project work products to your consulting practice. Follow your practice policies and
procedures about archiving project work products. Consider these questions before contributing your work:
Do you have the legal right to remove work products? Check the contractual agreement. Also, it is good practice to inform the accepting organization of your
intentions and ask for permission, even if you have legal authority.
Does the accepting organization have any legal or other reservations about using the accepting organization name in the body of the materials? If so, then you
must replace that name with one that is generic so work products cannot be traced to the accepting organization.
Does the work product require any more information in order to be a valuable project artifact? If so, then add a preface to the work product with the proper
explanation or substitute the work product prior to adding to any knowledge management system or project archive.
Attention: Take legal restrictions seriously. The accepting organization may have confidential information that if disclosed, even as a sample, to their competitors would
be detrimental to their position in the marketplace. The delivery organization has an obligation to protect the information of accepting organization. You may be placing
the accepting organization in legal and financial risk if you were to disclose such information.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. Use this link to access the phase-specific guidance for Scrum.
Back to Top
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product Key Type
Gain Acceptance
SM.030 Gain Acceptance Final Acceptance Certificate Y Core
Close Processes and Contract
SM.060 Close Scope Management Closed Scope Management Core
SM.070 Identify Future System Enhancements Future System Enhancements Core
FM.050 Close Project Financials Closed Project Financials Y Core
WM.060 Close Work Management Closed Work Management Y Core
RKM.060 Conduct Post-Production Risk Assessment Post-Production Risk Assessment Y Core
IPM.050 Produce Final Issue and Problem Report and Close Log(s) Closed Issue and Problem Log Core
STM.070 Release Staff Released Staff Core
CMM.060 Submit Final Reports Final Reports Core
QM.060 Conduct Post-Production Quality Review Post-Production Quality Review Y Core
CM.080 Close Configuration Management Closed Configuration Management Core
IFM.050 Close Infrastructure Closed Infrastructure Core
PCM.040 Close Contract Closed Contract Y Core
OCHM.040 Establish Follow-up Process Follow-up Process Core
Document Lessons Learned and Archive Project
CMM.040 Document Lessons Learned Lessons Learned Y Core
CMM.050 Turn Over Project Documentation Project Archives Y Core
Back to Top
ACTIVITY FLOW DIAGRAM
Back to Top
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
The accepting organization perceives the value of the project.
The expectations and business requirements of the accepting organization have been met.
Satisfaction concerns are identified and addressed prior to requesting acceptance of work products.
All financial obligations are paid by the accepting organization.
The accepting organization will provide references.
The projects financial performance criteria has been accurately measured.
Outstanding issues and problems which affect phase work products are resolved prior to their acceptance.
Change control, configuration control, and quality records are complete and accurate, and demonstrate compliance with project standards.
Early attention was given to acceptance planning and definition of acceptance criteria.
Good relationship between delivery and accepting organization achieve through collaboration and managed expectations.
Incremental reviews have been conducted throughout the project (with adequate attendance by accepting organization) and time has been allowed for rework
during incremental acceptance. This results in less time begin needed for rework in the final acceptance.
Back to Top
QUALITY CRITERIA
At the end of this phase, the following criteria should be met or exceeded
Have the accepting organizations business requirements been satisfied?
Have the accepting organizations expectations been met?
Has the accepting organization approved all final work products?
Has the final project work product been packaged and signed off by the accepting organization?
Have all outstanding financial obligations been paid?
Have all work products been harvested for reuse?
Does the project manager understand document retention requirements?
Have all open issues been resolved?
Have all problems been resolved?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PC.ACT.GA - GAIN ACCEPTANCE
This activity includes gaining formal acceptance for the project from the client.
Back to Top
OBJECTIVES
The objective of this activity is to gain formal project acceptance.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.050 Gain Acceptance Final Acceptance Certificate Acceptance Certificate
Project Acceptance Report
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Review the contract to make certain that all contractual obligations are met.
Ensure that all sign-offs have been received.
Back to Top
PREREQUISITES
You will need the following for this activity:
Contract
PS.ACT.CPMP Complete Project Management Plan
Project Execution and Control Activities
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PC.ACT.CPC - CLOSE PROCESSES AND CONTRACT
This activity closes out the project processes for each of the project management processes. In addition, the contract is reviewed to make sure that all obligations have
been met.
Back to Top
OBJECTIVES
The objective of this activity is to update all final reports and verify that the contract obligations have been met.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.060 Close Scope Management Closed Scope Management Scope Management Lessons Learned
SM.070 Identify Future System Enhancements Future System Enhancements Future System Enhancements
FM.050 Close Project Financials Closed Project Financials Financial Management Lessons Learned
WM.060 Close Work Management Closed Work Management Work Management Lessons Learned
RKM.060 Conduct Post-Production Risk Assessment Post-Production Risk Assessment Post-Production Risk Assessment
Risk Assessment Lessons Learned
IPM.050 Produce Final Issue and Problem Report and Close Log(s) Closed Issue and Problem Log Issue and Problem Management Lessons Learned
STM.070 Release Staff Released Staff Refer to the Task Overview for guidance.
CMM.060 Submit Final Reports Final Reports Project Closure
End Report
Engagement Summary
QM.060 Conduct Post-Production Quality Review Post-Production Quality Review Client Satisfaction Report
Project Healthcheck Checklist
Metrics Report
CM.080 Close Configuration Management Closed Configuration Management Configuration Management Lessons Learned
IFM.050 Close Infrastructure Closed Infrastructure Refer to the Task Overview for guidance.
PCM.040 Close Contract Closed Contract Supplier Assessment Record
OCHM.040 Establish Follow-Up Process Follow-Up Process Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Close processes and reports for each of the Project Management processes.
Close contract.
Establish follow-up procedures.
Back to Top
PREREQUISITES
You will need the following for this activity:
Contract
PS.ACT.CPMP Complete Project Management Plan
Project Execution and Control Activities
PC.ACT.GA Gain Acceptance
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PC.ACT.DLLAP - DOCUMENT LESSONS LEARNED AND
ARCHIVE PROJECT
This activity compiles the lessons learned through project execution and control and it archives the project.
Back to Top
OBJECTIVES
The objective of this activity is to document areas of improvement for future engagements and areas that were performed well.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
CMM.040 Document Lessons Learned Lessons Learned Lessons Learned
CMM.050 Turn Over Project Documentation Project Archives Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Document Lessons Learned
Turn Over Project Documentation
Submit Final Reports
Back to Top
PREREQUISITES
You will need the following for this activity:
PC.ACT.GA Gain Acceptance
Project Execution and Control Activities
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[BT] BID TRANSITION
The Bid Transition process, although represented in Project Start Up, is in reality more of a project initiation task. The first major activity that a project manager is
expected to perform is to participate in the handoff from the "sales cycle" to the "delivery cycle".
It is critical to the success of the project that the project manager and any other groups/subject matter experts that will take part in the project have a full understanding of
important facets of the project such as the contract conditions, assumptions, project site, scope, staffing, financials, customer needs, work products, time schedule, cost,
performance criteria (quality), and business case.
It is important to recognize the difference between contract management and project management. For example, the contract determines the scope of the project, the
financial terms, project timeline, and the specific work products that are expected. A project manager must meet these contractual responsibilities. Project management
focuses on managing the scope, time schedule, responsibilities, and resources of the project. A good project manager must keep track of and control both the contractual
responsibilities and project responsibilities.
The project manager must accept the handover from sales. Acceptance means that the project manager is accountable for the project, not simply fully understanding the
context as a passive spectator, but accepts responsibility for the project with all the constraints handed over by the sales cycle. Because the sales cycle is not
responsible for delivery, the project manager should recalculate the cost and time schedule and if a deviation occurs re-negotiate the project conditions.
This must be achieved not only through review of the bid and proposal material, but also by having the bid team transition their understanding of the bid to all those
individuals involved in the start up of the project so that these individuals gain an understanding of the bids assumptions from all perspectives.
The bid material will contain the projects baseline information. However, this information must be validated both internally and with the client.
The bid material including project scope, project approach, key work products, and the acceptance criteria must be reviewed to determine any ambiguities, risks, issues,
and changes that must be addressed with the client during the validation process.
Obligations and the projects financials must be reviewed and validated with the owning cost center.
PROCESS FLOW
The Bid Transition process does not dictate a specific flow or order that the tasks should be performed. In general, the tasks should be performed sequentially, but no
constraints, other than the project manager's time, keep Bid Transition tasks from being performed in parallel.
Back to Top
APPROACH
The Bid Transition process is the first activity in the Project Start Up phase of Manage. It is critical to the project's success that the tasks outlined in the Bid Transition
process be performed. A project manager must understand the contract and must review that understanding with the customer.
In general, the Bid Transition process is the opportunity for the project manager to fully understand the business case and the contracted approach to meeting the
business objectives.
The Bid Transition process offers the project manager an opportunity to:
Meet with the Sales Team to ensure that the contract is understood.
Meet with the client to confirm the project scope, objectives, and project timeline. The business case and project approach should also be discussed and agreed.
Document any changes to the contract or bid material and to re-baseline the project with these changes.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS BT.010 Review and Analyze Bid Material Reviewed and Analyzed Bid Management Core
PS BT.020 Review and Confirm Business Case Confirmed Business Case Core
PS BT.030 Identify Project Stakeholders Identified Project Stakeholders Core
PS BT.040 Review and Accept Project Budget Accepted Project Budget Core
PS BT.050 Review Contract with Client Reviewed Contract Y Core
PS BT.060 Review Project Approach with Client Reviewed Project Approach Y Core
PS BT.070 Create Project Management Framework Project Management Framework Y Core
Back to Top
OBJECTIVES
The objectives of the Bid Transition process are:
Handoff the project from the Bid Team "sales cycle" to the Project Manager "delivery cycle".
Document and communicate the contractual responsibilities.
Document and communicate the project responsibilities.
Identify and document the Project Stakeholders.
Review and validate obligations and project financials.
Reach agreement between the project manager and the owning cost center as to the project scope, objectives, approach, budget and expected financials.
Reach agreement between the project manager and the client as to designated obligations and the project scope, objectives and approach.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
CPM Client
Project
Manager
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.010 - REVIEW AND ANALYZE BID MATERIAL
The Review and Analyze Bid Material task occurs after the project manager is assigned to the project. The project manager gathers and reviews all the available bid
material. This includes informal documentation from the sales team who participated in the demo such as their discovery documents, any non-standard requirements that
were noted and/or demonstrated to the customer and possibly correspondence between the implementing organization and the prospect. Some projects may not result
from a sales process. In this case, materials similar to a bid that would provide project background, deliverables and budget information should be used.
If the project manager determines that changes are needed to the bid Material or the contract, then these changes must be communicated to, reviewed with, and
approved by the appropriate areas.
Gather and review all bid material from contracts, operations, bid manager(s), and the Risk Management review.
Analyze and document key organizational risks.
Review contract for critical areas.
Confirm commitment to deliver.
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Reviewed and Analyzed Bid Material - The Reviewed and Analyzed Bid Material may include the following components:
Reviewed Bid Material
Confirmed Presence of Key Organizational Risks
Reviewed Contract
Reviewed Contract work product Schedule
Commitment to Deliver Engagement
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather and review all bid material. Reviewed Bid
Material
The Reviewed Bid Material is a collection of all the material gathered,
organized and cataloged for reference as needed during the project.
2 Confirm presence of key organizational risks. Confirmed
Presence of Key
Organizational
Risks
The Confirmed Presence of Key Organizational Risks consists of a
stakeholder organizational chart showing the key stakeholders.
Include placeholders for TBD, unidentified or missing stakeholders.
Add identified risks to the overall project risk analysis.
3 Review the contract to determine critical areas. Reviewed
Contract
The Review Contract component document a summary of the critical
areas of the contract.
Add identified risks to the overall project risk analysis.
4
Review Contract's deliverable schedule.
Reviewed
Contract
Deliverable
Schedule
5 Confirm commitment to deliver. The project manager should verify they
can commit to the delivery of the project based on all updated
information. This includes scope, resources, timelines, project profit, etc.
Commitment to
Deliver
Engagement
The Commitment to Deliver Engagement is an email and/or other
communication that confirms the commitment to proceed with the
engagement.
Back to Top
APPROACH
Gather and Review Bid Material
If available, gather and review the following materials:
contract and associated documentation
bid documents
project organization
proposal or statement of work
project estimate
initial risk analysis
project staff plan
sub-contractor scope and contract terms, if applicable
approval emails
high-level workplan
business case (if completed by implementing organization, third-party or client)
client's request for information (RFI) and request for proposal (RFP) and request for quote (RFQ)
responses to RFI, RFP and RFQ
Confirm that you have the answers to the following 5 key questions regarding organizational risks:
Has the client experienced a merger or acquisition in the last three years?
Has the client faced previous failures in implementing new technologies?
Is this a multiple site implementation with all organizations (or subsidiaries) required to adapt to the implementing organization's leading practice processes which
will drive significant organizational change?
Will this project impact whether the organization will conduct business in a centralized or decentralized environment?
Are internal communications for employees mostly informal (i.e. ad hoc) and not a on a regular recurring basis?
Confirm Presence of Key Organizational Risks
Perform analysis to identify and confirm the availability and appointment of client sponsors, oversight or program management, infrastructure support, and other client
stakeholders.
Review Contract
Review the contract to determine critical areas.
Review Contract's Deliverable Schedule
Review the contract's deliverable schedule in the contract to determine milestones that need to be reflected in the projects workplan and possibly in the project
accounting structure.
Confirm Commitment to Deliver
Confirm commitment to delivery. The project manager should verify they can commit to the delivery of the project based on all updated information. This includes scope,
resources, timelines, project profit, etc.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Contract and Associated Documentation These are the bid materials you should get from the bid manager and review
Bid Documents
Project Organization
Proposal or Statement of Work (SoW)
Project Estimate
Initial Risk Analysis
Project Staff Plan
Sub-Contractor Scope and Contract Terms, if applicable
Approval Emails
High-Level Workplan
Business Case (if completed by implementing organization, third-party or client)
Client's Request for Information (RFI) and Request for Proposal (RFP) and Request
for Quote (RFQ)
Responses to RFI, RFP and RFQ
, if available.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT010_REVIEWED_AND_ANALYZED_BID_MATERIAL.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.020 - REVIEW AND CONFIRM BUSINESS CASE
This Review and Confirm Business Case task makes certain that the project manager has a clear understanding of the business case for the project. A project manager
who understands the purpose of the project and clearly understands what the project is trying to achieve, will be much better equipped to address both the customer's
and the implementing organization's expectation for a successful project. This is especially important during the execution of the project when scope changes are
requested. The direction of the project should always tie back to the business case.
To help businesses achieve the transformations envisioned, project managers must take steps to verify that the project is closely aligned to an underlying business
strategy or business case from the outset. Specific business performance metrics should to be adopted, understood and confirmed throughout the projects life span to
validate project success. Defining and reviewing performance metrics will help keep the client focused on the actual business value of the project. Conversely, if there is
not a clear, compelling business case for the project and/or there is not a clear, direct connection between the project and a key business strategy, the project manager
should treat this gap as a major risk to the client and the project
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Confirmed Business Case
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review or identify the Business Objectives, Critical
Success Factors and associated Specific
Performance Metrics.
Business Case The Business Case describes what business objectives are being satisfied by the
project. It includes Business Objectives, Critical Success Factors and
Performance Metrics.
2 Identify specific Business Performance Metrics. Business Performance
Metrics
The Business Performance Metrics document the metrics.
Specific Performance Metrics may not have been gathered during the sales
cycle.
3 Identify gaps as project risks. Business Case Gaps The Business Case Gaps documents gaps as project risks.
4 Consider hosting an Executive Workshop to fill gaps. Business Case Gaps
Executive Workshop (if
appropriate)
Back to Top
APPROACH
The project manager has to know the critical success factors of the project. Projects can finish on time, under budget, and within scope, but be deemed a failure. If a
team finishes a project without regard to whether the work addresses the needs of the stakeholders, the project is unsuccessful.
In some cases, the original request for proposal and the associated response will identify the projects business objectives. If the project manager has not been involved in
the sales cycle, the project manager should contact the appropriate personnel within the implementing organization (for example, account executive, product consultants,
client executive, or anyone else who was involved in the sales cycle) to find out what was discussed during the demonstrations and if any hot issues surfaced at that
time.
The original request for proposal (RFP) may also give a good indication of what the organization considered to be important objectives prior to reviewing any vendors
products. If the RFP does not define the objectives, ask to see the clients internal documents that describe the business objectives the project is expected to achieve.
Ideally, the business case will focus on concrete business objectives and will identify an associated metric for each objective. It should be possible to map the business
objectives back to the business requirement definition. The objectives should be prioritized by the positive impact each will have on the organization. This is a good
opportunity to gain consensus on which objectives will be addressed as part of the current project and which will be deferred to a subsequent phase.
Some examples of business objectives include:
Decrease cycle counting cost by XX% with better inventory tools
Close the books Y days earlier with integrated applications
Generate invoices quicker and more accurately with improved pricing techniques
If none of the business objectives are written or documented, consider an Executive Strategy workshop with the major stakeholders, executives, and key users. The
workshop should drive out key business objectives that led to the software purchase. Oracle offers Executive Workshops.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Bid Material (Bid Preparation and Bid Review Process)
Contract (Contract Preparation Process)
Review these materials to confirm the Business Case.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT020_CONFIRMED_BUSINESS_CASE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.030 - IDENTIFY PROJECT STAKEHOLDERS
A stakeholder is defined as a person, group, or business unit that has a share or an interest in a particular activity or set of activities.
In this task, identify project stakeholders. Project stakeholders should be identified as early as possible. The success of the project increases when an active stakeholder
is identified and involved with the project.
Identify a stakeholder who has a vested interested in completing the project successfully. Optimally, the stakeholder should have the authority and contacts to influence
others to commit resources to the project.
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Identified Project Stakeholders
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify implementing organization stakeholders. Internal Stakeholders This component lists all the stakeholders from the implementing
organization, that is, the project manager's organization.
2 Identify client (end user) stakeholders. Client (end user)
Stakeholders
This component lists all the stakeholders from the client
organization.
3 Identify prime contractor stakeholder (if a third party organization is
involved as the primary implementing organization).
Prime Contractor
Stakeholders (if
appropriate)
This component lists all the stakeholders from the third-party
organization.
4 Identify sub-contractor stakeholders (if a third party organization is
involved but not acting as the primary).
Sub-contractor
Stakeholders (if
appropriate)
This component lists all the stakeholders from the third-party
organization.
Back to Top
APPROACH
For each organization, identify the stakeholders along with each stakeholders interest and influence in the project. At a minimum these should include the executive
sponsors, other sponsors, the functional organizations and/or individuals who will use the environment resulting from the project, the project manager(s), and
organizations providing resources to the project effort. Stakeholder interests and influence may overlap or there may be identifiable differences between the interests of
some stakeholders.
All stakeholders may be identified in a single form document although occasionally it may be appropriate to use a separate form to identify stakeholders for separate
organizations.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Sales Team Notes (Bid Development Process)
Bid Team Notes (Bid Review Process)
Review these items to identify potential project stakeholders.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Stakeholder Capturing This technique provides guidance on what information should be captured about each stakeholder.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT030_IDENTIFIED_PROJECT_STAKEHOLDERS.XLS MS EXCEL
All stakeholders may be identified in a single form although occasionally it may be appropriate to use a
separate form to identify stakeholders for separate organizations.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.040 - REVIEW AND ACCEPT PROJECT BUDGET
The expectation is that the bid financials will be adopted as the project budget. In the Review and Accept Project Budget task, the project manager reviews the bid
financials prior to establishing the initial Project Baseline Budget. If after the review, the project manager can make a compelling, fact-based argument to the responsible
Portfolio Management team that the bid financials are not achievable, a revised baseline project budget may be set and agreed to. This revised budget baseline (revenue
and margin) becomes the financial targets to which the project will be held.
The final, agreed upon project budget (revenue and margin) must then be documented and used as a baseline to monitor the projects financial performance.
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Accepted Project Budget
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review initial bid financials and create
Baseline Project Budget.
Baseline Project Budget
At a minimum, the Baseline Project Budget includes:
the final bid material
the estimate
the final Contract
Suggestion: Create a .zip file for the Baseline Project Budget including all of its
components. Made the Baseline Project Budget available to appropriate team members
through a project workspace or another collaborative environment.
2 Verify the budget with the final
contract and assumptions. Create a
revised estimate as necessary.
Revised Project Budget
3 Verify or create the staff plan. Revised Project Staff Plan
4 Apply the appropriate expenses,
Hosting, etc. to accurately estimate
the total cost.
Revised Project Cost
Estimates
5 Verify the revised project financials
against the bid financials.
Verified Project Financials
6 Discuss the results of the review with
the Portfolio Management team.
Meeting Notes Documenting
the Results of the Discussion
and Final Agreement
7 Accept project budget. Accepted Project Budget. Once the project budget is accepted, the appropriate time and expense tracking system can
be set up.
Back to Top
APPROACH
Use your organization's estimating tool or model to verify the project estimate or create the revised project estimate.
Document the required Staff Plan by level over time along with other factors such as but not limited to hosting and sub-contractors etc. and to document the final revised
project budget for cost, revenue and margin.
Back to Top
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Reviewed and Analyzed Bid Material (BT.010)
Confirmed Business Case (BT.020)
This material contains the information you need to review and accept the project budget.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.050 - REVIEW CONTRACT WITH CLIENT
It is essential to the overall success of the project for the project manager to reach a clear understanding and agreement with the client stakeholders as to the scope,
objectives, approach, assumptions and contractual terms governing the project. To facilitate this understanding and to establish a positive foundational relationship for
the project, the project manager conducts a contract review with the client project sponsor, project management and any third-party project managers.
During this review, the following items should be discussed:
Review the contract with the client.
Determine adequacy of all contractual roles in the engagement.
Understand explicit deliverables. Clarify implicit deliverables such as performance tuning, etc.
Review and validate the project acceptance criteria. Make sure both parties agree on the acceptance criteria and that they are well documented. This includes
agreement/PM sign-off.
Document all gaps and agreements.
ACTIVITY
PS.ACT.RPAC Review Project Assets with Client
Back to Top
WORK PRODUCT
Reviewed Contract
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review the contract with the client. Understanding of Explicit and
Implicit Deliverables
None
2 Determine adequacy of all contractual
roles in the engagement.
Contractual Roles The Contractual Roles lists all the roles for the engagement and verifies the project
roles meet the given expectations in the contract.
3 Review and validate the project
acceptance criteria.
Validated Project Acceptance
Criteria
4 Identify all gaps and agreements. Gaps, Agreements, and Action
Items
Back to Top
APPROACH
Review the Contract with the Client
Understand explicit deliverables. Clarify implicit deliverables such as performance tuning, etc.
Determine Adequacy of All Contractual Roles
Determine adequacy of all contractual roles in the engagement, that is, is the project staffed appropriately given the expectations in the contract.
Review and Validate the Project Acceptance Criteria
Make sure both parties agree on the acceptance criteria and that they are well documented. This includes agreement/PM sign-off.
Identify All Gaps and Agreements
Following the client meeting, document to the client, in writing, the areas of agreement, gaps, and action items. The action items should include the name of the person
responsible for the action and the date the action should be completed. One action item may be to initiate the first Scope Change for the project that may or may not
have a financial impact on client funding. It does however set an example for the use of the Scope Management process.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
25
Project Manager 75
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Contract (Contract Preparation Process) This is the document that you need to review with the client.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT050_REVIEWED_CONTRACT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.060 - REVIEW PROJECT APPROACH WITH CLIENT
Review the project approach with the client. The project approach includes the method (Oracle Unified Method), the project site, duration, administration, infrastructure,
and workplan.
The project approach should also address areas such as incremental development specifically detailing any increment scope and contractual deliverables, blended
delivery and other project approaches.
ACTIVITY
PS.ACT.RPAC Review Project Assets with Client
Back to Top
WORK PRODUCT
Reviewed Project Approach
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review and validate the obligations of all involved parties (that is, the
client, the implementing organization and any third-parties).
Validated Project
Parties' Obligations
2
Review the project approach including the following main areas:
Project Method(s)
Strategy
Plans
Client Organization
Acceptance
Project Administration
Project Infrastructure
Reviewed Project
Approach
3 Document all agreements, gaps and action items. Agreements, Gaps
and Action Items
4 Obtain agreement and Project Management sign-off. Signed Off Project
Approach
Confirm agreements and gaps along with any assigned action
items. Include a signature line for the client to sign-off.
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
25
Project Manager 75
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You will need the following for this task:
Prerequisite Usage
Scope, Objectives and Approach (Bid Preparation/Bid Review/Contract Preparation
Processes)
Use the Scope, Objectives and Approach to validate the project approach
with the client.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT060_REVIEWED_PROJECT_APPROACH.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.070 - CREATE PROJECT MANAGEMENT FRAMEWORK
The Create Initial Project Management Plan Framework is the last task in Bid Transition. It also marks the beginning of the Project Start Up phase. The Project
Management Framework is the first component of the Project Management Plan (PMP).
The creation of the PMP is started with the Project Management Framework in this task. The project manager creates the Project Management Framework along with the
project sponsor and other stakeholders. At this point in the project, the Project Management Framework represents the PMP at the strategic level. In fact, the Project
Management Framework can be thought of as the initial or high-level version of the PMP. Together, each of the Manage process components are discussed and the
project manager and the client agree on a high-level approach for each process.
After the Project Management Framework is created early in the Project Start Up phase, it is then used as a key prerequisite for each of the Manage process plans --
Scope Change Management Plan, Quality Management Plan, Risk Management Plan, etc. The PMP is refined in an iterative fashion through input and approval from the
various project stakeholders and subject matter experts as the project progresses. This means the PMP is not a status document but is evolved to become the project
management artifact that details the tools and approach for each of the 13 OUM Manage processes. See the figure below:
The Project Management Plan (PMP) is perhaps the single most important work product produced by the project manager. The PMP integrates all the OUM Manage
processes (Scope, Financial, Work, Risk, Staff, Quality, Configuration, Infrastructure, Procurement, etc.) into an integrated set of documents to guide project execution
through closure. The PMP sets stakeholder expectations and formally communicates, as precisely as possible, how the project will be conducted from a project
management perspective.
Whether developed as a single document or as a set of documents (e.g., one for each Manage process), each process component of the PMP must be presented to key
client stakeholders and discussed in detail during the Project Start Up phase. The client must approve and sign off on all components of the PMP.
The individual sections of the PMP are discussed in detail within the Project Start Up phase for each of the Manage process areas.
ACTIVITY
PS.ACT.RPAC Review Project Assets with Client
Back to Top
WORK PRODUCT
Project Management Framework
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create the Project Management
Framework.
Project
Management
Framework
The basic elements of the Project Management Framework are described in this document. This
will be the foundation for the Project Management Plan to be completed in the Project Start Up
phase.
2 Review Project Management Framework
with the client and any third-party
stakeholders.
Accepted Project
Management
Framework
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Regardless of the size and nature of an engagement, the client always has an expectation of what the implementing organization (for example, Oracle) will do. Always
produce a confirmation document (which goes into more detail than the Proposal document) to clarify expectations of both sides in terms of the following:
Scope and Objectives
Approach - Phases, Tasks, work products, and Milestones
Acceptance of Oracles Work
Standards and Procedures to be followed during the engagement, including detailed Roles and Responsibilities
The Project Management Framework is developed using the Project Management Framework template. It provides the foundation for, and is a key component of the
Project Management Plan (PMP) but only presents the high level summary of each element of the full PMP that is developed during the Project Start Up Phase. For a
small project, the PMP may be a single document but for medium to large size projects it is more likely to be comprised of multiple documents and should, at a minimum,
address these areas:
Project Scope
Project Objectives
Project Approach
Project Workplan
Project Resourcing
Project Financials
Project Quality
Change Management
Configuration Management
Testing
Verification and Validation
Project Team Training Strategy
End-User Training Strategy
Communication
If the PMP is a single document, the Project Management Framework Table of Contents can be used to direct users of the PMP to the appropriate content areas of the
document as needed. If the PMP is comprised of multiple documents then the Project Management Framework should provide direction to the users as to the location of
each element of the PMP.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or
repetitive activities, tasks or task steps. If your project does not have a dedicated project
administrator, the project manager would perform these duties.
25
Project Manager Collaboratively develop the Project Management Framework. 75
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Proposal (Bid Preparation/Bid Review Cycle)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT070_PROJECT_MANAGEMENT_FRAMEWORK.DOC MS WORD
BT070_ABBREVIATED_PROJECT_MANAGEMENT_FRAMEWORK.PPTX MS POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[SM] SCOPE MANAGEMENT
Scope definition is one of the most important aspects of managing a project or a large program. The Scope Management process identifies clear boundaries of what is to
be implemented and key work products to be produced. Not only does it define what the project will produce, but it also defines what will not be produced. Scope
Management should also be considered as a setting of expectations for the client. Project scope must be articulated with enough clarity and detail so that no one could be
confused about what the project will and will not accomplish.
Change Management is the second key component of the overall Scope Management process. The objectives of scope change management are to capture, evaluate
and approve change requests to agreed project baseline.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for clearly validating (already defined in contract), documenting, gaining agreement on, and
communicating the scope of the project effort, including key work products and milestones. The project manager must describe the scope of the project in as much detail
as possible. It is important for the project manager to always keep in mind the Confirmed Business Case when determining if an area is in or out of scope. In addition, the
scope management approaches to be used over the course of the project are laid out. This information is captured in the Validated Scope, which becomes part of the
overall Project Management Plan.
Additionally, the project Manager must document, gain agreement on, and communicate a formal process for managing subsequent changes to the agreed upon scope as
they arise. This information is documented in the Scope Change Management Processes.
The project manager may need to update project scope, cost, budget, schedule and quality requirements based upon approved project changes orders. Effective project
change control is essential to complete projects on time and on budget. Approved scope changes affect the configuration of the work products.
Project Execution and Control Phase
During Execution and Control, the project manager should continue to re-confirm project scope with the customer and needs to regularly review the contract to ensure that
project scope is not being compromised.
The scope verification is not a single task performed only in the Project Start Up phase. The Manage Scope task is ongoing and is performed by the project team. When
deviations from the agreed contractual scope occur, the project manager should verify the changes with the customer. This is a continuous process throughout the
Project Execution and Control phase. Any deviation in scope needs to be quickly flagged and raised to the key stakeholders as a project scope change.
Effective scope change management is essential to complete projects on time and on budget. Use the Scope Change Management Process developed during Project
Start Up to properly integrate or postpone requests for changes to the project's scope. This process is designed to help you implement an efficient and effective method
of change control within the project management framework.
Project Closure Phase
The project managers focus during Project Closure should be to confirm project scope and objectives with the client and make certain that all project scope items have
been successfully delivered. Discuss agreed upon deviations and put closure on the project. Review contract to make certain that scope obligations have been met.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS SM.010 Define and Confirm Scope Validated Scope Y Core
PS SM.020 Develop Scope Change Management Processes Scope Change Management Processes Core
Project Execution and Control
PEC SM.030 Manage Scope Managed Scope Y Core
PEC SM.040 Manage Acceptance Managed Acceptance Y Core
Project Closure
PC SM.050 Gain Acceptance Final Acceptance Certificate Y Core
PC SM.060 Close Scope Management Closed Scope Management Y Core
PC SM.070 Identify Future System Enhancements Future System Enhancements Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Project
Leads
This role is filled by project team members (e.g., business analyst, developer, designer, system architect, etc) providing input for the project
preliminary scope statement with respect to individual team tasks and preparing documentation describing the project impact: schedule, cost, time
and resources.
Client (User)
CPS Client
Project
Sponsor
CPM Client
Project
Manager
Assist in developing the Validated Scope.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.010 - DEFINE AND CONFIRM SCOPE
The Define and Confirm Scope task addresses and documents the characteristics and boundaries of the project and its associated work products. The Validated Scope
is a key component of the Project Management Plan. The outputs from Bid Transition process are prerequisites that can be used as input to this task.
ACTIVITY
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
WORK PRODUCT
Validated Scope - The Validated Scope is the definition of the project and summarizes what needs to be accomplished.
The Validated Scope should be distributed to:
Project Sponsor
Steering Committee
Project Managers (client and integrator)
Project Leads
The Validated Scope is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine the overall business
objectives for the project.
Context Statement Document the overall business objectives of the project.
2 Determine project requirements
and work products.
Requirements and
Work Products
List which tasks and work products will be necessary to complete the project.
3 Determine project constraints. Constraints List the conditions that may limit the project team's choices, including but not limited to project budget,
release dates, resource availability, and holiday schedules.
4 Determine key project assumptions. Assumptions List any assumptions (beliefs) that are considered "real and certain," including but not limited to scope,
resources, user participation, sign-off, and issues resolution.
5 Determine functional processes. Functional
Processes
List the functional processes.
6 Identify application modules. Application Modules List the application modules.
7 Define the technical scope. Technical Scope Document the technical scope definition.
8 Define the organizational scope. Organizational
Scope
Document the organizational scope definition.
9 Define the geographic scope. Geographic Scope Document the geographical scope definition.
10 Define the conversion scope. Conversion Scope Document the conversion scope definition.
11 Define the Interface scope. Interface Scope Document the interface scope definition.
12 Define the reporting scope. Reporting Scope Document the reporting scope definition.
13 Define the customization scope. Customization Scope
Document the customization scope definition.
14 Define the workflow scope. Workflow Scope
Document the workflow scope definition.
15 Obtain approval from key
stakeholders.
Approved Validated
Scope
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
The Validated Scope statement should:
Clearly identify all application modules, enhancements, reports, interfaces, conversions and locations in scope.
Define what is out-of-scope.
Define key project assumptions as part of the scope definition.
Define how much contingency (i.e., management reserve is going to be withheld for risk, issues, problems, and unplanned work).
Document all assumptions concerning scope, resources, user participation, sign-off, issues resolution, QA.
As mentioned above, it is extremely important to document assumptions regarding scope. In addition any constraints that the project is operating under that may affect the
project's ability to achieve the scope must also be documented.
Do not include scheduled milestones in the Validated Scope.
The following is an example of a high-level product scope definition for a hypothetical HRMS project:
Module Functionality
Phase I
Delivered
DD-MM-
YYYY
Phase II
Delivered
DD-MM-
YYYY
HR Module Position Management X
HR Module Recruit Workforce - Requisitions X
HR Module Recruit Workforce - Applicant Tracking X
HR Module EEO X
HR Module Career and Succession Planning X
HR Module Salary Planning X
HR Module Variable Compensation X
Constraints
Constraints are conditions that limit the project teams choices for completing the project.
Examples of constraints are:
Project budget
Release dates
Resource availability
Holiday schedules
Pay close attention to client-related constraints. It is imperative to uncover client plans for expansion, acquisitions, or other competing projects that might impact the
current project.
Assumptions
Assumptions are those beliefs around which decisions involving the project scope were made. For planning purposes, assumptions should be considered as real and
certain. Assumptions may impact the projects scope, schedule, or cost if they turn out to be invalid.
Examples of assumptions are:
Modules or business flows will be implemented as delivered without modification
Client project team members will have ready access to all corporate policy and procedure documentation
All assumptions concerning scope, resources, user participation, sign-off, issues resolution, QA and similar items should be documented.
Back to Top
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Siebel Customer Relationship Management (CRM)
This task has supplemental guidance that should be considered if you are doing a Siebel CRM implementation. Use the following to access the task-specific supplemental
guidance. To access all Siebel CRM supplemental information, use the OUM Siebel CRM Supplemental Guide.
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Develop the preliminary Validated Scope. 60
Project Leads This role is filled by project team members (e.g., business analyst, developer, designer, system architect, etc) providing input
for the project preliminary scope statement with respect to individual team tasks.
30
Client Project Sponsor Authorize project activities and approves project scope and definition. *
Client Project Manager Assist in developing the Validated Scope. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Confirmed Business Case (BT.020)
Project Management Framework (BT.070)
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Pair-Choice Priority This technique provides guidance in prioritization. It includes an MS Word template that can be used to assist in prioritization.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM010_VALIDATED_SCOPE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.020 - DEVELOP SCOPE CHANGE MANAGEMENT
PROCESSES
Scope creep kills. First it kills the budget. Then it kills the schedule. Finally it kills the project.
The objective of the Develop Scope Change Management Processes is to develop and document the various processes (procedures) for managing change during the
project. These processes include but are not limited to the following:
managing, assessing and approving change requests to established baselines
communicating approved and implemented changes to the stakeholders
updating project scope, cost, budget, schedule, and quality requirements based upon approved project scope changes
configuring work products
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Scope Change Management Processes - The Scope Change Management Processes documents the various processes (procedures) for managing change during the
project. It includes the following components:
Change Request Process
Identification Process - how to identify that a change needs to occur or has occurred
Review/Assessment Process - this is the procedure for reviewing change requests (for example, Change Request Board, Change Control Board)
Approval Process
Management Process
Reporting Process
Tracking Process
Change Request Form - used to capture individual change requests
Change Control Log - used to track the status of all change requests
who is logging the request
detailed functional and/or technical description of the requested change
description of the project impact and priority
cost and schedule impact adjustments to Project Workplan and Financial Management Plan
resource impact adjustments to Resource plan
approval/escalation process (for example, who is responsible for approving/rejecting proposed project changes (project manager/client project manager,
other roles and responsibilities, are any changes automatically approved without review, etc.)
Contract Update Process
Project Management Plan Components Update Process
Roles and Responsibilities
Back to Top
TASK STEPS
You should follow these steps
No. Task Step Component Component Description
1 Define the process for managing, assessing,
approving change requests.
Change Request
Process
Define this process in detail. Be sure to include:
Identification Process
Review/Assessment Process -- who and how
Approval Process -- who and how
Management Process
Reporting Process
Tracking Process
2 Create or obtain a change request form. Change Request Form This form is used to capture individual change requests. Include the following:
who logged the request
detailed technical/functional description of the change
cost impact (Financial Management Plan)
schedule impact (Project Workplan)
resource impact (Resource Plan)
approval/rejection section
3 Create or obtain a change request log. Change Request Log This log is used to track all change requests.
4 Define the process for updating the contract. Contract Update
Process
Define the process for updating the contract for approved change requests.
5 Define the process for updating any Project
Management Plan components, if necessary, for any
approved scope changes.
Project Management
Plan Components
Update Process
Define the process for updating any Project Management Plan process
components (for example, Financial Management Plan, Project Workplan, etc.)
for approved change requests.
6 Define roles and responsibilities. Roles and
Responsibilities
List any and all roles involved and describe the responsibilities.
7 Obtain key stakeholder agreement and approval on
the Scope Change Management Processes.
Approved Scope
Change Management
Process
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Proposed changes can require new or revised cost estimates, schedule activity sequences, schedule dates, resource requirements and analysis of risk response
alternatives. These changes can require adjustments to any of the components of the Project Management Plan (e.g., Validated Scope, Financial Management Plan,
Project Workplan, etc.) or other project work products. Any deviation in scope needs to be quickly flagged and raised to the key stakeholders as a project scope change.
Effective project change control is essential to complete projects on time and on budget. Scope Management is the process used to properly integrate or postpone
requests for changes to the project's scope.
Develop Scope Change Management Process that implement an efficient and effective method of change control. Consider the following:
Use Change Request Forms and Log to track change requests and change orders from creation, through necessary approvals, to implementation.
Control and update the scope, cost, budget, schedule, and quality requirements based upon approved changes, by coordinating changes across the entire project
and configuration.
Maintain the integrity of baselines by releasing only approved changes for incorporation into project products or services, and maintain their related configuration
and planning documentation.
Influence the factors that circumvent integrated change control so that only approved changes are implemented.
No work should be initiated unless key stakeholders have agreed to the scope change and have signed-off. Ensure that key stakeholders (for example, client executive
sponsor, key IT and business stakeholders, any partner senior executives and project sponsor are part of the Scope Change Management Processes and Change
Control Board.
Proposed changes can require new or revised cost estimates, schedule activity sequences, schedule dates, resource requirements and analysis of risk response
alternatives. These changes can require adjustments to the project management plan, project scope statement, or other project work products. Any deviation in scope
needs to be quickly flagged and raised to the key stakeholders as a project scope change. Effective project change control is essential to complete projects on time and
on budget. Scope change management is the process used to properly integrate or postpone requests for changes to the project's scope. This plan is designed to help
you implement an efficient and effective method of change control within the project management framework.
No work should be initiated unless key stakeholders have agreed to the scope change and have signed-off.
It is recommended that all changes be documented, including those that do not have a financial or schedule impact.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks
or task steps. If your project does not have a dedicated project administrator, the project manager would perform these
duties.
10
Project Manager Prepare documentation describing the project impact: schedule, cost, time and resources. 70
Project Leads This role is filled by project team members (for example, business analyst, developer, designer, system architect, etc.)
preparing documentation describing the project impact: schedule, cost, time and resources.
20
Client Project Sponsor Review and approve changes to the project scope. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope Statement
(SM.010)
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Scope Change Management requirements that should be taken into
consideration when developing the detailed Scope Change Management Processes.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM020_CHANGE_REQUEST_PROCESS.DOC MS WORD
SM020_SCOPE_CHANGE_MANGEMENT_CHECKLIST.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.030 - MANAGE SCOPE
In the Manage Scope task, you put into practice the processes documented in the Scope Change Management Processes and manage any possible scope changes
(Change Requests) as defined. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MSAA Manage Scope, Acceptance and Approvals
Back to Top
WORK PRODUCT
Managed Scope - Managed Scope is the execution of the Scope Change Management Processes. Scope changes are identified, documented, reviewed, approved or
not, and as necessary, any project documentation is updated.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 As scope changes are identified, route them through the
processes identified in the Scope Change Management
Processes.
Change Request Form Once a scope change is identified, complete a Change Request Form.
2 Add each scope change (completed Change Request Form)
to the Change Request Log and track its progress.
Change Request Log Track all change requests from identification to implementation or rejection.
3 Obtain client agreement and approval and sign off on any
approved scope changes before implementation.
Change Request
Approval
Obtain any necessary sign-off to the Change Request Form or Approval
Certificate as defined in the Scope Change Management Processes.
4 Update the contract for any approved scope changes. Updated Contract Update the contract for approved change requests.
5 Update any Project Management Plan components, if
necessary, for any approved scope changes.
Updated Project
Management Plan
Components
Updating any Project Management Plan process components (for example,
Financial Management Plan, Project Workplan, etc.) for approved change
requests.
6 Implement approved scope change. Change Request Log Assign the work to the appropriate roles for completion and update the
Change Request Log to indicate resolution.
Back to Top
APPROACH
The Validate Scope and Scope Change Management Processes are developed during the Project Start Up phase and set forth the scope definition and processes for
managing scope. They should be communicated to the project team in the Scope Management Presentation made during the Team Orientation Meeting. Refer to the
Conduct Team Orientation task (STM.050) for more information on the Team Orientation Meeting. During the Team Orientation Meeting, the Validated Scope and Scope
Change Management Processes should be made available to all project team members to make sure they understand the scope of the project and the scope of their
tasks as well as the dangers of scope creep.
One of the main reasons for missing project schedule deadlines and cost overruns is scope creep unauthorized work that is outside of the projects scope. The
additional work is often undertaken for positive reasons (ease of use, added value, goodwill), but the fact that it was not approved increases the chance that it will not fit
with the projects big picture goals. A good example is the introduction of a seemingly innocent customization that blossoms into a much larger undertaking. All work
should only be included once the impacts have been understood and formally accepted by the key stakeholders and the Change Request Board.
Use the Project Workplan to manage the scope.
Any deviation in scope needs to be quickly flagged and raised to the customer as a project scope change.
Any scope change must then be documented according to the Scope Change Management Processes (including a cost/schedule impact analysis).
No work should be initiated unless the key stakeholders have agreed to the scope change and have signed off.
For approved change requests be sure to update the Project Workplan, Resource Plan, and Finance Management Plan to reflect the change. Add the new tasks, assign
resources, level the plan if necessary, and baseline the additional tasks. Do not re-baseline the entire plan or you will lose your variances.
Some guidelines to help avoid the introduction of creep include:
Be sure that the entire project team knows the baseline scope of the project.
Be sure that the entire project team is aware of the Scope Change Management Processes. This reduces the probability of an unauthorized change being made.
Regularly review the Validated Scope to ensure that project scope is not being compromised and review it with the project stakeholder.
Ensure that all project team members (client and implementers) are alert to detecting deviations in scope and report any deviations to project management.
Project management should review all proposed changes in scope in terms of the overall project impact; including any impact on the business objective for
undertaking the project.
Document all scope changes including those with no resource implications. Take a comprehensive view of scope changes in terms of impact on the overall
solution, the project schedule, resource level, client business objectives and related projects and tasks.
Be careful not to extend the scope of the project by agreeing to changes verbally.
Do not start any of the proposed work unless the client has agreed to the scope change and has signed off.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Ensure that all scope changes go through the Scope Change Management Processes. 85
Client Project Sponsor Approve change requests recommended by the Change Request Board. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope (SM.010))
Scope Change Management Processes
(SM.020)
The Scope Change Management Processes documents the strategy and processes for managing scope change during
the project.
Orientation Guide (STM.040)
Oriented Team (STM.050)
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Scope Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM030_CHANGE_REQUEST_FORM.DOC MS WORD
SM030_CHANGE_REQUEST_LOG.XLS MS EXCEL
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.040 - MANAGE ACCEPTANCE
As part of the Scope Management process, acceptance must be managed. At the end of a project phase or increment, meet with the project executive sponsor (and other
stakeholders as appropriate) and make sure that the project scope and objectives have been met. Gain acceptance from the project sponsor on the completed work
products. As a precaution, make sure that acceptance is documented on all outstanding project work products.
ACTIVITY
PEC.ACT.MSAA Manage Scope, Acceptance and Approvals
Back to Top
WORK PRODUCT
Managed Acceptance
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Complete the Acceptance Criteria for the work products completed for the given increment or phase. Acceptance
Criteria
2 Meet with the client and make sure that the project scope and objectives have been met. Gain acceptance from the client on the
completed work products. As a precaution, make sure that client acceptance is documented on all outstanding project work products.
Acceptance
Certificate
Back to Top
APPROACH
Complete the Acceptance Criteria for the work products completed for the given increment or phase. Schedule a meeting with the project sponsor to discuss the project,
review the Acceptance Criteria and sign the Acceptance Certificate. Review the contract to make certain that scope obligations are being met. Discuss all agree upon
deviations. Be sure to:
Review the contract to make certain that all contractual obligations are being met.
Ensure that all sign-offs have been received to this point in the project.
For Fixed Price projects, ensure that the Final Acceptance Certificate(s) for the milestone in the Project Workplan or the milestone in a milestone payment plan is
presented to the customer, signed, and submitted to finance, operations, and contracts for processing according to the contract payment milestone schedule.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope (SM.010))
Scope Change Management Processes
(SM.020)
The Scope Change Management Processes documents the processes for managing acceptance during the
project.
Orientation Guide (STM.040)
Oriented Team (STM.050)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM040_ACCEPTANCE_CRITERIA.DOC MS WORD
SM040_ACCEPTANCE_CERTIFICATE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.050 - GAIN ACCEPTANCE
As part of Project Closure, meet with the accepting organization and make sure that the project scope and objectives have been met. Gain acceptance from the
authorized individual for the overall project. As a precaution, make sure that authorized acceptance is documented on all outstanding project work products. This task can
be executed at the end of a defined increment of work, such as the end of an iteration (or Scrum sprint) or project phase.
ACTIVITY
PC.ACT.GA Gain Acceptance
Back to Top
WORK PRODUCT
Final Acceptance Certificate
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Meet with the authorized approver and make sure that the project scope and objectives have been met. Gain acceptance from
authorized individuals on the overall project. As a precaution, make sure that authorized acceptance is documented on all outstanding
project work products.
Final
Acceptance
Certificate
Back to Top
APPROACH
Schedule a meeting with the project sponsor (and any other authorized signatories) to discuss the project and sign the Final Acceptance Certificate along with any other
closure documents (for example, closure letter, sign-off letter, etc.). Review the contract to make certain that scope obligations have been met. Discuss all agreed upon
deviations. Be sure to:
Review the contract to make certain that all contractual obligations are met.
Verify with the team that work is ready to be submitted to the authorized individuals for sign-off.
Have tests been done?
Is the required documentation available?
Are there any open issues or problems?
Submit the deliverables/work products and begin Acceptance process immediately during/after the review or walkthrough of the work being submitted.
Plan to answer questions and prioritize any issues that impede completion of the process and assist the signatory in accepting.
Offer guidance to the signatory on acceptance to make the process more efficient and effective.
The accepting organization is often responsible for the acceptance test, but they may require assistance and guidance.
Review and agree upon the list of acceptance issues.
The acceptance period refers to the period until the accepting organization completes acceptance testing and results have been delivered.
Perform rework to resolve the issues, if necessary.
Ensure that all sign-offs have been received.
Ensure the signatory has authority to sign.
If there are open items, escalate to project sponsor and add to Issues Log to monitor until closed (approved/accepted).
For Fixed Price projects, ensure that the Final Acceptance Certificate(s) (for example, the last milestone in the Project Workplan or the last milestone in a milestone
payment plan) is presented to the signatory, signed, and submitted to the appropriate organizations (such as finance, operations, and contracts) for processing according
to the agreed upon contract payment milestone schedule.
Project Acceptance Report
It is recommended that a Project Acceptance Report be produced. The purpose of the Project Acceptance Report is to provide a perspective on the project and the
overall success of implementation. The objective of the review is to assess progress toward project goals, financial goals and identity any required follow-on activity.
Review Project Objectives - This section should re-state the project objects and provide some qualitative assessments as to how the project results compared to
the project objectives.
Review Project Statistics - This section should provide some qualitative assessments and quantitative representations regarding some key project indicators.
Review Project Budget - This section should provide some qualitative assessments and quantitative representations regarding the financial health throughout the
project lifecycle.
Review Project Test Results - This section should present a synopsis of the results for the test cycles (systems, integration, and user) executed throughout the
project lifecycle.
Review Project Issues - This section provides a summary of the issues encountered throughout the project lifecycle, with the exception of post go live activities.
Please make sure to identify all open issues, where ownership needs to be transferred to the operational sustaining organization.
Review Project Risks - This section should summarize the risks encountered throughout the project lifecycle, with the exception of post go live activities.
Review Project Milestones - This section should provide a cumulative summary of the project milestones presented in the weekly status report. Please note that all
milestones detailed below have received signoff that can be found in the project diary.
Future Recommendations - This section should provide some general recommendations that should be considered for future projects.
Future Projects - This section should provide a listing of the potential future projects, which have been identified through the MoSCoW List, change request log or
through conversations with the project team members and process owner.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM040_ACCEPTANCE_CERTIFICATE.DOC MS WORD
SM050_PROJECT_ACCEPTANCE_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.060 - CLOSE SCOPE MANAGEMENT
The Close Scope Management task is executed in the Project Closure phase. It is a clean-up task to close or transition any open change requests and archive any
documentation.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Scope Management
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Close any open change orders. Change Request Log
2 Transition any deferred Change Requests or items
to the client.
Change Request Log
3 Document any lessons learned. Scope Management Lessons
Learned
This report is used to create the Lessons Learned report produced in the
Communication process.
4 Ensure that all documentation is organized and
archived.
Back to Top
APPROACH
To obtain closure on the project, be sure to:
Close all open change orders.
Transition any deferred change request or items to the client.
Ensure that all documentation and records, physical or electronic, are systematically reviewed, organized, archived and deliver to the client, as required.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM060_SCOPE_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.070 - IDENTIFY FUTURE SYSTEM ENHANCEMENTS
In this task, you identify opportunities for enhancing the system in the future. You may identify opportunities and challenges and propose a future direction for new
improvements.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Future System Enhancements
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review Open Issues List Issue Log
2 Review Lessons Learned Lessons Learned
3 Examine Industry Trends Future Business Directions
4 Propose Future Business Direction Future Business Directions
5 Consider Open Enhancement and Change Requests that were considered out of scope Business Process Enhancements
6 Summarize Recommendations Executive Summary
Back to Top
APPROACH
Looking forward, you should consider the new features planned for the system.
You may be in an industry that has undergone some dramatic changes. If so, then it is likely that the future business direction must be in line with these changes or be
able to absorb them. For example, if there is an outsourcing trend in forward distribution, then you might want to consider the benefits and costs of implementing such a
program. Collecting industry trends can be based on obtaining general knowledge or a detailed analysis of books and periodicals.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM070_FUTURE_SYSTEM_ENHANCEMENTS.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[FM] FINANCIAL MANAGEMENT
Once a project price has been agreed between the client and the service provider, financial expectations have been set. The project manager must now meet these
expectations and report on the financial metrics to the client and service provider stakeholders as required by the project reporting strategy and stakeholder procedures.
In order to control costs and provide a basis for financial monitoring and reporting, the project manager needs to plan the project costs in detail.
Financial Management is heavily dependent on the Scope, Staff, Quality and Work Management processes. The financial details are not necessarily shared in a client in a
fixed price situation.
Key aspects of the Financial Management process are:
Tracking actual spend against budget (typically obtained from the service provider's financial system and/or the Project Workplan)
Developing a realistic forecast to completion (from the approved project schedule and Resource Plan)
Calculating actual and realistic forecast margin
Note: Financial Management does not usually address tracking client costs.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for confirming the project finances (with key stakeholders), establishing the financial baseline and
defining the processes for managing project finances. These include:
A cost burdened project plan that correlates to the project budget
A labor and expense task structure (set up in the service provider's financial system and/or the Project Workplan) to track costs in line with procedures
A process for tracking and reporting financial performance internally and performance metrics to the client
A process for updating the Financial Management Plan based on approved change orders
A process for how invoices will be processed by the client and tracked to payment
Project Execution and Control Phase
During the Project Execution and Control phase, the project manager is responsible for tracking and controlling project effort and expenses according to the processes
established in the Project Start Up phase. These need to be managed closely and reported to the client and the service provider stakeholders. Key activities in this phase
typically include:
Entering and approving project expenses
Tracking actuals for project labor and expenses, including sub-contractors in service provider's financial system and/or the Project Workplan and Resource Plan
Updating the project schedule and Resource Plan and forecasting the financial position at project completion including any exposure on the part of service provider
and/or the client.
Performing an earned value analysis to track cost and schedule performance
Keep in mind that you need to keep track of the project costs independent of the project funding/financing but need to be in control of both.
The following data elements are typically tracked (as a minimum)
Standard rates, discounts, and actual rates for each consultant
Other project costs
Travel and expenses
Nonbillable time and expenses
A key component of successful Financial Management is the capability to compare planned achievements with actual accomplishments. Earned value analysis is the
accepted approach to achieve this.
These guidelines provide the opportunity to develop cash flow schedules, if required.
Scope changes impact cost. The successful management of project scope contributes directly to controlling project costs. Scope creep is a common cause of budget
overruns unless increases in project scope are accompanied by additional funding to perform new activities. This is an important reason why an approved project scope
is one of the fundamental building blocks of documented in the Project Management Plan.
Forecasting
Forecasting has always been a difficult concept for project managers. Because project managers focus on the success of their project, they tend to be optimistic about
the potential outcomes. This does not mean that they are not realists, but it does mean that they tend to think of the glass as being half full, rather than half empty since
both descriptions are equally accurate.This view tends to color their forecasts, sometimes at the expense of the hard truth. Accurate forecasts are essential to
establishing credibility which is an essential block of successful project management.
Project Closure Phase
During the Project Closure phase, the project manager is responsible for reconciling and closing all project finances and providing final reporting. The final actuals are
compared to the original budget as a measure of project financial performance. Activities include:
Closing out Financial Management Plan
Obtaining payment on any outstanding invoices
Closing the project entry on the service provider's financial system and/or the Project Workplan
Providing final financial reports to the client and the service provider stakeholders
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS FM.010 Refine Project Budget Approved Project Budget Y Core
PS FM.020 Develop Financial Management Plan Financial Management Plan Y Core
PS FM.030 Set Up Time and Expense Tracking Time and Expense Tracking Core
Project Execution and Control
PEC FM.040 Manage Project Finances Managed Project Finances Y Core
Project Closure
PC FM.050 Close Project Financials Closed Project Financials Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
TM Team
Members
Accurately track time and expenses and submit them on time.
Client (User)
CPS Client
Project
Sponsor
CPM Client
Project
Manager
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.010 - REFINE PROJECT BUDGET
Using the preliminary budget information from the Bid Transition process as a starting point, refine the project budget based on additional information now available.
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Approved Project Budget
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather any necessary documentation. None The following documentation is
needed:
Validated Scope
Baseline Project Workplan
WBS
activity resource estimates
labor categories and associated
labor rates
cost of non-labor resources.
2 Obtain and apply the rates to derive the labor budget that relates to the planned effort and
resources required to perform the project.
Labor Budget
3 Calculate a project non-labor expense budget. Non-Labor Expense
Budget
4 Validate the budget. Project Budget
5 Cost burden the Project Workplan. Cost-Burdened Project
Workplan
6 Obtain approval from key stakeholders. Approved Project
Budget
Obtain any necessary sign-off or
Approval Certificate.
Back to Top
APPROACH
The costs for schedule activities are estimated for all resources that will be assigned to the project. This includes, but is not limited to, labor, materials, allowance or a
contingency cost. A project estimate in a budget is a quantitative assessment of the likely costs of the resources required to complete the schedule activity.
Cost estimates can benefit from refinement during the course of the project to reflect the additional detail available. The accuracy of a project estimate will increase as the
project progresses through the project lifecycle.
Typically, a budget has been established and reviewed during the Bid Transition Process. This budget now needs to be refined and calculated in line with the detailed
Validated Scope and Baseline Project Workplan developed.
1. Develop and agree to the project budget.
Review the Validate Scope and the Baseline Project Workplan that reflects the planned staffing. Obtain the WBS, activity resource estimates, labor categories and
associated labor rates and cost of non-labor resources.
Obtain and apply the rates to derive the labor budget that relates to the planned effort and resources required to perform the project.
Calculate a project non-labor expense budget. Expense caps must be represented in the expense budget.
Include budget allocations for offshore and onsite resources if they are included in the project.
There is more flexibility in time and materials projects; however, the project budget should be allocated in key areas (e.g., budget by phase, budget by module/flow,
budget by work effort type functional, technical, DBA).
2. Obtain formal written approval on the budget from the key stakeholders and escalate if there are any concerns.
If you run into budget problems consider the following tips:
More senior consultants carry higher rates but should also have the implementation skills and experience to complete work more rapidly. Consider reducing effort
estimates on key tasks when there is a more senior resource.
Look for schedule gaps where a resource is not assigned full-time to a task for a short period. This dead time between activities for specialized resources is often poorly
utilized and adds to project costs unnecessarily. Find tasks assigned to heavily utilized resources and assign them to resources with gaps in their schedule. This can
result in a significantly improved schedule without incurring any additional cost.
Try reducing initial project scope. One approach is to divide the initial scope of the project into two or more phases. Discuss phasing options with your customer. Each
phase will have costs and benefits. What can they afford and where can they spend their money to get the most out of their investment? Accelerate project components
with a higher ROI and use the savings to justify funding for later phases.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Accepted Project Budget (BT.040) Use the Accepted Project Budget as the starting point.
Validated Scope (SM.010)
Baseline Project Workplan (WM.010)
The budget needs to be refined and calculated in line with the detailed Validated Scope and Baseline Project Workplan.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.020 - DEVELOP FINANCIAL MANAGEMENT PLAN
The objective of the Develop Financial Management Plan task is to develop and document the strategy and processes (procedures) for managing finances during the
project. The Financial Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Financial Management Plan - The Financial Management Plan documents the strategy and processes (procedures) for managing finances during the project. The
Financial Management Plan is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 State the financial strategy for the project. Financial Management Strategy. Document the strategy.
2 Determine the expense policies and reporting
procedures.
Project Expense Policy and
Reporting Process
Document the expense policies and reporting procedures.
3 Determine the process for invoices and payment
tracking.
Invoices and Payment Tracking
Process
Document the process for invoices and payment tracking.
4 Develop a system for tracking pertinent project
financial information.
Financial Tracking System Document the tracing system. Use a spreadsheet approach to track various
project financial information.
5 Determine reporting requirements and
guidelines.
Financial Reporting Requirements
and Guidelines
Document reporting requirements and guidelines.
6 Compile components into one document. Financial Management Plan
7 Obtain approval from key stakeholders. Approved Financial Management
Plan
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Develop and document the Financial Management strategy and processes in the Financial Management Plan. Once the Approved Project Budget has been refined, the
specific financial reporting metrics and the corresponding support process's and systems must be developed and agreed on with the key stakeholders.
Develop the Project Expense Policy and Reporting Process. Consider the following:
Expenses that are re billable to the client and any supporting documentation required by client - Sometimes clients want to review receipts. (The project manager
should confirm this with the client.)
Expense constraints (e.g., per diem, preferred hotels, rental car usage, etc.)
While the policy is part of the Financial Management Plan, you may also want to include it in the Orientation Guide for team members.
Develop the Invoices and Payment Tracking Process. Consider the following:
The project manager may be responsible for tracking payment of client invoices. Non-payment of invoices can indicate project issues.
Fixed price projects require Acceptance Certificates to be signed by the client.
Invoices should be reviewed prior to submission.
Establish the project Financial Tracking System. At a minimum, the system should:
Track all actuals numbers against budget, forecast, including variances.
Track all actuals for individual human resources on a week by week basis.
Calculate project totals for all numbers on a week by week basis.
Track all actuals against fiscal boundaries (months, quarters, years).
Track standard costs (with up lifts represented).
Forecast cost and T&E through project completion.
Track invoiced and paid labor and expenses by invoice number.
Develop any of the Financial Reporting Requirements and Guidelines (client and internal).
Compile the above components into the Financial Management Plan and gain acceptance from key stakeholders.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Cient Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Financial Management requirements that should be taken into
consideration when developing the detailed Financial Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
FM020_DEVELOP_FINANCIAL_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.030 - SET UP TIME AND EXPENSE TRACKING
Determine and document the approach for time and expense tracking. The project team and the client may have different time and expense tracking requirements.
Develop a system that will satisfy both requirements.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Time and Expense Tracking
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Establish or confirm local policies and procedures for time and expense tracking.
2 Verify that the project is funded properly (labor and expenses) in the relevant company financial systems (in Oracle Corporation this
would be Oracle Project Accounting).
3 Verify that services invoicing processes are in place for the Oracle, client and sub-contractors.
4 Develop and agree to a policy for use of non-billable codes, if required.
5 Define labor and expense tasks for recording actuals in accordance with project requirements and procedures.
6 Work with operations to set up labor tasks.
7 Assign project resources to labor and expense tasks and notify the resources.
Back to Top
APPROACH
At a minimum, the following should be established:
the project week span - Will reporting be done Sunday through Saturday or Saturday through Friday?
the format and location of time sheets
the due date for time sheets
the method and timing for reporting expenses totals to the project manager and the expense approval process
the approvals required before performing work on a non billable basis
the project's overtime policies
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Financial Management Plan (FM.020) The Financial Management Plan documents the strategy and processes (procedures) for managing finances during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
FM030_EXPENSE_TRACKING_SPREADSHEET.XLS MS EXCEL
FM030_PROJECT_TEAM_TIME_SHEET.XLS MS EXCEL
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.040 - MANAGE PROJECT FINANCES
In the Manage Project Finances task, you put into practice the processes documented in the Financial Management Plan and the Time and Expense Tracking and
manage the financial aspects of the project. Project team members should provide the project manager with a weekly update for every task assigned to them. They
should provide the actual time spent on each task during the past week and an estimate of the remaining time necessary to complete each one. This is a good way to
measure the progress of an activity while it is in progress and is essential for proper forecasting. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MPF Manage Project Finances
Back to Top
WORK PRODUCT
Managed Project Finances
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Report Finances weekly. Weekly Finance Report
2 Report Finances monthly. Monthly Finance Report
Back to Top
APPROACH
Microsoft Project can be used to capture actual project costs and compare them to baseline (budgeted) costs by assignment, resource, or task. For Earned Value
Analysis, the three values of interest are the Actual Cost, Planned Value, and Earned Value. Microsoft continues to use the old acronyms for these values, so you find
Actual Cost in the ACWP field, Planned Value in the BCWS, and Earned Value in the BCWP field. These three values allow you to determine and report the most useful
information from the Earned Value Analysis process. However you must set up your plan differently for fixed price vs. time and materials projects in order to get the
numbers you need.
For time and materials projects you need to to:
1. Assign at least one resource to every task (except summary tasks and milestones).
2. Assign a standard rate to every resource.
3. Resource level your plan.
4. Save the project baseline.
For fixed price projects you need to:
1. Assign at least one resource to every task (except summary tasks and milestones).
2. Assign every resource a standard rate of zero (yes, zero!).
3. Structure your work breakdown so that every billing event is represented by a summary task and enter the billing amount into the summary task's Fixed Cost field.
4. Resource level your plan.
5. Save the project baseline.
On a weekly basis:
Approve project expenses for all team members. Validate that they are submitting expenses weekly and that they are adhering to company and project expense
policies.
Maintain a record of submitted and approved expenses.
Update workplan tasks with actuals so that you can determine the Earned Value CPI (Cost Performance Index) at the project level. Looking at CPI at the individual
or summary task is less useful because small variances can cause large changes in the CPI if the number of tasks is small. If you are using Microsoft Project, use
the Resource Usage view to:
Enter Actual Work completed for each task on the resource's time sheet.
Enter Remaining Work as reported for each task on the resource's time sheet.
On a monthly basis:
Reconcile client invoices to your financial records.
Gather data on invoice payments (amounts, dates, check numbers).
Track payment of any outstanding subcontractor invoices and update financial tracking spreadsheet.
On an as-needed basis
Update budget (as well as the workplan and resource plan) to reflect any approved change orders. Track change orders separately from the original budget so that
the original budget can be compared against actuals at project completion).
Track milestone revenue against budget and get signature(s) on certificates of acceptance for any completed milestone. Send signed Acceptance Certificates to
Operations, Finance and Contracts for processing.
Report project financials according to approved reporting guidelines.
When you identify cost overruns, address them a soon as possible. The longer you wait to make necessary adjustments the more restricted your options become. If you
have done a good job creating estimates and monitoring performance, the reasons for schedule problems and cost overruns should be easy to explain. The idea is to
identify and deal with small issues early instead of letting them turn into large problems.
You should always make your manager aware of any serious cost overruns and how you intend to handle them. How you raise cost overrun issues with the client will
partly depend upon your relationship with them. It is often beneficial to informally discuss the situation with key client managers and the project sponsor to get their
guidance before you develop your formal recommendation. Be prepared to offer suggested alternatives, such as substituting personnel or phasing in functionality. If the
situation requires logging an issue or problem, use the appropriate issue/problem form and the process outlined in the Issue and Problem Management System. If the
solution affects scope, complete the Change Request Form and initiate the processes outline in the Scope Change Management Processes. Be sure to follow up with
formal issues reporting that identifies the cause and contains options that show the impacts to schedules, scope, personnel, and costs. The project Steering Committee
should also be informed of the situation.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Gather time sheets and enter the data into the workplan. Perform cost performance analysis. Report deviations from financial
plan.
40
Team Members Accurately track time and expenses and submit them on time. 50
Client Project Sponsor *
Steering Committee
Member
Approve remedial efforts to address financial variances, whether by approving additional budget or personnel changes. *
Client Project Manager Review financial reports and participate in addressing variances. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Financial Management Plan (FM.020) The Financial Management Plan documents the strategy and processes (procedures) for managing finances during the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Metrics for Agile Projects Use this technique to measure actual budget expended against what was planned for agile projects.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.050 - CLOSE PROJECT FINANCIALS
During Project Closure, the project manager is responsible for reconciling and closing out all project finances and producing final reports.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Project Financials
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Update final task status to the Project Workplan. Closed Project Workplan
2 Enter remaining T&E to Time and Expense
Tracking System.
Closed Project in T&E System
3 Run final T&E reports. Final T&E Reports
4 Reconcile outstanding vendor invoices. Closed Vendor PO
5 Enter final updates to financial tracking
spreadsheet.
Final Financial Tracking
Spreadsheet
6 Document any lessons learned. Financial Management Lessons
Learned
This report is used to create the Lessons Learned report produced in the
Communication process.
7 Produce final financial reports. Final Financial Reports
Back to Top
APPROACH
Compare the final actuals to the original budget as a measure of assessing project financial performance.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Make final updates to tracking documents and produce final reports. 85
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
FM050_FINANCIAL_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[WM] WORK MANAGEMENT
The Work Management process focuses on the following:
develop the Project Workplan
define and document the processes and policies to be used to execute, maintain, control and close-out the Project Workplan
manage team work
close out team work activities and the Project Workplan and provide final project financials
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for clearly defining, documenting, gaining agreement on, and communicating the Project Workplan
as well as the Work Management Plan that defines the control processes and policies to be used to execute and control the Project Workplan. Processes and policies
that should be discussed in the Work Management Plan include the following:
Developing the Baseline Project Workplan
Controlling the Workplan through the life cycle of the project.
Executing the Workplan
Managing Team Work
Managing Team Time
The Project Workplan is the hub of Project Management as it denotes all the tasks and activities to be performed by the team within the projects scope, objectives, and
approach and it provides a repository of data that the project manager can utilize to plan the project. A project planning tool must be used for developing, maintaining,
managing and closing out the Project Workplan.
Project Execution and Control Phase
During the Project Execution and Control phase, the project manager is responsible for managing team work and controlling and executing the Project Workplan. The
project manager would typically collaborate with the client project manager to manage client team work.
Project Closure Phase
During Project Closure, the project manager is responsible for closing out team work activities and the Project Workplan and for providing final project financials.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS WM.010 Develop Baseline Project Workplan Baseline Project Workplan Y Core
PS WM.020 Develop Work Management Execution and Control Processes and Policies Work Management Plan Y Core
Project Execution and Control
PEC WM.030 Manage Project Workplan Project Workplan Y Core
PEC WM.040 Track Schedule Performance Schedule Performance Y Core
PEC WM.050 Manage Approvals Managed Approvals Y Core
Project Closure
PC WM.060 Close Work Management Closed Work Management Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Project
Leads
This role is filled by project team members (for example, business analyst, developer, designer, system architect, etc) providing expert advice.
Client (User)
CPS Client
Project
Sponsor
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.010 - DEVELOP BASELINE PROJECT WORKPLAN
In this task, you determine, organize, estimate, link, and schedule all of the tasks representing the work to be performed on the project and organize them into the
Baseline Project Workplan. This task can be performed with varying degrees of scope, rigor, and detail, depending on the circumstances in which it is used. It can be
used for forecasting, estimating, planning and impact analysis. You can use the Work Breakdown Structure (WBS) created during the Bid Transition process (if available)
or any of the example workplans found in the Key Component sections of the views as a starting point and then tailor the workplan, as appropriate for the project.
OUM encourages plans to be developed according to an approach that balances agility with discipline. This approach allows for a more agile project situation where the
system is developed through a series of mini-projects (iterative) and in smaller portions at a time (incremental), enabling the project team to take advantage of what was
learned during development of earlier parts or versions of the system and incorporate external feedback from project stakeholders. Agile projects typically follow a more
adaptable and collaborative approach.
ACTIVITY
PS.ACT.DW Develop Workplan
Back to Top
WORK PRODUCT
Baseline Project Workplan - The Baseline Project Workplan consists of the following:
An Implementation Plan that represents one full pass through all of the OUM phases. It focuses on the project objectives, milestones and the number of iterations.
An Iteration Plan that includes an Iteration Plan Summary that focuses on the scope, objectives, and approach for the first iteration of Inception and a detailed
WBS Project Workplan that provides a network of interdependent tasks representing all work, with staff work assignments and schedules.
It should be distributed to the following:
Project Manager
Project Stakeholders
Team Leads
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create the
initial
Implementation
Plan
Implementation
Plan
The Implementation Plan is a brief, coarse-grained outline for the project. The main purpose of the Implementation Plan is to
provide a roadmap for achieving the projects goals, along with a sketch of the number and purpose of each iteration needed per
phase.
2 Create the
Iteration Plan
for the first
iteration of
Inception.
Iteration Plan
Summary
WBS Project
Workplan
The Iteration Plan is made up of the Iteration Plan Summary and the WBS Project Workplan.
The Iteration Plan Summary for the first iteration of Inception outlines the scope, objectives and approach for the iteration. As the
project progresses, an Iteration Plan Summary will be created for each iteration in the project.
The WBS Project Workplan is a detailed workplan that represents the lowest and most detailed layer of planning. You can use the
Work Breakdown Structure (WBS) created during the Bid Transition process (if available), the OUM Project Workplan, or any
other example Project Workplan that can be found in the Key Components section of some views as a starting point and then
tailor the workplan as appropriate for the project. Refer to Tailoring OUM for Your Project for an overview of the tailoring process
in OUM.
3 Refine and
baseline the
WBS Project
Workplan.
Baseline WBS
Project
Workplan
A Baseline WBS Project Workplan captures the original project data that will be utilized for tracking and reporting and for
determining project variances. It allows you to compare actual performance during the project back to the the Baseline WBS
Project Workplan.
4 Consider the
need to
partition the
WBS Project
Baseline WBS
Project
Workplan
Update the Baseline WBS Project Workplan with appropriate partitions (e.g., by product, by process, by custom work verses
configuration work, etc.). Partitions allow a project to be partitioned or divided into smaller pieces. These pieces may be
implemented serially, in parallel or staggered.
Workplan.
Back to Top
APPROACH
Overview
As shown in the figure below, there are two plans active in the project at any given time on an OUM project the Implementation Plan and the Iteration Plan.
DEFINITIONS OF PLANS AT EACH LAYER
The Implementation Plan
The Implementation Plan is a brief, coarse-grained outline for the project. The objectives for the project are reflected in the Implementation Plan and tie back to the
Business Case developed in the OUM Envision Focus Area. The main purpose of the Implementation Plan is to provide a roadmap for achieving the projects goals,
along with a sketch of the number and purpose of each iteration needed per phase.
The Iteration Plan
The Iteration Plan contains the Iteration Plan Summary and the detailed WBS Project Workplan that represents the lowest and most detailed layer of planning. An
individual Iteration Plan Summary will be created for each iteration in the project. The current Iteration Plan focuses on how an incremental set of objectives and/or
functionality will be delivered within the framework of the project. The main purpose of the Iteration Plan is to lay out how the team will achieve the stated objectives for
the given iteration.
PLANNING USING A TOP-DOWN/BOTTOM-UP APPROACH
In OUM, plans are created using a top-down/bottom-up approach in which the plans at each layer (Implementation and Iteration) are created and maintained in a
simultaneous fashion. Because the plans are inter-related, it is likely that a change to a plan at one layer will cause the need for an adjustment to a plan at another layer.
The planning layers are show in the figure below.
In the Project Start Up phase, the focus is on the Implementation Plan. Also in Project Start Up, the initial iteration of the OUM Implement Inception phase is drafted to the
degree that the project is able to move into the Inception phase.
During Inception, the Implementation Plan created in Project Start Up is further refined as more project requirements and risks are uncovered. As the project iterates
through the later phases, the plans at each layer (implementation and iteration) will be adjusted based on the results of iteration assessments and as project objectives
shift, as is often the case.
On any OUM project, an Iteration Plan for the upcoming iteration is created before that iteration begins. Also, the Implementation Plan must be examined to ensure it is
still valid as the Iteration Plans are created and maintained.
Therefore, at any time on an OUM project the following plans should be active:
One Implementation Plan
Two Iteration Plans - one for the current iteration and a draft for the upcoming iteration
In the Project Start Up phase, the focus is on the Implementation Plan. Also in Project Start Up, the initial iteration of the OUM Implement Inception phase is drafted to the
degree that the project is able to move into the Inception phase.
During Inception, the Implementation Plan created in Project Start Up is further refined as more project requirements and risks are uncovered. As the project iterates
through the later phases, the plans at each layer (implementation and iteration) will be adjusted based on the results of iteration assessments and as project objectives
shift, as is often the case.
The project manager is expected to develop, communicate and maintain a resource-leveled workplan for each project over which he/she has project management
responsibility.
Create the Initial Implementation Plan
In OUM, the Implementation Plan is an outline of the project, showing the total number of planned iterations across the five OUM phases (Inception, Elaboration,
Construction, Transition and Production) as well as key milestone dates for each of these iterations. The Implementation Plan will sketch out the work across the five
phases by outlining the number of iterations in each phase and major milestones. Using the estimates for the project and the known priorities, lay out an Implementation
Plan, mapping requirements (both functional and technical) very roughly to each projected iteration. Keep in mind that an iteration in OUM should be from two to six
weeks in length, which allows the work on the project to be broken up into manageable chunks. You may find that certain requirements pose design or architectural risks,
and should consider assigning them to earlier iterations in order to address those potential risks as early in the project as possible. A representation of a typical
Implementation Plan is shown below.
The Implementation Plan presents a roadmap of the planned iterations and should summarize the following:
Objective(s) of each iteration and its contribution to the project goal(s)
Business Milestones
Project Commitments
Team Composition
Project Dependencies
Project Approach
Factors that Drive the Number of Iterations per Phase
As part of the Implementation Planning, the number of iterations per phase will need to be determined. In general, OUM recommends using the standard number of
iterations as depicted in the OUM Implement Focus Area diagram. However, there are several factors that can increase or decrease the number of iterations represented
in the plan(s). The factors that would increase the number of iterations per phase are shown in table below.
Phase Factors
Inception
Highly variable scope
Lack of artifacts from Envision or Envision not conducted
Poorly defined / documented business objectives
Disagreement between stakeholders
Elaboration
Unstable architecture
Unproven architecture
Unstable requirements
Unavailable development environment
Challenging non-functional requirements
Construction
Large amounts of functionality to develop and test
Poor architecture
Limited team resources
Transition
Hardware replacement or rollout
Number of deployment and / or rollout sites
Large numbers of users to be trained or complex training required
Production
Level and length of support required
Incremental rollout strategy
Refer to the Determining the Number of Iterations technique below.
Before commencing work, present the plan to the stakeholders to gain agreement on the Implementation Plan. The project team in particular should agree on the
Implementation Plan.
Create the Iteration Plan for the First Iteration of Inception
Create the Iteration Plan for the first iteration of the Inception phase.
First, create the Iteration Plan Summary documenting the scope, objectives and approach for the iteration. As the project progresses, an Iteration Plan Summary will be
created for each iteration in the project.
Next, create the detailed WBS Project Workplan. It should be detailed enough to allow the project to move forward. Consider using the WBS from Bid Transition (if
available) or using any of the OUM example workplans as a starting point. To determine if a suitable starting Project Workplan template is available, review the Key
Components section of the OUM view that most closely matches the project profile. The tasks for an Iteration Plan in Inception should contribute towards goals for
meeting the Lifecycle Objective milestone that includes confirming the business objectives and project scope, determining risk, estimating cost and plan and staffing and
preparing the project team.
Once the core of the WBS Project Workplan is established, add or eliminate tasks or processes to match the identified scope and risk of the project. The next step in
building the detailed WBS Project Workplan is to consider the depth to which a particular task will be executed. Tasks in OUM are placeholders for work and are highly
scalable. Under the proper circumstances, spending the time to simply consider a task can constitute executing the task. This is a perfectly acceptable practice and is
often preferable to eliminating the task totally. Tasks are there to remind you of the process and order of the work. Finally, consider whether it is advisable or appropriate
to combine tasks or to execute the project using OUM's activities, which are groupings of tasks.
Refine and Baseline the Project Workplan
Refine the layers of the Project Workplan (that is, the Implementation Plan and Iteration Plan) for the first iteration of Inception, as necessary based on the risks and scope
information available during Project Start Up.
Although there is often uncertainty inherent in agile project, it is recommended that you baseline the Implementation Plan. The baseline provides a means for balancing
control and the requirement for responsiveness of incremental delivery. An initial baseline is created against which the team can implement change within defined
tolerances. Where change falls outside of these the Scope Change Management process is invoked. This is essential for stakeholder control and visibility. The baseline
also provides the benefits of providing an ability to track performance and the teams velocity, as well as improve future estimating capabilities.
In order to calculate the initial baseline for the Implementation Plan, 5 data points are required:
the number of planned iterations for the entire project
the length of each iteration in calendar days
the number of use cases planned for the project
the budget planned for the project
the start date of the project
Consider the Need to Partition the Workplan
In a large and/or complex OUM project, there may be a need to break up the expected functionality into partitions. This could include one for each major release of the
product to be developed, implemented or upgraded. Projects that are more than a year in duration, those with high risk factors and/or projects where there is business
value to be gained from delivery of a sub-set of the overall functionality are all candidates for the partitioned workplan approach. This approach allows risk to be spread
over a number of partitions and permits business value to be delivered sooner.
In the case where the multiple partitions will be used to accomplish the projects objectives, an overall plan should be established to map out the partitions. These
partitions may be implemented serially, in parallel or staggered. Each partition should be planned so that the delivery of some subset of the project benefits are realized
through the delivery of working software and/or implementation of Commercial Off-the-Shelf Software (COTS). This is done by examining the business drivers and
schedule goals for the project, laying out the work and assigning the milestones in the roadmap to one or more partitions.
Once the overall plan for the partitions is established, the planning details can be pushed to the lower level Implementation and Iteration Plans for each partition. As the
project progresses through the first partition and subsequent partitions, more information is brought to light that will require the plans at each layer to be adjusted.
Back to Top
SUPPLEMENTAL GUIDANCE
Iterative and Incremental Project Planning
This task has supplemental guidance for iterative and incremental project planning. Use Planning a Project using OUM - An Iterative and Incremental Approach to access
the supplemental information.
Tailoring OUM for Your Project
Refer to Tailoring OUM for Your Project for an overview of the tailoring process in OUM.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager 65
Project Leads This role is filled by project team members (for example, business analyst, developer, designer, system architect, etc) providing
expert advice.
25
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Work Breakdown Structure (WBS) (Bid Process)
Validated Scope (SM.010)
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Determining the Number of Iterations Use this technique to estimate the number of iterations for each phase when developing the Implementation Plan.
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Work Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IMPLEMENTATION_PLAN.DOC MS Word - Use this template to create the Implementation Plan.
ITERATION_PLAN_SUMMARY.DOC MS Word - Use this template to create the Iteration Plan Summary portion of the Iteration Plan that documents the scope,
objectives and approach for the iteration.
OUM Project Workplan MS Project - Use this template to create a detailed Project Workplan as a starting point.
Scrum Project Workplan (optional) MS Project - You may choose to use this workplan if you are using a Scrum project management approach on your project.
Although, a Scrum Workplan is not an official Scrum artifact, some projects may require a Project Workplan.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.020 - DEVELOP WORK MANAGEMENT EXECUTION AND
CONTROL PROCESSES AND POLICIES
Develop and document the strategy, control processes and policies that are used to manage, support and implement the work during the project. The Work Management
Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Work Management Plan - The Work Management Plan documents the strategy, control processes and policies that are used to manage, support and implement the
work during the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop any Work Management policies
and procedures.
Work Management Polices
and Procedures
Document any policies and procedures. Include the following:
Team Time Entry Process
Task Assignment to Project Team Members Process
Task Status Reporting Process
Unplanned Activities Time Capture Process
2 Develop Project Workplan updates and
versioning procedures.
Workplan Updates and
Versioning Procedures
Document the update and versioning procedures. Include the following:
Workplan Change Procedure
Workplan Archival Procedure
3 Develop monitoring and controlling
processes.
Work Management Monitoring
and Controlling Processes
Document any monitoring and controlling processes. Include the following:
Workplan Utilization to Analyze Project Trends
Workplan Utilization to Report Project Progress
4 Develop work product approval process Work Product Approval
Process
Approval Certificate
The Work Product Approval Process includes a list of all project work products
requiring approval of sign-off and from whom. In addition, define the following:
turn-around time
process
Obtain or create Approval Certificate Form.
5 Define contingency and management
reserve strategy.
Project Contingency and
Management Reserve
Strategy
Document contingency and management reserve strategy.
6 Obtain key stakeholder agreement and
approval on the Work Management Plan.
Approved Work Management
Plan
Obtain any necessary sign-off or Approval Certificate.
7 Make Work Management Plan available to
team members and client.
Work Management Plan
Back to Top
APPROACH
Develop Work Management Policies and Procedures
Develop and document the work management processes and policies that will be used during the project execution and control phases and communicate these to the
project team and client management. These policies and processes include:
Team Time Entry Process
Task Assignment to Project Team Members Process
Task Status Reporting Process
Unplanned Activities Time Capture Process
Team Time Entry Process
Time entry may include entering time to specific milestones reflected in the Project Accounting system work breakdown structure. Assigning workplan tasks would include
assigning tasks to all project team members including the client. Utilizing milestones for time entry would facilitate earned value analysis at the milestone level using the
Project Accounting actuals. If it is planned to enter actuals into the Project Workplan, time entry would also include the project team completing a time sheet weekly
indicating how much time was spent on individual tasks. Entering of actuals to the Project Workplan facilitates earned value analysis starting at the task level through the
planning tool.
Task Assignment to Project Team Members Process
At a minimum, team members must be advised of their upcoming tasks at least two weeks in advance so that team members can plan their work schedules. A best
practice would be to develop a weekly schedule that would advise the project team as a whole including the client of the planned activities that must be completed
during a pre-determined period.
Task Status Reporting Process
Determining task status would generally reflect status based on the amount of work (hours) remaining. For example, if a task has a 40 hour baseline, 20 hours have
been spent on the task to date and the team member feels that the task can still be completed with the remaining time allocated, the task would be considered 50%
complete. However, if the team member estimates that either more or less remaining hours are needed, the task must then be re estimated. If the team member
estimates that the duration (start and end dates) does not line up to the original duration, the task must be rescheduled (and re estimated if appropriate). Task status
reporting must be performed weekly and the information would be given by the team member to the project manager at the end of the work week. The project manager
must review and approve all re estimating and rescheduling; the project managers review could result in the project manager overriding the new estimate/revised
schedule given by a team member. Feedback regarding this approval and the resulting schedule change, if any, needs to be given as soon as possible to the team
member preferably by the first day of the following work week after the status was given. The rule of thumb is that no task would have a zero estimate to complete if
the task is not completed and no task would have overdue start and end dates. A best practice would be that the team would provide task status in weekly team status
reports.
Unplanned Activities Time Capture Process
The team must work to plan any activities outside of plan need to be reported weekly by the team and tracked by the project manager. Team members need to obtain
the project managers approval before taking part in unplanned activities. If this is not possible, the team member needs to advise the project manager of the activity as
soon as feasible. The amount of work on these activities needs to be tracked and reported separately from planned work. An unplanned activity would be considered
immediately complete; otherwise it would be a change and would need to go through the Scope Change Management Processes. A best practice would be to include an
area in weekly team status reports for the team to advise of the activity performed and the amount of work (hours) performed. The project manager would log the
unplanned activity in a specified area in the Project Workplan including the resource that performed it and the amount of time spent.
Develop Workplan Updates and Versioning Procedures
Develop the procedures to control the Project Workplan consisting of the following:
Workplan Change Procedure
Workplan Archival Procedure
Workplan Change Procedure
Changes made to the Project Workplan would, as a rule, entail changes due to re-estimating, re-scheduling, re-assigning resources and applying change order tasks.
Changes due to re-estimating and re-scheduling would not be re-baselined so that the original estimate and schedule could be used for variance tracking and reporting.
Changes requiring resource re-assignment would be done by zeroing out the original resource and then adding the new resource to the task with the original resources
work remaining given to the new resource.
Changes due to applying change order tasks need to include a method to identify the change order this could be done through a text field in the plan that would be used
for this data. Change order tasks would be base lined so that the original estimate and schedule would be captured. For the most part, change orders will be customer
approved change orders.
Develop Work Management Monitoring and Controlling Processes
Document the processes to execute the Project Workplan. These processes would include but are not limited to the following:
Workplan Utilization to Analyze Project Trends
Workplan Utilization to Report Project Progress
Executing the Project Workplan would include work management as discussed above, but it also includes methods that the project manager would utilize to manage the
project to plan. These would comprise of analyzing and tracking project trends and variances based on project actuals, analyzing the projects critical path and analyzing
and reporting project progress based on the repository of information that would be collected during the execution of the plan.
Workplan Utilization to Analyze Project Trends
Analyzing project trends would usually be done by reviewing the project tasks to see how well they are being performed and project resources to see how well they are
performing. Analyzing these trends and making adjustments based on the trends is essential in keeping the team working to plan.
Determining variances in task performance and the schedule is vital in determining the projects progress to date, determining the projects estimate to complete and in
forecasting how well the project will complete. This variance analysis is typically called earned value analysis. Earned value analysis encompasses a variety of analyses
based on pre-determined algorithms that result in indicators that are applied to the projects results to date.
Workplan Utilization to Report Project Progres
Reporting project progress using the Project Workplans repository of data would include reporting progress to all those concerned with the project from the team
member to the executive sponsors. Team member progress reporting must entail progress on his/her tasks as well as on the project as a whole. At a minimum, this
information must be given to team members on a weekly basis. These progress reports would typically be given at the task level. Executive-level project progress
reports would typically be given at a higher level.
Develop Work Product Approval Process
The first step in the process is to agree on the specific project work products that require approval. It is always best to agree on these in advance to avoid surprises later.
One the list is complete, the next step is to decide who the appropriate approver is for each work product. While it might be tempting to try to assign responsibility to one
person for a whole class of work products, make sure that all of them are appropriate for that person to approve. On close inspection, some might need to have a
different person's approval. Next, define the turnaround time from the time the work product is turned over for review until an approval or deficiency notice is due back. If
possible, include a "deemed acceptance" clause in the timeline, so that if no response is received within a specified period of time, the work product is automatically
approved. Finally, define the process that the work products will go through. Will delivery be hard or soft copy? Will the "clock" start upon delivery or is a separate
notification required? What is the escalation procedure if there is a difference of opinion about the justification for a rejection notice? Once all the questions have been
answered (there are more than were mentioned here), document them and get an approval signature for the process.
The most important approval is the first one. Gain approval of the Work Management Plan. By sticking to the agreed-upon process from the beginning, you improve the
odds that there will not be a breakdown in the procedure later on, when it might be more critical. Everyone will be in the habit of working through the approval process
and it should be followed routinely.
Define Project Contingency and Management Reserve Strategy
Contingency reserve is an often misunderstood and neglected project management concept. The simple fact is contingency reserve should be included as a standard,
required project management tool on most projects.
Contingency reserve planning can be quite sophisticated and there is a substantial body of literature available on the subject. The Project Management Institute's Project
Management Body of Knowledge (PMBOK) provides an excellent treatment of the subject.
There are two terms you should be familiar with: contingency reserve (a.k.a., contingency funds) and management reserve.
Term PMBOK Definition
Contingency Funds
Contingency reserves are estimated costs to be used at the discretion of the project manager to deal with anticipated, but not certain
events. These events are known unknowns and are part of the projects scope and cost baselines.
Management Reserve
Management reserves are budgets reserved for unplanned, but potentially required, changes to project scope and cost. These are
unknown unknowns and the project manager must obtain approval before obligating or spending this reserve. Management
contingency reserves are not a part of the project cost baseline, but are included in the budget for the project. They are not
distributed as budget and, therefore, are not a part of the earned value calculations.
An easy way to remember the difference is with a simple mnemonic. Project delays and associated costs caused by snowstorms in Canada come out of contingency
funds. Project delays and associated costs caused by snowstorms in Mexico come out of management reserve.
Contingency Funds
Contingency funds should be a standard tool used by project managers to address schedule and cost-related risks. Ideally, the projects contingency funds should equal
the total of the expected cost (probability times impact) of all project schedule and cost risks and their associated risk response plans.
Management Reserve
This may also be handled by change requests.
Communicate the Work Management Plan to the Project Team
Once the Work Management Plan is developed, obtain any necessary sign-off or Approval Certificate from the client. Make the Work Management Plan available to the
project team and client.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Work Management requirements that should be taken into consideration
when developing the detailed Work Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
WM020_DEVELOP_WORK_MANAGEMENT_PROCESSES_AND_POLICIES.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.030 - MANAGE PROJECT WORKPLAN
In the Manage Project Workplan task, you put into practice the strategy, processes and procedures documented in the Work Management Plan to engage resources to
execute the Work Management Plan (tasks and processes) defined in the Project Start Up phase and regularly review and update the Project Workplan with the actuals.
This task is ongoing throughout the Project Execution and Control phase by following an iterative and incremental planning approach.
As discussed in task, Develop Baseline Project Workplan (WM.010), plans are created in OUM using a top-down/bottom-up approach in which the plans at each layer
(Implementation and Iteration) are created and maintained in a simultaneous fashion. Because the plans are inter-related, it is likely that a change to a plan at one layer
will cause the need for an adjustment to a plan at another layer. At any given time in a project, there are two Iteration Plans active the one for the current iteration and
the one for the upcoming iteration. In this task, the Iteration Plan for the current iteration is monitored and maintained, the Iteration Plan for the subsequent iteration is
drafted and the Implementation Plan is adjusted as necessary based on the current and projected actual versus expected progress.
ACTIVITY
PEC.ACT.MPW Manage Project Workplan
Back to Top
WORK PRODUCT
Project Workplan - The Project Workplan consists of the following:
An Implementation Plan that represents one full pass through all of the OUM phases. It focuses on the project objectives, milestones and the number of iterations.
An Iteration Plan that includes an Iteration Plan Summary that focuses on the scope, objectives, and approach for the first iteration of Inception and a detailed
WBS Project Workplan that provides a network of interdependent tasks representing all work, with staff work assignments and schedules.
The Project Workplan is a living document that needs to be actively managed and maintained to reflect the current status and provide a realistic forecast throughout the
duration of the project. The Project Workplan is executed using the Work Management Plan. The Project Workplan consists of the following:
An Implementation Plan that represents one full pass through all of the OUM phases. It focuses on the project objectives, milestones and the number of iterations.
Various Iteration Plans, each consisting of an Iteration Plan Summary that focuses on the scope, objectives, and approach for the iteration and a detailed WBS
Project Workplan that provides a network of interdependent tasks representing all work, with staff work assignments and schedules. Each Iteration Plan is
focused on accomplishing the respective iteration's objectives and reducing risk.
The Baseline Project Workplan that was created in WM.010 is used as the starting point for the Project Workplan. It was created using a top-down/bottom-up approach in
which the plans at each layer (Implementation and Iteration) are created and maintained in a simultaneous fashion. Because the Implementation Plan and Iteration plans
are inter-related, it is likely that a change to a plan at one layer will cause the need for an adjustment to a plan at another layer.
Notice that the plan at the Implementation Plan level is longer in terms of time horizon but lower in granularity. This allows the project manager and other stakeholders to
have a roadmap view of the projects major milestones. The detailed planning is done at the Iteration Plan level that has a shorter time-horizon but more detail. This
allows the project manager and team members to have a way of planning and managing their day-to-day work.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify the objectives for the current Iteration
Plan.
Objectives,
Iteration Plan
Summary,
Iteration
Objectives
An iterations objectives and scope are defined in OUM by the set of use cases, configuration
requirements and other non-functional requirements that will be achieved during the iteration.
These requirements are selected from the projects current MoSCoW List and should be focused
on achieving the objectives of the present phase of the project.
2 Create the current Iteration Plan. Iteration Plan
for the Current
Iteration
The current Iteration Plan includes a time horizon for the next two to six weeks. It often can start
with a copy of the initial Iteration Plan (from the Baseline Project Workplan - WM.010) or the prior
Iteration Plan (depending on where you are in the project). Bring forward any work not completed
from the prior iteration and any approved change requests.
3 Towards the end of the current iteration, create
the draft plan for the upcoming iteration.
Iteration Plan
for the
Upcoming
Iteration
The upcoming Iteration Plan should start with a copy of the current Iteration Plan and is updated
for the next iteration. It evolves as the current iteration is executed. As results are known during
the current iteration, it will become apparent which tasks need to be included in the next iteration.
4 Adjust the Implementation Plan as needed. Implementation
Plan
The Implementation Plan must be kept in synch as each subsequent Iteration Plan is developed.
The degree to which an iteration achieves its objectives will impact future iterations as well as
milestones on the Implementation Plan.
5 Use the monitoring and controlling processes
documented in the Work Management Plan to
analyze the Project Workplan for variances
and trends and update accordingly.
Updated
Project
Workplan
The Project Workplan is updated for any variances and trends. Be sure to follow the update and
version procedures defined in the Workplan Change Procedure of the Work Management Plan
(WM.020).
6 Periodically, review the Implementation Plan for
the project schedule and completion estimate.
Project
Schedule and
Completion
Estimate
The Project Schedule and Completion Estimate is determined from the Project Workplan,
Resource Plan and Work Management Plan.
7 Produce Progress Reports. Various Work
Management
Progress
Reports
Various Work Management Progress Reports are produced based on the Reporting Procedures
and Reports and Schedule defined in the Work Management Plan (WM.020).
8 Ensure project team is submitting weekly time
and expense reports.
Weekly Time
and Expense
Reports
Weekly Time and Expense Reports are submitted by the project team based on the procedures
defined in the Work Management Plan (WM.020).
9 Ensure work breakdown structure (WBS) and
time entries are in synch.
Weekly Time
Entry
The Weekly Time Entry is synchronized with time entry according to the Team Time Entry Process
defined in the Work Management Plan (WM.020).
10 Enter actuals in WBS weekly for the current
Iteration Plan.
Updated
Iteration Plan
The Iteration Plan is updated weekly with actuals.
11 Assign team members to tasks. Task
Assignments
Task Assignments are given to team members according to the Task Assignment to Project Team
Members Process defined in the Work Management Plan (WM.020)
12 Communicate project status to team. Team Status
Report
The Team Status Report is communicated to the team as defined in the Task Status Reporting
Process defined in the Work Management Plan (WM.020).
13 Update task status (at least weekly). Task Status
Report
The Task Status Report is updated weekly as defined in the Task Status Reporting Process
defined in the Work Management Plan (WM.020).
14 Capture all unplanned activities. Unplanned
Activities Log
The Unplanned Activities Log is produced as defined in the Unplanned Activities TIme Capture
Process defined in the Work Management Plan (WM.020)
15 Forecast remaining work. Remaining
Work Forecast
The Remaining Work Forecast is a realistic forecast of work remaining.
16 Back up and archive Project Workplan. Project
Workplan
The Project Workplan is backed up and archived as defined and scheduled in the Workplan
Archival Procedure in the Work Management Plan (WM.020)
Back to Top
APPROACH
The Project Workplan is a living document that needs to be actively managed and maintained to reflect the current status and a realistic forecast throughout the duration
of the project. Use the strategy, control processes and policies documented in the Work Management Plan (WM.020) to manage the Project Workplan.
Iteration planning is where the bulk of planning for a project occurs. Each iteration should be planned so that a set of specific objectives are accomplished and a group of
project risks are addressed. A project manager will typically analyze and manage the current Iteration Plan on a daily basis.
The Iteration Plan information should be compiled in two documents. The first document, the Iteration Plan Summary reflects the scope and objectives of the iteration. The
primary goal of the scope is to clarify the iteration's objectives, priorities and evaluation criteria. This information can be used to track the iteration's progress and drive the
iteration assessment. The rest of the plan captures the detailed plan at the task level for the execution of the iteration.
For each iteration, the top risks should be identified based on the current state of the project (i.e., progress to-date, project phase, team experience, etc.). A rule of thumb
is to narrow the top risks to a list of no more than 10. Based on the list of the top 10 risks, the Iteration Plan can be developed to actively address each risk.
The deliverables for a given iteration should be associated with one or more of the iterations objectives. The iterations deliverables should not be confused with the OUM
task work products. The work products are just a means to an end to producing the deliverable and are not necessarily related to the projects objectives.
The most important deliverable of any iteration is the increment that will be developed. This is defined in OUM by the set of use cases, configuration requirements and
other non-functional requirements that will be achieved during the iteration. These requirements are selected from the projects current MoSCoW List. Selecting the right
set of requirements requires collaboration among all team members and should be focused on the current Ms and Ss shown on the MoSCoW list. Simply stated, the
MoSCoW List registers the known business requirements. Each requirement is classified by the first letter of: Must, Should, Could or Wont.
As the project moves along and risks are retired, the focus of the iterations can shift to filling out the needed functionality for the product under development. Also, change
requests and identified defects can be addressed as the more architecturally significant use cases have been realized. To achieve the right balance, the required
functionality, change requests and defects must be prioritized and estimated by analyzing the MoSCoW List. See task, RD.045 - Prioritize Requirements for more
information on how MoSCoW is used in OUM.
The scope of the iteration will be determined according to the objectives for the current iteration, team capacity and the iterations deliverables. These factors are
discussed in the sections below.
Objectives of the Current Iteration
Based upon the results of the risk analysis and the progress of the project up to this point must be refined to provide a clear set of measurable and achievable objectives
for the given iteration. The objectives for any iteration should be based on the current phase the project and should relate to meeting the milestone objectives for the
particular phase.
Team Capacity
The teams capacity is a broad measure of the amount of effort the team will be able to take on in the iteration. The team capacity must be considered when planning the
scope of work for the iteration. The capacity is determined by the teams size, availability and velocity, which refers to the speed at which a team can implement and test
use cases and change requests.
As the project progresses, it is often the case that requirements are handled with less effort which results in an increase in the teams velocity. Velocity can be used to
develop the initial estimates of the duration and effort required to complete the current iteration.
A teams velocity over time can be tracked using a burn-down Chart.
The burn-down chart above tracks progress by showing a decrease in the remaining hours. A project team can select any measure they deem relevant to measure
progress such as the number of scenarios completed, days remaining, etc.
The current teams capacity drives the initial estimates for the effort and duration for the given iteration. These initial estimates are needed to select which objectives will
be included in the Iteration Plan and will be further refined as the Iteration Planning progresses.
Deliverables for the Iteration
The deliverables should be associated with one or more of the iterations objectives. The iterations deliverables should not be confused with the OUM task work products.
The work products are just a means to an end to producing the deliverable and are not necessarily related to the projects objectives.
The most important deliverable of any iteration is the increment that will be developed. This is defined in OUM by the set of use cases and other non-functional
requirements that will be achieved during the iteration. These requirements are selected from the projects current MoSCoW list. Selecting the right set of requirements
requires collaboration among all team members and should be focused on the current Ms and Ss shown on the MoSCoW list. Simply stated, the MoSCoW List registers
the known business requirements. Each requirement is classified by the first letter of: Must, Should, Could or Wont.
As the project moves along and risks are retired, the focus of the iterations can shift to filling out the needed functionality for the product under development. Also, change
requests and identified defects can be addressed as the more architecturally significant use cases have been realized. To achieve the right balance the required
functionality, change requests and defects must be prioritized and estimated by analyzing the MoSCoW List. See Task RD.045 - Prioritize Requirements for more
information on how MoSCoW is used in OUM.
The second document in the Iteration Plan is the WBS Project Workplan. It lays out the detailed tasks required to achieve the scope that has been established for the
current iteration. This is done by selecting the appropriate tasks from the OWM work breakdown structure (WBS) for the current phase of the project.
As with any OUM project, it is recommended that the project manager build the Project Workplan by starting with the appropriate pre-tailored view for the type of project
under consideration (Solution-Driven Application Implementation, Requirements-Driven Application Implementation, etc.) and scaling the project for the given
circumstances. The Project Workplan should focus on the tasks included in the OUM Implement Core Workflow, which identifies the core tasks within the Implement
Focus Area.
Resources need to be associated with each OUM task included in the Project Workplan. The resources are assigned based on availability and matching the appropriate
skill-set to the task. All OUM tasks contain a Roles and Responsibilities table that can be used when assigning resources to tasks. In addition, the Project Roles reference
page provides additional information about the specifics of each role.
Once the resource assignments have been made estimates can be developed for each task associated with the iteration. The detailed estimates are determined by
refining the initial capacity-based estimates through the use of traditional estimating techniques that can be augmented through a commitment-driven approach. The
commitment-driven estimating approach involves asking those team members assigned to provide an estimate of how much effort will be required to complete the tasks
for each requirement in the iteration.
The individual task estimates balanced with the team velocity form the basis for the estimates for the Project Workplan. These estimates should be verified against
broader estimates completed as part of the initial planning effort for the iteration.
OUM strives to minimize dependencies within the detailed Project Workplans due to the limited duration of the plans. The key to reducing dependencies is to select
relatively independent bits of functionality that can then be integrated to achieve the iterations objectives. However, dependencies cannot be completely eliminated and
must be taken into account. This is where the project manager must work with the project team and stakeholders to do further analysis of the MoSCoW List. The
dependencies for the use cases addressed in the current iteration must be reflected on the MoSCoW List must also be reflected in the detailed plan for the iteration.
Each objective must be associated with an evaluation criterion that defines how the achievement will be measured and the levels of those measurements that will be
considered a success. These evaluation criteria must be clear and not subjective. The evaluation criteria must be objective and measurable so that progress toward the
projects goals can be demonstrated at the end of the iteration.
Iteration assessments are essential since iterative development is a collaborative endeavor between the project team, end users and project sponsors. The iteration
assessments are important events since they uncover potential issues that could derail the iteration. They also allow the team the ability to take necessary corrective
action to get the project righted. Iteration assessments include demonstrating evidence of results, open and honest review of the iteration, discussion on how to improve
the next one and acceptance reviews to ensure objectives have been met and the evaluation criteria have been satisfied.
Because of the large number of variables in a project and their interdependencies, it is not possible to accurately forecast all the outcomes. For this reason, projects rarely
run exactly as per the plan defined at the outset and require active management to stay on track. Without a realistic, up-to-date plan the project is likely to be out of
control and the project manager will lose credibility.
On a regular basis, analyze the Project Workplan for variances and trends for tasks and resources (for example, incomplete tasks to be sure that none have overdue start
or end dates or zero work remaining). Revise task estimates and task assignments as needed to meet the projects schedule and budget. Changes could include but are
not limited to task re estimating, task rescheduling, resource reassignment, and changes due to change orders. When making changes to the work plan, keep the
baseline intact unless the change is due to a change order. If tasks are added due to change orders, these must be base lined. If there are multiple changes consider
consider re-baselining for a package rather than individual changes.
Keep abreast of the projects schedule and estimate to complete this information is derived from the Project Workplan. It is common practice for project managers to
use a separate Resource Plan to determine the resource actuals and estimates to complete. This Resource Plan and the Project Workplan must correlate. The project
manager must be prepared to provide this information (as accurately as possible) whenever asked.
Following the processes developed in the Work Management Plan during Project Start Up, regularly report project progress based on the Project Workplan this would
include entering financials and project start and end dates in any required project progress reports. The projects estimate to complete given in the project progress report
must map to the Project Workplan and must correlate to all other financial reports.
Following the procedure developed in the Work Management Plan during Project Start Up, ensure that the project team is entering time weekly. This may include time
entry to the clients time entry system if the project is T&M.
Reminder: All team time must be entered into the time and expense system - this may include non-billable time.
If the Time and Expense Tracking system has a work breakdown structure reflecting project milestones, ensure that the time entry corresponds to task status. If actuals
are captured in the Project Workplan, a workplan audit needs to be performed monthly to ensure that system to capture time and expenses and the Workplan are in sync.
If actuals are being entered into the Project Workplan, collect this information weekly and enter the actuals into the Project Workplan. These actuals would also provide
task status.
Review the Project Workplan for unassigned tasks and assign tasks to team members that would be the tasks primary resource. Tasks must be assigned at least one
week in advance of their start date unless the task is a recent add on due to a change order. Assignment of tasks must include advising the assignee of task priority,
dependencies, duration, schedule (start and end dates), estimated work, and review schedule. It is good practice to provide team members with a task information sheet,
which lists their individual tasks at a glance.
Keep the project team abreast of the overall project status. On a regular basis, review the project status with the team. Provide an up-to-date hard copy of the Project
Workplan to project team members at least bi-weekly. Give the project team an at-a-glance schedule at pre-defined times this needs to be no less than 2 weeks at a
glance. This is particularly important for the client so that they can plan their work schedule in advance. As the entire team needs to be working toward the same, most
up-to-date version of the plan, ensure that the most current copy of the Project Workplan is understood and accessible to those who need it.
Following the procedure developed in the Work Management Plan (WM.020) during Project Start Up, capture task status from the team and update the Project Workplan
with the status. Again, the timing and content of task status reporting is defined in the Work Management Plan. Usually, it is performed weekly and the information is
given by the team member to the project manager at the end of the work week. It is a recommended practice that the team member provide task status via a weekly task
status report. The team member can also use the status report to communicate risks, issues, and upcoming plans. Review all requests by team members indicating that
a task needs to be re estimated and/or rescheduled. Either approve requests or adjust them. Advise team members as soon as possible of any adjustments made.
The project manager must review and approve all re-estimating and rescheduling; the project managers review could result in the project manager overriding the new
estimate/revised schedule given by a team member. Feedback regarding this approval and the resulting schedule change, if any, needs to be given as soon as possible
to the team member preferably by the first day of the following work week after the status was given. The rule of thumb is that no task should have a zero estimate to
complete if the task is not completed and no task would have overdue start and end dates.
Determining task status should generally be based on the amount of work (hours) remaining. For example, if a task has a 40 hour baseline, 20 hours have been spent on
the task to date and the team member feels that the task can still be completed with the remaining time allocated, the task would be considered 50% complete. However,
if the team member estimates that either more or fewer remaining hours are needed, the task must then be re-estimated. If the team member estimates that the duration
(start and end dates) does not line up to the original duration, the task must be rescheduled (and re-estimated if appropriate).
The team member must work to plan any activities outside of plan need to be reported weekly by the team member and tracked by the project manager. Team
members need to obtain the project managers approval before taking part in unplanned activities. If this is not possible, the team member needs to advise the project
manager of the activity as soon as feasible. The amount of work on these activities needs to be tracked and reported separately from planned work. A recommended
practice is to include an area in weekly team status reports for the team to advise of the unplanned activity performed and the amount of work (hours) performed. The
project manager would log the unplanned activity in a specified area in the work plan including the resource that performed it and the amount of time spent.
Following the procedure developed in the Work Management Plan (WM.020) during Project Start Up, capture all unplanned activities and log them including the activity,
resource, and amount of time spent. A good practice is to include a section in the Project Workplan to log these. They would be closed immediately after being logged.
Include this information when reporting status.
Estimate remaining work on the project by reviewing the Actuals; and by estimating the remaining effort. It is important that the remaining effort is not calculated by Budget
minus Actual. Remaining effort in the project must be calculated.
Other Considerations
The Baseline Project Workplan (WM.010) and Work Management Plan (WM.020) are developed during the Project Start Up phase and set forth the plan, strategy,
policies and procedures for managing work. They should be communicated to the project team in the Work Management Presentation made during the Team Orientation
Meeting. Refer to the Conduct Team Orientation task (STM.050) for more information on the Team Orientation Meeting. During the Team Orientation Meeting and
whenever a new resource joins the project, it is important for the project manager to establish the culture and ground rules for how the project works. The project
manager must ensure that the team members doing the work, clearly understand
the project objectives
the tasks they are accountable for and how they fit into the overall project plan
when they need to be completed by
to what standards or quality criteria
how they are reviewed and approved
the need for timely, realistic reporting and no surprises
The above need to be reinforced throughout the duration of the project.
Project Workplan Backup and Archiving
Along with other key project documents the Project Workplan must be backed-up to secure storage (not on the project managers notebook/PC ) on a weekly basis and
previous versions archived
Engaging Staff
Once a need for a specific resource has been identified, the delays to their being available to the project can be significant, particularly for international resources. A good
Project Workplan will greatly assist identifying resource requirements in advance.
Back to Top
SUPPLEMENTAL GUIDANCE
Iterative and Incremental Project Planning
This task has supplemental guidance for iterative and incremental project planning. Use Planning a Project using OUM - An Iterative and Incremental Approach to access
the supplemental information.
Tailoring OUM for Your Project
Refer to Tailoring OUM for Your Project for an overview of the tailoring process in OUM.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Workplan (WM.010) Start with the Baseline Project Workplan.
Work Management Plan
(WM.020)
The Work Management Plan documents the policies, procedures and processes for managing the Project Workplan during the
project.
Orientation Guide (STM.040)
Oriented Team (STM.050) Oriented Team members (resources) are assigned to tasks in the Project Workplan.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Determining the Number of Iterations Use this technique to refine the estimate of the number of iterations for each phase as the project progresses.
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Work Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Iteration Plan Summary MS WORD - Start with a copy of the initial Iteration Plan Summary (from the Baseline Project
Workplan - WM.010) or the prior Iteration Plan Summary (depending on where you are in the project)
to create the Iteration Plan Summary portion of the Iteration Plan that documents the scope,
objectives and approach for the iteration. Bring forward any work not completed from the prior
iteration and any approved change requests.
WM030_ASSIGNMENT_REQUEST.DOC MS WORD
WM030_WORK_PRODUCT_TRACKING_SPREADSHEET.DOC MS WORD
WM030_UNPLANNED_ACTIVITY_LOG.DOC MS WORD
WM030_ITERATION_END_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.040 - TRACK SCHEDULE PERFORMANCE
Tracking scheduled performance is periodically measuring actual project accomplishments against what was planned. This important output of this process is the
determination of whether the plan is on track or if a meaningful variation from the plan has occurred.
Technically speaking, the dividing line between a meaningful variation and a variation that is not significant is called the Variance Threshold. Project managers should
always choose a variance threshold for the schedule early on (often a 10% variance is used) so that they have a standard to compare against.
ACTIVITY
PEC.ACT.MPW Manage Project Workplan
Back to Top
WORK PRODUCT
Schedule Performance
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Calculate schedule variance and schedule performance index. Schedule Variance (SV) and Schedule Performance Index (SPI)
2 Forecast the project completion date. Completion Date Forecast
Back to Top
APPROACH
Track the Schedule Performance
One technique used to track the schedule performance is by employing the Earned Value Technique:
Calculate the Schedule Variance (SV) and Schedule Performance Index (SPI)
The two earned value components used to calculate schedule variance (SV) and the schedule performance index (SPI) are Planned Value and Earned Value. Used
together, they can give you an objective measurement of the project's status and provide a foundation for building a reliable forecast. The project manager should assess
the status of the schedule at least every month - preferably weekly.
Calculate Planned Value (PV) for the Project at the End of the Current Reporting Period
Planned Value is defined as the budgeted cost of the work scheduled up to the end of the current period. This information is typically available directly from your
scheduling tool, but only if the workplan is resource-leveled and cost burdened. In Microsoft Project, for example, the data is available in the Earned Value view.
Calculate Earned Value (EV) for the Project at the End of the Current Reporting Period
Earned Value is the budgeted cost of the work actually completed at the end of the current reporting period. This information may also be available from your scheduling
tool as mentioned above.
Calculate the Schedule Variance and Schedule Performance Index (SPI)
Schedule Variance = Earned Value - Planned Value SPI = Earned Value/Planned Value
Tip: One confusing aspect of earned value analysis is that Schedule Variance is a monetary amount. This makes it difficult to convey to anyone outside the project
management community since they do not intuitively grasp the relationship between time and cost. To eliminate the potential misunderstanding, convert SV to days by
using the average cost per workday.
Tip: To convert the SPI to an easily understandable percentage, multiply it by 100, then subtract it from 100. For example, an SPI of 1.03 becomes 103, then 3 percent. A
positive result means you are ahead of schedule, a negative result means you are behind schedule.Evaluate upcoming project work, risks and potential corrective
actions. Are there events or risks on the horizon that are likely to have a significant adverse or positive impact on cost performance? Are there corrective or preventive
actions that the team, our management or client management can realistically take to improve the situation?
Forecast the Project Completion Date
Determine the best method to forecast the completion date. Assess underlying schedule performance drivers and trends. For example, determine whether every task is
taking longer than planned or if there have been a few, significant exceptions. If a lot of tasks are running over, look for a global problem. You should validate the original
assumptions, estimate, and Validate Scope definition. If there are relatively few tasks running into problems, they should point you to the source of the problem (i.e.,
under-performers on the team, poor leadership, availability problems). Improving schedule variances may indicate a learning curve being surmounted and/or the
momentum of effective team building. Worsening schedule variances may indicate significant problems with the original estimates, staff problems, poor project
management or other major challenges. Based on this assessment of the situation, the project manager must select the most appropriate technique for forecasting the
project's completion date. The three approaches are:
Critical Path Method (CPM)
This method is the standard approach used by most project managers to produce a a single point-in-time estimate for project
completion. This is the default for all Microsoft Project plans.
Performance Evaluation and Review
Technique (PERT)
Some project managers prefer to use PERT, even though it requires more data, because they feel that it produces a more reliable
completion date. PERT estimation requires that you enter optimistic and pessimistic estimates in addition to the most probable
duration for each task. PERT then computes a completion date relying on the assumption that tasks are more likely to finish late
than finish early. The project end date computed by PERT will be later than the same project analyzed using CPM, and is likely to
be closer to the actual completion than CPM. In fact, PERT can be very accurate when non-critical paths have a fair amount of
slack. The formula for PERT is:
(Optimistic Estimate + (4 times Most Likely Estimate) + Pessimistic Estimate) divided by/6
Monte Carlo Simulation
The only tool capable of correctly analyzing for convergence issues is one that uses Monte Carlo simulation. Monte Carlo
simulation involves examining a large sample of possible outcomes for each task and path. The tool builds a statistical picture of
the likelihood of the project finishing by specific dates. The same amount of information is required as for a PERT analysis, but
the result is a much more complete picture of your project. Monte Carlo simulation can tell you:
What is the probability of your project finishing on a specific date?
What is the probability that your project will stay under budget?
What completion date corresponds to a confidence level (for example 95%) that you need
Monte Carlo simulation can be done in Excel and there are popular Monte Carlo simulation tools available outside of Oracle.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Calculate performance metrics and measure against variance threshold. Recommend or take corrective action to resolve
meaningful deviations from plan.
85
Client Project Sponsor Approve corrective actions recommended by the project manager. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Baseline Project Workplan
(WM.010)
The Baseline Project Workplan provides the baseline for tracking performance.
Work Management Plan (WM.020) The Work Management Plan documents the policies, procedures and processes for managing the Project Workplan during the
project.
Project Workplan (WM.030) At any given point, the current Project Workplan is used to track performance against planned performance.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Metrics for Agile Projects Use this technique to measure actual project accomplishments against what was planned for agile projects.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.050 - MANAGE APPROVALS
As part of the Work Management process, approvals must be managed. In this task, you manage the approval of project work products based on the procedures defined
in the Work Product Approval Process component of the Work Management Plan. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MSAA Manage Scope, Acceptance and Approvals
Back to Top
WORK PRODUCT
Managed Approvals - Managed Approvals is the executing the procedures defined in the Work Product Approval Process of the Work Management Plan. As project
work products requiring approvals are completed, the approvals are initiated per the Work Product Approval Process.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Obtain approval for identified project work products as
they are completed.
Approval
Certificate
Complete the Approval Certificate for the work product and send to defined approver
as defined in the Work Product Approval Process.
2 Follow-up that the Approval Certificate has been received
within the determined timeframe.
3 If the Approval Certificate has not been received, initiate
the Escalation procedure.
Initiate the Escalation procedure defined in the Work Product Approval Process.
4 File Approval Certificates. Signed Approval
Certificates
Back to Top
APPROACH
Use the Work Product Approval Process component of the Work Management Plan to implement this task. As project work products are completed, complete Approval
Certificates and forward to the designated approver for a signature. Follow-up that Approval Certificates are received in accordance with the timeline provided in the Work
Product Approval Process. If not, initiate the defined Escalation procedure. File signed Approval Certificates.
Managing work product approvals is an important task. If they are not managed, the project timelines can be impacted by schedule slippage and rework or even
cancellation. There is more to the process than simply walking a document over to the sponsor for a signature.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Work Management Plan (WM.020) The Work Management Plan documents the Work Product Approval Process for managing approvals during the project.
Project Workplan (WM.030)
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.060 - CLOSE WORK MANAGEMENT
During the Project Closure phase, the project manager is responsible for closing out project team work activities and the Project Workplan, archiving the project's work
products and work products, and providing final project metrics.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Work Management
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Close the Project Workplan and analyze
metrics.
Completed Workplan, Schedule Metrics
Report
Perform the necessary functions to close the Project Workplan and
produce the Schedule Metrics Report.
2 Document any lessons learned. Work Management Lessons Learned This report is used to create the Lessons Learned report produced in the
Communication process.
3 Close Work Management and Project
Workplan execution.
Closed Time Entry System of Record,
Archived Work Products
Back to Top
APPROACH
Close Project Workplan
Based on the project teams final status, update the Project Workplan with the final status from the team and mark all tasks complete.
Perform the final reconciliation between the Project Workplan and the time reporting system of record.
Perform a final analysis of the Project Workplan for variances and trends.
Produce the final Schedule Metrics Report and provide to internal and client management.
Perform the final back up and archive of the Project Workplan.
Close Work Management and Project Workplan Execution
Close project team time entry in the time entry system of record.
Create archive folders for hard copy work information. Create a separate folder for each activity.
Create archive media for soft copy work products, organized in folders by activity level.
Gather lessons learned during the Project Workplans execution and enter them into the lessons learned repository.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Gather work products and create archives for each activity. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
WM060_WORK_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[RKM] RISK MANAGEMENT
Risk Management is a structured process for identifying, documenting, gaining agreement on, and communicating risks throughout the lifecycle of a project. This process
does not deal with the management of issues and problems. There are dealt with in the Issue and Problem Management process. Risks are differentiated from issue and
problems as follows:
An Issue is an open concern or matter that is under discussion and could adversely impact the success of a project.
A Problem is a perceived variance between the expected and actual ability of an item to fulfill its defined purpose (for example, a software bug, consistent
unexpected downtimes, a faulty design, service request, etc.)
Risk is the possibility of an uncertain future outcome or condition, that if it occurs, has a positive or negative effect on a projects objectives, which may be mitigated
by pre-emptive action.
A Risk is viewed in two dimensions:
Risk Probability - the likelihood that a certain risk will negatively affect a project
Risk Impact - measures the anticipated severity of a risk
Although risks can have a positive outcome, when we talk about risk on an Oracle project, were usually concerned with things that may adversely affect the project. Think
about risks in relation to their effect on the triple constraints (scope, schedule and cost) and solution quality. Examples of common risk sources on our projects include:
Size and complexity of effort (for example, solution footprint, number of business units, geographic breadth)
Technical (infrastructure technology, applications, third party, legacy)
Staffing (both client and Oracle)
Funding
Timeline
Culture (national and organizational)
Management style
Clarity of purpose
Business value
Client relations
Organizational change management
Project organization structure
External factors
The goal of Risk Management is to reduce or eliminate predictable variances in the projects schedule and budget. Risk Management does not necessarily eliminate risk,
but attempts to reduce the exposure to risk.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Project Start Up, the project manager is responsible for documenting, gaining agreement on, and communicating a structured Risk Management Plan as well as
developing a Risk Management System for identifying, documenting and mitigating project risks throughout the lifecycle of the project.
A structured Risk Management Plan includes the following components:
Risk identification
Risk analysis and prioritization
Risk response planning
Risk monitoring and control
A formal Risk Management System is also created for tracking risks.
A formal risk assessment is required at bid time. During Project Start Up, it needs to be revisited and a Baseline Risk Assessment should be created.
Project Execution and Control Phase
Risk management becomes even more critical during Project Execution and Control. It is important for the project manager to regularly conduct risk assessments.
Particular attention should be paid to risks prior to production cutover.
Project Closure Phase
During the Project Closure phase, there may still be risks that will impact the client as they move forward into production (e.g., support risks, operational risks, etc.). The
project manager should conduct a Post-Production Risk Assessment and evaluate these risks and communicate them to the client.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS RKM.010 Develop Risk Management Plan Risk Management Plan Y Core
PS RKM.020 Conduct Baseline Risk Assessment Baseline Risk Assessment Y Core
PS RKM.030 Develop Risk Management System Risk Management System Core
Project Execution and Control
PEC RKM.040 Manage Risk Managed Risk Core
PEC RKM.050 Monitor and Control Risk Assessed Risk Y Core
Project Closure
PC RKM.060 Conduct Post-Production Risk Assessment Post-Production Risk Assessment Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.010 - DEVELOP RISK MANAGEMENT PLAN
The goal of this task is to identify possible risk, calculate their potential impact on the project, and develop options for handling each risk should it develop during the
course of the project as well as develop the process (procedure) for managing risk during the Execution and Control phase of the project. This information is then
documented in the Risk Management Plan. The Risk Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Risk Management Plan - The Risk Management Plan documents possible risk and their potential impact on the project (e.g., low, moderate or high) and the options for
handling each risk should it develop during the course of the project as well as the process (procedure) for managing risk during the Execution and Control phase of the
project. The Risk Management Plan is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine which risks are likely to affect the project. Identified Risks Watch
List
Document the characteristics of each identified risk.
2 Identify the priority of the risk response for each identified
risk.
Qualitative Risk
Response
Document the priority of the risk response for each identified risk and use it as
an input to quantifying each risk.
3 Quantify each identified risk. Projected Possible Risk
Impacts
Document the possible impacts for each identified risk on project
implementation.
4 Determine a mitigating response to each identified risk. Risk Response Plan Document a response plan for each identified risk.
5 Develop the Risk Management Process. Risk Management
Process
Document the procedure for managing and tracking risk during Project
Execution and Control.
6 Define roles and responsibilities. Roles and
Responsibilities
List any and all roles involved and describe the responsibilities.
7 Obtain key stakeholder agreement and approval on the
Risk Management Plan.
Approved Risk
Management Plan
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
The project manager (and sometimes the client project manager) is responsible for managing risk overall. In a large project, there may be a full-time position dedicated to
managing risk.
Risk management is "an organized means of identifying and measuring risk and developing, selecting, and managing options for handling these risks." The Risk
Management Plan specifically addresses the following:
Identified Risks Watch List - Determine which risks are most likely to affect the project and document the characteristics of each including trigger events. The
trigger event can be used to monitor for the risk.
Qualitative Risk Response - Identify the priority of the risk response and then use it as an input to quantify the risk (i.e., projecting possible risk impacts).
Projected Possible Risk Impacts - Quantify the risk. Analyze and evaluate each risk and risk interaction to assess the range of possible impacts on the project
implementation.
Risk Response Plan - Determine the response to a risk event by examining the range of possible responses and choosing the best approach.
Risk Management Process - Develop the procedures for managing risk during Project Execution and Control. This process should include monitoring already
identified potential risks and the process for dealing with them if their trigger event occurs as well as dealing with entirely newly identified risks. The process should
include components for identifying, assessing, approving, handling, tracking and reporting risk.
Roles and Responsibilities - Identify and document, by roles and responsibilities, the person who owns and manages the Risk Management Plan -- the person who
proactively looks for any real or potential problems. If someone other than the project manager is responsible for risk management, the project manager should
meet with them regularly to discuss their risk areas. Document those conversations, too. When all is said and done, the project manager is ultimately responsible.
The table below lists some possible responses to risk.
Response Description
Avoid
Eliminate the cause of the risk. Now that you know about this particular risk, you plan to steer around it altogether.
Transfer
Deflect the risk by transferring the risk outside the organization. Possible candidates include a subcontractor, the customer, or a supplier. Transfer often
involves developing contract terms and conditions unique to the situation.
Mitigate
Deal with the risk in one of these standardized approaches:
Reduce the probability of occurrence, frequently by choosing an alternate approach.
Reduce the impact of the risk event by having a plan in place to immediately react to the event if it occurs. That might mean flying in an expert to
help move the project along if the team runs into a problem they cant solve.
Accept and
Control
Accept some of the risks from the offset and control those throughout the lifecycle.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Risk Management requirements that should be taken into consideration
when developing the detailed Risk Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM010_RISK_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.020 - CONDUCT BASELINE RISK ASSESSMENT
During Project Start Up, conduct an baseline risk assessment. The objective is to identify risk, assess current risk levels and ensure proper risk techniques are applied.
This assessment is conducted by:
project sponsors
project leadership team
project team members
other stakeholders from the team (for example, internal risk managers)
ACTIVITY
PS.ACT.RBC Review Bid and Contract
TASK GROUPS
Back to Top
WORK PRODUCT
Baseline Risk Assessment - The Baseline Risk Assessment provides a point-in-time snapshot of the risk at Project Start Up.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify any current potential risk issues. Identified Risks Document the characteristics of each identified risk.
2 Identify the priority of the risk response for each
identified risk.
Qualitative Risk
Response
Document the priority of the risk response for each identified risk and use it as an
input to quantifying each risk.
3 Quantify each identified risk. Projected Possible
Risk Impacts
Document the possible impacts for each identified risk on project implementation.
4 Determine a mitigating response to each identified risk. Risk Response Plan Document each mitigating response to each identified risk.
5 Obtain key stakeholder agreement and approval on the
Risk Response Plan.
Approved Risk
Response
For each actual risk identified, obtain any necessary sign-off or Approval
Certificate for the determine response.
6 Execute the approved response for each risk. Mitigated Risk Document the results of applying the response to each risk.
Back to Top
APPROACH
Conduct a Baseline Risk Assessment for the project in the Project Start Up phase. The Baseline Risk Assessment includes the following components:
Identified Risks - Determine any risks that are currently affecting the project and document the characteristics of each. Qualitative Risk Response - Identify the
priority of the risk response and then use it as an input to quantify the risk (i.e., projecting possible risk impacts). Projected Possible Risk Impacts - Quantify the
risk. Analyze and evaluate each risk and risk interaction to assess the range of possible impacts on the project implementation. Risk Response Plan - Determine
the response to a risk event by examining the range of possible responses and choosing the best approach. Approved Risk Response - If necessary, obtain key
stakeholder agreement for the response.
Mitigated Risk - Determine if the the response to a risk event has mitigated the risk and document the results.
Use the Baseline Risk Assessment as a tool to monitor risk during the project.The following techniques for identifying risk are recommended:
Collect project historical data by interviewing stakeholders. Draw on past experience.
Use expert judgment.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Review (Bid Review Process)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM020_BASELINE_RISK_ASSESSMENT.DOC MS WORD
RKM020_RISK_MITIGATION.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.030 - DEVELOP RISK MANAGEMENT SYSTEM
In this task, you develop the system to support and execute the Risk Management Process documented in the Risk Management Plan. The Risk Management Process
contains the procedures for managing risk during Project Execution and Control. This includes identifying, assessing, approving, handling, tracking and reporting risk.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Risk Management System - The Risk Management System incorporates the various pieces required for managing risk during the project. It includes the following
components:
Risk Form
Risk Log
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create or obtain a risk form. Risk Form This form is used to capture individual risk items as they are identified.
2 Create or obtain a risk log. Risk Log This log is used to track all identified risk issues.
Back to Top
APPROACH
The actual procedures for the Risk Management System are defined in the Risk Management Process component of the Risk Management Plan. The focus here is to
support and execute those procedures. Generally, this involves obtaining or creating a Risk Form and a Risk Log. When obtaining or creating your forms keep in mind, at
a minimum, the following information should be captured:
Risk ID Each risk should have a unique ID.
Submitted By Enter the name of the person and/or organization who raised the risk.
Date Submitted Enter the date the risk was recorded in the Risk Log.
Estimated Response Plan Date Enter the date that a mitigation plan for the risk is expected to be in place.
Consequences Complete the impact to the project and/or business in terms of money, time, and/or quality.
Application/Flow/Module If applicable, enter the name of the application, flow, or module to which the risk pertains.
Type Enter the type of risk (e.g., technical, process, organizational, etc.).
Title Provide a short description of the risk (usually a few words or a sentence, helpful when reporting risks).
Description Enter a complete description of the risk, the more details the better.
Probability Indicate the probability of the risk.
Escalation Indicate the current escalation level and anticipated date and level of next escalation.
Target Date Enter the target date for closure review of this risk.
Assigned To Enter who currently owns mitigation of the risk.
Status Enter the current status of the risk (typical values are open or closed).
Risk Response Plan Provide a detailed description of actions (including dates and owners) required to deal with the risk.
The Risk Form is used to raise a risk item and provide the basic information to start the process. The Risk Log is used to track the progress and provide reporting.
Consider a central risks repository for delegated project team members to log and update risks as required. The project manager should avoid the scenario where many
team members are updating the risk logs.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Plan (RKM.010) Use the processes defined in the Risk Management Plan to develop the Risk Management System.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Risk Portfolio Use this technique to assess overall project risk.
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Risk Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM030_RISK_FORM.DOC MS WORD
RKM030_RISK_LOG.XLS MS EXCEL
RISK_ISSUE_PROBLEM_LOG.XLS MS EXCEL - This template provides a combined Risk, Issue and Problem Log.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.040 - MANAGE RISK
The Manage Risk task entails executing the process detailed in the Risk Management Plan for the potential risks identified in the Identified Risks Watch List. While there
is a value in working through the process of developing the plan, there is a lot more value in working with the plan regularly to help navigate the implementation. Resist
the temptation to carefully file the plan away somewhere. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MRIP Manage Risks, Issues and Problems
Back to Top
WORK PRODUCT
Managed Risk - Managed Risk is executing the procedures defined in the Risk Management Plan when an already identified potential risk from the Identified Risks
Watch List is triggered. Risks are are monitored and if detected their Risk Response Plan is executed to mitigate the risk.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Monitor risk. Updated
Project
Management
Plan
Monitor the risks already identified in the Identified Risks Watch List.
Update the appropriate components of the Project Management Plan
for any new potential risks.
2 As actual risks are identified (e.g., their trigger event occurs), route them
through the procedures identified in the Risk Management Process of the
Risk Management Plan.
Risk Form Once an actual risk is triggered, complete a Risk Form.
3 Add each identified risk (completed Risk Form) to the Risk Log and track
its progress.
Risk Log Track all risks from identification to mitigation.
4 Respond to risks. Implemented
Risk
Response
Plan
Implement the agreed upon Risk Response Plan from the Risk
Management Plan when symptoms/risks occur.
5 Track and report individual risk status. Risk Log Update the Risk Log.
Back to Top
APPROACH
Monitor Risk - Monitor any risks already identified on the Identified Risks Watch List developed in the Risk Management Plan. Make risk review an agenda item for the
project meetings to keep risk awareness in front of the entire project team. If any new potential risks are identified, analyze the probability and severity of each risk and
update all the appropriate components of the Risk Management Plan.
Respond to Risk - When a trigger event occurs, execute the response steps from the Risk Management Plan. Reiterate the importance of project team members
identifying concerns about new risks as they become aware of them. Remind them that it is better to raise a concern and decide not to take any action based on the
information than to miss a trigger event altogether.
Use the Project Workplan - Add tasks to the Project Workplan for risk reviews following major milestones and/or at the end of each phase (e.g., after competing the
Construction phase). This provides both lessons learned on the phase that is closing out and provides an opportunity to review issues associated with the upcoming
phase. Reassessing the upcoming phase is important because you will know more than you did at the beginning of the project. That information will help you reassess
risks you identified initially as well as spot new risk.
Tool Tip: Use Microsoft Projects Task Notes capability to insert risk trigger information into your Project Workplan. This will make it easier for the team to keep an eye on
specific areas or exposures.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Plan (RKM.010)
Risk Management System (RKM.030)
These work products document the processes and system for managing risks during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Use Risk Form created/edited in RKM030
Use Risk Log created/edited in RKM030
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.050 - MONITOR AND CONTROL RISK
The Monitor and Control Risk task entails executing the procedures detailed in the Risk Management Process for unplanned or NEW risks that were not already identified
in the Identified Risks Watch List. These risks do not already have the benefit of being analyzed and having a Risk Response Plan in place in the Risk Management Plan.
Therefore, the risk analysis, response planning and approval are also part of this task. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MRIP Manage Risks, Issues and Problems
Back to Top
WORK PRODUCT
Assessed Risk - Assessed Risk is the executing the procedures defined in the Risk Management Plan for NEWLY identified risks that have not already been identified as
potential risks in the Risk Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Conduct regular risk assessment and identify any current
risks.
Risk Form
For each risk identified, complete the Risk Form. Include the following:
characteristics of the identified risk
priority
project impacts
risk response recommendation
Follow the procedures set forth in the Risk Management Plan.
2 Add each newly identified risk (completed Risk Form) to the
Risk Log to track its progress.
Risk Log Track all risks from identification to mitigation.
3 Obtain key stakeholder agreement and approval on the risk
response recommendation.
Approved Risk
Response
For each risk, obtain any necessary sign-off on the Risk Form or Approval
Certificate for the recommended response.
4 Execute the approved response for each risk. Mitigated Risk Document the results of applying the response to each risk.
5 Track and report results of risk assessment. Risk Log Update the Risk Log.
Back to Top
APPROACH
During Project Execution and Control, monitor periodically for unplanned for risk. If any new unplanned for risks are encountered, analyze and asses the risk and
complete a Risk Form with the following information:
Description
Priority
Projected Impacts
Risk Response Recommendation
Use the Risk Log to monitor and track risk.
Periodically ensure the following:
Reassess that the project assumptions are still valid.
Make sure the policies defined in the Risk Management Plan are being followed. Modify contingency or reserve funds to keep in line with the risks of the project.
Update the Risk Management Plan, as necessary.
An easy way to remember the difference between monitoring and controlling risk is with a simple mnemonic. Project delays and associated costs caused by snowstorms
in Canada come out of contingency funds. Project delays and associated costs caused by snowstorms in Mexico come out of management reserve.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Plan (RKM.010)
Risk Management System (RKM.030)
These work products document the processes and system for monitoring and controlling risks during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Use Risk Form created/edited in RKM030
Use Risk Log created/edited in RKM030
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.060 - CONDUCT POST-PRODUCTION RISK ASSESSMENT
During Project Closure, conduct a post-production risk assessment to properly ascertain any remaining or possible risk prior to transitioning the Risk Management System
to the client.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Post-Production Risk Assessment - The Post-Production Risk Assessment provides a point-in-time snapshot of the risk at Project Closure.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify any current potential risk issues. Identified Risks Document the characteristics of each identified risk.
2 Identify the priority of the risk response for each
identified risk.
Qualitative Risk Response Document the priority of the risk response for each identified risk and use it as an
input to quantifying each risk.
3 Quantify each identified risk. Projected Possible Risk
Impacts
Document the possible impacts for each identified risk on project implementation.
4 Determine a mitigating response to each
identified risk.
Risk Response Plan Document each mitigating response to each identified risk.
5 Compile the assessment into one document. Post-Production Risk
Assessment
Compile all the components into one document.
6 Document any lessons learned. Risk Management Lessons
Learned
This report is used to create the Lessons Learned report produced in the
Communication process.
Back to Top
APPROACH
Conduct a Post-Production Risk Assessment for the project in the Project Closure phase. The Post-Production Risk Assessment includes the following components:
Identified Risks - Determine any risks that are currently affecting the project and document the characteristics of each.
Qualitative Risk Response - Identify the priority of the risk response and then use it as an input to quantify the risk (i.e., projecting possible risk impacts).
Projected Possible Risk Impacts - Quantify the risk. Analyze and evaluate each risk and risk interaction to assess the range of possible impacts on the project
implementation.
Risk Response Plan - Determine the response to a risk event by examining the range of possible responses and choosing the best approach.
Transition the Risk Management System to the client and provide to them the Post-Production Risk Assessment. The information in the Assessment provides the client
with a plan for future Risk Management to reduce exposure and ensure a proper response to certain project risks.
Lastly, document any lessons learned for inclusion in the Lessons Learned reporting produced in the Communication process.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or 15
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM060_POST_PRODUCTION_RISK_ASSESSEMENT.DOC MS WORD
RKM060_RISK_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[IPM] ISSUE AND PROBLEM MANAGEMENT
Issue and Problem Management is a structured process for identifying, documenting, tracking and resolving issues and problems as they occur throughout the lifecycle of
a project. The project manager is responsible for defining, gaining agreement on, and communicating, a structured process to capture and track issues and problems
using a formal issue/problem log. This log must be actively maintained, and effort must be devoted to put closure on critical project issues. It is the project managers
responsibility to record, assign, and track issues as well as to drive the resolution of open issues/problems. The project must also communicate and report on
issue/problem status.
While issues and problems are very different, the management of them is very similar. Issues are differentiated from problems and risks as follows:
An Issue is a point or matter that is not settled and is under discussion (there may also be opposing views and/or disagreements). Some issues if not addressed,
could adversely impact the success of a project. (From PMI PMBOK Third Edition)
A Problem is a perceived variance between the expected and observed ability of an item to fulfill its defined purpose (for example, a software bug, consistent
unexpected downtimes, a faulty design, TARs/SRs, etc.). (From PMI PMBOK 2000)
A Risk is an uncertain event or condition, that if it occurs, has a positive or negative effect on a projects objectives. (From PMI PMBOK Third Edition)
Issues and problems can be raised by any project stakeholder, including project team members, the client, third-party integrators, or vendors. They should be categorized
by type and priority, and an estimated closure date should be assigned. Once the issue/problem has been formally documented, it is typically assigned to an owner for
resolving. If an issue/problem cannot be resolved, it must be escalated to senior management for resolution. The resolution may result in the need for a project change
requiring a change order. The investigation and/or resolution may require the establishment of one or more entries in the risk log for assessment and quantification.
Note: Issues related to product expectations, including TARs/SRs, should be recorded as problems, not issues.
Key aspects of Issue and Problem Management are:
Enforce issues/problem resolution
Analyze cause and effects associated with issues/problems
Capture, analyze, and resolve and/or escalate issues/problems
Establish reporting metrics (for example, by category, by application, by flow, etc.)
A best practice is to discuss open issues and problems in project status meetings, including executive steering committee meetings, and to make an effort to put a hard
closure on lingering issues/problems.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Start Up, establish both the Issue Management Strategy and the Problem Management Strategy as well as the Issue and Problem Management System
Project Execution and Control Phase
Following the strategy, processes, and procedures established during Project Start Up, the project manager must make sure that all project issues are carefully and
accurately logged, prioritized, and assigned for closure. Moreover, it is the project managers responsibility to drive open issues to a closure that fulfills the contractual
requirements in a manner that is acceptable to the client.
Project Closure Phase
During Project Closure, the project manager must generate a final issue and problem report and communicate any remaining open issues and problems to the client.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS IPM.010 Develop Issue Management Strategy Issue Management Strategy Y Core
PS IPM.020 Develop Problem Management Strategy Problem Management Strategy Core
PS IPM.030 Develop Issue and Problem Management System Issue and Problem Management System Core
Project Execution and Control
PEC IPM.040 Manage Issues and Problems Managed Issues and Problems Y Core
Project Closure
PC IPM.050 Produce Final Issue and Problem Report and Close Log(s) Closed Issue and Problem Log Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.010 - DEVELOP ISSUE MANAGEMENT STRATEGY
Develop the definition, purpose and overall project strategy for handling issues. In addition, develop the process (procedure) for managing issues during the Execution
and Control phase of the project. Document this information in the Issue Management Strategy. The Issue Management Strategy is a key component of the Project
Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Issue Management Strategy - The Issue Management Strategy contains the definition, purpose and strategy for issue management as well as the process (procedure)
for managing issues during the Execution and Control phase of the project. The Issue Management Strategy is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define issues. Definition Provide a clear definition of what constitutes an issue.
2 Define the purpose of issue management. Purpose Document the purpose.
3 Define the overall project strategy for issue management. Strategy Document the strategy.
4 Develop the Issue Management Process. Issue Management Process Document the procedure for managing and tracking issues during
Project Execution and Control.
5 Define roles and responsibilities. Roles and Responsibilities List any and all roles involved and describe the responsibilities.
6 Obtain key stakeholder agreement and approval on the Issue
Management Strategy.
Approved Issue
Management Strategy
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Because issues and problems have similar management needs, they have been combined into a single Issue and Management process. For the benefit of project team
members, be sure to provide a very clear and specific definition of what constitutes an issue. The first decision you may need to make for issues and problems is whether
or not to combine the management of issues and problems. Some reasons to consider whether or not to combine issue and problem management follow:
Can you create or obtain a single form and log that meets the needs of both issues and problems?
What is the size of your project? For a small project, you may want to combine issue and problem management, while you may want to separate them for larger
projects.
Follow a common standard strategy throughout the project. This strategy should remain the same from Project Start Up until Project Closure.
Develop the procedures for managing issues during Project Execution and Control. Issues should be logged and tracked at the offset of the project so as not to cause any
project schedule delays. The Issue Form and Issue Log are common tools used by project managers to log, prioritize and assign issues to the project team. Most projects
have issues, agreeing on closing issues is the responsibility of the project manager. The Issue Management Process should include the following:
Use of an Issue Form
Prioritize issues, including establishing clear guidelines and definitions for discrete issue priorities (e.g., showstopper/executive, high, medium, low, etc.).
Assign each issue to a person(s) responsible for owning resolution and for performing impact analysis, as required.
Use of an Issue Log
Track and report issues status (e.g., issue aging, open/closed status, resolution status, etc.).
Escalation Procedures, including how long does the issue stay at one level before it is escalated to the next level up to the executive committee.
Document any roles involved and describe the responsibilities.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Issue Management requirements that should be taken into consideration
when developing the Issue Management Strategy.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM010_ISSUE_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.020 - DEVELOP PROBLEM MANAGEMENT STRATEGY
Develop the definition, purpose and overall project strategy for handling problems. In addition, develop the process (procedure) for managing problems during the
Execution and Control phase of the project. Document this information in the Problem Management Strategy. The Problem Management Strategy is a key component of
the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Problem Management Strategy - The Problem Management Strategy contains the definition, purpose and strategy for problem management as well as the process
(procedure) for managing problem during the Execution and Control phase of the project. The Problem Management Strategy is a key component of the Project
Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define problems. Definition Provide a clear definition of what constitutes a problem.
2 Define the purpose of problem management. Purpose Document the purpose.
3 Define the overall project strategy for problem management. Strategy Document the strategy.
4 Develop the Problem Management Process. Problem Management
Process
Document the procedure for managing and tracking problems during
Project Execution and Control.
5 Define roles and responsibilities. Roles and Responsibilities List any and all roles involved and describe the responsibilities.
6 Obtain key stakeholder agreement and approval on the
Problem Management Strategy.
Approved Problem
Management Strategy
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Because issues and problems have similar management needs, they have been combined into a single Issue and Management process. For the benefit of project team
members, be sure to provide a very clear and specific definition of what constitutes a problem. The first decision you may need to make for issues and problems is
whether or not to combine the management of issues and problems. Some reasons to consider whether or not to combine issue and problem management follow:
Can you create or obtain a single form and log that meets the needs of both issues and problems?
What is the size of your project? For a small project, you may want to combine issue and problem management, while you may want to separate them for a very
large project.
Every project has problems. Problems can be raised by any project stakeholder, including project team members, the client, third-party integrators, or vendors. Problems
need to be prioritized, assessed and resolved. The Problem Management Process should include the following:
Use of an Problem Form
Validate the problem to ensure results can be repeatable.
Prioritize problems, including establishing clear guidelines and definitions for discrete priorities (high, medium, low, etc.).
Assign the problem to a project SME.
Use of an Issue Log
Track and report problem status
Ensure the right resources are on this problem.
Time Resolution Procedures, including assigning a time for resolving the problem.
Monitor Procedures to ensure that the problem does not reoccur.
Document any roles involved and describe the responsibilities.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Problem Management requirements that should be taken into
consideration when developing the Problem Management Strategy.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM020_PROBLEM_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.030 - DEVELOP ISSUE AND PROBLEM MANAGEMENT
SYSTEM
In this task, you develop the system to support and execute the Issue Management Process and the Problem Management Process documented in the Issue
Management Strategy and Problem Management Strategy. These processes contains the procedures for managing issues and problems during Project Execution and
Control. This includes identifying, assessing, approving, handling, tracking and reporting issues and problems.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Issue and Problem Management System - The Issue and Problem Management System incorporates the various pieces required for managing issues and problems
during the project. It includes the following components:
Issue/Problem Form
Issue/Problem Log
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create or obtain a issue/problem form. Issue/Problem Form This form is used to capture individual issue/problem items as they are identified.
2 Create or obtain a issue/problem log. Issue/Problem Log This log is used to track all identified issues/problems.
Back to Top
APPROACH
The actual procedures for the Issue and Problem Management System are defined in the Issue and Problem Management Process components of the corresponding
Issue and Problem Management Strategies. The focus here is to support and execute those procedures. Generally, this involves obtaining or creating an Issue/Problem
Form and an Issue/Problem Log. Depending on whether or not you are combining or separating issue and problem management, you may need one Form and Log or a
separate Issue Form and Problem Form and Issue Log and Problem Log.
When obtaining or creating your forms keep in mind, at a minimum, the following information should be captured:
Issue/Problem ID - Each issue/problem should have a unique ID (e.g., I#### or P####).
Submitted By Enter the name of the person and/or organization who raised the issue/problem.
Date Submitted Enter the date the issue/problem was recorded in the Log.
Estimated Action Date Enter the date that the next action is expected on this issue/problem.
Impact Asses and document the impact to the project and/or business in terms of money, time, and/or quality.
Application/Flow/Module If applicable, enter the name of the application, flow, or module to which the issue/problem pertains.
Type Enter the type of issue/problem (e.g., technical, process, organizational, etc.).
Title Provide a short description of the issue/problem (usually a few words or a sentence, helpful when reporting issues/problems).
Description complete description of the issue/problem, the more details the better
Priority Indicate a priority (typically values could be critical, high, medium, low).
Escalation Indicate the current escalation level and anticipated date and level of next escalation.
Days Open Calculate the number of days this issue or problem has been opened.
Target Close Date Enter a target date for resolution.
Assigned To Enter who currently owns resolution of the issue/problem.
Status Enter the current status of the issue/problem (typical values are open or closed).
Action Plan/Comments Enter a detailed description of actions (including dates and owners) required to resolve the issue/problem.
The Form is used to raise an issue or problem and provide the basic information to start the process. The Log is used to track the progress and provide reporting.
Consider a central issue/problem repository for delegated project team members to log and update issues/problems, as required. Log all issues/problems, no matter how
minor. All team members, including the client team members, should have access to originate issues.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Issue Management Strategy
(IPM.010)
Problem Management Strategy
(IPM.020)
Use the processes defined in the Issue Management Strategy and Problem Management Strategy to develop the Issue and
Problem Management System.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM030_ISSUE_FORM.DOC MS WORD
IPM030_ISSUE_LOG.XLS MS EXCEL
IPM030_PROBLEM_FORM.DOC MS WORD
IPM030_PROBLEM_LOG.XLS MS EXCEL
RISK_ISSUE_PROBLEM_LOG.XLS MS EXCEL - This template provides a combined Risk, Issue and Problem Log.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.040 - MANAGE ISSUES AND PROBLEMS
In the Manage Issues and Problems task, you put into practice the processes documented in the Issue Management Strategy and Problem Management Strategy and
manage any issues/problems as defined. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MRIP Manage Risks, Issues and Problems
Back to Top
WORK PRODUCT
Managed Issues and Problems - Managed Issues and Problems is using the Issue and Problem Management System to execute the procedures documented in the
Issue Management Strategy and Problem Management Strategy to manage any issues/problems.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Perform an initial issues and problems assessment to identify issues and problems
using the Baseline Risk Assessment (RKM.020) and the Bid Transition collateral.
Issue/Problem
Form
An Issue / Problem Form is completed for each issue /
problem identified.
2 As issues/problems are identified, route them through the processes identified in the
Issue Management Strategy and Problem Management Strategy.
Issue/Problem
Form
Once an issue/problem is identified, complete an
Issue/Problem Form.
3 Add each issue/problem (completed Form) to the Issue/Problem Log and track its
progress. Identify owners and target resolution / fix timeframes
Issue/Problem
Log
Track all issues/problems from identification to
resolution.
4 Obtain client agreement and approval and sign off on any issue/problem resolution, as
necessary.
Issue/Problem
Resolution
Approval
Obtain any necessary sign-off to the Form or Approval
Certificate as defined in the appropriate process.
5 Implement approved resolution Issue/Problem
Log
Assign the work to the appropriate roles for completion
and update the Log to indicate resolution.
6 Escalate unresolved issues and problems. Issue/Problem
Log
Update the Log.
7 Track and report issues/problems. Issue/Problem
Log
Back to Top
APPROACH
Managing issues and problems consists of the following steps:
1. Conduct an initial issues and problems assessment and log any issues / problems uncovered.
2. Log all project issues/problems as they arise.
3. Prioritize, identify owners and target resolution/fix timeframes and assign issues/problems for closure.
4. Escalate unresolved issues/problems according to priority as previously defined in the Issue Management Strategy or Problem Management Strategy.
5. Track and report issue and problem status.
Discuss open issues/problems and log new issues/problems at project status meetings. Communicate high-priority issues/problems to the Executive Steering Committee,
as appropriate. Use the Log to provide metrics to the Executive Steering Committee regarding issues/problems opened, issues/problems closed, and aging of all open
issues/problems. These metrics should reflect an analysis of the issues/problems by priority.
Share all project issues/problems openly and frankly, and provide mechanisms for solutions. The important point to remember is not to let an issue/problem become a
discussion point that may negatively affect team performance. Identify, assess, share, and close issues/problems without making them personal with any team member.
Vocally reward team members for closing an issue/problem on time.
The output of this strategy is referred to as the Issue/Problem Log. Identifying, assessing and logging issues/problems should be a continuous process during the project;
the status of logged issues/problems should be shared at project status meetings.
The Issue/Problem Log is used to document the issues and problems that have been raised by project stakeholders and how they have been addressed. Stakeholders
should be involved in this issue and problem resolution process, as appropriate. Be sure to communicate the status and resolution of issues and problems to
stakeholders, particularly those who may not have access to the Issue/Problem Log, as defined in the Communication Plan.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Issue Management Strategy (IPM.010)
Problem Management Strategy (IPM.020)
Issue and Problem Management System
(IPM.030)
These work products document the strategy and processes for managing issues and problems during the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Issue and Problem Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Use Issue Form created/edited in IPM030
Use Issue Log created/edited in IPM030
Use Problem Form created/edited in IPM030
Use Problem Log created/edited in IPM030
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.050 - PRODUCE FINAL ISSUE AND PROBLEM REPORT
AND CLOSE LOG(S)
This task is executed in the Project Closure phase. It is a clean-up task to close the Issue and Problem Log(s) which includes all closed and any remaining open items.
This production officially closes the logs. Update the log(s) with any transitional information prior to closing or use the logs to create a Final Issue and Problem Report.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Issue and Problem Log
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Analyze any unresolved issues or problems. Issue/Problem Log
2 Update the Issue/Problem Log or produce Final Issue
and Problem Report.
Final Issue and Problem Report
Final Issue/Problem Log
Update the log with any pertinent transitional information or produce a
separate report.
3 Close Issue/Problem Log. Closed Issue/Problem Log
4 Document any lessons learned. Issue and Problem Management
Lessons Learned
This report is used to create the Lessons Learned report produced in
the Communication process.
Back to Top
APPROACH
Analyze the Issue/Problem Log and consider the business impact and risk of any unresolved issues. Document this analysis in the log or create a separate Final Issue
and Problem Report. Provide this information to the client and transition the Issue and Problem Management System to the client.
Note: The resolution of remaining open issues may present additional business opportunities.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM050_ISSUE_AND_PROBLEM_MANAGEMENT_LESSON_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[STM] STAFF MANAGEMENT
Your project is a mini organization unto itself and should be treated as such. The Staff Management process focuses on the following:
plan resource requirements
identify, document, and assign roles, responsibilities, and reporting relationships for the project team members
evaluate the skills required to deliver the project
manage the project team
release staff
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
As part of Project Start Up, the project manager needs to identify, document, and assign roles, responsibilities, and reporting relationships for the project team members,
including Oracle, client and sub-contractors (if used). You must work closely with consulting managers and consulting resource managers within Oracle (and similar
managers, if working with a partner or contractor) and within the clients organization, to staff your projects with the people who have the skills and knowledge you
require. Document your findings in the Resource Plan.
Next, the project manager must evaluate the skills required to deliver the project (within the agreed upon scope) and develop the Staff Management Plan translating those
skills into project roles. From there, the project manager should source, select, and schedule qualified individuals to fill the agreed upon project roles. These people
should be organized into a cohesive team with assigned roles and responsibilities, and given the tools and information required to perform their assigned tasks. The
project manager assesses the skills of the team members and develops training plans, as required.
This process should include the entire organization of the project, the internal project team, the sponsors, the key stakeholders, the support personnel, and everyone else
who will play a role in getting the project to closure or be responsible for assuming control of the application once the project is completed.
Project Execution and Control Phase
During the Execution and Control phase, the project manager is responsible for managing and leading the project team and for understanding the status of the work they
are performing as well as any issues they may have. The project manager must also work within the defined governance model to ensure that everyone is kept informed
and that the project stays on track.
The project manager also monitors the progress of training and mentoring activities during this phase.
As new team members join the project and others leave, the project manager is responsible for ensuring that there are smooth and seamless transitions.
Project Closure Phase
During Project Closure, the project manager is responsible for ensuring that resources roll off smoothly, that work was performed and documented as planned, and that
knowledge sharing to the successors has occurred. The project manager documents the resources' performance and shares it with the resources' managers.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS STM.010 Plan Resource Requirements Resource Plan Y Core
PS STM.020 Develop Staff Management Plan Staff Management Plan Y Core
PS STM.030 Staff Project Staffed Project Y Core
PS STM.040 Prepare Orientation Guide Orientation Guide Core
Project Execution and Control
PEC STM.050 Conduct Team Orientation Oriented Team Core
PEC STM.060 Manage Project Team Managed Project Team Core
Project Closure
PC STM.070 Release Staff Released Staff Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.010 - PLAN RESOURCE REQUIREMENTS
In this task, develop the project team structure and reporting hierarchy as well as identify the roles and responsibilities required to complete the project.
Resource planning begins with validating that the resource requirements identified during the Bid Transition process are appropriate to meet project needs. The Validated
Scope and detailed Project Workplan are key inputs to this task. As the project progresses, it may be necessary to update the Resource Plan to accommodate evolving
requirements. Resource updates that would affect the project budget must be discussed with the client and handled through the Scope Management process. (Refer to
the Scope Management Process.)
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Resource Plan - The Resource Plan documents the project team structure and reporting hierarchy and the roles and responsibilities required to complete the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop the project team structure and reporting hierarchy. Project Team Organization
Chart
Document the structure and hierarchy in an organization
chart.
2 Identify the roles and responsibilities required to complete the
project.
Resource Plan
3 Obtain approval from key stakeholders. Approved Resource Plan Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Your project is a mini organization unto itself and should be treated as such. During Project Start Up, identify, document, and assign roles, responsibilities, and reporting
relationships for the project team members.
Define the skills and knowledge considered necessary to meet the projects requirements and determine the length of time those people will be required. A good
starting point is the response Oracle sent to the RFP. A high-level project schedule is typically included. It specifies the resources and time commitment, based
on the modules being implemented. Resumes of Oracle consultants matching the skills and knowledge required are attached. Determine timing for when each role
should be filled and the duration to support the Project Workplan. (Refer to the Work Management process.)
Determine the reporting relationships required among the different groups or individuals assigned to the project.
Identify the approximate number of resources on each sub-team and the relationships between each sub-team.
Identify roles that will be staffed by the client, Oracle, or a third party. Format this information into an organizational chart for clarity. Review organizational charts
with the client to obtain consensus. Ensure the client has resources in some key positions.
Identify any constraints that might limit how the project team is organized. Again, use the RFP or the response to the RFP to gather as much information as you
can about the organization, its employees, and any external groups, such as unions, that may have an impact on your project.
Determine the availability of the resources you require from the customer and Oracle. The best way to staff your project is with consultants assigned to your
project full time and customer experts for the duration required.
Third-party resources may be necessary to meet resource requirements. (refer to Procurement Management).
Work with team leads to detail roles and responsibilities for each team member. Roles and responsibilities for each team member should include: skill set and job
requirements, major work product responsibilities, project team role and team interaction expectations, and status reporting responsibilities.
The result of planning is an understanding and articulation of the detailed roles, responsibilities, and reporting relationships required for the project.
Back to Top
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope (SM.010
Project Workplan (WM.030)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM010_PROJECT_TEAM_ORGANIZATION_CHART.DOC MS WORD
STM010_RESOURCE_PLAN.XLS MS EXCEL
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.020 - DEVELOP STAFF MANAGEMENT PLAN
The objective of the Develop Staff Management Plan task is to develop and document the following components:
Resource Requirements (refer to STM.010 - Plan Resource Requirements)
Staff Performance Expectations
Retention and Recognition Plan
Performance Appraisal Plan
Poor Performance Remediation Plan
Mentoring Plan
Individualized Training and Skill Building Plans
The Staff Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Staff Management Plan - The Staff Management Plan documents the staff requirements, performance expectations, and various staffing plans. The Staff Management
Plan is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Use the Resource Plan to determine resource
requirements.
Resource Requirements Document the resource requirements.
2 Determine staff performance requirements. Staff Performance Requirements Document the performance requirements.
3 Obtain retention commitments and design
recognition activities and plan.
Retention and Recognition Plan Obtain written retention commitments. Plan and document team building
activities and recognition plans.
4 Develop Performance Appraisal Plan. Performance Appraisal Plan Document the Performance Appraisal Plan.
5 Develop staff remediation plan. Poor Performance Remediation
Plan
Document the remediation plan.
6 Develop mentoring plan. Mentoring Plan Document the Mentoring Plan.
7 Develop training and skill building plans. Individualized Training and Skill
Building Plans
Document training and skill building plans.
8 Obtain approval from key stakeholders. Approved Staff management
Plan
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Staff Performance Expectations
Document and communicate expectations for team member performance, such as, timeliness, adherence to the work plan, travel, etc.
Manage to a budget and ensure that you do not overrun the budget unless there is adequate justification in advance. Get buy-in from the project team early on to
ensure they will cooperate with this.
Monitor other rules of engagement. The customer may have special hotel rates or guidelines they wish the consultants to follow. Failure to comply with reasonable
customer requests causes unnecessary friction.
Establish procedures for deviation from expectations.
Retention and Recognition Plan
Obtain a commitment that the team members will not be removed from the project until you are satisfied that they can be released. This commitment should come
from the customer for staff they have dedicated to the project; from the consulting resource manager for Oracle staff; and from the managers for the partners staff.
Build in time in the project for team building activities to foster a cohesive work environment. The activities should include all team members (Oracle, client and
third-party).
Keep the team challenged. Give them an assignment that you know will stretch their skills and knowledge.
Recognize accomplishments as they are completed. Task and milestone completion deserve recognition.
Keep the team informed of the progress of the project. Team members do not like surprises any more than you do. Tell them how they are progressing. This is
helpful for those periods when you may require them to work longer hours to meet a deadline.
Get their buy-in and solicit their opinions. This will make the team members feel like full contributors to many facets of the project. Their experience and opinions
may give you added perspectives when dealing with certain challenging situations.
Performance Appraisal Plan
Work with resource managers and team member managers to define procedures for documenting performance.
Build time into the schedule to ensure team members are given timely and accurate reviews.
Poor Performance Remediation Plan
Work with the team member to establish a plan for correcting poor performance.
Monitor and document progress on a weekly basis. Decide quickly if the team member is not the right fit for the position and replace as needed to mitigate delays in
the project schedule.
Mentoring Plan
Mentoring is also about nurturing the talents of those who are assigned to the project team. Take the time to find out what the members of your team would like to
accomplish on this project. Look for opportunities where you might be able to accommodate their desire to try something new. Assist them whenever possible to
enhance their skills and abilities.
Match team member skill sets to ensure junior team members have access to senior team members as needed. This is an excellent way to ensure the client team
members are learning the necessary skills and knowledge sharing is occurring.
Have senior team members regularly meet with junior team members to ensure work is completed on time and is the best approach from a functional and technical
perspective.
Individualized Training and Skill Building Plans
Refer to the skills required by role, as defined in the Resource Requirements component, to identify gaps in knowledge areas and develop individualized training
plans. Functional skills depend on the scope of the project and the software applications being implemented. Technical skills include database, operating system,
network, programming, and web development.
Coordinate client training with the client and the implementing organization's training department to plan training for client team members. It is recommended that
the client take the initial or introductory training as early as possible and take the more advanced classes after they have spent some time working with the
application.
Review the project lifecycle and identify the milestones where specific skill sets by role will be needed.
Determine the number of training participants, the length of time they will be involved in training, and when the training should most appropriately take place.
Research alternative training opportunities, review course schedules, and create a training plan to include each members courses and dates. Plan training early to
ensure availability.
Ensure the work plan reflects team member training and that team members attend training as scheduled.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive
activities, tasks or task steps. If your project does not have a dedicated project administrator, the project manager
would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Resource Plan (STM.010) Use the Resource Plan to determine resource requirements.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM020_STAFF_MANAGEMENT_PLAN.DOC MS WORD
STM020_STAFF_TRAINING_PLAN.DOC MS WORD
STM020_STAFF_MANAGEMENT_PROCEDURES.DOC MS WORD (Former PJM2.6.1 Template)
STM020_PROJECT_ROLES_AND_RESPONSIBILITIES.PPTX POWERPOINT (Former Compass Template/Example)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.030 - STAFF PROJECT
Staffing the project addresses the issues that influence getting the right people for the project.
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Staffed Project - The Staffed Project is the assigning of resources (people) to the roles defined in the Resource Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify resources to fill the project roles. Staffed Project
Back to Top
APPROACH
Staffing the project involves:
Identifying team leads for each sub-team and detailing responsibilities for team leads.
Working with team leads to detail roles and responsibilities for each team member. Roles and responsibilities for each team member should include: skill set and
job requirements, major work product responsibilities, project team role and team interaction expectations, and status reporting responsibilities.
Associating the roles with specific tasks and activities in the project work plan and project budget in order to develop an overall resource plan. The resource plan
will highlight what resources are needed and when they are needed. (refer to Work Management).
Reviewing sourcing strategy with client.
Identifying available Oracle resources with appropriate skills.
Working with the client to secure required client resource commitments.
Working with Procurement to fill third-party roles, if necessary.
Making final determination of project resources and obtaining schedule commitments.
Adjusting Project Workplan based on resource training, vacations and other commitments.
Getting the right people for projects can sometimes be a challenge. You must work closely with consulting managers and consulting resource managers within Oracle
(and similar managers, if working with a partner or contractor) and within the clients organization, to staff your projects with the people who have the skills and knowledge
you require. At times you may find you have inherited a project team consisting of Oracle resources, client technical resources, partner resources, Contracting Service
Providers, independent consultants, and users the client has chosen to represent the user community. In this situation you should:
Determine whether you have the right people. Start with the Resource Requirements from the Staff Management Plan. Compare the skills and knowledge of the
people on the team with the skill requirements in the plan. Talk to each member of the team to gather all the information you require to complete your comparison.
Determine that there is the correct number of people. Again, using the tools mentioned above, make sure that there are enough team members for the tasks to be
completed.
Completing these two tasks will enable you to assess if you have the right people with the right mix of skills. If a particular team member has a weakness in a particular
area, assigning them to assist a more knowledgeable team member may give you two very strong people at a later point in the project.
Remember that during a project there is a vast amount of knowledge sharing and skill enhancement. Take this into consideration when you assess your team. This is
especially true of the users assigned to the project team, assuming they have been sent to the appropriate Oracle training classes.
If adequate resources cannot be obtained, either from the client, the third-party or Oracle, an issue must be created and managed, as it may impact project timelines.
(refer to Issue Management).
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Resource Plan (STM.010) Use the Resource Plan documents to identify the project team structure and reporting hierarchy and the roles and responsibilities
required to complete the project.
Staff Management Plan
(STM.020)
Use the Staff Management Plan to match staff to requirements and performance expectations.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Staff Management.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.040 - PREPARE ORIENTATION GUIDE
In this task, develop a comprehensive team member Orientation Guide to be used during Project Kickoff and afterward for the on-boarding of new team members. This
will help to streamline the on-boarding process, ensure consistent communications and reduce the project manager and team leads' workload during the on-boarding
process. Depending on your project, you may decide to produce multiple guides tailored to a specific process (e.g., Scope Management) or for a specific audience
(Oracle, client, or sub-contractor team member), or for any other reason deemed appropriate.
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Orientation Guide - The Orientation Guide is a comprehensive document that includes pertinent information for project team members. Initially, it is used during Project
Kickoff and and then made available for new team members that join the team after Project Kickoff. Depending on your project, you may decide to produce multiple
guides tailored to a specific process (e.g., Scope Management) or for a specific audience (Oracle, client, or sub-contractor team member), or for any other reason
deemed appropriate.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather team member information. Team Member Introduction Document biographies of key members.
2 Produce team contact information. Team Contact List Document a listing of all team members with contact information (phone number,
email, cell number, etc.)
3 Produce logistic information. Logistics Document any directions, etc.
4 Highlight important contract information. Contract Deliverables and Terms
and Conditions
Highlight any relevant contract information for the project team.
5 Produce appropriate Project Management
Plan components
Project Management Plan (PJM
Process Component) Guidelines
Compile and document relevant information for each PJM process as
appropriate for your project (e.g., Scope Management, Work Management.
etc.).
6 Gather any reporting guidelines that were not
already covered in previous components.
Reporting Guidelines Document any reporting guidelines that were not already covered in previous
components.
7 Gather any pertinent team meeting
information.
Meeting Schedules Produce a calendar or listing of all team meetings.
8 Compile all components into one guide. Orientation Guide Organize all components into a cohesive Orientation Guide and provide a table
of contents.
Back to Top
APPROACH
Your project Orientation Guide should be tailored to your project. Including a section for each process may be pertinent for a large project, but not necessary for a small
project. Even on a large project, some process overviews may not be needed. Make the various PJM process work products available to all team members and reference
them in your guide rather than repeat information already documented. As with tailoring the sections you include in your Orientation Guide, you may also decide to
produce multiple guides tailored to processes, audience or some other appropriate reason. The following is a suggested format for an Orientation Guide:
Team Member Introductions
Team Contact Information, Key Contact List (phone numbers)
Logistics - Directions Contract Deliverables and Terms and Conditions
Scope Management - Project scope, objectives, and approach
Financial Management
Work Management - Project organization, Time and Expense Reporting Guidelines, Work Rules, Project Workplan and timeline, Key Risk Management Work
Products
Issue and Problem Management
Staff Management
Communication Management - Communication Plan
Configuration Management Infrastructure Management
Procurement Management
Organization Change Management Reporting Guidelines
Meeting Schedules
As necessary, update the Orientation Guide throughout the duration of the project so that it will be up-to-date new members who join the team.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
SM.010 Validated Scope (SM.010)
Scope Change Management Processes (SM.020)
Financial Management Plan (FM.020)
Work Management Plan (WM.020)
Project Workplan (WM.030)
Risk Management Plan (RKM.010)
Risk Management System (RKM.030)
Issue Management Strategy (IPM.010)
Problem Management Strategy (IPM.020)
Issue and Problem Management System (IPM.030)
Staff Management Plan (STM.010)
Communication Plan (CMM.020)
Infrastructure Management Plan (IFM.010)
Procurement Strategy and Process (PCM.010)
Client's Organizational Change Management
Strategy (OCHM.010)
These work products contain the pertinent information for project team members that needs to be compiled
into the Orientation Guide.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM040_PREPARE_ORIENTATION_GUIDE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.050 - CONDUCT TEAM ORIENTATION
In this task, plan and conduct a Project Kickoff meeting to orient the team to the project. If necessary, similar orientation meetings can be given for new team members
that join the project after kickoff. This meeting will help streamline the on-boarding process, communicate the project objectives and structure, and begin to develop
cohesion among the team. Use the Orientation Guide to help structure the meeting and plan presentations. Depending on your project, you may decide to hold multiple
Project Kickoff meetings tailored to a specific process (for example, Scope Management) or for a specific audience (implementing organization, enterprise, or sub-
contractor team member), or for any other reason deemed appropriate.
Again, depending on the project, additional orientation meetings may not be feasible, make the Orientation Guide and Project Kickoff Presentation available to all new
team members that join the project after kickoff.
ACTIVITY
PEC.ACT.OMT Orient and Manage Team
Back to Top
WORK PRODUCT
Oriented Team - The Oriented Team is a project team that has received the Orientation Guide and participated in a Project Kickoff or team orientation meeting`where the
project objectives and structure have been communicated.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify audience. Attendees List Create a list of all attendees.
2 Schedule meeting and provide for
meeting infrastructure.
Project Kickoff
Schedule and
Infrastructure
Determine the date, time and place for the meeting. Make arrangements for appropriate seating, equipment
(screen, flip charts, etc.). Make lunch arrangements.
3 Set meeting schedule. Project Kickoff
Agenda
Use the organization of the Orientation Guide to develop the presentation. Individual presentations can be
developed for each component of the Orientation Guide by the leads for each area. All the presentations
combined become the Project Kickoff Presentation.
4 Create Kickoff presentation. Project Kickoff
Presentation
5 Conduct Team Orientation Meeting. Oriented Team
6 Make Project Kickoff Presentation
and Orientation Guide available for
new staff, as needed.
Published
Orientation
Materials
This may mean organizing all the individual component presentations into some sort of organized file
structure. Make sure copies of the Orientation Guide are available to new staff.
Back to Top
APPROACH
Identify Audience
Work with the client to identify the audience, to schedule client attendance. You need to know how many people will be in attendance.
Schedule Meeting and Provide for Meeting Infrastructure
Work with the client to set the date, time and place for the meeting. Obtain appropriate facilities to accommodate the number of attendees. Prepare for any needed
equipment (projectors, screens, flip charts, etc.). Make food and drink arrangements. Make arrangements to have enough copies of the Orientation Guide for each
participant.
Set Meeting Schedule
Use the organization of you Orientation Guide to help set the meeting schedule.
Arrange for the project sponsor to provide either opening or closing remarks to the project team. Remarks should emphasize the client's executive management support to
the project team as well as the significance and impact of the project on the client and its operations. Advanced planning may be necessary to ensure the appropriate
client executives are available to speak at the orientation meeting.
Create Kickoff Presentation
The project manager should oversee development of orientation meeting materials and ensure presentation materials are prepared, including presentation slides,
attendee materials, and flip charts. Use the organization of the Orientation Guide to develop the presentation. Have team leads create the presentation for their areas and
lead the presentation of their area during the meeting. For example, the team lead for Scope Management is responsible for developing the presentation to communicate
the Validated Scope and Scope Change Management Processes to the members as well as presiding over the presentation .
Conduct Team Orientation Meeting
Distribute the Orientation Guide and any other orientation meeting materials.
Allow each team member to introduce themselves and the role they will play on the project.
Capture any issues and concerns that cannot be addressed during the meeting and establish a plan to respond back to the team.
Make Project Kickoff Presentation and Orientation Guide Available
After the initial Project Kickoff Meeting, it may not be feasible to hold additional meetings as new staff join the project. Make the Project Kickoff Presentation and the
Orientation Guide available to new staff as they join the project.
Other Considerations
Review the project team Communication Plan to ensure the orientation meeting adheres to standards already discussed with and agreed upon by the client.
Include time in the Project Workplan for the orientation meeting so that it does not conflict with other team member assignments.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Orientation Guide (STM.040) Use the Orientation Guide to help structure the meeting and plan presentations.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Service Architecture Review this technique as input into this task.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM050_PROJECT_KICKOFF_ORIENTATION.PPTX POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.060 - MANAGE PROJECT TEAM
In the Manage Project Team task, you put into practice the procedures documented in the Staff Management Plan and manage the staff. This includes the following
activities:
Conduct regular staff meetings.
Review and respond to team status reports.
Maintain the resource plan,
Advise client project manager or appropriate client project sponsor if there are any issues relative to client team member performance.
Provide regular performance feedback to both individuals as well as Oracle line management.
Retain and develop project team members.
Plan for resource roll offs.
Release resources as required.
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.OMT Orient and Manage Team
Back to Top
WORK PRODUCT
Managed Project Team - The Managed Project Team is a staff that is managed using the procedures documented in the Staff Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Conduct regular staff meetings. Individual Status
Reports
These are typically one-on-one or group meetings separate from project status meetings.
2 Review and respond to team status reports. Team Status
Reports
Allow staff members room to present their issues and concerns in status reports. Do not
distribute individual status reports.
3 Review and respond to team status reports. Team Status
Reports
Allow staff members room to present their issues and concerns in status reports. Do not
distribute individual status reports.
4 Maintain the Resource Plan Updated
Resource Plan
Keep track of team members' start and stop dates and any planned time off.
5 Advise client project manager of client team
member performance issues.
Any client team member performance impacting project schedule or quality should require a
change order.
6 Provide regular performance feedback. Performance
Appraisals
7 Retain and develop project team members. Retention Plans
8 Plan for resource roll-offs. Updated
Resource Plan
Give reasonable notice to Oracle management and resource managers of the resources being
released. (Refer to STM.070 - Release Staff.)
9 Release resources, as required. Updated
Resource Plan
Not all resources are released at Project Closure. (Refer to STM.070 - Release Staff.)
Back to Top
APPROACH
Conduct Regular Staff Meetings
Regular staff meetings provide a forum for the project manager and the team member to discuss the team member's perspective on how the project is proceeding
and how the team member's tasks are proceeding. If these meetings are not scheduled, they typically don't happen.
Encourage the team member to share thoughts and concerns that he or she may be reluctant to share in a group atmosphere.
Review the team member's work schedule and capture any changes to the planned work schedule.
Commit to following up with any issues or concerns that could not be addressed during the meeting and establish a time and means for getting back to the team
member with the results.
Review and Respond to Team Status Reports
Have team members complete status reports on a weekly basis, detailing the tasks they have completed, the tasks they plan to complete, any deviations, and any
issues or concerns they may have in completing their tasks.
Be sure to read the status reports on a timely basis and provided feedback on their issues and concerns.
Use the team members' status reports as input to the team's status report that is widely distributed. Do not distribute individual status reports
Maintain the Resource Plan
Keep track of team members' start and stop dates and any planned time off.
Advise Client PM of Client Team Member Performance Issues
Provide specific facts when presenting performance issues of a client team member.
Be constructive and provide alternatives to getting the team member back on track.
Communicate the impact to the project if corrective action is not taken.
Keep in mind that the issue is not the client's problem but a project problem and that you are willing to assist in the solution.
Provide Regular Performance Feedback
There may be a time when a team member is not the right fit for the project. To be fair to the individual and to the success of the project, once identified, the
individual should be removed from the project and replaced as soon as possible. This is by no means an easy task. As the project manager, you must:
Document the reasons why you feel the person is not the right fit for the project. Be constructive and keep the comments job-related.
Speak to the team member about their performance. Perhaps there are some underlying issues, such as personal illness, family illness, or travel that could be
having a negative impact on the work being produced by this individual.
If the team member is from Oracle, first discuss your observations with them. Hard personnel issues are best handled first thing in the morning, not in the evening
when you and your team member are tired. If a satisfactory conclusion cannot be reached, discuss your concerns with the employees manager and determine
possible solutions. The consulting resource manager can also help find a replacement, if required.
If the team member is from a partner, speak with their manager and customer management about your concerns and about a replacement.
If the team member is not an employee, you should work out an exit plan with the individual and begin to search for a replacement, either from Oracle, the partner,
or outside resources. There may have been very valid reasons why a subcontractor was hired for the project and those same reasons may bind you to finding a
similar replacement. These rules should be defined when the resource plan is being finalized.
Retain and Develop Project Team Members
You have all the right people on your project team. Now, how do you keep them? A couple of suggestions:
Obtain a commitment that the team members will not be removed from the project until you are satisfied that they can be released. This commitment should come
from the client for staff they have dedicated to the project; from the consulting resource manager for Oracle staff; and from the managers for the partners staff. It is
not as simple with independent consultants.
Give the team the support they require.
Keep the team challenged. Give them an assignment that you know will stretch their skills and knowledge.
Keep the team informed of the progress of the project.
Get their buy-in and solicit their opinions. This will make the team members feel like full contributors to many facets of the project. Their experience and opinions
may give you added perspectives when dealing with certain challenging situations.
Recognize your team when their deadlines or milestones are met. Make sure you send a copy to their manager or direct report.
Encourage the team members to spend social time (i.e., lunch, coffee break, ice cream break) with customer team members, extended team members, and
partners. Relationship building makes the project much more fun and interesting.
Follow the skill development and mentoring plans as defined in the Staff Management Plan prepared in step STM.020 - Develop Staff Management Plan.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Staff Management Plan (STM.020) The Staff Management Plan documents the various plans for managing staff during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM060_INDIVIDUAL_STATUS_REPORT.DOC MS WORD
STM060_ASSIGNMENT_REQUEST.DOC MS WORD (Former PJM 2.6.1 template)
STM060_ASSIGNMENT_TERMS_OF_REFERENCE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.070 - RELEASE STAFF
The goal of this task is to effectively release staff. Resources are released from the project throughout the project lifecycle. In most cases, the release dates are known
and documented as part of task STM.030 - Staff Project. Follow the same procedures whether the resource is leaving during the project or at Project Closure. However,
during Project Closure all remaining staff is released.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Released Staff - Released Staff are staff that have been released from the project and been given a performance appraisal (or some other form of performance feedback
to their manager for consideration in future performance appraisal).
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Plan for resource roll offs. Updated Resource Plan
2 Release resources, as required. Updated Resource Plan
3 Prepare project performance appraisals. Performance Appraisals/Feedback
Back to Top
APPROACH
Plan for Resource Roll Offs
Give reasonable notice to the management that owns the resource and the resource managers of the resources that are being released.
Allow adequate time for knowledge sharing before the resource leaves. Include time in the Project Workplan for the resource that is leaving and the resource that is
taking over the responsibility to conduct hand-over. It is best when there is time allowed to have a proper transition session.
If the resource is leaving the project before deployment, review staffing requirements to finish the project. It is always ideal to keep resources for the duration of the
project. If it is possible to assign the resource additional tasks and extend the resources end date, negotiate the change with the organization owning the resource
and the resources manager.
Release Resources, as Required
Review the resources tasks and related documentation for completeness before the resource leaves.
Verify that knowledge sharing has occurred with the resource that is assuming responsibility for the work.
Recognize the resource's contribution to the team.
Prepare Project Performance Appraisals
Provide feedback on all aspects of the resource's performance: adherence to project procedures, task completion, quality, willingness to help others, flexibility,
product knowledge, ability to communicate (orally and in writing), relationship with client, professionalism, conduct, administrative task completion, etc.
Document performance throughout the project, especially significant achievements and deviations from expected results, to facilitate the preparation of the
performance appraisal. Relying on memory can lead to inaccurate and unfair representations of performance.
Discuss deviations from expected results as they occur and include the resource's manager, as appropriate. The resource and the resource manager should not be
learning about the deviation for the first time in a performance appraisal. Note when corrective action was successful in getting the team member back on track.
Provide feedback to resource managers for interim reviews, as requested.
Solicit feedback from team leads when preparing appraisals for resources in their sub-teams.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[CMM] COMMUNICATION MANAGEMENT
The Communication Management process is focused on the internal project team communications to key stakeholders regarding progress and status. This process does
NOT address the broader set of communication typically associated with Organizational Change Management. Please see the Organization Change Management
process for steps in setting up organizational communication. Organizational Change Management is also addressed within the Organizational Change Management
process embedded in the Envision (EOCM) and Implement (OCM) focus areas. Therefore, these processes should be coordinated to avoid overlap or confusion.
Effective project communications require consistent, accurate and complete reporting of progress and status. Of the facets of Project Management, communications
planning is one of the most critical to success. The project manager is responsible for developing a Project Team Communication Plan, training the project team in the
plan's importance and maintaining the Project Team Communication Plan.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
Communication Management begins with the first client contact and continues to evolve throughout the project life cycle. Project communications is a critical function in
any project and a formal method must exist for effective communications with project stakeholders, including the client, project team members and other interested
entities. Developing a Project Team Communication Plan requires the same thoroughness of planning and execution as any other facet of the project. Routine and
predictable communications must be discussed, documented, and agreed to during Project Start Up.
During the Project Start Up phase, the project manager is responsible for defining the overall strategy for communicating and sharing project information. This includes
documenting and agreeing with key stakeholders concerning the:
Who? What audience and which individuals will receive the communication? Who will provide information necessary for the communication?
What? What information is the audience looking for? If the communication is addressed to the project Steering Committee, project progress to plan,
budgetary information, issues, and tactical plans for the next reporting period might be appropriate. Communications directed to Portfolio Directors
might include personnel performance, staff projections and internal communications. Communications for senior-level client executives should focus
on concerns at a management level.
Why? Why is the communication being prepared? Will it communicate weekly status to the core team and Steering Committee or announce the completion
of a major milestone to management and end users? Objectives of the communication must be clearly stated when the communication is written.
When? When is the communication needed? Communications submitted too late to be of value in decision-making are wasted efforts and may cause
problems. If the information is needed immediately, the communication should be ready. As with any plan, frequency and timing are keys to success.
How? How should the information be presented to best meet the needs of the audience? What media will be used: reports, meetings, email, etc?.
Communications can be verbal, written, or include a combination of both. Verbal communications can be formal, including a prepared discussion
using formal reports and visual aids, or informal as in a round table discussion. If informal communications are used, all significant conversation,
issues, and decisions must be documented with a follow-up memorandum to the participants, the project managers project diary, and the core team.
Project communication activities typically include but are not limited to:
Reports:
Scheduled, Written Status Reports
Financial Reports
Profiles
Project Reviews
Meetings:
Project Launch Communications/Kickoffs
Scheduled Status Meetings
Scheduled Steering Committee Meetings
Project Execution and Control Phase
Following the strategy, processes, and procedures defined in the Project Team Communication Plan developed in the Project Start Up phase, the project manager must
ensure smooth, concise, and effective communications are occurring at all levels of the project. Its important that all project stakeholders; users and project team
members are informed about the project activities and status. Prior to go-live, it is especially critical to have a strong Communication process in place so that all project
participants are fully aware of critical project activities.
Execution of most Project Team Communication Plans is an on-going process. Like so many components of project operations it needs to have a regular, recurring
schedule that is communicated as well.
Occasionally you will miss a scheduled communication. It can be very satisfying to have someone mention that they noticed that it had not shown up on time. That means
that not only are people reading your communications, but they are looking forward to receiving them!
Dont fall into the trap of only communicating at set times. Be aware of opportunities to communicate (and be communicated to) that are not planned. Project managers
should have their elevator speech ready if someone asks them for a few impromptu words about their project. Likewise, when you overhear adverse comments being
made, pay attention. Unsolicited communications can alert you to a situation you may never have uncovered through planned communications.
Management by walking around is an excellent form of communication with team members. The focus of this day-to-day activity is to engage in brief informal
discussions to assess progress or problems and observe productivity. A good opening for these conversations is, Hows it going today?
Make time for informal group feedback. There are always external factors that impact project success. Ask what concerns the group has, what rumors they may
have heard. You may be able to provide direction on a stalled activity by removing misconceptions or ambiguities.
Effective project communications require consistent, credible, logically structured and concise reporting of project progress and status. Credibility is key here. Clear, direct
communications on the projects direction, progress and health are critical to success. These two quotes sum up the value of credibility:
For every week of upset you avoid by hiding the truth, you gain a month of bitterness and mistrust. Besides, the grapevine already has the news, so dont imagine that
your information is a secret. - William Bridges
Saying what you think you are expected to say has several drawbacks, you may get the expectation wrong, the expectation may change, it is difficult to keep clear what
you've said in the past, especially when expectations keep changing, it destroys your mind and spirit. Telling the truth is often the most powerful action you can take. -
William Bridges.
Project Closure Phase
At the conclusion of the project, a Lessons Learned report and other Final Reports (project status, etc.) must be written and compiled and key project documentation must
be turned over to the client. Ensure that the client and/or partner have been given the appropriate work products and then remove client and partner access to any
internal systems.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS CMM.010 Conduct Project Stakeholder Analysis Project Stakeholder Analysis Core
PS CMM.020 Develop Project Team Communication Plan Project Team Communication Plan Core
Project Execution and Control
PEC CMM.030 Manage Project Team Communication Project Team Communication Core
Project Closure
PC CMM.040 Document Lessons Learned Lessons Learned Y Core
PC CMM.050 Turn Over Project Documentation Project Archives Y Core
PC CMM.060 Submit Final Reports Final Reports Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
TM Team
Members
Publish individual reports, distribute and file. Participate and share views on what worked and what could be improved.
Client (User)
CPS Client
Project
Sponsor
CPM Client
Project
Manager
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.010 - CONDUCT PROJECT STAKEHOLDER ANALYSIS
Stakeholders are those entities (a person, group or department) whose interests and expectations need to be taken into account when making key project decisions.
Alternatively, a stakeholder is someone who has a vested interest in your project or will be affected by its outcomes.
The Project Stakeholder Analysis is an important prerequisite to the Project Team Communication Plan (CMM.020). In this task, the goal is to identify the project
stakeholders, determine their influence, concerns and interest in the project, determine what information they would like to receive and by what method of delivery. The
Project Stakeholder Analysis should be incorporated into the project's overall Project Team Communication Plan, which is a component of the Project Management Plan.
ACTIVITY
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
WORK PRODUCT
Project Stakeholder Analysis - The Project Stakeholder Analysis documents the project stakeholders, their influence and interest in the project, what information they
would like to receive and by what method of delivery.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review
previously
gathered
information.
None Review the Identified Project Stakeholders from Bid Transition and any other pertinent information.
2 Identify key
stakeholders.
Stakeholder or
Stakeholder Group
Begin with C level executives but extend the assessment to cover all groups significantly affected by the project and/or
who can influence its outcome. Remember that stakeholders can be external to the entity you are working with and that
these needs need to be passed on to the Organizational Change Management process.
3 Assess project
impact on each
stakeholder.
Organizational
Change
Management
Impact
Think about the project impact on stakeholders in broad business terms. Typically, larger projects drive significant changes
in business processes, roles and responsibilities, organizational structures and technology usage.
4 Assess
stakeholder
interest /
influence and
concerns.
Importance/Influence
/Concerns
During Project Start Up, solicit input from the client project manager and functional/business unit heads regarding their
views on project impact and the roles their groups should play. Recognize that a stakeholder group's perception of the
project's impact and the significance of their role in the project can be surprisingly different from the project team's. See
Tools for one way to address this.
5 Prioritize
stakeholders.
Prioritized
Stakeholders
The Prioritized Stakeholders show which stakeholders have the greatest influence on the project.
6 Assess the
frequency of
reporting for
each
stakeholder.
Frequency Document the frequency of reporting for each stakeholder.
7 Determine
informational
needs of each
stakeholder.
Information Desired Determine what information each stakeholder wishes to receive. Similar stakeholders should be grouped together to
reduce the number of communications required.
8 Determine the
delivery method
for each
stakeholder.
Delivery Method Determine the preferred delivery channels, (e.g., email, newsletter, etc). Similar stakeholders should be grouped together
to reduce the number of communications required.
Back to Top
APPROACH
This task should be conducted as early in the project as possible during Project Start Up. Often this activity is conducted in an initial Implementation Planning Workshop or
Engagement Workshop. Stakeholder analysis is begun during the Bid Transition process, therefore review the documentation from Bid Transition, if available.
As project managers we are required not only to manage internal project members but also to ensure that the concerns of key stakeholders are addressed and that the
efforts of these stakeholders are aligned with the project's business objectives. Communication of project goals, progress, requirements and impacts is key to ensuring
that stakeholders are informed and aligned with project goals. Specifically, stakeholders need to be made aware of the status of issues and change requests,
adjustments to the project workplan, corrective actions and lessons learned. These communications should be made frequently and clearly and should be coordinated
with the Client's Organizational Change Management Strategy (OCHM.010) and later with the Implement focus area Organizational Change Management process.
Use a matrix with Influence (high to low scale) and Contribution (high to low scale) and placing the stakeholders in one of the four quadrants within a grid (See example
below). The Communication Plan can use the quadrants as a basis for the types of communications that need to be made.
Assess Stakeholder Concerns
It is important to identify the stakeholders concerns for the following reasons:
Concerns can be addressed proactively.
All stakeholders are vested in the project and not alienated.
Overall project risk is reduced.
The project can focus on satisfying the concerns of the most important stakeholders (see stakeholder prioritization below).
USE THE STAKEHOLDER LIBRARY
If there is an enterprise-level Stakeholder Library available (ENV.BA.015), then this is a good place to retrieve the stakeholder base concerns. Now review the project risk
register to see how any risk affects the identified concerns. For example, consider how the following affects identified concerns:
Which resources will be available and what skills do they have?
What budget is on hand?
What is the schedule?
Referring to historical stakeholder information related to your project or the enterprise can save time and flag risks, liabilities, or unresolved issues that can then be
prioritized and managed.
Prioritize Stakeholders
The purpose of the stakeholder prioritization is to determine which stakeholders (and their associated concerns/interests) may significantly influence the success of the
project. Therefore, the prioritization should have an influence on when and how to communicate with the stakeholders. Also, since resources, time and finances for
stakeholder analysis may be limited, the list of stakeholders to be interviewed must be prioritized. The type and scale of the project and the complexity of the concerns
should dictate how much time, at any stage of the project lifecycle, should be devoted to this task.
To assist with the stakeholder prioritization, stakeholders are analyzed by different attributes or criteria. These attributes aid in classifying stakeholders by relevance. They
should include project contribution and project influence at a minimum but can be extended depending on the organization's requirements.
ASSESS STAKEHOLDER CANDIDATES
Each stakeholder candidate is assesses against a list of predefined criteria to assist with stakeholder prioritization.
Project Contribution Score
Project Influence Score
Stakeholder Assessment Score (Multiply the Project Contribution Score by the Project Influence Score)
For each identified stakeholder, capture the three scores in a stakeholder analysis table.
EVALUATE STAKEHOLDER SCORE
After all stakeholders have been assessed, utilize the captured metrics to identify key stakeholders. Key stakeholders are those who can significantly influence or are
more importance to the success of the project. From the information captured, the most important stakeholders from a contribution and influence perspective can be
concluded.
By combining influence and importance metrics and using a grid diagram, stakeholders can be classified into different groups that will help identify assumptions and the
risks that need to be managed throughout the project lifecycle.
Primary Stakeholders
Primary stakeholders are stakeholders that have both significant influence over the project and contribute significant effort to the success of the project. These important
stakeholders have concerns, problems, needs and interests that are high priority and if they are not assisted effectively then the success of the project may be in
jeopardy.
Secondary Stakeholders
Secondary stakeholders should be addressed as much as possible subject to project time constraints.
Tertiary Stakeholders
Tertiary stakeholders are a low priority and should only be addressed if they require the same viewpoints as a primary or secondary stakeholder.
FINALIZE STAKEHOLDER PRIORITIZATION
The type and scale of the project and the complexity of the concerns dictates how many stakeholders concerns should be addressed. Use a stakeholder priority grid to
prioritize which project stakeholders to address.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Conduct session and document results. 85
Client Project Sponsor Participate in session and provide insight into the client. *
Client Project Manager Facilitate the development of the Project Stakeholder Analysis by providing insight in to the client. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Identified Project Stakeholders (BT.030) Use the stakeholders from this work product as the starting point of stakeholders to be analyzed.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM010_PROJECT_STAKEHOLDER_ANALYSIS.XLS
MS EXCEL
One technique for capturing and documenting the results of your stakeholder analysis is to use a 4-quadrant
Stakeholder Mapping matrix. This matrix categorizes stakeholders by their interest and influence, which
results in the following groupings and stakeholder management strategies:
High Interest/High Influence - High Interest/High Influence
Low Interest/High Influence - "Keep Satisfied"
High Interest/Low Influence - Keep Informed
Low Interest/Low Influence - Minimum Effort
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.020 - DEVELOP PROJECT TEAM COMMUNICATION PLAN
Document a communications strategy for the project team (including the client responsibilities and tasks). The Project Team Communication Plan should include but is not
limited to:
Project kickoffs.
Written communications (including status reports) - executive, management, project team, and Oracle practice management.
Templates need to be provided - these must be performed consistently.
Distribution rules need to be established for all written communications.
Status Meetings - executive steering committee, management, and project team.
Meeting attendees need to be established for all meetings - required quorum also needs to be established.
Meeting standards need to be established for all meetings (e.g., agendas, minutes, action items).
Reporting Needs - what are the reporting needs identified for the project? What reports are expected, and at what frequency.
Plan and conduct a walk through of the planned project communications with the client, project team and Oracle practice management to gain understanding and
agreement for the project communications strategy. Whenever possible provide template an/or samples to convey the types and formats of planned communications.
The Project Team Communication Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Project Team Communication Plan - The Project Team Communication Plan documents the overall communication strategy for the project team.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine overall
communication strategy.
Overview/Introduction Document the overall communication strategy for the project.
2 Review the Project
Stakeholder Analysis
(CMM.010).
Project Team
Communication
Matrix
Use the Project Stakeholder Analysis as the starting basis for this component. Update with any new
information.
3 Review all available means to
distribute information.
Delivery Channels Document what distribution channels are available to the client (e.g., e-mail, web conferencing, newsletters,
inter or intra net sites, etc.).
4 Review contractual and
procedural influences.
Required Reporting Document what reports are required for the project.
5 Review constraints and
assumptions to eliminate non-
essential requirements.
Constraints and
Assumptions
As an example - it is important to understand what budget you have to perform this task. Use of a web
developer or web conferencing may require funding in the project which you may or may not have.
6 Determine project meeting
schedules and other pertinent
meeting information.
Scheduled Meetings
(Calendar of Events)
Document when status meetings will be held, i.e., every Thursday at 9:00 AM or on some in frequent
calendar. Include purpose, attendees, location, remote access, etc.
7 Determine report distribution
frequency.
Calendar of Report
Distributions
Document when reports will be published, i.e., every Friday at end of business on the third Monday of the
month, etc.
8 Incorporate filing procedures. Project Archive
Structure
It is important to let everyone know where to file status reports and what the archive structure. This is
defined within the Document Management Plan in Configuration Management.
9 Determine Project Team
Communication Plan update
procedures.
Project Team
Communication Plan
Update Procedures
Document the procedures for updating the Project Team Communication Plan. This may include a review
process to determine if the update is necessary as well as whether any changes are needed to the Project
Team Communication Plan at a predefined time, i.e., each time the project manager reviews project status.
10 Obtain or create report
templates for all required
Report Templates
(for various reports)
Obtain or create templates for all required reports that will be used for the project. In general, oracle
procedures by region may recommend content for these reports and can be used as a base template.
reports. However, the client requirements may alter the template. Include a sample of each template as an appendix
to the plan.
11 Obtain key stakeholder
agreement and approval on
the Project Team
Communication Plan.
Approved Project
Team
Communication Plan
Obtain any necessary sign-off or Approval Certificate.
12 Make Project Team
Communication Plan available
to team members and client.
Project Team
Communication Plan
File the plan for easy reference.
Back to Top
APPROACH
The Project Team Communication Plan should address the reporting requirements of the project. As a first step this task should review the Project Stakeholder Analysis
(CMM.010). The team should then consider the importance of keeping each group informed based on influence and interest in the project, budgetary constraints and
delivery channels available to the team including such things as road shows, e-mail, newsletters, internet or intranet sites, presentations, web conferencing capabilities,
etc. Finally, it is up to this team to consider what contractual or procedural influences exist as to reporting requirements placed on the project.
The following reports are rather standard to most projects and should be considered for the project (other reports may also need to be considered):
Client Profile Sheet
Status Report
Steering Committee Report / Presentation
Financial Report
Project plans including the Project Management Plan and all of its components
The Project Team Communication Plan should discuss where these reports are stored / filed and indexed during the project. The structure is defined in the Document
Management Plan in Configuration Management. At a minimum, the Project Team Communication Plan must cover:
Operational Communication
Project Status Reporting: Team, Project, Steering, Others
Project Status Meetings: Team, Project, Steering, Others
Escalation Channels and Triggers
Use of the Project Repository
Formal Contractual Communication
Requirements in detailed accordance with signed contractual agreements (Notifications, Milestone Acceptances, Final Acceptances, etc., as specified by
contract)
Applicable elements of the Project Team Communication plan should be replicated as made relevant by any subcontractor/partner/other entities contractual
agreements.
Stakeholder Communication
Adoption and Change Management
Project meetings are scheduled in the Project Team Communications Plan. You should focus pursuing a clear understanding of efforts, status, and issues. You may want
to suggest that participants take meeting minutes on a rotating basis or arrange for the assignment of a recording secretary, enabling you to better concentrate on the
meeting. Circulation of notes to participants for final editing will help assure more complete and accurate publications.
A process needs to be defined to adjust the communications plan through out the project. As new stakeholders are added or removed from the project, when new
communications delivery channels become available or are lost or as changes to budgetary, contractual or procedural requirements are made, the Project Team
Communications Plan should be updated to reflect these changes to the project. This is a living breathing document and should not be written and then discarded as a
step completed.
While not highlighted within the Project Team Communication Plan, informal communications are key success factor in a project. The project team should incorporate
these informal communication channels in to the project:
Management by walking around is an excellent form of communication with team members. The focus of this day-to-day activity is to engage in brief informal
discussions to assess progress or problems and observe productivity. A good opening for these conversations is, Hows it going today?
Make time for informal group feedback. There are always external factors that impact project success. Ask what concerns the group has, what rumors they may
have heard. You may be able to provide direction on a stalled activity by removing misconceptions or ambiguities. Go to lunch, have a happy hour, gather around
the coffee pot.
Have an elevator speech on where you are in the project and what is coming up next
Results of the communications planning process include a document that defines:
Information collection and filing
Distribution structure detailing to whom information will flow
Description of information distributed, including format, content, and level of detail
Schedule defining when communications will be produced
Methods of communicating and updating changes to the plan
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Write Project Team Communication Plan. 85
Client Project Sponsor *
Client Project Manager Approve Project Team Communication Plan. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Communication Management requirements that should be taken into
consideration when developing the detailed Project Team Communication Plan.
Project Stakeholders
Analysis (CMM.010)
Use the Project Stakeholder Analysis as the starting basis for this component. Update with any new information.
Documentation
Management Plan
(CM.030)
The Documentation Management Plan documents a clear structure for document management that the project team can follow when creating
and storing project documents, the location where all documentation is stored, and the document version control procedures.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM020_PROJECT_TEAM_COMMUNICATION_PLAN.DOC MS WORD
CMM020_CLIENT_PROFILE_SHEET.DOC MS WORD
CMM020_STEERING_COMMITTEE_PRESENTATION.PPTX POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.030 - MANAGE PROJECT TEAM COMMUNICATION
In the Manage Project Team Communication task, you put into practice the reporting requirements, scheduled meetings and procedures documented in the Project Team
Communication Plan and manage communication. This task is ongoing throughout the Project Execution and Control phase.
Using the Project Team Communication Plan to manage is similar to all other areas of management in that you need to be prepared to evaluate and make changes to the
plan as the project progresses. The key areas to be addressed in managing communication are:
Compile data from various input sources to create the various communications.
Publish the communication in the various reports.
Conduct project meetings.
Meet the distribution schedule for each communication (report).
File the communications (reports) according to the Project Archive Structure.
Evaluate the effectiveness of the Project Team Communication Plan and adjust the plan as necessary.
ACTIVITY
PEC.ACT.MCOP Manage Communications and OCM Plans
Back to Top
WORK PRODUCT
Project Team Communication - Project Team Communication is the result of the execution of the Project Team Communication Plan. Communication is gathered,
reported, and distributed according to the Communication Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Compile and gather data. None Individual reports, issue logs and financial data
should be gathered.
2 Complete and publish reports using the
templates and schedules detailed in the Project
Team Communication Plan.
Various Reports (Status Reports, Steering Committee Reports,
Financial Reports, and other key reports as defined in the Project
Team Communication Plan)
Write summary reports from the gathered data.
3 Conduct project meetings. Meeting Minutes Conduct scheduled meetings and take minutes
of key decisions.
4 Distribute reports. Various Published Reports Reports are made available or delivered to
stakeholders.
5 File reports. Updated Project Archives Place communications in the proper place in
the Project Archive as defined by the
Communication Plan.
6 Evaluate and adjust Project Team
Communication Plan.
Revised Project Team Communication Plan Gather feedback informally or formally on the
effectiveness of communications and adjust
the plan as necessary.
Back to Top
APPROACH
The project manager should review the Project Team Communication Plan and ensure that each required communication is occurring as planned or make adjustments to
the plan as required. In this respect, the project manager should ensure that such things as Status Reports, Steering Committee Reports and Financial Reports are
generated and distributed timely and that all reports are being properly filed.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Update Project Team Communication Plan. Publish summary reports, distribute and file. 65
Team Member Publish individual reports, distribute and file. 25
Client Project Sponsor *
Client Project Manager Approve changes to Project Team Communication Plan. Publish summary reports, distribute and file. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Team Communication
Plan (CMM.020)
The Project Team Communication Plan documents the overall communication strategy for the project team. Use the procedures
documented in the plan to manage project team communications.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM030_MEETING_MINUTES.DOC MS WORD
CMM030_WEEKLY_PROJECT_STATUS_REPORT_W_INST.DOC
CMM030_WEEKLY_PROJECT_STATUS_REPORT.DOC
MS WORD - These templates are the same. The first template includes instructions.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.040 - DOCUMENT LESSONS LEARNED
At the start of Project Closure, Conduct a Lessons Learned session and document the findings. In many cases, this is viewed as the last step in the process. However, it
is recommended that this task occurs closely after the Go-Live date of the project and prior to the project team being redeployed to other opportunities. This is especially
key as it is often difficult to pull resources back together to hold this session once the team has begun to disperse.
While this task is placed squarely in the Project Closure phase of the project, this task can often be conducted at the end of a phase of the project and prior to the next
phase beginning. In this way, the project can use this task as a continuous improvement step within the overall project.
A lessons learned session is an important part of the project close-out process because it a primary method through which we learn and gather suggestions for
improvement. The output of the lessons learned session can be utilized as an input to planning the next project. The results of lessons learned sessions are important
because they add to the common understanding of what a good project is and how detrimental influences can be avoided.
Therefore, a Lessons Learned session is intended to:
Be an opportunity to review and document events that impacted success or failure of a project
Provide a basis for process improvements
Increase likelihood of success of future projects.
Project Managers should be cautious not to use the session as a finger pointing session, a blame session or a way to find excuses for failure.
ACTIVITY
PC.ACT.DLLAP Document Lessons Learned and Archive Project
Back to Top
WORK PRODUCT
Lessons Learned - The Lessons Learned documents what went well, what worked and what can be improved the next time a similar project is undertaken. It is generally
organized by process.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Conduct Lessons
Learned Session.
None Organize by process and document what worked well and where opportunities exist for
improvement.
2 Gather any
process-specific
Lessons Learned,
if available.
Various Process Lessons Learned (e.g.,
Scope Management Lessons Learned,
Work Management Lessons Learned,
etc.)
If any processes documented a process-specific Lessons Learned, incorporate it into the project
Lessons Learned.
3 Perform a "post-
engagement"
estimate.
Post-engagement Estimate This step includes completion of an estimating model based upon the actual characteristics of the
engagement that has just been completed. The completed estimate would then be used to
compare to the actuals of the project to assist in reviewing the accuracy of the estimating model(s).
4 Organize and
compile Lessons
Learned.
Lessons Learned Compile the Lessons Learned. Organize all the individual documents into one document. Add any
information to the appropriate process section. Add a structure (i.e., title page, contents, index,
etc.).
Back to Top
APPROACH
Gather all project team members to discuss what went well, what worked and what can be improved the next time a similar project is undertaken. Document the results.
As part of Project Closure, each process may have already documented a process-specific Lessons Learned. In that case, compile the various process-specific reports
into one project Lessons Learned. Add any additional comments to the appropriate process sections. Organize the Lessons Learned with a title page and contents.
The following are recommended topics for inclusion in the lessons learned document:
Provide advice/suggestions from your perspective on what you've learned, experienced and observed from an overall process and project management for your
implementation(s)
Include "things done well" that would be beneficial to future engagements
Include "opportunities for improvement" or things that you would add, change or delete if you had a chance to do it over again.
Elaborate as required to fully explain the lesson
Project Success
Project implementations are successful when they:
Are delivered on time
Are delivered within cost
Meet quality and functional requirements
Satisfy the customer, AND
Deliver the benefits as defined in the business case
Questions to be Considered when Completing Lessons Learned
Was the project successful?
Was it delivered on time?
Was it delivered within cost?
Did the work products meet quality and functional requirements?
Was the customer satisfied?
Did the project achieve the benefits as defined in the business case?
Existence and Effectiveness of Critical Success Factors
Sponsorship and Business Case
Was there a defined and compelling business case (e.g. R/A)?
Was the leadership involved in defining the business case?
Did the leadership fully understand, support, and buy-into the business case?
What things did the leadership do to support the project that was effective? Not effective?
What things should the leadership have done more of? less of?
List things done well in the area of sponsorship and business case.
List opportunities for improvement in this area.
Approved Project Plan
Was there an approved project plan before the project started?
Did the project plan define the what/how/when/who/cost of the project?
List things done well in the area of project planning.
List opportunities for improvement in this area.
Project Management
Was there sufficient and effective project management to guide the project?
Were there activities to support planning, activating, controlling and ending the project?
When changes occurred that would impact any of the measures of a success project (time, cost, quality, customer satisfaction, benefits), was there a change
order process to renegotiate the contract with the sponsors?
List things done well in the area of project management.
List opportunities for improvement in this area.
Execution of tasks
Were the tasks as defined in the work stream structure efficiently and effectively performed?
Were the tasks to be performed documented, standardized and repeatable?
Was there appropriate facilitation of the tasks that needed to be performed?
List things done well in the areas of task execution.
List opportunities for improvement in this area.
List lessons learned in the area of configurations, setups, etc.
Quality Assurance
Was there an effective process in place to assure the existence and quality of the work products?
List things done well in the area of quality assurance.
List opportunities for improvement in this area.
Issue Resolution
Was a process in place to quickly raise and resolve issues that were beyond the scope of the project team to resolve?
Was a process in place to quickly identify and resolve issues that were in the scope of the project team to resolve?
Were there any issues that were either not resolved or not resolved quickly enough that impacted the project schedule?
List things done well in the area of issue resolution.
List opportunities for improvement in this area.
People
Were there a sufficient number of people resources to successfully complete the project?
Was there a sufficient capability of people to successfully complete the project?
Was the personal safety, health and well being of people (stakeholders) appropriately attended to?
List things done well in the area of people.
List opportunities for improvement in this area
Support Processes
Was there an effective organization (team structures, inter-team processes, intra-team processes) in place?
Were there support processes in place to facilitate the work? (e.g. administration, etc.)
Were the tools sufficient to complete the work?
Were the facilities and physical work environment conducive to effective work and team processes?
Was the work environment conducive to teaming, cooperation and productivity, quality of life, etc.?
List things done well in the area of support processes.
List opportunities for improvement in this area.
Technical Infrastructure
Was a 24 x 7 in control and capable technical environment in place to support the work?
Where the instances available when needed?
List things done well in the area of technical infrastructure.
List opportunities for improvement in this area.
Change leadership and management
Were a business case, organization readiness assessment and stakeholder analysis effectively performed as key first steps toward defining a change plan?
Was there change plan to support the project implementation?
Did it address:
Opportunity realization and risk mitigation
Mobilization and alignment of leaders
Communication with stakeholders
Design and development of the future organization
Preparation and equipment of the workforce (training)
Were leadership and management change activities appropriately integrated into the project plan to enable project success?
Risk mitigation
Opportunity realization
Communication planning and execution
Leadership involvement
Future organization design
Training of key stakeholders
List things done well in the area of change leadership and management.
List opportunities for improvement in this area.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Prepare Lessons Learned Report. 65
Team Members Participate and share views on what worked and what could be improved. 25
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM040_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.050 - TURN OVER PROJECT DOCUMENTATION
As part of Project Closure, organize and turn over all project documentation.
Provide client with all project documentation, work products and other relevant information. Also provide the client with a checklist of these items.
Ensure compliance with the implementing organizations (for example, Oracle) responsibility to protect client confidential information.
Finalize archive of all project work products (hardcopy and disks) in compliance with the implementing organization Document Retention Policy.
ACTIVITY
PC.ACT.DLLAP Document Lessons Learned and Archive Project
Back to Top
WORK PRODUCT
Project Archives - The Project Archives is all the project documentation organized and stored to media, turned over to the client and retained per the implementing
organization's Document Retention Policy.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Organize and provide project documentation, work
products and other information to client.
Client Project Archives All project documentation, work products and other information are organized and
stored to media (hardcopy, disk) and turned over to the client.
2 Comply with Code of Conduct regarding confidential
information.
Protected Client
Confidential
Information
3 Finalize archive of project work products for 48
months post warranty.
Project Archives All project work product are are organized and stored to media (hardcopy, disk) and
retained per Document Retention Policy.
Back to Top
APPROACH
The project manager should walk the client through the final structure and agree that archives are now the complete responsibility of the client. The implementing
organization records should also be organized and retained.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Turn over archives to client. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.060 - SUBMIT FINAL REPORTS
In this task, you prepare any necessary Final Reports for the key sponsors. These reports include but are not limited to the following:
Project Engagement Summary
Final Project Status Report
Final Financial Report.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Final Reports - The Final Reports are prepared at the end of the project for the key sponsors.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather information and prepare Project
Engagement Summary
Project
Engagement
Summary
Complete report.
2 Prepare Final Project Status Report. Final Project Status
Report
Complete report.
3 Prepare Financial Report. Final Financial
Report
Complete report.
4 Prepare any other reports, as necessary Various Final
Reports
Complete reports.
5 Review Final Reports with key sponsors and
agree on project closure.
Sign-Off Obtain any sign-off or Approval Certificate. Ask the key sponsors to sign-off that they agree
that the project is closed and obtain any feedback.
Back to Top
APPROACH
Prepare a Project Engagement Summary for the key sponsors at the conclusion of the project. This should summarize, at a minimum:
Final scope including approved change orders
Change orders that were requested but not approved
Financial performance (or earned value analysis)
Schedule performance (or earned value analysis)
Project accomplishments
Any open issues, risks or problems that need to be addressed by the key sponsors moving forward
Additional areas of opportunities moving forward (license, consulting, and support)
Prepare final Project Status Report and Financial Report.
Prepare any additional final reports, as necessary.
Review Final Reports with key sponsors.
Agree on project closure.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Prepare Final Reports. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
All Prior Project Reports (Project Archives)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM060_PROJECT_CLOSURE.DOC MS WORD
CMM060_END_REPORT.DOC MS WORD
CMM060_ENGAGEMENT_SUMMARY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[QM] QUALITY MANAGEMENT
"Project Quality Management includes all the activities of the performing organization that determine the quality policies, objectives, and responsibilities so that the project
will satisfy the needs for which it was undertaken. It implements the quality management system through the policy, procedures, and processes of quality planning,
quality assurance, and quality control, with continuous process improvement activities, conducted throughout..." (from the Project Management Institute's A Guide to the
Project Management Body of Knowledge Third Edition). The Quality Management process is broken down in three (sub) processes:
Quality Planning - identifying which quality standards are relevant to the project and determining how to satisfy them
Quality Control - monitoring specific project results to determine whether they comply with the relevant quality standards
Quality Assurance - executing the systematic quality activities to determine if the quality processes are being followed and whether they are satisfying the projects
quality needs
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Project Start Up, the project manager must define, in the Quality Management Plan, the strategies, standards, and procedures in the areas of Quality Planning,
Control, Assurance as well as Process Improvement. The project manager must also develop the overall governing process and establish control and reporting
mechanisms to ensure that the quality of the project implementation process and work products meet stipulated standards.
Project Execution and Control Phase
Throughout the Execution and Control phase of the project, the project manager monitors the Quality Control as set forth in the Quality Control and Reporting Process
documented in Project Start Up to ensure that work products are properly reviewed and meet specifications prior to presentation to the client. The project manager must
also assess whether all Quality Management (sub)processes are functioning according to plan and, if not, take corrective action. The project manager keeps the
stakeholders informed on key aspects of the project. Product problems are not managed as part of the Quality Management process, they are tracked via the Issue and
Problem Management process for follow up and resolution.
Prior to go-live, comprehensive reviews (internal and external) must be undertaken to confirm that the project results are in compliance with contractual obligations, and
that the requirements and objectives of the Quality Management Plan have been achieved.
Project Closure Phase
A comprehensive Post-Production Quality Review(s) must be undertaken to confirm that the project has been conducted according to the Quality Management Plan and
that all activity and results were in compliance with contractual obligations, and that the objectives of the Quality Management Plan have been achieved. Instances of
project commitments, requirements, and objectives not achieved must be documented and communicated to key stakeholders.
Quality Manager
Some projects have a dedicated quality manager. If so, the quality manager, with guidance from the project manager, plans and prescribes all matters affecting quality of
a project.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS QM.010 Develop Quality Management Plan Quality Management Plan Y Core
PS QM.020 Develop and Document Quality Control and Reporting Process Quality Control and Reporting Process Y Core
Project Execution and Control
PEC QM.030 Develop Project Team Quality Management Orientation Project Team Quality Management Orientation Core
PEC QM.040 Manage Quality Control Quality Control Y Core
PEC QM.050 Perform Quality Assurance Managed Quality Assurance Y Core
Project Closure
PC QM.060 Conduct Post-Production Quality Review Post-Production Quality Review Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.010 - DEVELOP QUALITY MANAGEMENT PLAN
Today, customers place increasing importance on the role of quality in the goods and services they purchase. Quality management has become a proactive, process-
driven practice that is critical to successful project management. It is the key element in assuring that all of the projects requirements are satisfied.
The goal of this task is to establish the quality objectives for the project work products as well as the project delivery process. This plan should describe the quality
processes, standards and procedures that will be used during the project implementation in order to facilitate the stakeholders involved in the product acceptance to
verify its conformance to stipulated requirements. This information is then documented in the Quality Management Plan. The Quality Management Plan is a key
component of the Project Management Plan. In keeping with the organization of the Quality Management process, the Quality Management Plan has three major
components:
Quality Planning Process
Quality Assurance Process
Quality Control Process
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Quality Management Plan - The Quality Management Plan documents the quality processes, standards and procedures that will be used during the project
implementation in order to facilitate the stakeholders involved in the product acceptance to verify its conformance to stipulated requirements.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Establish the Quality Planning Process. Quality Planning Process Document the Quality Planning Process. Include the following
sections:
Purpose
Scope
Client Culture
Definitions
Process
Tools and Techniques
Standards
Procedures
Quality Activity Schedule
2 Establish the Quality Assurance Process. Quality Assurance Process Document the Quality Assurance Process. Include the
following sections:
Purpose
Scope
Process
Tools and Techniques
Quality Assurance Questions
3 Establish the Quality Control Process. Quality Control Process
- Purpose
- Scope
- Tools and techniques
Document the Quality Control Process. Include the following
sections:
Purpose
Scope
Tools and Techniques
4 Obtain key stakeholder agreement and approval on the Quality Approved Quality Obtain any necessary sign-off or Approval Certificate.
Management Plan. Management Plan
Back to Top
APPROACH
Quality Planning Process
Quality Planning is the process of identifying which quality standards are relevant to the project and determining how to satisfy them. Document the decisions and
conclusions from the Quality Planning Process in the Quality Planning Process component of the Quality Management Plan. The Quality Planning Process should
specifiy the plan to establish, monitor and ensure quality objectives for project deliverables and work products as well as the project delivery process. Use the following
information to complete the sections of the Quality Planning Process component.
Client Culture regarding Quality Management: Identify the client's quality management requirements in the Quality Management Plan.
Definition
Include generally accepted definitions that could be explicit in the document in order to facilitated the overall understanding of quality management. Consider including the
following:
Quality of product is the conformance to requirements to user needs and expectations.
Quality of delivery process is the conformance to the process established to conduct the project.
Quality of specification is the conformance to specifications of requirements or specification of delivery process. Specifications could be understood as a
translation of requirements using the project standards established in the execution method (i.e. standard that define how to write a functional specification) or to
perform the project management processes in the Project Management Method (i.e. Project Management Framework that establish all Project Management
Process)
Quality Review is a type of assessment undertaken to ensure the suitable, adequacy, effectiveness, and efficiency of the subject matter to achieve established
objectives. There are many types of quality reviews that could be used as a tool to perform a quality assurance or a quality control activities.
Tools and Techniques
Describe the tools and techniques that the project will use. It's not appropriate to include techniques that you do not plan to use.
Start by obtaining the standards and procedures from the Project Management Framework and from the execution method, such as the testing strategy and testing
documents standards is a technique to select those that apply to the current project.
The output of Quality Planning is this document, the quality management plan with all standards, procedures and checklists that should be used to the further quality
process, as well as the master schedule for the quality activities and the updated project plan with the quality baseline.
Standards
In this section, identify which standards will be used by the quality activities during the project.
The specification of each Project Management Method delivery process are described as a standard in the Project Management Framework (refer to BT.070 Project
Management Framework) and the specification of each execution method delivery process are described as a standard to perform the correspondent tasks. Therefore,
OUM Manage contains the standards that should be applied to perform the quality activities related to the project management activity and the execution method
contains the standards that should be used to perform the quality activities related to product that should be delivered.
For Application Implementation projects consider the standards defined by the Oracle On Demand group in the areas of Configuration, Extension, Modifications,
Localization and Interface development and deployment.
Some of the standards are:
BT.070 Project Management Framework
Documentation Control Standards
Configuration, Extension, Modifications, Localization and Interface Standards from Oracle On Demand
Procedures
Identify which procedures will be used to perform quality activities during the project and reference where it is described. Typical procedures are:
QM.020 Quality Control and Reporting Process
Document Control and Approval Procedure
Production Assessment Review
Performance Compliance
Quality Activity Schedule: Identify the main quality activities that will be performed during the project. The description should include its classification area (Quality
Planning, Quality Assurance, or Quality Control), the phase of the project where the quality activity will be performed, who is responsible for performing it, the work
product that will be produced at the end of the quality activity.
Describe the tool, technique, procedure and standard that applies to the planned quality activity, in the quality control process definition.
The detailed tasks and related activities should be managed in the Work Management process.
The table below shows an example of a quality activity schedule:
Quality Activity Quality Process Phase Who Milestone Work Product
Develop Quality Management Plan Quality Plan Start Up Project Manager QM.010 Quality Management Plan
Planning Review Quality Assurance Start Up External Quality Manager
Work Product Review for Definition Phase Quality Control Definition Project Manager / SME / Client
Quality Assurance Process
Quality Assurance is applying the planned, systematic quality activities and any ongoing processes to ensure that the project employs all delivery processes needed to
meet requirements. Quality assurance is a periodic or ongoing evaluation of the projects quality process with the objective of deciding whether the projects work
products are meeting the stated or implied needs of the project. A secondary purpose is to assure the stakeholders that the system is producing appropriate and
acceptable work products and that the sum of the work products will equal the projects objectives. During this task, you document the quality activities and any ongoing
process that will be used during the Perform Quality Assurance task (QM.050) in the Quality Assurance Process component of the Quality Management Plan.
Quality Control Process
Quality Control is the process of monitoring specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate
causes of unsatisfactory results. During this task, you document at a high-level the purpose, scope and tools and techniques for the Quality Control Process. The
following task, Develop and Document Quality Control and Reporting Process (QM.020) describes in detail the Quality Control Process and tools that will be used in the
project.
Quality reviews, quality control tools, inspection, defect repair review, and testing strategies from the execution method are common tools used to perform quality control.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Develop the Quality Management Plan. Depending on your project, you may have a designated quality manager in this role
that reports to the project manager.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Quality Management requirements that should be taken into consideration
when developing the detailed Quality Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM010_QUALITY_MANAGEMENT_PLAN.DOC MS WORD
QM010_QUALITY_MANAGEMENT_PROCEDURES.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.020 - DEVELOP AND DOCUMENT QUALITY CONTROL AND
REPORTING PROCESS
Quality Control is the process of monitoring specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate
causes of unsatisfactory results. During the previous task, Develop Quality Management Plan (QM.010), you documented at a high-level the purpose, scope and tools
and techniques for the Quality Control Process. In this task, you develop and document a Quality Control and Reporting Process, using the information in the Quality
Management Plan as a starting point. Specifically, during this task you identify what key project elements require monitoring and control and their associated required
characteristics and performance criteria that must be monitored, analyzed, evaluated, and controlled. Document how they will be monitored and measured, and how the
results will be communicated to project stakeholders.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Quality Control and Reporting Process - The Quality Control and Reporting Process identifies and documents the following:
Key Project Elements that require monitoring and control and the associated Required Characteristics / Performance Criteria
Processes to:
Identify and review Key Project Elements and document actual achievement versus Required Characteristics / Performance Criteria.
Compare the actual achievement versus the Required Characteristics / Performance Criteria, analyze the results, and determine quality performance.
Assemble and communicate the quality performance results (management information) to all key stakeholders.
Assemble and communicate process improvement feedback (issues/problems, remedial action recommendations) to the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine the key project elements that require
monitoring and control and identify/establish the
associated required characteristics /
performance criteria.
Key Project
Elements and
Performance
Criteria
This component provides a list of all the key project elements that require monitoring and
control along with the required characteristics and performance criteria for each. A
description of acceptance criteria for project work products and the project overall (usually
spelled out in the contract).
2 Develop and document processes to review key
project elements, compare the actual
achievement versus the required characteristics /
performance criteria.
Comparison of
Actual
Achievement vs
Performance
Criteria
Document processes to review key project elements and document actual achievement
versus Required Characteristics / Performance Criteria and compare them to what was
actually achieved.
Include a list of the Quality Control roles and responsibilities.
Describe how the quality of the project processes is to be determined (project reviews) and
how the quality of project work products is to be determined (work product reviews).
Document processes to assess the effectiveness of the testing plan.
3 Analyze and communicate the results. Results Analysis
and
Communication
Document processes to:
Analyze the results, and evaluate performance
Communicate the quality performance to stakeholders
Communicate process improvement feedback to the project.
4 Obtain or create Quantity Control Reports Quality Control
Checklist
Quality Control
Performance
Notification
Obtain or create any necessary Quality Control forms.
Quality Control
Process
Improvement
Feedback
Notification
5 Obtain key stakeholder agreement and approval
on the Quality Control and Reporting Process
Approved Quality
Control and
Reporting
Process
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Quality Control vs Quality Assurance
It is important to maintain the distinction between Quality Control (inspection) and Quality Assurance (management).
A Quality Control process can be as simple as verifying that a report was spell checked before submitting it to the customer. It can be as complex as a multi-person code
walk through. The project manager needs to decide how much detail is needed and how intricate the process will be. The goal is to routinely examine work items (work
products, intermediate products, and services) during their creation/delivery and ensure that they conform to project standards.
Quality assurance is the process of looking at the sum total of the quality activities in the project and assessing whether they are achieving the quality objectives laid out in
the Quality Management Plan.
Activities associated with the Quality Control Process are:
Determine and document the Key Project Elements that require monitoring and control and the associated Required Characteristics / Performance Criteria.
Identify the acceptance criteria for project work products and the project overall (usually spelled out in the contract).
Specify quality roles and responsibilities.
Describe how the quality of the project processes is to be determined (project reviews) and how the quality of project work products is to be determined (work
product reviews).
Develop and document processes to systematically examine the Key Project Elements and document actual achievement versus the Required Characteristics /
Performance Criteria.
Describe the testing plan, how it will be developed, reviewed with the client, and approved.
Review the actual achievement versus the Required Characteristics / Performance Criteria, analyze the results, and determine quality performance.
Communicate the quality performance (management information) to all key stakeholders.
Assemble and communicate process improvement feedback (issues/problems, remedial action recommendations) to the project.
Quality reviews, quality control tools, inspection, defect repair review, and testing strategies from the execution method are common tools used to perform quality control.
Definition: Required Characteristics / Performance Criteria: are properties that a Key Project Element must have in order to meet management expectations and/or
effectively fulfill an intended role within the project. The are generally specified as follows:
conformance to specified requirements (contract, procedures, regulations, etc.)
achievement of specified results (reject levels, cycle times, etc)
attainment of specified expectations (profitability, critical success factors, etc.)
Identifying Key Project Elements
Key Project Elements: are aspects of the project, that in the judgment of management, are significant enough to influence success or failure and therefore require
monitoring and control.
The are generally identified from the following areas:
Contractual Obligations
Statutory Regulations
Internal/External Organizational Standards, Requirements, and Expectations
Project Processes, Procedures, Activities, Test Results, Outcomes, and Accomplishments
Key project elements that require monitoring and control must be identified from a variety of sources. They must be identified and assembled in a consolidated list. The
obvious focus is on those elements that are relevant and significant to the success or failure of the project, i.e. those elements that influence:
Contractual Compliance
Statutory Compliance
Client Satisfaction
Oracle Expectation Achievement
Examples of a more detailed breakdown are:
Contractual Requirements
work products
Service Level Standards
Roles and responsibilities
Assumptions
Critical Success Factors
Performance Objectives
Statutory regulations
National, Regional, Local
OC and Client Standard Operating Procedures (Project Management Plan)
Corporate, Regional, Business Unit, Practice
Bid Transition
Scope Management
Financial Management
Work Management
Quality Management
Risk Management
Issue/Problem Management
Staff Management
Communication Management
Configuration Management
Infrastructure Management
Procurement Management
Organizational Change Management
Industry Leading Practices
Mutually Established Project Conventions
Client Specifications and Expectations
Oracle Consulting Specifications and Expectations
Test Results
If the customer has a formal quality policy in place, look for any required processes that involve documentation of test or inspection activities, or a feedback and corrective
action cycle. Specific activities, such as design standards or reporting requirements that are relevant to the project may also be mentioned in the policy. Everything in
the quality policy that applies to the project is a quality need and must be included in the Quality Control and Reporting Process.
The Project Management Plan, as the guideline for all project activities, is an important factor in determining quality needs. The project critical success factors will also
help to define quality needs. Focus on each success factor; identify the appropriate standards and quality control processes that will ensure that each one will be
achieved. The projects service levels, availability, and performance objectives are other elements for which quality needs can be identified.
Determine Required Characteristics / Performance Criteria (Quality Needs); Review,
Document, and Compare the Actual Achievements
Required Characteristics / Performance Criteria are properties that key project elements must have in order to meet management expectations and/or effectively fulfill an
intended role within the project. A shorter description for this is quality need.
Examples of key project elements and corresponding required characteristics / performance criteria (quality needs) follow:
Key Project Element Required Characteristic / Performance Criteria (Quality Needs)
1. Configuration Management Plan
Follow recommended format.
Complete and approved by plan date.
Content compliant with recommended by procedure.
2. Run Payroll Test (Test Plan Element)
Meet specifications defined in the Test Plan.
Examples of Actual Achievement reporting follow:
Key Project Element Required Characteristic / Performance Criteria (Quality Needs) Actual Achievement
1. Configuration Management Plan
Follow recommended format. Compliant
Complete and approved by plan date. Not Compliant (2 weeks late)
Content compliant with recommended by procedure. Partially Compliant
2. Run Payroll Test (Test Plan Element)
Meet specifications defined in the Test Plan. Compliant with Specifications
Execution procedures must be established to define:
Monitoring responsibilities and approach
Data collection formats, frequencies and techniques
Actual achievement reporting conventions
Distribution lists
Process maintenance
Examples of techniques to provide quality control are:
Self-certification (individual work products)
Peer review (individual work products)
Independent review (overall project; work product sets)
Management review (overall project; work product sets)
External review (overall project; work product sets)
Examples of roles involved in quality control are:
Quality Manager - oversees preparation and review of project quality plans and assignments.
Quality Reviewer(s) - responsible for conducting regular project/process reviews
Quality Reviewer(s) - responsible for conducting quality reviews of project work products
Examples of external reviews/audits (taken from NAC standards) are:
Startup Tollgate (STG) Remote review (0.5 day). Provide an assessment and review of key startup activities and documentation to confirm successful project
start. A Startup Tollgate internal Report will be provided to PM and Practice Management at the conclusion of the Startup Review which will document and
communicate satisfactory Startup compliance status.
Delivery Assurance Review (DLR) Onsite or Offsite review (2 days). Provide comprehensive quality assessment that focuses on project performance,
governance and risk components associated with project delivery. After the DLR is completed, a DLR internal Initial Report will be distributed to PM and Practice
Management which will provide an evaluation of overall status, compliance (specific determination of compliant and non compliant items), follow up actions and
expected completion dates (within two weeks). A formal follow up process will be conducted that will determine the final status of the project and open items. A
DLR internal Final Report will be issued. Any remaining open actions at that time will be sent to the owning Portfolio Director for immediate follow up and
resolution.
Project Readiness Review (PRR) Onsite or offsite review (2 days). Provide a thorough review of go live project activities to validate overall readiness, identify
and prevent problems subsequent to production cut over. Similar to the DLR, a PRR An internal report will be distributed by QMG to PM and Practice
Management which will provide an evaluation of overall status, compliance (specific determination of compliant and non compliant items) and follow up actions.
Due to the timing and nature of the review, a strong emphasis is placed on quick and immediate resolution of open items prior to go live.
Examples of external approaches are:
Walk through: (individual or group) is a review whereby the reviewer(s) step through a work product to check for errors, inconsistencies, incompleteness, etc. The
findings and recommended actions resulting from the Walk through must be documented. Group Although should be coordinated by a designated leader.
Inspection: has the same purpose but is a more formal version of a Walk through. Formal roles are assigned to reviewers. These roles are:
Moderator (review lead)
Author (of the work product being reviewed)
Reader (reads out the part currently being reviewed)
Recorder (documents findings)
One or more reviewers who may also be role-playing (e.g., the customer view, the Oracle technical view, Oracle PM view, etc.).
Inspection reviews are extremely thorough since role-playing ensures that the work product is evaluated from many different angles and there is a great deal of
preparation before the Inspection itself. It is therefore the most expensive type of review to run, and should be used when appropriate (e.g., for end of phase work
products, for mission-critical work products).
Technical Review: focuses not just on looking for errors and incompleteness (as is the purpose of any review), but evaluates the technical aspects of a work
product e.g., elegance of code, functionality, etc. A Technical Design Review is a special type of Technical Review. A Technical Review is usually conducted as
part of a Walk through. or an inspection.
A key project element is the degree of self-sufficiency attained by the client organization prior to OC disengagement:
A possible quality control approach is to develop a knowledge sharing scorecard to evaluate the following sub-elements:
How self-sufficient is the customer?
What missing skills can additional training fill in?
What operational skills do they need to develop before they can run the system themselves?
Have you conducted dry runs when customers perform all of the processes to find out what knowledge gaps they have?
Start with a list of post-implementation responsibilities and related skills. Define the knowledge needed to carry out those duties independently. Identify the earliest and
latest point in the project where those skills could be transferred; then set the optimal time for the transfer. The optimal time is when the bulk of testing is complete and
further changes to the system will be minimal. Add checkpoints to your project plan to ensure that knowledge sharing is occurring.
Analysis of the results and corrective feedback could be used as a basis to develop a remedial training program.
Identify specific skills for each client team member to acquire, (that is, a team member might need to know Oracle Reports but not Java).
Ensure all client core team members receive appropriate Oracle classroom training.
Provide each person with an Oracle coach who has mastered the skill.
Identify how skill acquisition will be demonstrated (that is, complete all company setup for a new business unit).
Establish timeframe's for skill acquisition.
Establish knowledge sharing goals early in the project, then communicate and monitor them throughout the implementation. Create and publish a knowledge sharing plan
that identifies: the knowledge to be transferred, who will teach it, the specific resources to be taught, and the timeframe it will occur.
Analyze the Results and Communicate Quality Performance
In the end, actual achievement must be examined and compared to the required characteristics / performance criteria (quality needs) to determine results and evaluate
quality performance. But before communicating any results, determine the responsibility, frequency, format, and distribution for communicating quality performance in
management terms to all key stakeholders. In addition the PM will assemble and communicate process improvement feedback (issues, problems, and remedial action
recommendations) to the project team.
Management information and feedback reporting procedures must be established to define:
Generation Responsibilities
Formats and Content
Frequencies
Distribution Lists
Process Maintenance
Quality Review Reports
Test Results
Types of reporting tools and techniques frequently utilized are:
Cause and Effect Diagram
Control Chart
Flow Chart
Histogram
Pareto Chart
Run Chart
Scatter Diagram
Statistical Sampling
Inspection
Defect Repair Review
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Determine the Key Project Elements that require monitoring and control and identify/establish the associated Required
Characteristics / Performance Criteria. Develop, document, and execute processes to review Key Project Elements, compare
the actual achievement versus the Required Characteristics / Performance Criteria, analyze and communicate the results.
Assign and make sure regular project/process reviews are conducted.
Depending on your project, you may have a designated quality manager in this role that reports to the project manager. If so,
the quality manager would develop, document, and execute processes to review Key Project Elements, compare the actual
achievement versus the Required Characteristics / Performance Criteria, analyze and communicate the results. The
designated quality manager would also assign and make sure regular project/process reviews are conducted.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010) Use the processes defined in the Quality Management Plan to develop the Quality Control and Reporting Process.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM020_QUALITY_CONTROL_REPORTING_PROCESS.DOC MS WORD
QM020_QUALITY_CONTROL_CHECKLIST.DOC MS WORD
QM020_QUALITY_REVIEW_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.030 - CONDUCT PROJECT TEAM QUALITY MANAGEMENT
ORIENTATION
In the Project Start Up phase, the project manager must formally assemble the team to communicate the key tenets of the Quality Management Process, set the
appropriate expectations for the team, and thoroughly discuss quality management concepts. This activity can be conducted as a separate session or as part of a larger
meeting (for example, as part of an overall Project Kickoff).
ACTIVITY
PEC.ACT.OMT Orient and Manage Team
Back to Top
WORK PRODUCT
Project Team Quality Management Orientation - The Project Team Quality Management Orientation consists of project team that has attended a quality management
orientation and is aware of the key tenets of the Quality Management process for the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop Quality Management orientation presentation. Team Quality Management
Orientation Presentation
The Presentation explains key tenets of the Project Quality
Management process for the project:
What is quality on this project?
Quality milestones
Key aspects of the Quality Management Plan
Quality roles & responsibilities
2 Schedule orientation meeting or schedule presentation
during Project Kickoff.
Back to Top
APPROACH
The project manager is the leader and primary role model when it comes to quality. Every time he/she mentions quality, it communicates that quality merits a position of
high regard. If he talks about schedule and deadlines more than quality, the team will infer that he wants the work done on time regardless of the quality levels. This is an
impression that the project manager does not want to encourage. Remember, that the goal is ensure that quality is built in and not inspected in.
The project manager must establish that quality work products are an essential part of the project, and continually strive to build a project team culture in which team
members (Oracle, Client and third party) embrace the idea that every every team member contributes to overall project quality in everything that they do.
Use the opportunity to set expectations around quality in a formal team setting.
The orientation should cover topics such as:
Project Quality Scope - what quality on this project includes and what it does not include (e.g., It does not include gold plating and may not include certain types of
testing or documentation.)
Quality Milestones on the Project
Key Aspects of the Quality Management Plan
Purpose
Scope
Definitions
Process (Planning, Assurance, and Control)
Tools and techniques
Standards
Procedures
Master Schedule Plan
Project Team Quality Roles and Responsibilities
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager
Develop the Project Team Quality Management Orientation presentation and serve as the lead role model for project quality.
Depending on your project, you may have a designated quality manager in this role that reports to the project manager. If so,
the quality manager would then develop the Project Team Quality Management Orientation presentation and serve as the lead
role model for project quality.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010)
Quality Control and Reporting Process (QM.020)
Educate the team on the processes defined in these work products.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM030_PROJECT_TEAM_QUALITY_MANAGEMENT_ORIENTATION.PPTX POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.040 - MANAGE QUALITY CONTROL
The goal of quality control is to improve the likelihood of project success by systematically examining pre-determined key elements during project execution to ensure that
they are conforming to established standards.
In the Manage Quality Control task, you execute the Quality Control and Reporting Process (QM.020), which consists of the following steps:
Review Key Project Elements, and compare the actual achievement versus the Required Characteristics / Performance Criteria.
Analyze the results, and evaluate performance.
Review Reports
Test Results
Communicate the quality performance (management information) to all key stakeholders.
Responsibility, frequency, format , distribution
Assemble and communicate process improvement feedback (issues/problems, remedial action recommendations) to the project. Integrate with:
Test Process
Issue and Problem Management Process
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MPQ Manage Project Quality
Back to Top
WORK PRODUCT
Quality Control - Quality Control is the execution of the Quality Control and Reporting Process.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Periodically evaluate all key project elements and
capture a snapshot of whether or not they meet
acceptance criteria.
Updated Quality Control
Checklist
A listing of key project elements and corresponding Required Characteristics /
Performance Criteria. The activity consists of indicating whether or not the the criteria
have been met.
2 Analyze the results of the key project element
review.
Updated Quality Control
Checklist
Once again the Quality Control Checklist is updated with the summarized and
categorized results of the key element review indicating which elements are compliant
/non-compliant with the specified criteria.
3 Communicate the quality performance
(management information) to all key
stakeholders.
Quality Control
Performance
Notification
E-mail notifications directed to designated project stakeholders with a summarized
checklist attached communicating results of the Quality Control Review for their
respective areas of interest.
4 Assemble and communicate process
improvement feedback to the project.
Quality Control Process
Improvement Feedback
Notification
Assemble and communicate process improvement feedback (remedial action
recommendations) to the project. Interface with the following processes:
Testing
Issue and /Problem Management
Quality Management
Back to Top
APPROACH
The Project Manager is ultimately responsible for the quality of the overall delivery and must therefore ensure that the quality process is being adhered to during the work
execution phase. This usually best done through sample reviews either by the project manager or and appointed, trusted reviewer. When resources are under pressure,
quality is often the first casualty. The effort to resolve quality issues late in a project usually far exceeds the effort to achieve the required quality initially.
The inputs to this task are the Quality Management Plan, Quality Control and Reporting Process, quality metrics, quality checklists, testing scripts (with expected results)
from the execution method.
The primary output of this task is the defect identification report. In addition, the defects must be analyzed to determine collectively whether their underlying causes
stemmed from a common source or whether their causes were unrelated. In quality parlance, were they common cause or special cause defects? Understanding the
source of your defects goes a long way toward helping you prevent future defects.
Quality Management activities include verifying conformance to standards, identifying/eliminating problem causes, and monitoring compliance with the quality control
processes. Responsibility for those activities should be delegated to the lowest team member that can successfully execute the process. For example: if programmers
can check each other's work, they should. If consultants or team leads can check procedure documents for completeness and format, the project manager should not do
it. The project manager should avoid direct involvement in most quality control activities except for those work products that have a payment milestone associated with
them.
A quality management process can be as simple as verifying that a report is spell checked before submitting it to the client. It can be as complex as a multi-person code
walk through. The project manager needs to decide how much detail is needed and how intricate the process will be. The possibilities for quality management processes
are infinite. They are intended to answer the questions:
Whether or not all of the control processes are being followed
Whether or not the processes are achieving the objective (the quality need)
Quality Management execution processes typically fall into one of the following categories:
Self-certification: The person who did the work signs off on a checklist
Peer review: The people who perform the same role on the team review the work
Independent review: Someone from outside the producing team reviews the work
Management review: The person who does the work has their supervisor review it
External audit: Someone from outside the project inspects the work
Each quality process category provides a different level of certainty that the quality standards were met. Choose a category appropriate to the level of importance that
the work being inspected has. Each key project element might have its own review process, but the basic approach is similar:
Review the work product against the specification
Identify defects (either design flaws or problems with the work product)
Summarize and communicate the results to the relevant stakeholders
Provide corrective feedback and remedial recommendations to address outcome defects and processes
Ensure that critical project processes and activities receive priority attention:
Work products must be presented for review and acceptance with the client in a walk-through fashion. That is, do NOT just deliver documents to the client with an
acceptance certificate attached.
Answer any questions/issues on the spot
Make sure to clearly explain all significant details of the work product to the client.
Ask for signature/closure during the walk through
Ensure that all work products requiring client review are physically signed off by client
Acceptance Certificates for fixed price projects must be signed by the client and submitted to finance, operations, and contracts for processing according to the contract
payment milestone schedule.
Testing Process must adequately address all conditions related to overall system acceptance.
Coding Standards Code Review Process should be established and published to the project team using the Project Documentation Library.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Responsible for managing and/or delegating responsibility for the development and execution of the project Quality
Management process. Responsible for the results and proper functioning. Depending on your project, you may have a
designated quality manager in this role that reports to the project manager.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010)
Quality Control and Reporting Process (QM.020)
These work products document the plan and processes for managing quality during the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Quality Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM040_REVIEW_COMMENTS_LIST.DOC MS WORD
QM040_REVIEW_LEADER_FORM.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.050 - PERFORM QUALITY ASSURANCE
Quality Assurance is applying the planned, systematic quality activities and any ongoing processes documented in the Quality Management Plan to ensure that the
project employs all delivery processes needed to meet requirements. Quality assurance is a periodic or ongoing evaluation of the projects quality process with the
objective of deciding whether the projects work products are meeting the stated or implied needs of the project. A secondary purpose is to assure the stakeholders that
the system is producing appropriate and acceptable work products and that the sum of the work products will equal the projects objectives.
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MPQ Manage Project Quality
Back to Top
WORK PRODUCT
Managed Quality Assurance - Managed Quality Assurance is the execution of the Quality Management Plan to ensure that the project employs all delivery processes
needed to meet requirements.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Monitor specific project results from the quality control process to ensure compliance with quality objectives. Quality Compliance
2 Conduct planned and systematic activities (for example, Quality Reviews) to increase confidence that quality
planning objectives are met.
Fulfilled Quality Planning
Objectives
3 Monitor project management, quality management and execution processes for effectiveness. Updated Quality
Management Plan
Back to Top
APPROACH
The person who performs the Quality Assurance process (either the project manager or the quality manager) will have to evaluate the projects quality and delivery
processes with the objective of deciding whether the projects work products are meeting their stated objectives. A secondary purpose is to assure the stakeholders that
the system is producing appropriate and acceptable work products and that the sum of the work products will equal the projects objectives.
While performing quality assurance you may learn that the projects quality needs have changed or were stated incorrectly. Take this information back to the Quality
Planning Process step to redefine the needs, the standards, or the Quality Control processes, as needed. If you skip this step, you risk completing the project according
to the stated needs, but have the customer view it as a failure.
There will also be unplanned opportunities to gather information about project quality. For example, any time someone complains about something going wrong
repeatedly, you should identify it as an opportunity to find out which part of the quality process needs attention.
The inputs to this task are the Quality Management Plan, work performance information from quality control and testing activities, implemented corrective and preventive
actions as well as the whole Project Management Framework.
The output of this process are requested changes and recommended corrective actions to existing quality activities.
Tools and Techniques
The primary tool of the Manage Quality Assurance task is the Quality Review.The Quality Review is normally conducted by the quality manager and/or project manager.
The questions below should be answered during this task step. They allow the person conducting the review to assess whether the Quality Management Plan is
achieving the desired results and, if not, where the problem resides.
Quality Assurance questions regarding Quality Management:
Were any work products rejected or otherwise non-compliant?
Are the quality standards being met?
Are the quality management processes being followed?
Quality Assurance questions regarding Quality Planning:
Are the quality control processes effective?
Should additional work be reviewed by quality control?
Are some quality standards missing?
Were the quality needs defined correctly?
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Perform the quality assurance. Depending on your project, you may have a designated quality manager in this role that reports
to the project manager.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010) Execute the Quality Assurance Process documented in the Quality Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM050_AUDIT_ACTION_REPORT.DOC
QM050_AUDIT_REPORT.DOC
QM050_QUALITY_REPORT.DOC
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.060 - CONDUCT POST-PRODUCTION QUALITY REVIEW
Request, participate in, and respond to a Post-Production Quality Review. During Project Closure, conduct a final quality review to validate compliance and fulfillment of
the project's stated quality objectives prior to transitioning the Quality Control and Reporting Process to the client.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Post-Production Quality Review
Back to Top
TASK STEPS
No. Task Step Component Component Description
1 Conduct final review of specific project results from the Quality Control
process to comply with quality objectives.
Fulfilled Quality Objectives
2 Communicate the fulfilled quality performance (management information)
to all key stakeholders.
Quality Control
Performance Notifications
This component is the final Quality Control Performance
Notification.
3 Compile the review into one document. Post-Production Quality
Review
The Post-Production Quality Review is a compilation of all the
components into one document.
4 Document an lessons learned. Quality Management
Lessons Learned
Back to Top
APPROACH
Conduct a review of the Quality Control Checklist and document final fulfillment of project quality objectives. Document this analysis in the checklist or create a separate
Post-Production Quality Report. Provide this information to the client and transition the Quality Control and Reporting Process to the client.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated quality manager in this role that reports to the project manager. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM060_CLIENT_SATISFACTION_REPORT.DOC MS WORD
QM060_PROJECT_HEALTHCHECK_CHECKLIST.DOC MS WORD
QM060_METRICS_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[CM] CONFIGURATION MANAGEMENT
The objective of the Configuration Management process is to reduce project risk by defining appropriate management and control processes for important work products
including both documentation and software. A successfully implemented Configuration Management process reduces errors, rework and lost time related to configuration
problems such as installing incorrect versions of software, missed patches, obsolete or incorrect documentation.
The Configuration Management process is composed of an overall Configuration Management Plan and Processes, and specific, more detailed plans for tools,
documentation, software configuration, software release, environment and patch management, and controls. The Configuration Management Plan and Processes defines
the tools that will be used by the project, who on the project team is responsible for each area and what project work products will be formally managed. The
Configuration Management Plan and Processes, the Configuration Management Tools and the Documentation Management Plan should be created early in the Project
Start Up phase so that the project is well positioned to manage work products that are produced early in the project lifecycle.
Configuration Management identifies what configuration items will be managed for the project, how they will be identified, how baselines will be established, what
management processes will be used to track them, and what metrics will be established for reporting. Every project produces a number of work products that must be
placed in a secure repository and may require version control. The Configuration Management process defines:
what specific item configuration items will be produced by the project
how the items will be managed and at what level of detail will management will occur
what level of version control is required for each type of configuration items
what level of access is required for initiating, creating, and approving a change to any configuration item
what processes, procedures and controls apply to each type of configuration item
who is has responsibility for the execution of the Configuration Management process
what metrics will be used to support Configuration Management control
Configuration Items commonly produced during the course of a project include:
Project Documentation Items including (but not limited to):
Functional Specifications
Technical Specifications
Test Cases and Test Results
Any document considered a contractual deliverable
Scope Change Requests
Other Change Requests
Application Setup Documents
Workplan
Status Reports
Management Presentations
Client Signoffs
Key Emails
Software configuration items including (but not limited to):
Source Code for Extensions and Customizations
Reports
Database Configurations
Patches
Wrapper Installation Scripts
Seed Data
Additional significant items that require Configuration Management include environments and software releases.
Configuration Management is linked to change management, as changes to scope frequently imply changes to established baselines of configuration items.
The Configuration Management process provides guidance to the project manager and project team for establishing (or validating the establishment of) a sound
Configuration Management for the life of a project.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager creates a Configuration Management Strategy and Processes that defines:
what configuration items the project will produce
which specific Configuration Management plan will document the management of each configuration item or group of items
who has responsibility for completing each task in the Configuration Management process
how specific activities are the responsibility of the client or a third party
how activities that are responsibility of a client or third party will be integrated into the overall project plan and what status mechanism will be used
what metrics will be collected to track and report on the process
The project manager identifies any tools required to support the Configuration Management process. If additional tools are required, complete a tool evaluation and
selection, initiate the procurement process, and plan for installation or configuration of required tools.
The final Configuration Management task in the Project Start Up phase is the completion of the Documentation Management Plan. The Documentation Management
Management Plan must be completed prior to the start of Project Execution and Control in order to provide an established Project Library before documentation
configuration items are produced.
The Software Configuration Management plan can be completed early in the Project Execution and Control phase, in parallel with the creation of the functional and
technical specification work that precedes the development of code.
Project Execution and Control Phase
During the Project Execution and Control phase, the project manager is responsible for establishing the Software Configuration Management Plan, the Software Release
Management Plan, the Environment and Patch Management Plan and the Configuration Management Control Plan. In addition, the project manager is responsible for
monitoring the key elements of configuration management identified in the Configuration Management Control Plan and making any adjustments, as necessary.
Establishment of appropriate metrics helps the project manager track and monitor the effectiveness of the Configuration Management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during the execution phase. Specific metrics should be established based on the particular
project requirements. Common metric examples include:
number of configuration items by type (how many source code objects checked in, how many patches applied, how many documented checked in)
number of configuration items that required updates after initial approval
number of defects by type
number of change requests, approved changes
number of source code packages contained in a particular system release
time-related statistics (how long from patch request to patch application, how long to update a particular item, etc., how long to obtain approvals, etc.)
Choose metrics that can be collected using the processes and procedures defined. If Configuration Management tools are used or planned, the tool often produces a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual.
Project Closure Phase
During the Project Closure phase, the project manager records and documents all final versions of configuration items, validates that the client and/or partner have been
given the appropriate version of any contractual deliverables and archives all configurable items in an offsite secure location. The project manager should also
understand and comply with any applicable record retention rules.
Configuration Manager
Some projects have a dedicated configuration manager. If so, the configuration manager, with guidance from the project manager, plans, establishes and controls the
Configuration Management process on the project, with the following responsibilities:
Develop, document and implement Configuration Management Plan and Processes.
Establish project baselines and determine the content of project releases.
Ensure that no authorized changes are made to a project baseline.
Enforce configuration management procedures across all project processes.
Establish and ensure that the Enterprise Repository is adequately maintained and protected against damage or loss.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS CM.010 Develop Configuration Management Strategy and Processes Configuration Management Plan and Processes Y Core
PS CM.020 Obtain Configuration Management Tools Configuration Management Tools Core
PS CM.030 Create Project Documentation Management Plan Documentation Management Plan Core
Project Execution and Control
PEC CM.040 Create and Execute Software Configuration Management Plan Software Configuration Management Plan Y Core
PEC CM.050 Create and Execute Software Release Management Plan Software Release Management Plan Y Core
PEC CM.060 Create and Execute Environment and Patch Management Plan Environment and Patch Management Plan Core
PEC CM.070 Create and Execute Configuration Control Plan Configuration Management Control Plan
Project Closure
PC CM.080 Close Configuration Management Closed Configuration Management Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Depending on your project, you may have a designated configuration manager in this role that reports to the project manager.
Technical
Lead
This role is filled by a technical project team member (for example, developer, designer, system architect) acting in an advisory capacity.
Functional
Lead
This role is filled by a functional project team member (For example, business analyst, application/product specialist) acting in an advisory capacity.
Client (User)
CPS Client
Project
Sponsor
CPM Client
Project
Manager
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.010 - DEVELOP CONFIGURATION MANAGEMENT
STRATEGY AND PROCESSES
In this task, you develop and document the Configuration Management Plan and Processes. This task has four objectives:
1. Identify the which specific configuration items will be produced by the project.
2. Identify the approach used to manage and each configuration item or groups of configuration items.
3. Identify any software tools required to implement the configuration management strategy.
4. Establish the high-level metrics that will be used to measure the effectiveness of the Configuration Management process.
The first step is to identify which specific configuration items will be produced by the project. A configuration item is a unit of configuration that can be individually
managed or versioned. Units with similar requirements may be combined into an overall collection that is managed under the same set of processes and tools.
Configuration Items commonly produced during the course of a project include:
Project Documentation Items including (but not limited to):
Functional specifications
Technical specifications
Test Cases and Test Results
Any document considered a contractual deliverable
Scope change requests
Other change requests
Application setup documents
Software configuration items including (but not limited to):
Source code for extensions and customizations
Database configurations
Patches
Wrapper installation scripts
"Gold instance" setups
Seed data
Additional significant items covered by the Configuration Management processes are the environment or instance strategy, the patch management process and the
software release strategy. A single approach to configuration management that satisfies the requirements of all configuration items may not be available. The
Configuration Management process includes separate tasks to create plans for Project Documentation Management, Software Configuration Management, Environment
and Patch Management and Software Release Management in addition to the Configuration Management Plan and Processes. In the Configuration Management Plan
and Processes, identify what configuration items will be created, which configuration item types are associated with which specific management plan, and avoid detailing
all the processes for versioning, control and management. That information will be detailed in the appropriate plans.
The Configuration Management Plan and Processes is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Configuration Management Plan and Processes - The Configuration Management Plan and Processes documents the strategy, approach and processes to be used
for Configuration Management on the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Prepare an introductory overview of the Configuration Management process. Introduction Document the Purpose, Scope and
Application and other applicable
introductory information.
2 Identify the specific configuration items. Configuration Items Document the different configuration
items.
3 Group configuration items with similar requirements together and assign them to a specific
management plan.
Configuration
Management Plans
Document each plan with a brief
description and list the configuration
items for each plan.
4 Review available software tools and identify if any additional tools needed to support the
configuration management requirements of the project.
Configuration
Management Tools
Document any software tools.
5 Identify any responsible parties outside the immediate project team that will participate in the
Configuration Management process, such as an existing client Configuration Management group.
Document how coordination with such a group will work.
Roles and
Responsibilities
Document all responsible parties.
6 Identify the metrics that will be used to measure the Configuration Management process and how
they will be collected.
Metrics Document the metrics.
7 Obtain key stakeholder agreement and approval on the Configuration Management Plan and
Processes.
Approved
Configuration
Management Plan and
Processes
Obtain any necessary sign-off or
Approval Certificate.
8 Distribute and communicate the Configuration Management Plan and Processes. Configuration
Management Plan and
Processes
File the plan for easy reference.
Back to Top
APPROACH
Configuration Management identifies what configuration items will be managed for the project, how they will be identified, how baselines will be established, what
management processes will be used to track them, and what metrics will be established to report on the Configuration Management process. Every project produces a
number of work products that must be placed in a secure repository and may require version control. The Configuration Management process defines
what specific item configuration items will be produced by the project
how the items will be managed and at what level of detail will management will occur
what level of version control is required for each type of configuration items
what level of access is required for initiating, creating, and approving a change to any configuration item
what processes, procedures and controls apply to each type of configuration item
who is has responsibility for the execution of the Configuration Management processes and procedures
what metrics will be used to support Configuration Management control
Two common risks associated with Configuration Management are that either the configuration items are under defined (not all items that should be baselined or tracked
are covered by the process) or the reverse, the Configuration Management items and their associated control process over defined (so much effort is required to comply
tracking and control processes that overall project productivity is reduced.). For many types of configuration items, there are limits to effective configuration management
unless specialized tools are used that provide the necessary capabilities. As a result, this is a difficult area to manage practically and requires an operational focus.
When the project manager designs the configuration management process the goal must be provide effective tracking and control while avoiding nonproductive
"overhead" that slows the progress of the project. Care must be taken when using manual processes and controls put in place to assure that the manual processes are
in fact followed.
If configuration software tools are going to be purchased, a milestone to note when the tools need to be set up and ready must be added to the project workplan. A
dependency to this milestone must be added to the project tasks that rely on the new configuration software tools.
Metrics
Establishment of appropriate metrics helps the project manager track and monitor the effectiveness of the configuration management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during the execution phases. Specific metrics should be established based on the particular
project requirements but common example metrics include:
number of configuration items by type (how many source code objects checked in, how many patches applied, how many documents checked in)
number of configuration items that required updates after initial approval (changes to the baseline)
number of change requests to baselined items, number of approved changes
number of source code packages or components contained in a particular system release
time related statistics (how long do requests to promote or approve items take?)
Choose metrics that can be collected using the processes and procedures defined. If configuration management tools are in use or planned, the tool usually produces a
variety of metrics that can be reported. If tools are not in place, include metrics to that allow quick checks on the effectiveness of the manual process. Evaluate any
suggested metric for the value it provides against the effort required to collect, particularly if the collection effort is manual
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Client Project Sponsor *
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Configuration Management requirements that should be taken into
consideration when developing the detailed Configuration Management Plan and Processes.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM010_CONFIGURATION_MANAGEMENT_PLAN_AND_PROCESSES.DOC MS WORD
CM010_CONFIGURATION_MANAGEMENT_PROCEDURES.DOC MS WORD (Former PJM 2.6.1 template)
CM010_CONFIGURATION_ITEM_INDEX.XLS MS EXCEL
CM010_CONFIGURATION_ITEM_STATUS_RECORD.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.020 - OBTAIN CONFIGURATION MANAGEMENT TOOLS
The requirements for configuration management tools for the project are defined in the Configuration Management Plan and Processes. In this task, the project manager
with the assistance of the technical lead procures/obtains, installs and configures the tools required. Options available to the project manager to obtain the tools include
but are not limited to the following:
Assist client in procuring tools.
Obtain licenses for required tools.
Obtain open source tools
Assist client in obtaining additional licenses for client-owned tools.
If new tools are obtained or procured, the technical lead or client team is responsible for installing and configuring the tools for the project team's use. Documentation and
training materials for the tools should be uploaded to the designated project location (both physical and computer-based) and communicated to the project team.
In the event the client does not have configuration management tools and is unwilling or unable to procure them, a risk should be created through the Risk Management
Process (RKM.020). Development of software without a tool that provides basic version control and software configuration management capabilities is a high risk for the
project.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Configuration Management Tools - Configuration Management Tools are the tools listed in the Configuration Management Plan and Processes installed and
configured.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Procure or obtain tools defined in the Configuration Management Plan and Processes. Procured Tools
2 Install/configure tools. Configuration Management Tools
3 Upload tool documentation and training materials to the designated project location(s). Tool Documentation and Training Materials
Back to Top
APPROACH
The approach to this task is:
Procure or obtain tools defined in the Configuration Management Plan and Processes.
Install/configure tools.
Upload tool documentation and training materials to the designated project location(s).
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
5
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 15
Client Project Sponsor *
Technical Leads This role is filled by technical project team members (e.g., developer, designer, system architect) providing needed technical
information.
80
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes (CM.010) The Configuration Management Plan and Processes lists the tools that will be used for the project.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.030 - CREATE PROJECT DOCUMENTATION MANAGEMENT
PLAN
The objective of this task is to define a clear structure to manage project documents that the project team can follow when creating and storing project documents and to
assure that all documentation produced by the project is stored in a defined location, with appropriate version control and that changes made to documentation
configuration items can be tracked and audited. The plan should specify the following:
naming standards for documents
standards for the composition of document reference numbers or version control scheme
document repository folder and directory structures
specific storage location requirements for each document configuration item type
the process to identify and track the status of all document configuration items
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Documentation Management Plan - The Documentation Management Plan documents a clear structure for document management that the project team can follow
when creating and storing project documents, the location where all documentation is stored, and the document version control procedures.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Prepare an introductory overview. Introduction Document the Purpose, Objectives and Glossary and and other
applicable introductory information.
2 Establish definitions. Determine the definitions of "baseline" that apply to
documentation management.
Glossary Document the configuration item and baseline definitions.
3 Identify the specific configuration items. Documentation
Configuration
Items
Document the different configuration items. The Documentation
Configuration Items were initially defined in the Configuration
Management Plan and Processes.
4 Review contract requirements regarding document repository tool and
logistics.
Requirements Document the requirements.
5 Define any processes and procedures that govern document management. Documentation
Processes and
Procedures
Document any processes and procedures that govern document
management.
6 Document process controls that can be used to validate that document
management requirements, and any processes and procedures that are
followed during the course of the project.
Process Controls Define the process controls.
7 Ensure any project documentation standards are used. Standards Document or reference any standards.
8 Define the process to assure that implementing team intellectual capital is
protected.
Intellectual
Capital
Protection
Process
Document or reference any processes.
9 Define the process to assure that client information protection policies are
followed.
Client Intellectual
Capital
Protection
Process
Document or reference any processes.
10 Design metrics to measure the effectiveness of the Document Management
plan.
Metrics Document the metrics.
#TOP #Top
11 Obtain key stakeholder agreement and approval on the Documentation
Management Plan.
Approved
Documentation
Management
Plan
Obtain any necessary sign-off or Approval Certificate.
12 Distribute and communicate the Documentation Management Plan. Documentation
Management
Plan
File the plan for easy reference.
Back to Top
APPROACH
If the project is using a software tool to manage and control project documentation, the tool may provide a comprehensive document index. If manual tracking is used the
project manager should create a documentation index or a work product tracking log that covers all documents that the project plans to produce.
Examples of common configuration items that should be covered by the Documentation Management Plan:
functional specifications
technical specifications
test cases and test results
any document considered a contractual deliverable
scope change requests
other change requests
acceptance certificates or client sign off documents
work product or deliverable documents
The Documentation Management Plan should define what is considered a baseline for any document that is a formal configuration item. A baseline implies that the
document is in a state that requires it to enter the process of formal configuration control. The Configuration Management Control Plan defines the change control
mechanisms that will be used to request changes and approve changes related to baselined configuration items.
The Documentation Management Plan should also discuss the retention of project documentation not considered formal configuration items. While these items may not
be subject to change control procedures, they represent important project artifacts and should be retained in the designated physical location or repository folder.
Examples of such items include:
team status reports
emails documenting key decisions or recommendations
management presentations
workshop material or presentations
checklists used to support processes
templates produced by the project that could be reusable
Project documentation represents a significant portion of the effort in any project. The project manager must design and document a process that:
tracks all documents that are expected to be produced
tracks the reasons why changes to baseline documents were required
tracks what changes have been made
It is very important that any change be traceable and that the effort associated with change be quantifiable.
The project documentation also represents a significant amount of intellectual capital. In cases when the primary document repository resides on a client-owned network
or in a client-owned repository, the project manager must design and implement an effective process to assure that a copy of all the implementing organization's
intellectual capital is stored and protected.
When creating the Documentation Management Plan, the project manager should:
Review contract requirements for any specific requirements related to the document repository or management process.
Review local requirements related to document management.
Identify and document requirements, processes, procedures and controls related to document management.
Establish and document the requirements that constitute a "baseline" for a document configuration item.
Identify and document what procedure will be followed to request changes to baselined versions of documents.
Identify and document what procedure will be followed to when changes to baselined versions of documents are authorized.
If the client will provide a third party software tool to manage the document repository, identify and document any process or procedures required to access the
tool. Identify any training that may be required for the project team and add the training effort to the Project Workplan.
If the project is using a third-party software tool, establish a process to move the implementing organization's intellectual capital to an appropriate repository
location.
Document naming standards to be followed. If manual version control will be used, create naming standards that support the version control effort.
Establish a control process to assure that all documentation is being checked in to the document library in the proper folders and that the document adheres to
naming conventions, version control requirements, etc. If a software tools is used, the tool itself may provide the required controls.
Establish a control process to assure that sensitive implementing organization information is secured and not maintained on client environment.
Establish a control process to assure that project documentation standards are used.
Document client requirements relating to information protection.
Establish and document the requirements that constitute a "baseline" for a document configuration item.
Identify and document what procedure will be followed when changes are required to baselined versions of documents.
Identify any client or project specific logos, heading or footing requirements that should be used when producing project documents.
For some projects, the project manager may elect to include additional documentation, such as status reports, meeting minutes, presentations or workshop materials
given to the client or other documents. It is recommended that any recommendation given to the client, particularly those relating to activities outside of the direct scope
in the project should be formally documented and included as a configuration item in the project documentation repository. Recommendations given informally via email
or other method may be "lost" by the client and if the recommendations relate to a topic that could impact client success, a history of having provided the recommendation
can be useful if an issue related to the recommendation arises.
Establishing Baselines
As with all configuration management terms there are number of definitions of the term "baseline". The IEEE Std. 610.12-1990, IEEE Standard Glossary of Software
Engineering Terminology defines baseline in two ways:
Baseline:
1. A specification or product that has been formally reviewed and agreed upon, thereafter serves as the basis for further development, and can be changed only
through formal change control procedures.
2. A document or a set of such documents formally designated and fixed at a specific time during the life cycle of a configuration item.
(IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (corrected edition). IEEE Standards Collection--Software Engineering, 1993
Edition, Institute of Electrical and Electronics Engineers, Inc., New York, 1993.)
The project manager needs to establish reasonable baselines related to document management that protect the implementing organization and the project from the risk
of lost work. If only "final" documents are loaded as in definition 1 above, the risk is that not all documents will be available if something unforeseen occurs. This could
be a small problem if the level of effort to produce the document was small, but for some project documents, the level of lost effort could be considerable. A second
definition of "baseline" similar to definition 2 above may be needed in order to define when a document should enter the document management process in a draft form.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level configuration management requirements that should be taken into
consideration when developing the detailed Documentation Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM030_DOCUMENTATION_MANAGEMENT_PLAN.DOC MS WORD
CM030_DOCUMENT_INDEX_WORD.DOC MS WORD (Former PJM 2.6.1 template)
CM030_DOCUMENT_INDEX_EXCEL.XLS MS EXCEL
CM030_DOCUMENT_UPDATE_NOTICE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.040 - CREATE AND EXECUTE SOFTWARE
CONFIGURATION MANAGEMENT PLAN
The creation and execution of the Software Configuration Management (SCM) Plan is located in the Project Execution and Control phase rather than the Start Up phase
because actual software configuration items are not usually produced during Start Up, and the Document Management Plan is considered a more immediate need in the
lifecycle of a project. However, the SCM Plan must be created early in the Project Execution and Control phase before any objects are altered or produced. The SCM
Plan defines the process and controls for software configuration management. The specific details of software configuration management are often tightly aligned to the
requirements of the software configuration management tool selected during the Start Up phase of the project.
The Software Configuration Plan should include:
Identify any training needed related to the specific Software Configuration Management tool(s) and reference to training material.
Identify and document who has responsibilities related to each software configuration management tool(s) and process.
Identify "baseline" requirements that apply to each software configuration management item or group of items.
Identify and document the procedure to be followed to request changes to baselined versions of SCM items.
Identify and document the procedure which will be followed when changes to baselined versions of SCM items are authorized.
Define the policies and procedures for check in and check out of each software configuration item using the selected tool.
Define the access policy for software configuration tools.
Include any references to project naming standards related to software configuration items.
Identify any coding standards related to the Software Configuration Management process.
The creation of the SCM Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout the Project Execution and Control
phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Software Configuration Management Plan - The Software Configuration Management (SCM) Plan defines the process and controls for software configuration
management.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify training and access requirements related to the
software configuration management tool.
Training and Access
Requirements
Document training and access requirements related to the
software configuration management tool.
2 Identify responsibilities related to SCM tools and processes. Roles and Responsibilities Document the roles and responsibilities.
3 Define procedures for establishing and changing baseline
software configuration management items.
Establish and Change SCM
Baselines Procedures
Document procedures for establishing and changing baseline
software configuration management items.
4 Define policies and procedures for check in and check out. Check In and Check Out
Procedures
Document policies and procedures for check in and check out.
5 Define naming and coding standards related to software
configuration items.
Naming and Coding Standards Document naming and coding standards related to software
configuration items.
6 Define any control processes that relate to software
configuration management.
Control Processes Document any control processes that relate to software
configuration management.
7 Obtain key stakeholder agreement and approval on the
Software Configuration Management Plan.
Approved Software
Configuration Management
Plan
Obtain any necessary sign-off or Approval Certificate.
8 Distribute and communicate the Software Configuration
Management Plan.
Software Configuration
Management Plan
File the plan for easy reference.
9 Execute the Software Configuration Management Plan.
Back to Top
APPROACH
Examples of Software configuration items include:
Source code for extensions and customizations
Reports
Database configuration or parameters
"Wrapper" installation scripts
"Gold instance" setups
Seed data
Application setups
The Software Configuration tool(s) and processes can be owned by the client, provided by Oracle, purchased by the client for the project, or an open source product.
There can be multiple tools used to track various configuration items. It is the project manager's responsibility to present a cohesive plan to the customer for managing
the many type of configuration items and to identify and document the responsibilities. It is recommended that the project manager assign the functional and technical
leads the responsibility of documenting the policies and procedures for managing software configuration. In the event the project is using client tools, any existing client
policies and procedures should be included in the Project Documentation library and communicated to the team through a training event or a workshop.
Enterprise Repository
If an Enterprise Repository is to be used for the project, make sure it is set up during this task. The enterprise may already have a repository or one may already have
been set up as part of an Envision engagement.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) acting in an
advisory capacity.
*
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance Implementation (ENV.GV.100) If an Enterprise Repository is to be used for the project, check and see if one has already been set up in as as part of
an Envision engagement. It would have been installed and governed as part of Governance Implementation.
Configuration Management Tools (CM.020) The Configuration Management Tools specifies the tools to be used to execute the Software Configuration
Management (SCM) Plan.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
SOA Service Lifecycle Use this technique for guidance on how version control should be set up for services and dependent components.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM040_SOFTWARE_CONFIGURATION_MANAGEMENT_PLAN.DOC MS WORD
Tool Comments
Oracle Enterprise Repository The Oracle Enterprise Repository is a COTS Enterprise Repository tool solution that is used to establish and
maintain an Enterprise Repository.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.050 - CREATE AND EXECUTE SOFTWARE RELEASE
MANAGEMENT PLAN
A software release refers to the creation and availability of a new version of computer software product or a group of configuration items.
Release planning is the activity of determining a feasible combination of dates, features, components and resourcing for the next release of an existing software product.
The creation and execution of the Software Release Management governs the process used to assemble the components of a software release and the process used to
distribute the changes or the changed system to those people using it. It describes the contract between the project software development team, the project manager
(who coordinates the plan on behalf of the business), and the client project team.
A software release is composed of a collection of configuration items that may include:
Source code for extensions and customizations
Reports
Database configurations
"Wrapper" installation scripts
"Gold instance" setups
Seed data
Application setups
Release notes
Functional and Technical specifications related to the components of the release
The specific requirements of creating a software release may be tightly tied to the configuration management tools in use by the project.
Responsibilities of the project manager are:
Determine and document a policy for iterative software releases including milestones, time scales and supporting techniques to be employed.
Develop procedures and processes for software releases including any forms and tracking tools being used for the process.
Determine responsibilities for team members in the software release process.
Communicate to the client and project team the policies and procedures for software releases and gain their agreement.
Establish metrics that can be used to measure the effectiveness of the software release process.
Monitor that the work performed adheres to procedures for release management and migration.
The creation of the Software Release Management Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout the
Project Execution and Control phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Software Release Management Plan - The Software Release Management Plan documents the process used to assemble the components of a software release and
the process used to distribute the changes or the changed system to those people using it. It describes the contract between the project software development team, the
project manager (who coordinates the plan on behalf of the business), and the client project team.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define a policy for software releases . Software Release Policy Document the policy for software releases.
2 Create or obtain and software release forms. Software Release Forms Document or reference the forms.
3 Define procedures and processes for software releases including
any forms and tracking tools being used for the process.
Tracking Tools
Procedures and
Processes
Document procedures and processes for software releases including
any forms and tracking tools being used for the process.
4 Define responsibilities for team members in the software release
process.
Roles and
Responsibilities
Document the roles and responsibilities.
5 Establish metrics to measure the effectiveness of the software
release process.
Metrics Document the metrics
6 Obtain key stakeholder agreement and approval on the Software
Release Management Plan.
Approved Software
Release Management
Plan
Obtain any necessary sign-off or Approval Certificate.
7 Distribute and communicate the Software Release Management
Plan.
Software Release
Management Plan
File the plan for easy reference.
8 Execute the Software Configuration Management Plan. Make sure work performed adheres to procedures for release
management and migration.
Back to Top
APPROACH
Software release management is the responsibility of the project manager with the assistance of the technical and functional lead, the client project manager and the
configuration manager (if the project has someone in that role). It is recommended that the software configuration management tool selected for the project provide the
capabilities to build and manage software configuration releases. If such capabilities are not available, the project manager should evaluate the effort to support the
release process and potentially add resources. For large projects, or projects with numerous custom objects, tracking the release manually using a spreadsheet or other
paper based tool can require considerable effort.
SOA Release Planning Considerations
If the project is part of a wider service-oriented architecture (SOA) strategy, the Software Release Management Plan should contain SOA services that may be required by
other projects or may be dependant on other projects to provide SOA services. Because SOA increases the interdependencies across projects and even to some extent
within a project, software release planning in SOA projects is slightly more complex. If you are in on SOA project that is part of a wider SOA initiative, please refer to the
SOA Release Planning Technique for more details.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Client Project Sponsor *
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) acting in an
advisory capacity.
*
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes
(CM.010)
The Configuration Management Plan and Processes identifies the software configuration items that will be
produced and managed by the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
SOA Release Planning For SOA engagements, this technique defines leading practices for SOA release planning.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM050_SOFTWARE_RELEASE_MANAGEMENT_PLAN.DOC MS WORD
CM050_RELEASE_NOTE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.060 - CREATE AND EXECUTE ENVIRONMENT AND PATCH
MANAGEMENT PLAN
The Environment and Patch Management Plan defines the requirements, processes and procedures that govern environment and patch management for the project.
The Environment and Patch Management Plan should :
Define the technical environments that are required to support the project implementation and document their intended purpose. Identify the users that will be using
the environment. Identify the timeline for establishment of each project environment. Identify the timeline for decommissioning of each project environment.
Document the source of data for each environment. Define the access policies related to each environment. Document the "flow of control" as it relates to the
application of patches and software releases that are applied to each environment. Document the policies, processes and procedures to required to manage
configuration changes to the environments such as applying patches. Document the tools and techniques to manage the environments (creation, refreshing,
backup, patching, etc.).
Document the tools and techniques to monitor the status of the environments.
All environments should serve a specific purpose (development, test, quality assurance, production, etc.) and some have a limited life span. The Environment and Patch
Management Plan should document the processes required to create a new environment and to refresh an existing environment by cloning from another environment.
The plan should also specify the change control procedures that govern the application of patches. Application of patches may be mandatory to fix problems of an urgent
nature. Emergency and escalation procedures should be documented in Environment and Patch Management plan to permit the project team to react appropriately if the
need arises.
The creation of the Environment and Patch Management Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout
the Project Execution and Control phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Environment and Patch Management Plan - The Environment and Patch Management Plan documents the requirements, processes and procedures that govern
environment and patch management for the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define the strategy for environment and patch management. Strategy Document the strategy, objectives and key principles.
2 Define the project environments. Project Environments Document the various environments that will be used on the project
(for example, production, test, training, etc.).
3 Define the access policies related to each environment. Access Policies Document the access policies related to each environment.
4 Define the procedures to create, clone, and backup
environments.
Environment Procedures Document the procedures to create, clone, maintain and backup
environments.
5 Define any implementation environment hardware
requirements.
Implementation Environment
Hardware Requirements
Document any implementation environment hardware requirements.
6 Identify the tools and techniques for managing and
monitoring environments.
Environment Tools and
Techniques
Document the tools and techniques for managing and monitoring
environments.
7 Define policies and procedures for managing patches. Patch Management Procedures Document policies and procedures for managing patches.
8 Identify the tools and techniques for applying patches. Patch Tools and Techniques Document the tools and techniques for applying patches.
9 Define the responsibilities related to testing patches. Roles and Responsibilities Document the roles and responsibilities.
10 Obtain key stakeholder agreement and approval on the
Environment and Patch Management Plan.
Approved Environment and
Patch Management Plan
Obtain any necessary sign-off or Approval Certificate.
11 Distribute and communicate the Environment and Patch
Management Plan.
Environment and Patch
Management Plan
File the plan for easy reference.
12 Execute the Environment and Patch Management Plan. Execute the Environment and Patch Management Plan as defined
by the Project Workplan.
13 Monitor the Environment and Patch Management
processes.
Take corrective action as necessary.
Back to Top
APPROACH
Environment and patch management is the responsibility of the technical lead for the project. If this is client owned, the project manager is required to document or post
the appropriate documents provided by the client to the project teams documentation library. The technical lead should consider using tools that are available to monitor
the status of the environments.
The technical team will commonly receive patches that fix particular problems or add certain functionality. The functional team or business user may request a patch that
adds additional functionality. Before applying a patches, the projects change control process should be used to evaluate risk, financial impact and schedule impact. It is
recommended that a patch environment is set up to "test" the patch before introducing the patch to a working environment. The Environment and Patch Management
Plan includes the following for patches:
policies and procedures for applying software patches
tools and techniques for applying software patches
references to the the Projects Change Management Process
tools and techniques for monitoring the configuration of the environment
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
5
Project Manager Review and approve the Environment and Patch Management Plan. Depending on your project, you may have a designated
configuration manager in this role that reports to the project manager.
15
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) designated to develop and
monitor the Environment and Patch Management Plan.
50
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) designated to
develop and monitor the Environment and Patch Management Plan.
30
Client Project Sponsor *
Client Project Manager Review and approve the Environment and Patch Management Plan. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes (CM.010)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM060_ENVIRONMENT_AND_PATCH_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.070 - CREATE AND EXECUTE THE CONFIGURATION
CONTROL PLAN
The Configuration Management Control Plan defines the control mechanisms that govern the Configuration Management process for the project. This task includes
defining the controls, identifying the team members responsible for executing the controls, documenting the controls and executing those controls as required throughout
the project lifecycle.
Examples of Configuration Management control include:
Processes to log, prioritize and categorize, and track change requests
Process to review and approve change requests
Process to schedule approved changes
Process to validate patches applied to appropriate environments
Process to audit that application configuration documentation matches actual environment configuration
Process to schedule, implement and validate software releases
Process to roll back unsuccessful changes and recover to a prior baseline
The creation of the Configuration Control Management Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout the
Project Execution and Control phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Configuration Management Control Plan - The Configuration Management Control Plan documents the control mechanisms that govern the Configuration Management
process for the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Prepare an introductory overview. Introduction Provide introductory remarks.
2 Define Configuration Management control processes. Configuration Management
Control Processes
Document and describe the various CM processes.
3 Define and document configuration control metrics. Metrics Document configuration control metrics.
4 Identify tools and techniques to manage metrics. Tools and Techniques Document tools and techniques to manage metrics.
5 Define policies and procedures to control the identified
configuration items.
Configuration Items Policies
and Procedures
Document policies and procedures to control the identified configuration
items.
6 Define intersection points between Configuration
Management and other processes.
Intersection Points Document intersection points between Configuration Management and
other processes, particular Quality Management.
7 Define the responsibilities. Roles and Responsibilities Document the roles and responsibilities.
8 Obtain key stakeholder agreement and approval on the
Configuration Management Control Plan.
Approved Configuration
Management Control Plan
Obtain any necessary sign-off or Approval Certificate.
9 Distribute and communicate the Configuration
Management Control Plan.
Configuration Management
Control Plan
File the plan for easy reference.
10 Execute the Configuration Management Control Plan.
Back to Top
APPROACH
Controlling Configuration Management is a responsibility that is shared by the technical and functional leads. If the client has an established Configuration Management
group, they may be assigned the responsibility for Configuration Management control and the project may elect to leverage client processes that are already established.
If Configuration Management tools are in use, the tools may automate a number of the required controls, which eases the burden on the project team. What ever means
of controls are select, the project manager must design the controls in such a way to reduce project risk, while avoiding processes that are difficult to manage or
administer. If using processes already established by the client, the project manager should review those processes for any potential impact to the project work plan.
In addition to defining the processes for configuration management control, the Configuration Management Control Plan should also document the intersection points
between Configuration Management and other processes, particularly the Quality Management process. The creation of configuration items, including documents,
software and other artifacts should include specific quality inspections and reviews defined by the Quality Management process. The project manager should document
when Quality Management process tasks will occur for items under Configuration Management control. Examples include when code reviews will take, what levels of
testing are required to approve and promote a new software release, etc.
Specific control mechanisms vary depending on the project size, complexity and availability of configuration management tools. Some projects may establish a Change
Control Board, a group of individuals representing the various project teams, who review and approve all or a subset of changes. Some projects may have tools uses
workflow's to process and track changes and approvals. Some project may have dedicated code review teams, while others institute a peer review process. The
Configuration Management Control plan should document the specific control mechanisms planned and the parties responsible for implementing those controls.
Metrics
Metrics related to Configuration Management play an important role in Configuration Management control. Establishment of appropriate metrics helps the project
manager audit the Configuration Management process and identify areas of improvement. Metrics should also support the Configuration Management audit trail. Specific
metrics should be established based on the particular project requirements but common example metrics include:
number of configuration items by type status (how many source code objects checked in, how many patches applied, how many documented checked in)
number of configuration items that required updates after initial approval
number of change requests
number of approved changes
number of source code packages contained in a particular system release
time related statistics (how long from patch request to patch application, how long to update a particular item, etc., how long to obtain approvals, etc.)
Choose metrics that can be collected using the processes and procedures defined. If Configuration Management tools are in use or planned, the tool will often produce a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Produce and execute the Configuration Management Control Plan. Depending on your project, you may have a designated
configuration manager in this role that reports to the project manager. If so, the project manager would review and approve the
Configuration Management Control Plan.
85
Client Project Sponsor *
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) acting in an
advisory capacity.
*
Client Project Manager Review and Approve the Configuration Management Control Plan. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and
Processes (CM.010)
The Configuration Management Plan and Processes identifies the various configuration items that will be produced
and managed by the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM070_CONFIGURATION_MANAGEMENT_CONTROL_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.080 - CLOSE CONFIGURATION MANAGEMENT
During Project Closure, the project manager is responsible for closing out Configuration Management. This includes the following responsibilities:
Record and Document a current version of documentation, code, release, patches, and environments. It is a leading practice for projects to using a repository for
documentation or software configuration items.
If the project is using a repository for documentation or software configuration items, validate that copies of all final items that are Intellectual Capital are placed in
the project repository in the appropriate folders.
Validate that any sensitive material is removed from client environments, networks, PCs or other storage areas.
If appropriate, capture electronically hard-copy acceptance certificates and upload into the final project repository.
Finalize the archive of all project work products (hard copy and disks) according to policy requirements.
Document Configuration Management Lessons Learned
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Configuration Management
The Closed Configuration Management work product consists of the following components:
Finalized Documentation of Configuration Items
Project Work Products Archive
Configuration Management Lessons Learned Report
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Record current version of documentation and configuration items. Finalized Documentation of
Configuration Items
Document current version of documentation and
configuration items.
2 Finalize the archive of all project work products. Project Work Products
Archive
3 Remove all sensitive material from client environment. None
4 Create electronic images of all hard copy acceptance certificates and store
in the appropriate project Documentation Repository.
Project Work Products
Archive
5 Document any lessons learned. Configuration Management
Lessons Learned
This report is used to create the Lessons Learned report
produced in the Communication process.
Back to Top
APPROACH
All work products produced by the project should be retained in electronic format. If the project manager has hard copy of acceptance certification copies, electronic
copies should be created and stored in the appropriate Documentation Repository. Certificates can be scanned, or the project manager could fax them to himself and use
the .tif files created. If appropriate, all sensitive materials should be removed from the client environment.
Configuration Management Lessons Learned can be a separate document or used as part of the overall lessons learned document produced in the Communication
process.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
5
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 45
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) providing needed technical
information.
50
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes
(CM.010)
Documentation Management Plan (CM.030)
Software Configuration Management (SCM) Plan
(CM.040)
Software Release Management Plan (CM.050)
Environment and Patch Management Plan (CM.060)
Configuration Management Control Plan (CM.070)
Use these work products to identify any procedures for versioning and closing out each specific configuration
item type.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM080_CONFIGURATION_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[IFM] INFRASTRUCTURE MANAGEMENT
Infrastructure Management involves identifying and documenting requirements, planning and managing the components of the project infrastructure. The project
infrastructure has two main components:
the Team Work Environment
the Established Technical Infrastructure
The Team Work Environment includes those technical components that support the project team directly while the Established Technical Infrastructure environment is
composed of the hardware and software components that comprise and support the application environments planned for the project.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for establishing a stable and productive infrastructure to effectively manage and execute the project.
There are three Infrastructure Management tasks that occur during the Project Start Up phase:
Develop Infrastructure Management Plan
Establish Team Work Environment
Establish Technical Infrastructure
At the start of a project, the team requires PCs, printers, network access, user IDs to client systems, messaging, phone system access, VPN, office space and meeting
room space to work effectively. These requirements should be documented in the Project Management Framework and the project manager can use that as a starting
point to document the the Infrastructure Management Plan and Team Work Environment. The project manager should review the requirements and update any
requirements that were omitted or changed since the contract was executed.
If issues arise that prevent the project manager from obtaining appropriate work space or other project team infrastructure components, the project manager must move
quickly to resolve the issue and escalate, if necessary. For large projects or projects that are composed of virtual team members, lack of an effective or adequate Team
Work Environment can quickly become a critical path item that impedes project progress.
The project manager should establish and document the expected service levels related to the Established Technical Infrastructure, such as system availability and
backup requirements. Particular attention should be paid to availability requirements or service levels that apply to the development and test environments. For example,
if the project includes Global Blended Delivery, then system availability should be 24 by 7 to support development activities occurring in different time zones.
The project manager should also identify and document any required additional software, such as system management tools, system monitoring tools, backup and
archiving tools, testing tools, configuration management software, etc. (and servers to support them) that are stated or implied by the project scope. The detailed
requirements, architecture and deployment of these items should be covered by the Technical Architecture process. The Infrastructure Management plan should be
limited to identification and documentation of the high-level requirements and refer to the tasks in the execution method (Technical Architecture process) for the details.
Project Execution and Control Phase
During Project Execution and Control, the project manager monitors the Team Work Environment and the Established Technical Infrastructure and takes any corrective
action needed to assure that they are maintained at an acceptable level to support project activities.
If the project scope assigns partial or full responsibility for the implementation of the technical architecture to client personnel or third parties, the project manager should
detail who is responsible for each task in the Technical Architecture process and describe how the parties responsible will coordinate with the larger project team. Items
such as workplan activities, milestones, metrics, status, etc. should be described to avoid communication problems or issues during the project execution.
Metrics
Establishment of appropriate metrics helps the project manager track and monitor the effectiveness of the Infrastructure Management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during Project Execution and Control. Specific metrics should be established based on the
particular project requirements but common metric examples include:
Outputs from monitoring the Established Technical Infrastructure (CPU utilization, database statistics, network performance, etc.)
Performance against service-level requirements (how long does it take to establish a new environment once requested.)
Lost-time metric (amount of project development time lost due to unplanned outages)
Lead-time requirements (how long does it take to get a new team member's work environment set up, user ids established, etc.)
Choose metrics that can be collected using the processes and procedures defined. If infrastructure management tools are used or planned, the tools often produce a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual. Identification of metrics as early as possible allows the project manager to have effective measurements to manage infrastructure, permit
earlier identification of issues or problems, and in the event that significant infrastructure issues arise, quantify the impact of those issues on the project timeline.
Project Closure Phase
The project manager must document and turn over the Team Work Environment and Established Technical Infrastructure to the client. Items representing Oracle
intellectual capital, project work in progress or consultant materials, not to be provided to the client, must be removed from client infrastructure and archived as described
in the Configuration Management process. Any client owned assets that were provided to the project team should be inventoried and returned. Consultant access to
client systems should be revoked.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS IFM.010 Develop Infrastructure Management Plan Infrastructure Management Plan Core
PS IFM.020 Establish Team Work Environment Team Work Environment Core
PS IFM.030 Establish Technical Infrastructure Established Technical Infrastructure Core
Project Execution and Control
PEC IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Core
Project Closure
PC IFM.050 Close Infrastructure Closed Infrastructure Core
Back to Top
OBJECTIVES
The objectives of the Infrastructure Management process are:
identify, document and implement the requirements, processes, procedures and controls pertaining to the Team Work Environment and the Established Technical
Infrastructure.
Provide a stable and effective infrastructure to support the project objectives and timeline.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Technical
Lead
This role is filled by a technical project team member (for example, developer, designer, system architect) acting in an advisory capacity.
Client (User)
CPS Client
Project
Sponsor
CPM Client
Project
Manager
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.010 - DEVELOP INFRASTRUCTURE MANAGEMENT PLAN
Infrastructure Management involves identifying, planning and managing the components of the project infrastructure. The project infrastructure has two main
components, the team work environment and the technical infrastructure environment.
The team work environment includes the technical components that support the project team. Examples include:
PCs
phones, pagers, beepers
printers, fax machines, copiers
VPN access into the client site
VPN access into the Oracle network
access to client networks
access to shared drives, 3rd party software tools etc.
consultant workspace, conference rooms
When specifying project software to be used, include the specific software and versions required.
The project manager is responsible for documenting the requirements, process and procedures related to the team work environment, while the client project manager is
typically responsible for acquiring the actual physical resources. The client project manager should supply any client specific processes to be followed to obtain access,
user ids, equipment, and workspace needed by the project team.
The requirements, processes, procedures and controls that apply to the team work environment should be fully documented in the Infrastructure Management plan.
The technical infrastructure environment includes the hardware and software components related to the project application environments. Examples include:
Servers
Network
IO subsystems
Third-party software tools
It is assumed that the project will follow an execution method that includes a comprehensive Technical Architecture process. In the Infrastructure Management process,
the project manager should identify and document the high level requirements needed to support the project technical infrastructure and environments. Examples of
these requirements include:
identified business requirements related to production performance or availability
implied requirements for the development and test environments related to the production environment (if RAC or GRID is planned, at least some of the
development or test environments will have to be RAC or GRID)
implied requirements for additional third party software tools (if performance testing is in scope, an automated testing tool may be required)
availability requirements for instances (if Global Blended Delivery 24/7 support may be needed)
backup requirements for development and test environments
service level agreements related to cloning environments, restoring from backups, application and patches, etc.
service level agreements related to the support of an infrastructure hosting provider
In the event that some or all of the technical infrastructure tasks are the responsibility of a client or third party, the project manager should document who has
responsibility for each task, what work products will be produced, how status will be communicated and how coordination between the parties will take place. When work
is being done by a separate project team, the project manager should document how activities will be monitored and tracked in the Project Workplan.
The Infrastructure Management Plan is the framework for the project manager to identify and document the requirements needed to establish a technical infrastructure
environment that is stable and meets the project implementation requirements. Detailed technical requirements, processes and procedures related specifically to the
technical infrastructure environment are documented and executed following the execution method that has been chosen for the project implementation.
The Infrastructure Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Infrastructure Management Plan - The Infrastructure Management Plan documents the requirements needed to establish a technical infrastructure environment that is
stable and meets the project implementation requirements.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Provide an introduction. Introduction Document introductory remarks.
2 Identify team work environment requirements. Team Work Environment
Requirements
Document team work environment
requirements.
3 Define the team work environment processes, procedures and controls. Team Work Environment
Processes, Procedures and
Controls
Document the processes, procedures and
controls.
4 Identify high level technical infrastructure requirements and service levels. Technical Infrastructure
Requirements and Service Levels
Document high level technical
infrastructure requirements and service
levels.
5 Define high level technical infrastructure processes, procedures and controls. Technical Infrastructure
Processes, Procedures and
Controls
Document the processes, procedures and
controls.
6 Determine the responsibilities for establishing the technical infrastructure
environment Refer to Technical Infrastructure execution tasks for details.
Roles and Responsibilities Document the roles and responsibilities.
7 Establish infrastructure management metrics. Metrics Document the metrics.
8 Obtain key stakeholder agreement and approval on the Infrastructure Management
Plan.
Approved Infrastructure
Management Plan
Obtain any necessary sign-off or Approval
Certificate.
9 Distribute and communicate the Infrastructure Management Plan. Infrastructure Management Plan File the plan for easy reference.
Back to Top
APPROACH
At the start of a project, the team requires PCs, printers, network access, user ids to client systems, messaging, phone system access, VPN, office space and meeting
room space to work effectively. In the event that the project has a requirement for beepers, pagers, or special cell phones, this should be documented. These
requirements should be documented in the proposal or contract and the project manager should review those documents to determine if any requirements were omitted
or have changed and document them in the Infrastructure Management Plan. Any client processes or procedures that are required when consultants join the project
(forms to be filled out, individuals to be notified, etc.) should be documented.
If issues arise that prevent the project manager from obtaining appropriate work space or other project team infrastructure components, the project manager must move
quickly to resolve the issue and escalate if necessary. For large projects or projects that are composed of virtual team members, lack of an effective or adequate team
work environment can quickly become a critical path item that impedes project progress.
The project manager should establish and document the expected service level agreement that pertains to the Technical Architecture components of the technical
infrastructure environment such as system availability and backup requirements. Particular focus should be on the service levels required for the development and test
environments needed to support the project timeline and staffing plan. For example, if the project includes a Global Blended Delivery component, then system availability
should be 24 by 7 to support development activities occurring in different time zones.
The Project Manager should also identify and document any requirement for items such as system management tools, system monitoring tools, backup and archiving
tools, testing tools, configuration management software, etc. (and servers to support them) that are stated or implied by the project scope. The detailed requirements,
architecture and deployment of these items should be covered by the execution method Technical Architecture process. The Infrastructure Management Plan should be
limited to identification and documentation of the high level requirements and refer to the tasks in the execution method for the details.
As a general rule, while high level conceptual architecture can be included to enhance understanding, the project manager should avoid including detailed descriptions of
the planned technical architecture and refer instead to the associated execution method tasks. If the Project Workplan calls for an initial CRP environment that is needed
immediately on Project Start Up and is being provided by a hosting service, the Infrastructure Management Plan should refer to the documentation that establishes that
environment. The project manager may include a list of technical environments planned for the project, but specific environment details (how many instances will be
required, time frames, cloning procedures, etc.) should be defined in the Environment and Patch Management Plan produced in the Configuration Management process
as those requirements tend to evolve during the course of the Execution and Control phase.
Metrics
Establishment of appropriate metrics help the project manager track and monitor the effectiveness of the Infrastructure Management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during the execution phase. Specific metrics should be established based on the particular
project requirements but common example metrics include:
Outputs from monitoring the Technical Infrastructure (CPU utilization, database statistics, network performance, etc.)
Performance against service level requirements (how long does it take to establish a new environment once requested)
Lost time metrics (amount of project development time lost due to unplanned outages, missed maintenance windows, etc.)
Lead time requirements (how long does it take to get a new team member's work environment set up, user ids established, etc.)
Choose metrics that can be collected using the processes and procedures defined. If Infrastructure Management tools are in use or planned, the tools often produce a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual. Early identification of metrics allows the project manager to have effective measurements to manage infrastructure, permits identification
of issues or problems, and in the event that significant infrastructure issues arise, help to quantify the impact of those issues on the project timeline.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Create the Infrastructure Management Plan. 85
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) that provides advisory
assistance in the creation of the Infrastructure Management Plan.
*
Client Project Manager Identify client-specific procedures and requirements for access, etc. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Infrastructure Management requirements that should be taken into
consideration when developing the detailed Infrastructure Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IFM010_INFRASTRUCTURE_MANAGEMENT_PLAN.DOC MS WORD
IFM010_INSTALLATION_AND_RECORD.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.020 - ESTABLISH TEAM WORK ENVIRONMENT
Based on the requirements, processes, procedures and controls documented in the Infrastructure Management Plan, establish the project Team Work Environment. This
includes:
Establish appropriate technology infrastructure. This typically includes phones, PCs, laptops, printers, network access, email, voice mail and security access.
Establish software requirements, for example team members should have laptops configured with any required software. The project manager should specify the
expected version of software required and if specific software is required for specific roles.
Provide access to conference rooms and training facilities and understand how to reserve those facilities.
Establish a project room command center if needed.
Create a structure, both physical (file cabinets) and computer-based (Directory Structure) to post all project documentation in accordance with project
requirements.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Team Work Environment
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Establish the Team Work Environment. Team Work
Environment
Establish the Team Work Environment per the requirements
defined in the Infrastructure Management Plan.
2 Examine expected staffing levels and project requirements over the project
lifecycle that could impact the Team Work Environment.
3 Adjust the Team Work Environment over time if changes to the project require it
and notify the client project manager.
4 Monitor the metrics relating to Team Work Environment and make corrections
as necessary.
Back to Top
APPROACH
If project roles requires team members to be proficient with software tools, this should be identified as part of the requirements for the position. If team members are
required to have laptops with tools that have additional license costs, this should also be identified as part of the requirements for the position.
For large project, monitor the effectiveness of the Team Work Environment. The contract may have specified that the client provide "adequate" workspace, and if there
are issues or problems that prevent the team from working productively, the project manager must address them before they impact the project.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Infrastructure
Management Plan
(IFM.010)
The Infrastructure Management Plan documents the requirements needed to establish a technical infrastructure environment that is stable and
meets the project implementation requirements. It specifically provides the details for the Team Work Environment.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.030 - ESTABLISH TECHNICAL INFRASTRUCTURE
Based on the requirements, processes, procedures and controls documented in the Infrastructure Management Plan, establish the project Technical Infrastructure. This
includes:
Oversee the installation and configuration of the project technical infrastructure environments, including hardware, software and application software.
Oversee the implementation of the project support infrastructure and system management tools including but not limited to backup, recovery, and archiving.
Begin procurement process for any additional third party software tools required.
Track the execution of these tasks against the time lines specified in the Project Workplan.
If client or third parties are responsible for some or all of the Technical Infrastructure tasks, begin coordination process documented in the Infrastructure
Management Plan.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Established Technical Infrastructure
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Install and configure project technical environments. Project Technical Environments
2 Implement project support infrastructure and system management tools. Project Support Infrastructure and System Management Tools
3 Begin Procurement of any software required by project.
Back to Top
APPROACH
The project manager should make sure that the requirements related to the Technical Infrastructure are driven by the needs of the project, not the constraints of the
client, particularly as they relate to the service levels, management and maintenance of the development and test environments.
Clients sometimes wish to limit access to hardware or other components of the Technical Infrastructure due to resource or budget constraints. The project manager must
work with the client to help them understand how the requirements relate to the objectives of the project, what risks are involved if the requirements are not met and to
assure that a stable and adequate technical infrastructure is available.
The execution of these tasks are primarily the responsibility of the technical lead.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Infrastructure
Management Plan
(IFM.010)
The Infrastructure Management Plan documents the requirements needed to establish a technical infrastructure environment that is stable and
meets the project implementation requirements. It specifically provides the details for the Technical Infrastructure.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IFM030_PHYSICAL_RESOURCE_PLAN.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.040 - MANAGE AND MAINTAIN INFRASTRUCTURE
In this task, monitor Infrastructure Management activities using the processes, procedures, controls and metrics defined in the Infrastructure Management Plan.
Examples include:
Ensure that all necessary software patches and hardware upgrades are applied in support of planned project activities.
Ensure that operational activities are occurring on a regular basis (e.g. backup, recovery, archiving, etc.).
Ensure that service levels are being met - especially infrastructure support service levels.
Report any issues or problems using established reporting procedures.
Ensure corrective action is taken.
Monitor effectiveness of corrective action.
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MMI Manage and Maintain Infrastructure
Back to Top
WORK PRODUCT
Maintained Infrastructure
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Monitor infrastructure management activities using the metrics defined in the Infrastructure Management
Plan.
Metric Reports
2 Report any issues or problems using establish reporting procedures. Issue, Problem Log
Updates
3 Ensure corrective action is taken. Issue, Problem Log
Updates
4 Monitor effectiveness of corrective action. Metric Reports
Back to Top
APPROACH
The project manager is responsible for monitoring the metrics related to Infrastructure Management and reporting them to the project leadership. If the project manager
identifies any any issues or problems such as missed failure to apply patches as scheduled, backups not taken on schedule, etc., an issue or problem should be logged
using the appropriate procedure. The technical lead is responsible for the collection of base metrics, identification of suggested resolutions to issues or problems
encountered and ensuring that corrective actions are appropriately implemented.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Infrastructure Management Plan
(IFM.010)
The Infrastructure Management Plan documents the processes, procedures and controls for managing the infrastructure
during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IFM040_EQUIPMENT_FAULT_RECORD.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.050 - CLOSE INFRASTRUCTURE
During Project Closure, the project manager is responsible for closing out Infrastructure Management. This includes the following responsibilities:
Perform final backup and archive of technical environment.
Remove all Oracle confidential information from client environment.
Turn over and document technical environment to client.
Revoke all access to client systems from Project Team Members.
Inventory and return any client owned assets, including software, supplies, office equipment, etc.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Infrastructure
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Perform final backup. Technical Environment Archive
2 Remove all Oracle confidential information. None
3 Turn over and document technical environment. Technical Environment Documentation
4 Revoke all access to client systems for project team members. Revoke Access
5 Inventory and return any client-owned assets. Return of Assets
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[PCM] PROCUREMENT MANAGEMENT
The Procurement Management process is focused on the following procurement tasks:
documenting the Procurement Strategy and Process
procuring any required goods and contracted services
managing the procurement of goods and services
The Procurement Strategy and Process determines whether to take a make-or-buy decision. It includes finding skilled people for the project (from the local office, from
the global company or external people to the company).
Procuring goods and services includes finding and deciding on one or more suppliers from the source above. Procuring contracted services includes setting up the
necessary contracts (i.e., contract administration).
The tasks above are normally managed by different roles in the organization.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
Typically, the project manager does not get involved in procurement activities except for acquiring human resources from outside firms (for example, Contract Service
Providers (CSPs)). Sub-contracted resources provide staff augmentation to the Oracle team. Normally, we use a CSP resource when qualified internal resources are
unavailable or to achieve a lower cost for our client. CSP firms have contracts with Oracle that include approved terms and conditions and pre-determined billing rates.
These agreements have been negotiated centrally by Oracle Consulting and should extend to all Oracle projects.
During Project Start Up, the project manager is responsible for documenting any procurement functions on the project in the Procurement Strategy and Process. This
includes documenting the roles and requirements of the procurement function and obtaining agreements from the key stakeholders.
Once the Financial Management Plan is in place, the project manager ensures that the procurement analyst(s) and buyer(s) understand the projects requirements for
subcontractors, hardware, network, application software configuration(s), etc.
Key aspects of procurement management are:
Analyzing requirements, negotiating and selecting suppliers (goods and/or services)
Ensuring scheduled deliveries
Project Execution and Control Phase
Following the Procurement Strategy and Process developed in the Project Start Up phase, the project manager is responsible for tracking, controlling and reporting on the
procurement status and expenditures.
Project Closure Phase
During Project Closure, the project manager is responsible for reconciling and closing out all open project procurement expenditures and providing a final planned versus
actual report.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS PCM.010 Develop Procurement Strategy and Process Procurement Strategy and Process Y Core
PS PCM.020 Procure Goods and Contracted Services Service Orders Core
Project Execution and Control
PEC PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Y Core
Project Closure
PC PCM.040 Close Contract Closed Contract Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.010 - DEVELOP PROCUREMENT STRATEGY AND
PROCESS
Develop, document, and communicate the Procurement Strategy and Process. This may include the processes supporting the necessary procurement of goods and/or
services to support the project objectives. The Procurement Strategy and Process is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Procurement Strategy and Process - The Procurement Strategy and Process documents the strategy and processes for supporting the necessary procurement of
goods and/or services to support the project objectives.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify procurement requirements. Procurement
Requirements
Document procurement requirements, such as:
Baseline hardware (along with an upgrade plan)
Network topology and scalability requirements
Third party software requirements
Subcontractor/services requirements
Project facilities
Off-site meeting facilities
Audio visual
2 Negotiate and establish a budget in support of agreed
upon purchasing requirements.
Purchasing Budget The budget should reflect the agreed upon categories and should be integrated
as part of the overall financial management process.
3 Define the procurement process. Procurement Process Document the procurement process from requisition to receipt of goods and
payment of invoice, including but not limited to:
Who purchases what (Oracle or the client)
Policies and procedures for rebilling purchases back to the client when
appropriate
Approval levels and lead times
Account numbers to be used for reporting purchases.
Rules pertaining to capital versus expense procurement
Situations when and how competitive bids must be obtained
Preferred vendor lists
Use of minority firms
4 Obtain key stakeholder agreement and approval on
the Procurement Strategy and Process.
Approved Procurement
Strategy and Process
Obtain any necessary sign-off or Approval Certificate.
5 Distribute and communicate the Procurement Strategy
and Process.
Procurement Strategy and
Process
File the plan for easy reference.
Back to Top
APPROACH
Considerations for Contracted Service Provider (CSP) Requirements: To make sure you get the exact skills you want, make sure you spell them out. Never assume that
everyone with particular skill also has an associated skill. Specify your expectations about the minimum experience (e.g., number of years, number of implementations)
required to be successful. Some requirements may be objective (must have successfully completed a specific course) or subjective (must have advanced knowledge
and experience with a given application). Every detail you add will help to communicate your needs to the CSP community and reduce the number of unqualified
candidates they propose.
Note: To maximize economies of scale and ensure that supplier lead times are honored, define procurement requirements as early in the project lifecycle as possible.
Note: It is also important that all procurement requirements are understood early to ensure timely delivery (and if necessary, installation and shake down) in order to
support critical project activities. Key dates and dependencies should be represented on the Project Workplan.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Procurement Management requirements that should be taken into
consideration when developing the Procurement Strategy and Process.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
PCM010_PROCUREMENT_STRATEGY_AND_PROCESS.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.020 - PROCURE GOODS AND CONTRACTED SERVICES
Procure goods and contracted services as they would apply to the project. The contracted services could include Oracle services or services from other sub-contracting
firms. The goods could include servers, other computer and telecommunications hardware, facilities, etc.
Care should be taken to confirm the correct approval levels and authorities when entering into a contract. The project manager should confirm and follow the appropriate
procedures for the given organization.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Service Orders
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop service orders for goods
and contracted services.
Prepare a description for the
service order.
Prepared
Service
Order
The Service Order description should contain enough detail to allow the potential suppliers to clearly understand
what you want them to accomplish. Keep in mind that your work description will be sent to service providers, so
avoid including sensitive information, like contract value and customer name. Constraints and assumptions should
be included as well.
Here is a short checklist of additional things to include in the service order:
description of what is out of scope when necessary for clarification
start date
end date
reporting requirements (for example, status, time, expense)
2 Request supplier responses, as
applicable.
Supplier
Responses
The potential suppliers do most of the work in this task by preparing the appropriate response to the service
order(s). Proposals should be prepared according to service order's directives and requirements. The proposal is
a legal document which represents the supplier's offer to the service order.
3 Select suppliers, as applicable. Selected
Suppliers
Review supplier responses and narrow down list of potential suppliers until final suppliers are selected.
4 Contract services, as applicable. Contract The contract reflects all agreements reached in terms of the services to be provided.
5 Order Goods, as applicable. Purchase
Orders
Purchase Orders
Back to Top
APPROACH
Considerations for Getting the Best Value from Contract Service Providers: Make sure you know the rate for each resource you are considering. Your goal is to get the
best resource at the lowest cost -- which may mean paying more per hour for someone who can get the job done faster. Availability should be a significant factor, too.
What is the impact to the project if the resource is unavailable on the date planned?
Having a carefully written Service Order can make the difference between a successful partnership and a failure. Make sure that everything you want the service provider
to do is in the Service Order. Remember, the Service Order drives the statement of work (SOW) and the SOW is the contractual link between the project and the service
provider, if it is wrong, the wrong result will be produced.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Procurement Strategy and Process
(PCM.010)
Use the process developed in the Procurement Strategy and Process to open service orders and procure goods and
services.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.030 - ADMINISTER PROCUREMENT OF GOODS AND
CONTRACTED SERVICES
This task is the administrative task for managing the procurement of goods and services based on the previously defined Procurement Strategy and Process. Both the
buyer and supplier participate in this task. Each party confirms that both it and the other party are meeting or have met their contractual obligations. They also make sure
their own legal rights are protected.
ACTIVITY
PEC.ACT.APGCS Administer Procurement of Goods and Contracted Services
Back to Top
WORK PRODUCT
Managed Procurement of Goods and Services
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Administer contract. Updated Contract
Records
Update the records to include supplier performance, payments, corrective action taken, any contract
amendments or contract terminations.
2 Receive goods and contracted
services.
Received Goods and
Services
Update the Financial Management Plan with payments. Update the Project Workplan.
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
#TOP #Top
Procurement Strategy and Process
(PCM.010)
Use the process developed in the Procurement Strategy and Process to administer service orders for goods and
services.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
PCM030_INCOMING_ITEM_RECORD.DOC MS WORD (Former PJM 2.6.1 template)
PCM030_REJECTION_NOTE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.040 - CLOSE CONTRACT
During Project Closure, all services and goods are inspected and verified to be acceptable. All necessary records are updated.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Contract
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Close out all Requisitions, Purchase Orders, and Invoices. Closed Requisitions, Purchase Orders, and Invoices
2 Provide final reporting on Purchasing Budget and Supplier Performance. Final Purchasing Budget and Final Supplier Performance
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
PCM040_SUPPLIER_ASSESSMENT_RECORD.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[OCHM] ORGANIZATIONAL CHANGE MANAGEMENT
As part of every project, it is important to address the technology, people, organizational and benefit needs in order to succeed through the entire lifecycle. If people and
organizational risks and benefits measurement are well managed, then the stakeholders are able to accept the change and realize the expected benefits of the new
technologies. With an efficient Change and Communication Plan, it is possible to create the change momentum needed to increase buy-in and reduce resistance - thus
reducing productivity losses.
Do not confuse this process with the Communication Management process. The Communication Management process focuses on the internal project team
communications to key stakeholders regarding progress and status while Organizational Change Management focuses on the broader set of communication typically
associated with the client organization.
Note: Do not confuse the Change and Communication Plan from this process with the Communication Plan created in the Communication Management process.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Project Start Up, the project manager is responsible for understanding the client's organizational change management and documenting that understanding in the
Client's Organizational Change Management Strategy. In addition, the project manager has to identify who will define the overall strategy for identifying and mitigating
organizational risks (culture, management and stakeholders reactions and organization model) and maximizing benefits throughout the lifecycle of the project. This
includes agreeing (with key stakeholders) on:
how to align the executives and management around the project and get their commitment
how to prepare the Oracle team and the client resources working efficiently together in a very short period of time
how to anticipate and manage stakeholders expectations/reactions during the project
how to identify the organizational and human risks that must be addressed during the project
how to communicate to all stakeholders and the clients customers/suppliers the changes related to the implementation
how to prepare the stakeholders to adapt to and adopt the new tasks
how to put in place the procedures to track and measure benefits
Project Execution and Control Phase
During Project Execution and Control, the Organizational Change Management process addresses the soft (human and organizational) part of the implementation by
increasing the stakeholders involvement and management commitment. This task prepares the organization and people for the implementation and increases their
ownership and participation in the success of the project. It also helps make the transition as smooth as possible by managing issues by target group (i.e., the people
who are most impacted by the change) at the right time with the right activities to support the change momentum.
Although, Oracle is not directly responsible, it is important for the Oracle project manager to stay aware of all the change management initiatives in order to anticipate
how stakeholders will react to the change. It is crucial to deploy the full change/communication plan and provide to the clients managers all the information regarding the
impacts on people. If a project manager is aware of political issues or stakeholders positive or negative reactions, it is very important to inform the change management
resources on the project. It is crucial before the go live date to check that stakeholders, managers and customers have received all the information and support that they
need to adopt the new technology.
Project Closure Phase
After the go live, the client has to manage peoples reactions to the changes. During the next few months, stakeholders will try to adapt themselves to their new tasks, new
procedures and work environment.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS OCHM.010 Understand Client's Organizational Change Management Strategy Client's Organizational Change Management Strategy Y Core
PS OCHM.020 Identify Change Management Warning Signs Change Management Warning Signs Core
Project Execution and Control
PEC OCHM.030 Execute Change and Communication Plan Executed Change and Communication Plan Y Core
Project Closure
PC OCHM.040 Establish Follow-Up Process Follow-Up Process Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.010 - UNDERSTAND CLIENT'S ORGANIZATIONAL
CHANGE MANAGEMENT STRATEGY
Organizational Change Management focuses on how the project solution is to be implemented into the organization. Its purpose is to substantially increase the likelihood
of successful project implementation by addressing the organizational and human aspect of the change. The project does not drive the Organizational Change
Management process in the organization, it is driven by the client or a third-party supplier. The client is solely responsible for the Organizational Change Management
process. Therefore, understanding the client's Organizational Change Management Strategy is critical to having a successful project implementation.
Document the strategy in the Client's Organizational Change Management Strategy. The Client's Organizational Change Management Strategy is a key component of the
Project Management Plan.
ACTIVITY
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
WORK PRODUCT
Client's Organizational Change Management Strategy - The Client's Organizational Change Management Strategy documents how the project solution is to be
implemented into the organization.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define the Client's
Organizational Change
Management Strategy
Overview of Client's
Organizational Change
Management Strategy
Document the PM's understanding of the Client's Organizational Change Management Strategy.
2 Define Change and
Communication Plan.
Change and Communication
Plan Overview
Document the plan to communicate to stakeholders external to the project. Refer to the
Communication Management process for guidance on developing communication plans.
3 Create Communication Matrix External Stakeholder
Communication Matrix
The Change and Communication Plan should consider all stakeholders external to the project
team, what will be communicated, the frequency of the communication, and how the
communication will occur.
4 Document Scheduled
Meetings
Scheduled Meetings Document when status/communication meetings will be held, i.e., every Thursday at 9:00 AM or
on some in frequent calendar. Include purpose, attendees, location, remote access, etc.
Back to Top
APPROACH
One challenge the project manager has is to align necessary changes caused by the project to the organization level, process level, and job level. In addition, the project
outcome needs to be aligned to the technical environment supporting the business in the organization.
A project has the potential to contribute significantly to the organization bottom line. The outcome of the project will also impact the way business is conducted. The effects
of the project outcome will also probably impact the overall customer satisfaction, the relationship with suppliers and the cycle time of core processes.
The project managers role is to get a committed sponsor who understands how the project will affect the organization. A committed sponsor will recognize the demand
that a project makes on organizational resources. The resolute sponsor will commit resources (change agents) who take the responsibility to facilitate the
implementation of the change. An effective network of cascading sponsorship down the organization improves the commitments of other stakeholders to support the
change throughout the organization.
A critical factor in succeeding with the project implementation is to manage resistance against the change caused by the project outcome in the organization. The project
manager can assist the sponsor by collecting the data necessary to indicate the ongoing levels of commitments necessary to sustain the change and report that to the
sponsor.
Organizational Change Management in projects includes the following activities:
#TOP #Top
Clarify the scope of the project Organizational Change Management work with the client.
Ensure the creation of an Organizational Change Management team at the client including sponsors and change agents.
Ensure that end-users/target groups are identified and plans are developed for training, communication, and end-user involvement.
Provide appropriate type and level of initial project Organizational Change Management actions to target groups and end-users to ensure commitment and
understanding of the change
Support the analysis of target groups and end-users ability to adapt the necessary change and their resistance levels.
Support the client in developing appropriate transition plans for each target group and end-user group.
Support the client in executing and monitoring the progress and issues.
Assist the client in evaluating the final result.
The Client's Organizational Change Management Strategy should identify the following roles:
What are the overall timeframes, milestones, tasks and key work products for the Organizational Change Management process.
Who will sponsor the project and put in place the Sponsorship Program to bring on board the management team?
Who will facilitate the Executive Alignment Workshop to align executives behind the project vision and objectives?
Who will identify the organizational risks and lead the Executive Execution Plan / Governance Rules (ENV.EOCM.020 and A.OCM.030)?
Who will facilitate the Team-Building Workshop to set the team rules, etc.?
Who will determine the benefit opportunity areas that drive the savings and ROI?
Who will define and set baselines for the metrics and develop the reports for tracking and measuring benefits?
Who will create and deploy the Change Management Roadmap / Communication Campaign (A.OCM.140) as well as other internal project communications that
address the managers'/stakeholders' expectations and concerns and generate a two-way communication to keep people involved and knowledgeable regarding
the changes? The Change Management Roadmap / Communication Campaign includes activities and a two-way communication initiative organized by audience,
expectations, issues, speaker, and preferred communication channels to ensure that the right information is communicated to the right people using the right
vehicle at the right time.
Who will conduct the job impact analysis on the roles, organizational environment, workflow and necessary inputs to the HR policies and training plans.
Who is responsible for the development of a training strategy and plan for delivery of training?
If these roles are not identified in the Client's Organizational Change Management Strategy, the project manager should document this as a risk and bring it to the
attention of the project sponsor and Steering Committee.
Tip: Review the Organizational Change Management (OCM) process in the Implement Focus Area to ensure a correlation between the Client's Organizational Change
Management Strategy and the OCM process, activities, tasks and work products.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Organizational Change Management Management requirements that should be
taken into consideration when developing the detailed Organizational Change Management Strategy.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
OCHM010_CLIENTS_ORGANIZATIONAL_CHANGE_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.020 - IDENTIFY CHANGE MANAGEMENT WARNING
SIGNS
The project manager should monitor stakeholders' participation and attitude during the Start Up phase, and throughout the project lifecycle, to identify problems that can
arise as a result of ineffective organization change management. A stakeholder with a personal agenda could potentially cause a project to fail. Being proactive in this
area by continually communicating with all stakeholders decreases the likelihood that such a situation will occur.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Change Management Warning Signs
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Flag quickly any deviation in the Client's Organizational Change Management Strategy and
raise it to the stakeholders as a risk.
Client's Organizational Change Management
Strategy Deviations
2 Monitor stakeholders' participation and attitude during the Project Start Up phase. Stakeholders' Participation
3 Recognize and document any project risk related to people and /or organizational culture. Organizational Change Management Project
Risks
4 Consider as real and certain any constraint that has already been identified by the project
team.
Organizational Change Management Project
Constraints
Back to Top
APPROACH
The key to surviving change is to help all individuals become aligned with the vision and understanding the reason for the change. Understanding the factors that drive
change, and how people react to it is an important first step to early identify change management warning signs.
Finding a customer or partner who understands the underlying principles of change, and uses them to develop comprehensive change management framework can help
ensure the success of the project. Because this is a soft work product in a project, it can often be overlooked, or minimized in importance.
Business processes associated with new software (and the leading practices that go with it) can spell significant change to the systems users and the project manager
should identify these areas a project risks. The project manager keeps abreast of progress in this area in order to assess impact to the project timeframe's and work
products.
Items to recognize as change management warning signs include:
a high level of stakeholder reactions
difficulty in gaining sponsorship and/or obtaining business resources
misunderstandings about project expectations around scope, vision and/or objectives
low attendance at meetings, functions, etc.
difficulty in identifying and/or measuring benefits or tangible objectives for the project
existence of unplanned activities surrounding change management and/or benefits tracking
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Client's Organizational Change Management Strategy (OCHM.010) Review the Client's Organizational Change Management Strategy to identify warning signs/risks.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
OCHM020_CHANGE_MANAGEMENT_WARNING_SIGNS.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.030 - EXECUTE CHANGE AND COMMUNICATION PLAN
Execute the Change and Communication Plan that was developed as part of the Organizational Change Management Strategy. At a minimum, know how the change and
communication activities will be deployed and aligned with project milestones. Be aware of the key messages being communicated to users, customers, etc. This task is
ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MCOP Manage Communications and OCM Plans
Back to Top
WORK PRODUCT
Executed Change and Communication Plan
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Execute the Change and Communication Plan. None Communicate with external stakeholders based on the
guidelines and frequency outlined in the Change and
Communication Plan.
2 Review Organizational Change Management Strategy, including the
Change and Communication Plan with project stakeholders on a
periodic basis.
Updated Organizational
Change Management
Strategy.
Update the document, as required.
Back to Top
APPROACH
Confirm with accepting organization's project manager that the Organizational Change Management Strategy includes a plan to communicate to stakeholders external to
the project. This Change and Communication Plan should consider all stakeholders external to the project team, what will be communicated, the frequency of the
communication, and how the communication will occur.
The Organization Change Management team must anticipate and plan for changes affecting anyone in the organization or outside the organization who is impacted by the
new system. Often, the entire organization is affected. An example would be a payroll implementation that changes the look and feel of paychecks. Another example
would be a new system that will provide the consumer with the ability to order product on-line. Such an endeavor requires coordination between many business
departments and can take months to finalize. Review change information for potential impact to the overall training and work plans.
Business process change management involves anticipating and planning for changes in the way people do their jobs. If someone's day-to-day job processes are altered
by the new system, the business process change management plan should address it.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or
repetitive activities, tasks or task steps. If your project does not have a dedicated project
administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Client's Organizational Change Management Strategy
(OCHM.010)
Execute the Communication Plan documented in the Organizational Change Management Strategy.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.040 - ESTABLISH FOLLOW-UP PROCESS
During Project Closure, confirm with the client that a process is in place to review the progress of Organizational Change Management activities and determine if any
actions need to be taken to alter the strategy. Assess risk of deviations from the Client's Organizational Change Management Strategy and the potential affect to project.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Follow-Up Process
Back to Top
TASK STEPS
This section is not yet available.
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Client's Organizational Change Management Strategy (OCHM.010)
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Focus Area Overview
Method Navigation Current Page Navigation
ENVISION
INTRODUCTION
Envision comprises the areas of the Oracle Unified Method framework that deal with development and maintenance of enterprise level IT strategy, architecture, and
governance. Ideally, every enterprise should be executing these or similar processes. Every project that effects a corporation's IT landscape should have its origins here.
The goals for Envision are to:
Provide a set of processes that can be adopted by an enterprise in order to better align IT delivery with Business strategy.
Provide a framework for development of services for enterprise or strategic level interactions.
Provide the context for OUM based delivery services and connect those services to the larger IT lifecycle.
Indeed, one of the goals of OUM is to provide the methodological basis for the delivery of any IT related service. Envision extends OUM's capabilities beyond delivery
and management of software implementation projects into the realm of IT vision and strategy. Like many of aspects of OUM, it is not likely that all of Envision's processes
and tasks will be executed within any single enterprise, nor is it likely that Envision will ever contain an exhaustive set of enterprise level processes. Rather, Envision
should serve as a framework that can be scaled to suit the needs of a particular enterprise.
Envision is focused on information technology related business architecture and practices. The following is a list of the objectives of Envision:
Provide the vision for one or more projects intended to realize a focused set of business objectives
Establish or bolster a broad set of enterprise level IT processes that are to be continued
Define an enterprise "Strategy" on such topics as Governance, Business Intelligence, or Business Process improvement, prior to an OUM project that supports
implementation of specific technology in these areas
Respond to critical business needs or pain points
The diagram below shows how Envision relates to the other focus areas of the Oracle Unified Method. The diagram reflects the influence that Envision work has on OUM
delivery and management of OUM implementation projects (Implement focus area). Envision work may precede one or more IT Projects. Envision need not end when an
OUM delivery project starts, but spans the whole project lifecycle of current and future IT projects instead. The following picture illustrates the ongoing nature of Envision:
In future releases, Envision will become more complete and better integrated with the rest of the OUM framework. We will establish a stronger symbiosis between
Envision tasks and the OUM delivery tasks that are being executed to realize specific portions of the enterprise strategy. In general, any service that is focused at the
enterprise level or on strategic business objectives should be based on some combination of Envision tasks.
Back to Top
PHASES
Envision currently has two phases:
Initiate
Maintain and Evolve
During Initiate, you perform a set of foundational tasks. Those tasks have a broad range of objectives and applicability. At one end, delivering a service based on the
Envision Roadmap process can establish the vision for one or more projects intended to realize a focused set of business objectives (e.g., Roadmap to SOA). On the
other end, Initiate phase processes can be used to establish a broad set of enterprise level IT processes that are continued in the Maintain and Evolve phase.
The processes and tasks of the Maintain and Evolve phase bring the work begun during Initiate into the day to day life of the enterprise. This phase forms the foundation
for governing and managing enterprise level business processes and strategies. Envision is not intended to be a broad treatise on corporate strategic planning. It is
focused on information technology related business architecture and practices. Some enterprises may adopt these processes in whole or part. They should also form the
basis for defining service offerings. At the very least, they are intended to provide architects and practitioners with an evolving set of leading practices around Enterprise
Business Analysis, Enterprise Architecture, IT Strategy, and IT Portfolio Management.
Finally, Initiate-based services or sets of tasks may also be performed periodically. These may be required to develop further detail on specific objectives or to respond to
critical business needs or pain points that bubble up out of Maintain and Evolve tasks.
Back to Top
KEY CONCEPTS
One of the key concepts in understanding the Envision focus area is to see the relationship between an Envision project and how any subsequent implementation projects
make use of the artifacts from an Envision based project.
Envision projects produce the following types of artifacts:
Data and Information Models
Distributed Services Designs
Recommendations on Hardware & Software Components
Platform Configuration Designs
Operating Infrastructure Designs and Implementations
Selection of Applications and Systems Support Tools
Operations Infrastructure Strategies
The implementation projects in return provide:
Validation of Technical Designs
Exposure of Areas Requiring Further Work or Research at the Enterprise level
Value to the Enterprise through implementations that support the Business Objectives and Requirements
One other key concept is that Envision Projects are done at the Enterprise level, but do not always look at the entire enterprise at once. In some cases, proof of concept is
done to test a particular recommendation or strategy, and at the same time, solve a particular business problem for an area within the Enterprise.
Back to Top
PROCESSES
The overall organization of OUM is expressed by a process-based system engineering methodology.
A process is a cohesive set or thread of related tasks that align to a specific project objective. A process results in one or more key outputs. Each process is a discipline
that usually involves similar skills to perform the tasks within the process. You might think of a process as a simultaneous sub-project or workflow within a larger
development project.
This section describes the key OUM Envision processes.
[ER] Envision Roadmap Process
[BA] Enterprise Business Analysis Process
[OCM] Organizational Change Management Process
[EA] Enterprise Architecture Process
[IP] IT Portfolio Management Process
[GV] Governance Process
[ER] Envision Roadmap Process
The Envision Roadmap process accelerates project implementations by focusing on the key strategic and tactical areas that must be addressed in order to maximize the
Enterprise's return on investment, while minimizing the business risk in order to successfully complete a project.
[BA] Enterprise Business Analysis Process
The Enterprise Business Analysis process provides analysis of the enterprise-level requirements and sets up the business boundaries of the OUM project. It produces a
set of requirements models of the enterprise, such as enterprise process models, domain models and use case models.
[OCM] Organizational Change Management Process
The Organizational Change Management process starts at the strategic level with executives and then identifies the particular human and organizational challenges of the
technology implementation in order to design a systematic, time-sensitive, and cost-effective approach to lowering risk that is tailored to each organizations specific
needs. In addition to increasing user adoption rates, carefully planning for and managing change in this way allows organizations to maintain productivity through often-
difficult technological transitions. This in turn enables the organization to more easily meet deadlines, realize business objectives, and maximize return on investment.
[EA] Enterprise Architecture Process
Enterprise Architecture covers an enterprise-level view on both the application and technical architecture of the systems.
[IP] IT Portfolio Management Process
IT Portfolio Management covers a holistic view of the overall IT strategy of the enterprise. Its main purpose is to validate that IT projects are aligned with the corporate
strategy by maximizing the investment in IT projects while minimizing the risks.
[GV] Governance Process
In the Governance process you review the organizations strategies and objectives and affirm that the IT related objectives and strategies fit within those of the
organization. A well-defined Governance process should validate that the IT investments are aligned with the business strategies throughout the enterprise, and mitigate
associated risks.
Back to Top
ACTIVITIES
Envision tasks are further refined into activities to better represent the Envision lifecycle.
As part of OUM, Envision also uses the Unified Process (UP). UP is an iterative and incremental approach to developing and implementing software systems. Therefore,
any activity (and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable.
Activities may be iterated to either increase the quality of the activity or task outputs to a desired level, to add sufficient level of detail, or to refine and expand them on the
basis of user feedback.
Within the Envision phases, the following major activities have been identified:
Initiate Phase Activities
Prepare Envision Foundation
Prepare for Discovery
Conduct Executive Alignment Workshop - Envision
Define and Maintain Common Enterprise Concepts
Execute Discovery - Gather Information (As Is)
Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
Execute Discovery - Finish
Develop Solution and Present to Client
Plan Transition to Implementation
Maintain and Evolve Phase Activities
Maintain and Evolve
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
MANAGEMENT
OUM uses the Manage focus area. You should read the Manage focus area overview to gain a better understanding of this focus area.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[INIT] INITIATE
During Initiate, you perform a set of foundational tasks. Those tasks have a broad range of objectives and applicability. At one end, delivering a service based on the
Envision Roadmap process can establish the vision for one or more projects intended to realize a focused set of business objectives (for example, Roadmap to SOA). On
the other end, Initiate phase processes can be used to establish a broad set of enterprise level IT processes that are continued in the Maintain and Evolve phase.
Finally, initiate-based services or sets of tasks may also be performed periodically. These may be required to develop further detail on specific objectives or to respond to
critical business needs or pain points that bubble up out of Maintain and Evolve phase tasks.
This phase overview is written from the perspective of a Full Method View, utilizing ALL of the processes, activities and tasks in this phase. Therefore, all of the following
sections provide comprehensive information. If your project is utilizing a tailored approach (for example, Technology Full Lifecycle View, Application Implementation View,
Middleware Architecture View), not everything in this overview may be appropriate for your project. Please keep this in mind, especially when reviewing the Prerequisites,
Processes, Key Work Products, Tasks and Work Products and Task Dependencies sections. You should use OUM as a guideline for performing all types of information
technology projects, but keep in mind that every project is different and that you need to adjust project activities according to each situation. Do not hesitate to add,
remove, or rearrange tasks, but be sure to reflect these changes in your estimates and risk management planning. You should also consider the depth to which you
address and complete each task based on the characteristics of your particular project or project increment. See Oracle's Full Lifecycle Method for Deploying Oracle-
Based Business Solutions for further information on the scalability and adaptability of OUM.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Provide the vision for one or more projects in order to achieve a focused set of business objectives
Establish or bolster a broad set of enterprise level IT processes that are to be continued
Define an enterprise "Strategy" on such topics as Governance, Business Intelligence, or Business Process improvement, prior to an OUM project that supports
implementation of specific technology in these areas
Respond to critical business needs or pain points
Back to Top
PROCESSES
The following processes are active in this phase:
Envision Roadmap (ER)
Enterprise Business Analysis (BA)
Organizational Change Management (EOCM)
Enterprise Architecture (EA)
IT Portfolio Management (IP)
Governance (GV)
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
TIPS AND TECHNIQUES
This section is not yet available.
Back to Top
TASKS AND WORK PRODUCTS
Envision includes the following tasks:
ID Task Work Product
#TOP #TOP
Envision Roadmap
ER.010 Create Business Case for Envision Enagement Customer Envision Engagement Strategy
ER.015 Conduct Enterprise Maturity Assessment Maturity Analysis and Recommendations Report
ER.020 Determine Envision Engagement Strategy Envision Engagement Strategy
ER.025 Educate Enterprise on Area of Focus Educated Enterprise
ER.030 Set and Agree on Plan for Envision Engagement Envision Engagement Plan
ER.040 Research Enterprise Enterprise Research Findings
ER.045 Establish Executive Sponsorship Committed Executive Sponsorship
ER.050 Validate and Agree on Envision Engagement Plan Agreed on Envision Engagement Plan
ER.070 Define Modeling Strategy for the Enterprise Enterprise Modeling Strategy
ER.080 Obtain Existing Reference Material Existing Reference Material
ER.090 Conduct Solution Readiness Assessment Solution Readiness Assessment
ER.100 Define Supplemental Enterprise Requirements Supplemental Enterprise Requirements
ER.110.1 Perform Benefit Analysis Benefit Analysis
ER.110.2 Perform Benefit Analysis Benefit Analysis
ER.120.1 Identify and Mitigate Future State Risks Future State Risks
ER.130.1 Produce MoSCoW Improvement List MoSCoW Improvement List
ER.140 Share Product Strategies with Enterprise Informed Enterprise
ER.150 Review Discovery Findings Reviewed Discovery Findings
ER.160 Develop Desired Future State Desired Future State
ER.165 Identify Capability Challenges Current Capability Challenges
ER.167 Determine Remediation Approaches Remediation Approaches
ER.170 Develop Future State Transition Plan Future State Transition Plan
ER.180 Prepare for and Present Solution Recommendation Solution Recommendations
ER.190 Review Business Feedback and Identify Opportunities Opportunities Task List
ER.200 Prepare for Transition to Sales or Services Opportunities Action Plan
Enterprise Business Analysis
BA.010 Identify Business Strategy Business Strategy
BA.012 Define Business Scope Business Scope
BA.015 Conduct Enterprise Stakeholder Assessment Enterprise Stakeholder Inventory
BA.017.1 Determine Metrics Collection and Reporting Strategy Metrics Collection and Reporting Strategy
BA.018.1 Establish Current Baseline Metrics Current Baseline Metrics
BA.020 Document Enterprise Organization Structures Enterprise Organization Structures
BA.025 Determine Operating Model Validated Operating Model
BA.030.1 Develop Enterprise Glossary Enterprise Glossary
BA.040 Create Enterprise Function or Process Model Function or Enterprise Process Model
BA.045 Develop Enterprise Business Context Diagram Enterprise Business Context Diagram
BA.050 Develop Enterprise Domain Model (Business Entities) Enterprise Domain Model
BA.055 Develop Enterprise Knowledge Flow Enterprise Knowledge Flow
BA.058 Develop Business Architecture Business Architecture
BA.060.1 Perform High-Level Use Case Discovery High-Level Use Cases
BA.060.2 Perform High-Level Use Case Discovery High-Level Use Cases
BA.065 Review Busines IT SLA Business-IT SLA Report
BA.067 Review Business Volumetrics Business Volumetrics Report
BA.070 Identify Candidate Services Service Portfolio - Candidate Services
BA.080 Identify Candidate Enterprise Business Rules Candidate Business Rules
BA.090 Identify Process Improvement Options Process Improvement Options
Organizational Change Management
EOCM.010 Create and Manage Ad Hoc Communications Ad Hoc Communications
EOCM.020 Prepare for Executive Alignment Workshop Executive Alignment Workshop Materials
EOCM.030 Conduct Executive Alignment Workshop Executive Business Objectives and Governance Rules
EOCM.040 Build and Deploy Sponsorship Program Sponsorship Program
EOCM.050 Assess Enterprise Change Readiness Preliminary Enterprise Change Management Assessment
EOCM.060 Prepare Project Team for Enterprise Culture Prepared Project Team
EOCM.070 Identify Change Agent Structure Change Agent Structure
Enterprise Architecture
EA.001 Justify and Engage Enterprise Architects Assigned Enterprise Architect
EA.002 Review External Reference Architectures External Reference Architectures Review
EA.010.1 Review Architecture Principles, Guidelines and Standards Architecture Principles, Guidelines and Standards
EA.030 Identify Current Enterprise Architecture Current Enterprise Architecture
EA.040 Analyze Capabilities Capabilities Model
EA.050 Identify Current Architectural Challenges Current Architectural Challenges
EA.057 Review Business Capacity Plan Business Capacity Plan
EA.060 Identify Architectural Gaps and Improvement Options Architectural Gaps and Improvement Options
EA.065 Identify Enterprise IT Strategy Enterprise IT Strategy
EA.075 Develop Technology Reference Architectures Technology Reference Architectures
EA.095 Review Enterprise Software Development Process Enterprise Software Development Process
EA.110 Develop Future State Enterprise Architecture Future State Enterprise Architecture
EA.120 Develop Information Architecture Information Architecture
EA.130 Develop Technology Architecture Technology Architecture
EA.140 Develop Applications Architecture Applications Architecture
EA.150 Define Transitional Architectures Transitional Architectures
EA.160 Define Business Rules Implementation Strategy Business Rules Implementation Strategy
EA.170 Identify Integration Requirements Integration Requirements
EA.190 Define Product Implementation Prioritization Product Implementation Prioritization Report
EA.200 Determine Development Framework and Policy Guidelines Development Framework
IT Portfolio Management
IP.010 Inventory Projects IT Project Portfolio
IP.012 Inventory Applications IT Application Portfolio
IP.014 Inventory Services Service Portfolio
IP.015 Conduct Portfolio Analysis Portfolio Analysis Report
IP.020 Analyze Services Service Portfolio - Proposed Services
IP.025 Populate Services Repository Populated Services Repository
IP.030 Analyze Business Rules Business Rules Analysis
IP.040 Identify Candidate Projects Candidate Projects
IP.050.1 Prioritize Projects Prioritize Projects
IP.060 Develop IT Portfolio Plan IT Portfolio Plan
Governance
GV.010 Define Governance Strategy Governance Strategy
GV.015 Review Current Governance Model Current Governance Model
GV.020.1 Determine Regulatory and Business Mandates Mandate Matrix
GV.030.1 Discover or Define Policies Governance Policies Catalog
GV.040 Determine Organizational Impact of Governance Impact Study and List of Proposed Organizational Changes
GV.050.1 Define Policy Implementation Processes Policy Implementation Processes
GV.060.1 Define Policy Implementation Tooling Governance Policy Tooling
GV.070.1 Define Policy Metrics Measurements Portfolio
GV.080.1 Define Policy Monitoring Processes Policy Monitoring Processes
GV.090.1 Determine Funding Model Funding Model
GV.092 Determine Projects Meta Data Description Projects Meta Data Description
GV.094 Determine Applications Meta Data Description Applications Meta Data Description
GV.096 Determine Services Meta Data Description Services Meta Data Description
GV.098 Determine Other Meta Data Descriptions Other Meta Data Descriptions
GV.100.1 Implement Governance Governance Implementation
Back to Top
ACTIVITY FLOW DIAGRAM
Back to Top
MANAGING RISK
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.PEF - PREPARE ENVISION FOUNDATION
This activity focuses on prepare the foundation for the Envision engagement, such as creating the Business Case, justifying and engaging enterprise architects,
establishing the executive sponsorship, documenting the organization structures, determining engagement strategies and defining the Business Scope.
Back to Top
OBJECTIVES
The objective for this activity is provide the foundation for the Envision engagement.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
ER.010 Create Business Case for Envision Engagement
EA.001 Justify and Engage Enterprise Architects
ER.040 Research Enterprise
ER.045 Establish Executive Sponsorship
BA.010 Identify Business Strategy
BA.012 Define Business Scope
BA.015 Conduct Enterprise Stakeholder Assessment
GV.010 Define Governance Strategy
BA.017.1 Determine Metrics Collection and Reporting Strategy
BA.018.1 Establish Current Baseline Metrics
BA.020 Document Enterprise Organization Structures
BA.025 Determine Operating Model
EA.002 Review External Reference Architectures
ER.015 Conduct Enterprise Maturity Assessment
ER.020 Determine Envision Engagement Strategy
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to execute the tasks and develop the work products with the assistance of the client stakeholders.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.RBAC Review Bid and Contract
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.PD - PREPARE FOR DISCOVERY
This activity focuses on creating and managing Ad Hoc Communications, educating the enterprise and setting the plan for the Envision engagement.
Back to Top
OBJECTIVES
The objective for this activity is to validate and agree on the Envision engagement.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
EOCM.010 Create and Manage Ad Hoc Communications
ER.025 Educate Enterprise on Area of Focus
ER.030 Set and Agree on Plan for Envision Engagement
ER.050 Validate and Agree on Envision Engagement Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to create and manage Ad Hoc Communications, educate the enterprise on any appropriate areas of focus and set, validate and agree on
the Envision Engagement Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.CEAWE - CONDUCT EXECUTIVE ALIGNMENT
WORKSHOP - ENVISION
This activity focuses on preparing and conducting the Executive Alignment Workshop and building and deploying the Sponsorship Program at the enterprise level.
Back to Top
OBJECTIVES
The objective for this activity is to capture the decisions made about enterprise vision, objectives, and success criteria in order to communicate them to the enterprise so
that they can then provide direction to middle managers and end users. During this activity, the executives will commit to modeling the change as they work to build and
deploy the Sponsorship Program.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
EOCM.020 Prepare for Executive Alignment Workshop
EOCM.030 Conduct Executive Alignment Workshop
EOCM.040 Build and Deploy Sponsorship Program
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the materials for and conduct the Executive Alignment Workshop and build and deploy the Sponsorship Program.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PD Prepare for Discovery
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.DMCEC - DEFINE AND MAINTAIN COMMON
ENTERPRISE CONCEPTS
In this activity, you develop, review and define the Enterprise Glossary, Enterprise Architecture Principles, Guidelines and Standards and Enterprise Modeling Strategy.
Back to Top
OBJECTIVES
The objective for this activity is to establish and maintain work products that provide standards for the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
BA.030.1 Develop Enterprise Glossary
EA.010.1 Review Architecture Principles, Guidelines and Standards
ER.070 Define Modeling Strategy for the Enterprise
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the work products and maintain them as appropriate.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
INIT.ACT.PD Prepare for Discovery
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.EDGI - EXECUTE DISCOVERY - GATHER
INFORMATION (AS IS)
The focus of this activity is to gather information about the enterprise.
Back to Top
OBJECTIVES
The objective for this activity is determine a realistic current state assessment of the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
EOCM.050 Assess Enterprise Change Readiness
EOCM.060 Prepare Project Team for Client Culture
EOCM.070 Identify Change Agent Structure
ER.080 Obtain Existing Reference Material
ER.090 Conduct Solution Readiness Assessment
GV.015 Review Current Governance Model
GV.020.1 Determine Regulatory and Business Mandates
BA.040 Create Enterprise Function or Process Model
BA.050 Develop Enterprise Domain Model (Business Entities)
BA.055 Develop Enterprise Knowledge Flow
BA.058 Develop Business Architecture
BA.060.1 Perform High-Level Use Case Discovery
EA.030 Identify Current Enterprise Architecture
EA.040 Analyze Capabilities
GV.030.1 Discover or Define Policies
EA.050 Identify Current Architectural Challenges
GV.092 Determine Projects Meta Data Description
IP.010 Inventory Projects
GV.094 Determine Applications Meta Data
IP.012 Inventory Applications
IP.015 Conduct Portfolio Analysis
BA.065 Review Business-IT SLA
BA.067 Review Business Volumetrics
GV.096 Determine Services Meta Data Description
IP.014 Inventory Services
GV.098 Determine Other Meta Data Descriptions
ER.100 Define Supplemental Enterprise Requirements
EA.057 Review Business Capacity Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to execute the tasks. This may include actually developing the work products or simply gathering already existing documents from the
enterprise.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
INIT.ACT.PD Prepare for Discovery
INIT.ACT.CEAWE Conduct Executive Alignment Workshop - Envision
INIT.ACT.DMCEC Define and Maintain Common Enterprise Concepts
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.EDBPD - EXECUTE DISCOVERY - BRAINSTORM,
PRIORITIZE AND DISCOVER ENTRY POINTS
In this activity, you analyze, develop and prioritize opportunities to improve the enterprise.
Back to Top
OBJECTIVES
The objective for this activity is to identify, analyze and prioritize opportunities to improve the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
BA.045 Develop Enterprise Business Context Diagram
GV.040 Determine Organizational Impact of Governance
EA.060 Identify Architectural Gaps and Improvement Options
EA.065 Identify Enterprise IT Strategy
ER.110.1 Perform Benefit Analysis
BA.060.2 Perform High-Level Use Case Discovery
EA.075 Develop Technology Reference Architectures
BA.070 Identify Candidate Services
IP.020 Analyze Services
IP.025 Populate Services Repository
BA.080 Identify Candidate Enterprise Business Rules
IP.030 Analyze Business Rules
BA.090 Identify Process Improvement Options
ER.120.1 Identify and Mitigate Future State Risks
ER.130.1 Product MoSCoW Improvement List
EA.095 Review Enterprise Software Development Process
IP.040 Identify Candidate Projects
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to identify architectural gaps and improvement options and process improvement options and then do some analysis on how to improve the
enterprise by addressing those options.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.EDF - EXECUTE DISCOVERY - FINISH
This activity focuses on sharing and reviewing discovery findings with the enterprise.
Back to Top
OBJECTIVES
The objective for this activity is to inform the enterprise of all the findings and improvement options defined up to this point to determine how to proceed further.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
ER.140 Share Product Strategies with Enterprise
ER.150 Review Discovery Findings
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to review the solution options with the enterprise. You should include a comprehensive list of findings and a preliminary assessment of
priorities.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.DSPC - DEVELOP SOLUTION AND PRESENT TO
CLIENT
The focus of this activity is to develop, prepare and present to the enterprise any necessary documentation to communicate the engagement solution.
Back to Top
OBJECTIVES
The objective for this activity is to communicate the solution to the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
GV.050.1 Define Policy Implementation Processes
GV.060.1 Define Policy Implementation Tooling
GV.070.1 Define Policy Metrics
GV.080.1 Define Policy Monitoring Processes
GV.090.1 Determine Funding Model
GV.100.1 Implement Governance
ER.160 Develop Desired Future State
ER.165 Identify Capability Challenges
ER.167 Determine Remediation Approaches
EA.110 Develop Future State Enterprise Architecture
EA.120 Develop Information Architecture
EA.130 Develop Technology Architecture
EA.140 Develop Applications Architecture
EA.150 Define Transitional Architectures
EA.160 Define Business Rules Implementation Strategy
ER.170 Develop Future State Transition Plan
EA.170 Identify Integration Requirements
IP.050.1 Prioritize Projects
ER.110.2 Perform Benefit Analysis
IP.060 Develop IT Portfolio Plan
EA.190 Define Product Implementation Prioritization
ER.180 Prepare for and Present Solution Recommendations
EA.200 Define Development Framework and Policy Guidelines
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define and prepare and implement any necessary Governance. Next, document the desired future state, any challenges and the
preferred approach to mitigating those challenges. An overall Future State Enterprise Architecture is developed along with documenting the the architecture for
Information, Technology and Applications. A Transition Plan is developed with projects for moving towards the future state from the current state. Projects are identified,
analyzed and prioritized.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.PTI - PLAN TRANSITION TO IMPLEMENTATION
The focus of this activity is to review business feedback and identify opportunities that could result in an implementation project.
Back to Top
OBJECTIVES
The objective for this activity is to transition from an Envision engagement to an implementation project(s).
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
ER.190 Review Business Feedback and identify Opportunities
ER.200 Prepare for Transition to Sales or Services
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to review business feedback and identify potential opportunities for implementation projects.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.DSPC Develop Solution and Present to Client
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[ME] MAINTAIN AND EVOLVE
The processes and tasks of the Maintain and Evolve phase bring the work begun during Initiate into the day to day life of the enterprise. This phase forms the foundation
for governing and managing enterprise level business processes and strategies. Envision is not intended to be a broad treatise on corporate strategic planning. It is
focused on information technology related business architecture and practices. Some enterprises may adopt these processes in whole or part. They should also form the
basis for defining service offerings. At the very least, they are intended to provide architects and practitioners with an evolving set of leading practices around Enterprise
Business Analysis, Enterprise Architecture, IT Strategy, and IT Portfolio Management.
Finally, Initiate-based services or sets of tasks may also be performed periodically. These may be required to develop further detail on specific objectives or to respond to
critical business needs or pain points that bubble up out of Maintain and Evolve tasks.
This phase overview is written from the perspective of a Full Method View, utilizing ALL of the processes, activities and tasks in this phase. Therefore, all of the following
sections provide comprehensive information. If your project is utilizing a tailored approach (for example, Technology Full Lifecycle View, Application Implementation View,
Middleware Architecture View), not everything in this overview may be appropriate for your project. Please keep this in mind, especially when reviewing the Prerequisites,
Processes, Key Work Products, Tasks and Work Products and Task Dependencies sections. You should use OUM as a guideline for performing all types of information
technology projects, but keep in mind that every project is different and that you need to adjust project activities according to each situation. Do not hesitate to add,
remove, or rearrange tasks, but be sure to reflect these changes in your estimates and risk management planning. You should also consider the depth to which you
address and complete each task based on the characteristics of your particular project or project increment. See Oracle's Full Lifecycle Method for Deploying Oracle-
Based Business Solutions for further information on the scalability and adaptability of OUM.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Maintain enterprise-level IT processes that are to be continued, such as Governance and Reference Architecture once established by an Envision-based project.
Obtain and 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
The following processes are active in this phase:
Envision Roadmap (ER)
Enterprise Business Analysis (BA)
Enterprise Architecture (EA)
IT Portfolio Management (IP)
Governance (GV)
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
TIPS AND TECHNIQUES
This section is not yet available.
Back to Top
TASKS AND WORK PRODUCTS
Envision includes the following tasks:
#TOP #TOP
ID Task Work Product
Envision Roadmap
ER.120.2 Identify and Mitigate Future State Risks Future State Risks
ER.130.2 Produce MoSCoW Improvement List MoSCoW Improvement List
ER.210 Monitor Current Situation and Pursue Relevant Updates Monitored Current Situation
Enterprise Business Analysis
BA.017.2 Determine Metrics Collection and Reporting Strategy Metrics Collection and Reporting Strategy
BA.018.2 Establish Current Baseline Metrics Current Baseline Metrics
BA.030.2 Develop Enterprise Glossary Enterprise Glossary
BA.100 Maintain Enterprise Business Models Maintained Enterprise Business Models
BA.110 Maintain Business Rules Maintained Business Rules
Enterprise Architecture
EA.010.2 Review Architecture Principles, Guidelines and Standards Architecture Principles, Guidelines and Standards
EA.210 Maintain Enterprise Architectural Models Maintained Enterprise Architectural Models
IT Portfolio Management
IP.050.2 Prioritize Projects Prioritize Projects
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.020.2 Determine Regulatory and Business Mandates Mandate Matrix
GV.030.2 Discover or Define Policies Governance Policies Catalog
GV.050.2 Define Policy Implementation Processes Policy Implementation Processes
GV.060.2 Define Policy Implementation Tooling Governance Policy Tooling
GV.070.2 Define Policy Metrics Measurements Portfolio
GV.080.2 Define Policy Monitoring Processes Policy Monitoring Processes
GV.090.2 Determine Funding Model Funding Model
GV.100.2 Implement Governance Governance Implementation
GV.110 Monitor and Analyze Governance Processes Governance Implementation Improvement Proposal
Back to Top
ACTIVITY FLOW DIAGRAM
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
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
INIT.ACT.DMCEC Define and Maintain Common Enterprise Concepts
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
INIT.ACT.DSPC Develop Solution and Present to Client
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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
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 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
This section is not yet available.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
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.110.1 Perform Benefit Analysis Benefit Analysis
ER.110.2 Perform Benefit Analysis Benefit Analysis
ER.120.1 Identify and Mitigate Future State Risks Future State Risks
ER.130.1 Produce MoSCoW Improvement List MoSCoW Improvement List
ER.140 Share Product Strategies with Enterprise Informed Enterprise
ER.150 Review Discovery Findings Reviewed Discovery Findings
ER.160 Develop Desired Future State Desired Future State
ER.165 Identify Capability Challenges Current Capability Challenges
ER.167 Determine Remediation Approaches Remediation Approaches
ER.170 Develop Future State Transition Plan Future State Transition Plan
ER.180 Prepare for and Present Solution Recommendation Solution Recommendations
ER.190 Review Business Feedback and Identify Opportunities Opportunities Task List
ER.200 Prepare for Transition to Sales or Services Opportunities Action Plan
Maintain and Evolve Phase
ER.120.2 Identify and Mitigate Future State Risks Future State Risks
ER.130.2 Produce MoSCoW Improvement List MoSCoW Improvement List
ER.210 Monitor Current Situation and Pursue Relevant Updates Monitored Current Situation
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
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.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Lead the assessment. 100
Client Stakeholders Participate in the assessment. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Service Architecture Review this technique as input into this task.
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-020_ENVISION_ENGAGEMENT_STRATEGY.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PD Prepare for Discovery
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PD Prepare for Discovery
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Service Architecture Review this technique as input into this task.
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-030_ENVISION_ENGAGEMENT_PLAN.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
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.
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 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Stakeholder Capturing This technique provides guidance on what information should be captured about each stakeholder.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PD Prepare for Discovery
Back to Top
WORK PRODUCT
Agreed on Envision Engagement Plan
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
Client Project Manager *
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Envision Engagement Plan (ER.030) This is the plan which is validated and agreed to in this task.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DMCEC Define and Maintain Common Enterprise Concepts
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Define the models and viewpoints to be developed during the engagement. 100
Client Enterprise Architect Assist with defining the models and viewpoints. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Envision Engagement Strategy
(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.
Enterprise Stakeholder Inventory
(BA.015)
The Enterprise Stakeholder Inventory for the identified Business Scope determines what kind of stakeholders are involved.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Service Modeling
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Execute discovery of existing client materials and perform assessment of those materials. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Has the reference material been organized and cataloged?
Are the project team members aware of what existing reference materials is available?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Perform maturity and readiness assessment for the chosen roadmap/approach. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Envision Engagement Strategy
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-090_SOLUTION_READINESS_ASSESSMENT.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Are the Supplemental Enterprise Requirements complete?
Are the Supplemental Enterprise Requirements consistent?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
ER.110.2
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-110_BENEFIT_ANALYSIS.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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Identify risks and develop risk mitigation strategies for selected improvement options. 100
Client Enterprise Architect Assist the enterprise architect. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-120_FUTURE_STATE_RISKS.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
ER.130.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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
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.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA 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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
Enterprise Requirements
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-130_MOSCOW_IMPROVEMENT_LIST.DOC MS WORD
Tool Comments
Enterprise Architecture 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.
Oracle Enterprise Software Framework
Overview
The Oracle Enterprise Software Framework (ESF) is a framework for software classification.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business goals.
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
You should follow these 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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 Enterprise Architect Provide assistance, as appropriate. *
Client Project Sponsor Provide general business and IT concerns, strategies and constraints. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business Strategy (BA.010)
Enterprise Function or Process Model (BA.040)
Enterprise Domain Model (BA.050)
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
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.
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 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 Enterprise Architect Provide assistance, as appropriate. *
Client Solution Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Enterprise Function or Process Model
(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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Enterprise Process Model (BA.040)
Enterprise Domain Model (BA.050)
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Enterprise Function or Process Model
(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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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
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.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Client Enterprise Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-170_FUTURE_STATE_TRANSITION_PLAN.DOC MS WORD
Tool Comments
Enterprise Architecture 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.
Oracle Enterprise Software Framework
Overview
The Oracle Enterprise Software Framework (ESF) is a framework for software classification.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Were ALL stakeholders who participated in the process considered in the transition planning?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
Back to Top
WORK PRODUCT
Solution Recommendations
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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.
Prepare Presentation
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Scope and prepare presentation. Construct attendee list with input from customer/Oracle stakeholders. Conduct presentation. 100
Client Enterprise Architect Provide assistance, as appropriate. *
Client Stakeholders Attend presentation and agree on next steps. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business goals.
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
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
You need the following for this task:
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business goals.
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-190_OPPORTUNITIES_TASK_LIST.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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ER-200_OPPORTUNITIES_ACTION_PLAN.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Monitor situation and identify relevant updates. 100
Solution Architect Provide assistance, as appropriate. *
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to understand the business goals.
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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:
#TOP #TOP
Back to Top
APPROACH
This section is not yet available.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
Initiate Phase
BA.010 Identify Business Strategy Business Strategy
BA.012 Define Business Scope Business Scope
BA.015 Conduct Enterprise Stakeholder Assessment Enterprise Stakeholder Inventory
BA.017.1 Determine Metrics Collection and Reporting Strategy Metrics Collection and Reporting Strategy
BA.018.1 Establish Current Baseline Metrics Current Baseline Metrics
BA.020 Document Enterprise Organization Structures Enterprise Organization Structures
BA.025 Determine Operating Model Validated Operating Model
BA.030.1 Develop Enterprise Glossary Enterprise Glossary
BA.040 Create Enterprise Function or Process Model Function or Enterprise Process Model
BA.045 Develop Enterprise Business Context Diagram Enterprise Business Context Diagram
BA.050 Develop Enterprise Domain Model (Business Entities) Enterprise Domain Model
BA.055 Develop Enterprise Knowledge Flow Enterprise Knowledge Flow
BA.058 Develop Business Architecture Business Architecture
BA.060.1 Perform High-Level Use Case Discovery High-Level Use Cases
BA.060.2 Perform High-Level Use Case Discovery High-Level Use Cases
BA.065 Review Busines IT SLA Business-IT SLA Report
BA.067 Review Business Volumetrics Business Volumetrics Report
BA.070 Identify Candidate Services Service Portfolio - Candidate Services
BA.080 Identify Candidate Enterprise Business Rules Candidate Business Rules
BA.090 Identify Process Improvement Options Process Improvement Options
Maintain and Evolve Phase
BA.017.2 Determine Metrics Collection and Reporting Strategy Metrics Collection and Reporting Strategy
BA.018.2 Establish Current Baseline Metrics Current Baseline Metrics
BA.030.2 Develop Enterprise Glossary Enterprise Glossary
BA.100 Maintain Enterprise Business Models Maintained Enterprise Business Models
BA.110 Maintain Business Rules Maintained Business Rules
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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
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.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
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.
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Motivational Modeling
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.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BA-010_BUSINESS_STRATEGY.DOC MS WORD
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
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.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA 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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Business Scope Definition This technique provides assistance in how to define the scope.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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.
Stakeholders Detail -
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.
Stakeholders Detail -
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.
Stakeholders Detail -
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.
Stakeholders Detail -
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.
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
SUPPLEMENTAL GUIDANCE
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.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Stakeholder Capturing This technique provides guidance on what information should be captured about each stakeholder.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BA-015_ENTERPRISE_STAKEHOLDER_INVENTORY.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
BA.017.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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 Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference Architecture Planning service offering.
Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental information, use the SOA Reference Architecture Planning
Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
BA.018.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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.
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
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.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BA-020_ENTERPRISE_ORGANIZATION_STRUCTURES.DOC MS WORD
Tool Guidance Comments
Enterprise Architecture Resources The Enterprise Architecture Resources provides links to additional resources that may be useful in completing this task.
Example Example Note
Enterprise Organization Structures MS Visio
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLSs
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Guidance Comments
Enterprise Architecture Resources The 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 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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DMCEC Define and Maintain Common Enterprise Concepts
BA.030.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Develop and maintain the Enterprise Glossary. 100%
Client Enterprise Architect Work with the enterprise architect to develop and maintain the Enterprise Glossary *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Customer Envision Engagement Strategy
(ER.010)
Envision Engagement Strategy (ER.020)
Business Strategy (BA.010)
Business Scope (BA.012)
Enterprise Organization Structures
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
BA-030_ENTERPRISE_GLOSSARY.DOC MS WORD
Tool Guidance Comments
See Manufacturer's documentation UBMatrix third party non-Oracle software may be used for this task.
Enterprise Architecture Resources The Enterprise Architecture Resources provides links to additional resources that may be useful in completing this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Have all of the identified terms been explained with a proper definition, preferably with examples?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
9 Update Enterprise Repository. Updated Enterprise
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.
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
SUPPLEMENTAL GUIDANCE
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
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.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
Enterprise Requirements
Management
This technique provides assistance on how to manage requirements at the enterprise level.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
Tool Guidance Comments
Enterprise Architecture
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
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 Business Context Diagram. In addition, ensure that the Enterprise Business Context Diagram is added/updated in the repository.
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.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
Tool Guidance 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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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).
Enterprise Function or
Process Model (BA.040)
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
The following techniques are available to assist with this task:
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.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BA-050_ENTERPRISE_DOMAIN_MODEL.DOC MS WORD
Example Comments
Domain Model
Tool Comments
Enterprise Architecture
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
4 Update Enterprise Repository. Updated Enterprise
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
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 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.
Enterprise Function or
Process Model (BA.040)
Use the Enterprise Function or Process Model to understand relevant business processes.
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 Knowledge Flow. In addition, ensure that the Enterprise Knowledge Flow is added/updated in the repository.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
Enterprise Architecture
Resources
The Enterprise Architecture Resources contain additional information that can 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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
You need the following for this task:
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.
Enterprise Organization Structures
(BA.020)
The Enterprise Organization Structures provide information about how the organization is organized and is part of the Business
Organizational View.
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
Organizational View.
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
Organizational View.
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
improvement options.
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.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements
Management
This technique provides assistance on how to manage requirements at the enterprise level.
Stakeholder Capturing This technique provides guidance on what information should be captured about each stakeholder.
Use Case Levels This technique provides guidance in utilizing Cockburn's technique for describing the different levels of use case models.
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 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
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
Back to Top
WORK PRODUCT
Business-IT SLA Report - The Business-IT SLA Report specifies key business SLA categories.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Elicit existing formal business-IT SLAs for critical capabilities. 50
Enterprise Architect
(Business Architect)
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Enterprise Organization
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Enterprise Functional or
Process Model (BA.040)
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.
Metrics Collection and
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Enterprise Glossary (BA.030.1)
Enterprise Function or Process Model
(BA.040)
Enterprise Domain Model (BA.050)
High-Level Use Cases (BA.060)
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
added/updated in the repository.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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).
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Enterprise Glossary (BA.030)
Use these work products to identify Candidate Business Rules.
Enterprise Function or Process Model (BA.040)
Enterprise Domain Model (BA.050)
High-Level Use Cases (BA.060)
Governance Policies Catalog (GV.030)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Example Scenario Comments
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect (Lead) Identify improvement options. 40
Enterprise Architect
(Business Architect)
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business Strategy (BA.010) Use the Business Strategy to determine whether a possible improvement option lies within the objectives
of the enterprise.
Enterprise Function or Process Model (BA.040)
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
The following templates and tools are available to assist with this task:
Template File Name Comments
BA-090_PROCESS_IMPROVEMENT_OPTIONS.DOC MS WORD
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern
the Business Enterprise Models. Analyze the impact of change and register the changes per the Governance Implementation.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements Management This technique provides assistance on how to manage requirements at the enterprise level.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
ME.ACT.ME Maintain and Evolve
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:
No. Task Step Component
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Create/update the Candidate Business Rules and implemented rules. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
implementation format.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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 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.
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
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 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:
#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
TASKS AND WORK PRODUCTS
The tasks and work product s for this process are as follows:
ID Task Work Product
Envision
Initiate Phase
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 Readiness Assessment
EOCM.060 Prepare Project Team for Enterprise Culture Prepared Project Team
EOCM.070 Identify Change Agent Structure Change Agent Structure
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.150.2 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
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.150.3 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
OCM.155.2
Monitor Change Management Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication Campaign 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.150.4 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
OCM.155.3
Monitor Change Management Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication Campaign 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.150.5 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
OCM.155.4
Monitor Change Management Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication Campaign 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
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
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
high performance team. Collaborate with the change management specialist to make sure that change management and project
management activities and expectations are aligned.
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
CRITICAL SUCCESS FACTORS
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PD Prepare for Discovery
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
You should follow these steps:
No. Task Step Component Component Description
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
Produce and monitor Ad Hoc Communications selections.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
EOCM-010_AD_HOC_COMMUNICATIONS_STRATEGY_APPROACH.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
You should follow these steps:
No. Task Step Component Component Description
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
accomplish the workshop objectives.
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.
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. 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.
Proof of Concept, Envisioning and Enterprise Architecture
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
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 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Client's Organizational Change Management Strategy
(PJM.OCHM.010)
The Client's Organizational Change Management Strategy documents how the project solution is to be
implemented into the organization.
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.
Business Strategy (BA.010)
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
The following techniques are available to assist with this task:
Technique Comments
Workshop Techniques Handbook
The Workshop Techniques Handbook provides detailed descriptions of various techniques for delivering
workshops during client projects.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.CEAWE Conduct Executive Alignment Workshop - Envision
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
You should follow these steps:
No. Task Step Component Component Description
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.
3 Facilitate the work session on
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.
5 Facilitate the work session on
reporting structure.
Reporting Structure The Reporting Structure describes the reporting structure for the project.
6 Facilitate the work session on
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.
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.
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.
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 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.
Proof of Concept, Envisioning and Enterprise Architecture
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Change Management
Specialist
Lead and facilitate the Executive Alignment Workshop. 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 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Workshop Techniques
Handbook
The Workshop Techniques Handbook provides detailed descriptions of various techniques for delivering workshops during client
projects.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
EOCM-030_EXECUTIVE_BUS_OBJECTIVES_AND_GOV_RULES.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 commit to managing potential political issues
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.CEAWE Conduct Executive Alignment Workshop - Envision
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
You should follow these steps:
No. Task Step Component Component Description
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
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.
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 (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.
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 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 necessary activities to build and deploy the Sponsorship Program. This collaboration facilitates the
agreed upon organizational change.
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 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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Change Management
Specialist
Build and deploy the Sponsorship Program. 70
Enterprise Architect Assist with any architectural topics. 30
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 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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Executive Alignment Workshop Materials
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
EOCM-040_SPONSORSHIP_PROGRAM.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
The Sponsorship Program is used:
to commit executives to managing potential political issues
to cascade the involvement to the next management level
to deploy the Sponsorship Program
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
Roles and Responsibilities
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
Roles and Responsibilities
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.
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 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 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.
Proof of Concept, Envisioning and Enterprise Architecture
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Project Manager See the above The Project Manager and OCM section. Effort for the project manager is not included at the task level. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
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 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
mitigate organizational risks.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
EOCM-
050_PRELIMINARY_ENT_CHANGE_READINESS_ASSESSMENT.DOC
MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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 Presentation
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.
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 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 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.
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 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
The Prepared Project Team is ready to interact with the enterprise and is sensitive to cultural and political issues.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
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 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 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Project Manager See the above The Project Manager and OCM section. Effort for the project manager is not included at the task level. *
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
EOCM-070_CHANGE_AGENT_STRUCTURE.DOC MS Word
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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
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
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
Initiate Phase
BA.010 Identify Business Strategy Business Strategy
BA.012 Define Business Scope Business Scope
BA.015 Conduct Enterprise Stakeholder Assessment Enterprise Stakeholder Inventory
BA.017.1 Determine Metrics Collection and Reporting Strategy Metrics Collection and Reporting Strategy
BA.018.1 Establish Current Baseline Metrics Current Baseline Metrics
BA.020 Document Enterprise Organization Structures Enterprise Organization Structures
BA.025 Determine Operating Model Validated Operating Model
BA.030.1 Develop Enterprise Glossary Enterprise Glossary
BA.040 Create Enterprise Function or Process Model Function or Enterprise Process Model
BA.045 Develop Enterprise Business Context Diagram Enterprise Business Context Diagram
BA.050 Develop Enterprise Domain Model (Business Entities) Enterprise Domain Model
BA.055 Develop Enterprise Knowledge Flow Enterprise Knowledge Flow
BA.058 Develop Business Architecture Business Architecture
BA.060.1 Perform High-Level Use Case Discovery High-Level Use Cases
BA.060.2 Perform High-Level Use Case Discovery High-Level Use Cases
BA.065 Review Busines IT SLA Business-IT SLA Report
BA.067 Review Business Volumetrics Business Volumetrics Report
BA.070 Identify Candidate Services Service Portfolio - Candidate Services
BA.080 Identify Candidate Enterprise Business Rules Candidate Business Rules
BA.090 Identify Process Improvement Options Process Improvement Options
Maintain and Evolve Phase
EA.010.2 Review Architecture Principles, Guidelines and Standards Architecture Principles, Guidelines and Standards
EA.210 Maintain Enterprise Architectural Models Maintained Enterprise Architectural Models
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
Back to Top
WORK PRODUCT
Assigned Enterprise Architect - The Assigned Enterprise Architect is engaged with the enterprise.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DMCEC Define and Maintain Common Enterprise Concepts
EA.010.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
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
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.
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 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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
Architecture Principles, Guidelines and Standards. In addition, ensure that the Architecture Principles, Guidelines and Standards are
added/updated in the repository.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
EA-010_ARCHITECTURE_PRINCIPLES_GUIDELINES_STANDARDS.DOC MS WORD
Tool Comments
Enterprise Architecture 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.
Oracle Enterprise Software Framework
Overview
The Oracle Enterprise Software Framework (ESF) is a framework for software classification.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
EA-030_CURRENT_ENTERPRISE_ARCHITECTURE.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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
IT Project Portfolio (IP.010)
Current Enterprise Architecture (EA.030)
Review these work products to understand the current situation in which you will identify architectural challenges.
Enterprise Process Model (BA.040)
Enterprise Domain Model (BA.050)
Use these models to identify possible challenges.
Supplemental Enterprise Requirements (ER.100) Review these requirements to help identify possible challenges.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Have all views of the enterprise architecture been considered?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
Relationship to Implement
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Provide input to the solution architect. 20
Solution Architect
(Technical 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
(Technical Architect)
Provide input to the solution architect. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
Is the Business Capacity Plan complete?
Is the Business Capacity Plan consistent, especially with reference to the Supplemental Enterprise Requirements?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
to the Envision project team
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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.
Consider the following:
Business Strategy (BA.010)
Architecture Principles, Guidelines and Standards (EA.010)
Current Enterprise Architecture (EA.030)
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
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.
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 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.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Provide the business perspective for key aspects of the Technology Reference Architectures. 20
Solution Architect
(Technical 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Business Strategy (BA.010)
Supplemental Enterprise
Requirements (ER.100)
External Reference Architectures
Review (EA.002)
Architecture Principles,
Guidelines and Standards
(EA.010)
Current Enterprise Architecture
(EA.030)
Current Architectural Challenges
(EA.050)
Use these work products to develop the Technology Reference Architectures.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
EA-075_SOA_REFERENCE_ARCHITECTURE.DOC MS WORD - Use this template when developing a SOA Reference Architecture.
Tool Comments
Enterprise Architecture 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.
Oracle Enterprise Software Framework
Overview
The Oracle Enterprise Software Framework (ESF) is a framework for software classification.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Current Enterprise Architecture
(EA.030)
Architectural Gaps and
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
The following templates and tools are available to assist with this task:
Template File Name Comments
EA-110_FUTURE_STATE_ENTERPRISE_ARCHITECTURE.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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
Back to Top
WORK PRODUCT
Information Architecture - The Information Architecture identifies the business objects in the overall enterprise.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
This task is executed in parallel with the following tasks:
Information Architecture (EA.120)
Applications Architecture (EA.140)
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
This becomes the enterprise information that will provide requirements information
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
This becomes the enterprise information that will provide requirements information
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
This becomes the enterprise information that will provide requirements information
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
This becomes the enterprise information that will provide requirements information
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
Relationship to Implement
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Oversee consistency with other future state architecture models. 20
Solution Architect
(Technical 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Supplemental Enterprise Requirements (ER.100)
Future State Enterprise Architecture (EA.110)
Applications Architecture (EA.140)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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 .
This task is executed in parallel with the following tasks:
Future State Enterprise Architecture (EA.110)
Enterprise Function and Process Model (BA.040)
Enterprise Business Context Diagram (BA.045)
High-Level Use Cases (BA.060)
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
Application Architecture
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 architecture.
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.
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Oversee consistency with other future state architecture models. 40
Solution Architect
(Application 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Enterprise Organization Structures
(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.
Supplemental Enterprise
Requirements (ER.100)
Desired Future State (ER.160) The Desired Future State defines in business terms the desired end state.
Future State Enterprise
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
Enterprise Architecture Resources The Enterprise Architecture Resources provides links to additional resources that may be useful in completing this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Current Enterprise Architecture
(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.
Architectural Gaps and
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
to the Envision project team
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
Back to Top
WORK PRODUCT
Business Rules Implementation Strategy
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
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
Review Work Products
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
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
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Make recommendations on how the remaining rules should be handled. 30
Solution Architect
(Technical Architect)
Provide input on which candidate rules are suitable for implementation in a particular product, such as a rule engine. 70
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
MoSCoW Improvement List (ER.130) Use the MoSCoW Improvement List to view the priorities of the various elements of the future architecture.
Future State Enterprise 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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
"Implementing Rules in ADF Business
Components" - White Paper
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 Business Rules
http://www.oracle.com/appserver/rules.html
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Enterprise Architect
(Business Architect)
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Future State Enterprise
Architecture (EA.110)
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.
Information Architecture
(EA.120)
Review the Information Architecture to form a basis for the Product Implementation Prioritization Report.
Technology Architecture
(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.
Future State Transition
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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.
Roles and Responsibilities
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.
Enterprise Architect
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Set the standards and guidelines regarding reuse/buy/make policies, choice of implementation technologies, implementation
methodologies, and implementation governance policies.
100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Current Enterprise Architecture
(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.
Information Architecture
(EA.120)
The work product provides the Information Architecture that has to be supported by the Development Framework.
Technology Architecture
(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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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:
#TOP #TOP
Back to Top
APPROACH
This section is not yet available.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
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.050.1 Prioritize Projects Prioritize Projects
IP.060 Develop IT Portfolio Plan IT Portfolio Plan
Maintain and Evolve Phase
IP.050.2 Prioritize Projects Prioritize Projects
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
This section is not yet available.
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
Identify Overlap and Redundancy
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
SUPPLEMENTAL GUIDANCE
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
inventoried projects and their relationships to other IT assets. In addition, ensure that the inventoried projects and their relationships are
added/updated in the repository.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
The Oracle Enterprise Repository is a COTS Enterprise Repository tool solution that is used to establish and maintain an Enterprise
Repository.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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.
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 Applications.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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.
Identify Overlap and Redundancy
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Interview stakeholders to compile the IT Applications Portfolio. 80
Solution Architect
(Application 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
inventoried applications and their relationships to other IT assets. In addition, ensure that the inventoried applications and their relationships are
added/updated in the repository.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
The Oracle Enterprise Repository is a COTS Enterprise Repository tool solution that is used to establish and maintain an Enterprise
Repository.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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.
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 Services.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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.
Identify Overlap and Redundancy
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
inventoried services and their relationships to other IT assets. In addition, ensure that the inventoried services and their relationships are
added/updated in the repository.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
The Oracle Enterprise Repository is a COTS Enterprise Repository tool solution that is used to establish and maintain an Enterprise
Repository.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Review current state and planned/underway projects to determine strengths/weaknesses. Analyze impact of planned offerings. 100
Client Enterprise Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Current Enterprise
Architecture (EA.030)
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Analyze Candidate Services and select services to be included in implementation proposal. 50
Solution Architect
(Application 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
proposed services and their relationships to other IT assets. In addition, ensure that the final proposed services and their relationships are
added/updated in the repository.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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.
SOA Service Boundary
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
The following templates and tools are available to assist with this task:
Template File Name Comments
IP-
014_SERVICE_PORTFOLIO.XLS
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.
Example Scenario Comments
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
Tool Comments
Enterprise Architecture
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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:
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 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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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.
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 task would have preceded this task, Populate Services Repository.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Submit initial list of Candidate Services into repository. 30
Solution Architect
(Technical Architect)
Migrate existing Services Portfolio into repository. 70
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
IT Asset Management Use this technique to access information on the meta data descriptions for services and usage agreements.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Analyze Candidate Rules into categories. 70
Solution Architect
(Application Architect)
Determine rule enforcement strategy per category. 30
Client Enterprise Architect Analyze Candidate Rules into categories. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Candidate Business Rules (BA.080) The Candidate Business Rules are being analyzed in this task.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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.
Determine Dependencies
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
SUPPLEMENTAL GUIDANCE
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.
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
IP-040_CANDIDATE_PROJECTS.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.
Oracle Enterprise Software Framework
Overview
The Oracle Enterprise Software Framework (ESF) is a framework for software classification.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
IP.050.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Review and update the IT Portfolio Plan. 20
Project Managers Provide status, estimates and actuals on projects. 80
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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
This section is not yet available.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
Initiate Phase
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
Maintain and Evolve Phase
GV.020.2 Determine Regulatory and Business Mandates Mandate Matrix
GV.030.2 Discover or Define Policies Governance Policies Catalog
GV.050.2 Define Policy Implementation Processes Policy Implementation Processes
GV.060.2 Define Policy Implementation Tooling Governance Policy Tooling
GV.070.2 Define Policy Metrics Measurements Portfolio
GV.080.2 Define Policy Monitoring Processes Policy Monitoring Processes
GV.090.2 Determine Funding Model Funding Model
GV.100.2 Implement Governance Governance Implementation
GV.110 Monitor and Analyze Governance Processes Governance Implementation Improvement Proposal
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.PEF Prepare Envision Foundation
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
You should follow these steps:
No. Task Step Component Component Description
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
Governance Strategy.
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
Governance Strategy.
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Provide the IT knowledge to ensure all appropriate measures are defined. 60
Enterprise Architect
(Business Architect)
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 Enterprise Architect Provide assistance, as appropriate. *
Client Stakeholders Own the Governance Strategy and execute against that strategy. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business Strategy (BA.010)
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Conduct interviews to establish a baseline view of current Governance. 100
Client Enterprise Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect
(Business Architect)
Compile Mandate Matrix. Preferably, this should be done by an enterprise architect that specializes in Business Architecture. 100
Client Enterprise Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
GV.020.1
Prerequisite Usage
Business Strategy (BA.010)
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.
Enterprise Organization Structures
(BA.020)
Use the Enterprise Organization Structures to understand what kind of organization units and regions comprise the
enterprise.
Enterprise Function or Process Model
(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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
GV.030.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
Enterprise Repository.
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
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Compile Governance Policies Catalog. 20 (EA)
Enterprise Architect
(Business Architect)
80
(BAR)
Client Enterprise Architect Assist in the discovery process. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Architecture Principles, Guidelines and
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
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
You should follow these steps:
No. Task Step Component Component Description
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.
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect
Enterprise Architect
(Business Architect)
Conduct Impact Study and develop proposals for organizational changes. 30 (EA)
70
(BAR)
Client Enterprise Architect Collaborate to develop proposals for organizational changes. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance Strategy (GV.010) Use the Governance Strategy to understand potential organizational impact.
Enterprise Organization
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.
Governance Policies Catalog
(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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
GV.050.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect
Enterprise Architect
(Business Architect)
Determine how policies will be implemented and define policy steps. 60 (EA)
40
(BAR)
Client Enterprise Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Governance Policies Catalog
(GV.030)
Use the Governance Policies Catalog to determine which policies need process descriptions.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
GV.060.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Present recommended tooling to client. 20
Solution Architect Provide tooling options to enterprise architect with benefits and prerequisites. 80
Client Enterprise Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
GV.070.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Compile Measurements Portfolio. 100
Client Enterprise Architect Provide assistance, as appropriate. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance Strategy (GV.010)
Mandate Matrix (GV.020)
Governance Policies Catalog (GV.030)
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
GV.080.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
targeted individuals at 3pm each Friday.
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
targeted individuals at 3pm each Friday.
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Establish and agree on monitoring process for successful Governance. 100
Client Enterprise Architect Provide assistance, as appropriate. *
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance Policies Catalog (GV.030)
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
GV.090.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect
(Business Architect)
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 *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
programs and projects.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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
Enterprise Repository.
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
programs and projects.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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 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
The following techniques are available to assist with this task:
Technique Comments
IT Asset Management Use this technique as a reference for program and project meta data descriptions.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
3 Determine application
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.
6 Determine application
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
Determine Reporting Requirements
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 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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 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
The following techniques are available to assist with this task:
Technique Comments
IT Asset Management Use this technique as a reference for applications meta data descriptions.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 to the setup of an Enterprise Repository
as an input for Governance implementation (GV.100)
Distribute the Applications 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 modification of applications and related assets [controlled as part of the Governance Implementation (GV.100)]
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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?
Have the appropriate associations with other IT assets been identified?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
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 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.
Determine Reporting Requirements
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 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. 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
SUPPLEMENTAL GUIDANCE
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Development Lifecycle
(SDLC) Staff
Provide requirements. *
Client CIO Provide requirements. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
as an input to the setup of an Enterprise Repository
as an input for Governance Implementation (GV.100)
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
Use the following criteria to check the quality of this work product:
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?
Have the appropriate associations with other IT assets been identified?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
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
You should follow these steps:
No. Task Step Component Component Description
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.
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 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.
Determine Reporting Requirements
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 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. 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Development Lifecycle
(SDLC) Staff
Provide requirements. *
Client CIO Provide requirements. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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 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
Governance policies.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
IT Asset Management Use this technique as a reference for other meta data descriptions.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
as an input to the setup of an Enterprise Repository
as an input for Governance Implementation (GV.100)
Distribute the Other Meta Data Descriptions as follows:
to individuals setting up the Enterprise Repository supporting the Governance Implementation
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
INIT.ACT.DSPC Develop Solution and Present to Client
GV.090.2
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
Governance policies.
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
Enterprise Repository.
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
ME.ACT.ME Maintain and Evolve
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
You should follow these steps:
No. Task Step Component Component Description
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
improvement options.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Measurements Portfolio (GV.070) Use the Measurements Portfolio to determine the method and metrics for measuring the success of the Governance
Implementation.
Governance Implementation
(GV.100)
The current Governance Implementation is the subject of the assessment and improvement proposals.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Focus Area Overview
Method Navigation Current Page Navigation
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.
[OCM] Organizational Change Management Process
The Organizational Change Management process starts at the strategic level with executives and then identifies the particular human and organizational challenges of the
technology implementation in order to design a systematic, time-sensitive, and cost-effective approach to lowering risk that is tailored to each organizations specific
needs. In addition to increasing user adoption rates, carefully planning for and managing change in this way allows organizations to maintain productivity through often-
difficult technological transitions. This in turn enables the organization to more easily meet deadlines, realize business objectives, and maximize return on investment.
[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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[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
The following is a list of the objectives of this phase:
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
The following processes are active in this phase:
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
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.
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).
Technical Architecture
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
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
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product
Business Requirements
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
Requirements Analysis
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
Mapping and Configuration
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
Performance Management
PT.010 Conduct Performance Management Workshop Performance Management Workshop Results
Technical Architecture
TA.004 Perform Technical Architecture Impact Analysis Technical Architecture Impact Analysis
TA.010 Conduct Technical Architecture Workshop Technical Architecture Workshop Results
Data Acquisition and Conversion
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
Organizational Change Management
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
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
ACTIVITY FLOW DIAGRAM
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
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
A.ACT.TPT - Train Project Team
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
RD.030 Develop Current Business Process Model
RD.034 Document Current Business Baseline Metrics
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 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
You will need the following for this activity:
A.ACT.GBRI Gather Business Requirements - Inception
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 prioritize the requirements, detail the supplemental requirements and develop use case models that describe the solution requirements.
Back to Top
PREREQUISITES
You will need the following for this activity:
A.ACT.GBRI Gather Business Requirements - Inception
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
A.ACT.GBRI - Gather Business Requirements - Inception
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
RD.140.1 Create Requirements Specification
RD.150.1 Review Requirements Specification
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 consolidate the requirements into a single work product and perform peer review of the software specifications.
Back to Top
PREREQUISITES
You will need the following for this activity:
A.ACT.GR Gather Solution Requirements
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
A.ACT.CCPI - CREATE CONCEPTUAL PROTOTYPE -
INCEPTION
B.ACT.CCPE - CREATE CONCEPTUAL PROTOTYPE -
ELABORATION
These activities consists of developing and validating the Conceptual Prototype.
*This activity has Application Implementation supplemental activity guidance.
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
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 these activities is to develop a Conceptual Prototype that assists in defining business requirements and user interface requirements early in the project.
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
You will need the following for this activity:
A.ACT.CCPI - Create Conceptual Prototype - Inception
A.ACT.GR Gather Solution Requirements
B.ACT.CCPE - Create Conceptual Prototype - Elaboration
B.ACT.DUCM Develope Use Case Model
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop 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
You will need the following for this activity:
A.ACT.GBRI Gather Business Requirements - Inception
A.ACT.GR Gather Solution Requirements
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
MC.010.1 Define Business Data Structures
MC.020 Define Business Data Structure Setups
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 design and define the key business structures and define the data/values needed to configure those key business structures.
Back to Top
PREREQUISITES
You will need the following for this activity:
A.ACT.GBRI Gather Business Requirements - Inception
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
OCM.010 Create and Manage Ad Hoc Communications
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 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
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the materials for and conduct the Executive Alignment Workshop and build and deploy the Sponsorship Program.
Back to Top
PREREQUISITES
You will need the following for this activity:
A.ACT.GBRI - Gather Business Requirements - Inception
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the 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
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the materials for each workshop and then conduct the workshops.
Back to Top
PREREQUISITES
You will need the following for this activity:
A.ACT.CEAW Conduct Executive Alignment Workshop
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the 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
You will need the following for this activity:
A.ACT.CEAW Conduct Executive Alignment Workshop
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
OCM.140 Develop Communication Campaign
OCM.150.1 Conduct Change Management Roadmap/Communication Campaign
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 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
You will need the following for this activity:
A.ACT.CCRA Conduct Change Readiness Assessment
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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.GBRI Gather Business Requirements - Inception
A.ACT.ECBB Establish Current Business Baseline
A.ACT.GR Gather Solution Requirements
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.CEAW Conduct Executive Alignment Workshop
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[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
The following is a list of the objectives of this phase:
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
The following processes are active in this phase:
Business Requirements (RD)
Requirements Analysis (RA)
Mapping and Configuration (MC)
Analysis (AN)
Design (DS)
Implementation (IM)
Testing (TE)
Performance Management (PT)
Technical Architecture (TA)
Data Acquisition and Conversion (CV)
Documentation (DO)
Organizational Change Management (OCM)
Training (TR)
Transition (TS)
Back to Top
KEY WORK PRODUCTS
Refer to Key Work Products for a complete list of key work products in OUM.
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.
Business Requirements
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.
Requirements Analysis
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.
Mapping and Configuration
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.
Performance Management
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.
Technical Architecture
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.
Data Acquisition and Conversion
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.
Organizational Change Management
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
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product
Business Requirements
RD.011.2 Develop Future Process Model Future Process Model
RD.042.2 Develop Glossary Glossary
RD.045.2 Prioritize Requirements (MoSCoW) Moscow List
RD.140.2 Create Requirements Specification Requirements Specification
RD.150.2 Review Requirements Specification Reviewed Requirements Specification
Requirements Analysis
RA.021.2 Capture User Stories User Story
RA.023.2 Develop Use Case Model Use Case Model
RA.024.1 Develop Use Case Details Use Case Specification
RA.025.2 Identify Candidate Services Service Portfolio - Candidate Services
RA.026.1 Populate Services Repository Populated Services Repository
RA.027.2 Identify Candidate Business Rules Candidate Business Rules
RA.028.2 Populate Business Rules Repository Populated Business Rules Repository
RA.030.2 Validate Conceptual Prototype Validated Conceptual Prototype
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
Mapping and Configuration
MC.010.2 Define Business Data Structures Business Data Structures
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.090.2 Conduct Reporting Fit Analysis Reporting Fit Analysis
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.005.2 Develop Conceptual Prototype Conceptual Prototype
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.005.2 Determine Testing Requirements Testing Requirements
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.025.2 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
Performance Management
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
Technical Architecture
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
Data Acquisition and Conversion
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
Organizational Change Management
OCM.150.2 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
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
Training
TR.010.2 Define Training Strategy Education and Training Strategy
Transition
TS.020.1 Define Cutover Strategy Cutover Strategy
Back to Top
ACTIVITY FLOW DIAGRAM
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
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop 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
You will need the following for this activity:
A.ACT.LCOB Lifecycle Objective Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
A.ACT.LCOB Lifecycle Objective Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the 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
You will need the following for this activity:
A.ACT.LCOB Lifecycle Objective Milestone
B.ACT.Di Define Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to create or refine the business process models and document role-based procedures based on the processes.
Back to Top
PREREQUISITES
You will need the following for this activity:
A.ACT.LCOB Lifecycle Objective Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 prepare plans for Testing. This includes Integration, System, Systems Integration and Acceptance testing.
Back to Top
PREREQUISITES
You will need the following for this activity:
B.ACT.DPS Define Project Strategy
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define and 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
You will need the following for this activity:
A.ACT.LCOB Lifecycle Objective Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Configuration Prototype Environment and conduct the workshop(s).
Back to Top
PREREQUISITES
You will need the following for this activity:
B.ACT.SSC Specify Software Configuration
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
MC.100 Define and Estimate Application Extensions
MC.110 Define Gap Resolutions
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to review 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
You will need the following for this activity:
B.ACT.GBRE Gather Business Requirements - Elaboration
B.ACT.PVC Prototype and Validate Configuration
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
B.ACT.DUCM - DEVELOP USE CASE MODEL
During this activity, you develop the Use Case Model.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
ID Task Name
RA.021.2 Capture User Stories
RA.023.2 Develop Use Case Model
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the Use Case Model and identify the use cases.
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
You will need the following for this activity:
B.ACT.GBRE Gather Business Requirements - Elaboration
B.ACT.PGA Perform Gap Analysis
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
A.ACT.CCPI - CREATE CONCEPTUAL PROTOTYPE -
INCEPTION
B.ACT.CCPE - CREATE CONCEPTUAL PROTOTYPE -
ELABORATION
These activities consists of developing and validating the Conceptual Prototype.
*This activity has Application Implementation supplemental activity guidance.
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
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 these activities is to develop a Conceptual Prototype that assists in defining business requirements and user interface requirements early in the project.
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
You will need the following for this activity:
A.ACT.CCPI - Create Conceptual Prototype - Inception
#TOP #TOP
A.ACT.GR Gather Solution Requirements
B.ACT.CCPE - Create Conceptual Prototype - Elaboration
B.ACT.DUCM Develope Use Case Model
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
RD.042.2 Develop Glossary
RD.045.2 Prioritize Requirements (MoSCoW)
RD.140.2 Create Requirements Specification
RD.150.2 Review Requirements Specification
RA.025.2 Identify Candidate Services
RA.027.2 Identify Candidate Business Rules
RA.028.2 Populate Business Rules Repository
RA.180.1 Review Use Case Model
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 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
You will need the following for this activity:
B.ACT.GBRE Gather Business Requirements - Elaboration
B.ACT.DUCM Develop Use Case Model
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define 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
You will need the following for this activity:
B.ACT.CS Consolidate Specification
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
B.ACT.DUCD - DEVELOP USE CASE DETAILS
During this activity, you develops the use case details.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
ID Task Name
RA.024.1 Develop Use Case Details
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 further detail the use cases in preparation for use case realization producing the solution design.
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
You will need the following for this activity:
B.ACT.BSA Baseline Software Architecture
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
B.ACT.AE - ANALYZE - ELABORATION
This activity allows for analyzing the captured requirements by refining and structuring them in the Analysis Model.
*This activity has Application Implementation supplemental activity guidance.
Back to Top
OBJECTIVES
The objective for this activity is to analyze the use cases and requirements.
Back to Top
TASKS
The tasks included in this activity are:
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
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 perform analysis of the use cases and prepare and review the Analysis Model.
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
You will need the following for this activity:
B.ACT.DUCD Develop Use Case Details
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
B.ACT.DE - DESIGN - ELABORATION
This activity allows for designing the system to meet all functional and supplemental requirements.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
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
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 realize the use cases into a software Design Model.
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
You will need the following for this activity:
B.ACT.AE Analyze - Elaboration
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TE.020.2 Develop Unit Test Scripts
TE.035.2 Create Integration Test Scenarios
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Unit Test Scripts and the Integration Test Scenarios.
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 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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TE.025.2 Create System Test Scenarios
The tasks included in the Develop System Test Scenarios - Construction activity are:
ID Task Name
TE.025.3 Create System Test Scenarios
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the System Test Scenarios.
Back to Top
PREREQUISITES
You will need the following for these activities:
B.ACT.DSTSE - Develop System Test Scenarios - Elaboration
B.ACT.DE Design - Elaboration
C.ACT.DSTSC - Develop System Test Scenarios - Construction
B.ACT.LCAR Lifecycle Architecture Milestone (if no custom development)
C.ACT.DC Design - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare 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.
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
You will need the following for this activity:
B.ACT.DE Design - Elaboration
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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.
*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 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
TE.030.2 Perform Unit Test
TE.040.2 Perform Integration Test
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 performed unit and integration tests when and as needed.
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 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.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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TE.070.1 Perform System Test
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 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
You will need the following for these activities:
B.ACT.PEE Prepare Environments - Elaboration
B.ACT.DSTSE Develop System Test Scenarios - Elaboration
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TE.072.2 Test Pre-Upgrade Steps
TE.073.2 Test Packaged Software Upgrade
TE.074.2 Test Post-Upgrade Steps
TE.075.2 Perform Post-Upgrade Reconciliation Testing
TE.076.2 Review Upgrade Test Results
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 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
You will need the following for these activities:
B.ACT.VUPE Validate Upgrade Process - Elaboration
B.ACT.SSC Specify Software Configuration
C.ACT.VUPC Validate Upgrade Process - Construction
C.ACT.ACDC Acquire and Convert Data - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the 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
You will need the following for this activity:
A.ACT.LCOB Lifecycle Objective Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define and prepare 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.
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
You will need the following for this activity:
B.ACT.DPS Define Project Strategy
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
OCM.160 Prepare Business Process Impact Inventory
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 task, Prepare Business Process Impact Inventory and capture the impact of the business process changes.
Back to Top
PREREQUISITES
You will need the following for this activity:
B.ACT.GBRE Gather Business Requirements - Elaboration
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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,
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
The tasks included in these activities are:
ID Task Name
OCM.150 Conduct Change Management Roadmap / Communication Campaign
OCM.155 Monitor Change Management Roadmap / Communication Campaign Effectiveness
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 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
You will need the following for these activities:
B.ACT.DCMRCCE Deploy Change Management Roadmap / Communication Campaign
- Elaboration
A.ACT.LCOB Lifecycle Objective Milestone
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
B.ACT.LCAR - LIFECYCLE ARCHITECTURE 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 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.
Estimate cost and plan.
Prepare project environment.
Mitigate risks.
Back to Top
ACTIVITIES
The following activities are included in this milestone:
B.ACT.DPS Define Project Strategy
B.ACT.DI Define Infrastructure
B.ACT.PEE Prepare Environments - Elaboration
B.ACT.GBRE Gather Business Requirements - Elaboration
B.ACT.DTP Develop Test Plans
B.ACT.SSC Specify Software Configuration
B.ACT.PVC Prototype and Validate Configuration
B.ACT.PGA Perform Gap Analysis
B.ACT.DUCM Develop Use Case Model
B.ACT.CCPE Create Conceptual Prototype - Elaboration
B.ACT.CS Consolidate Specification
B.ACT.BSA Baseline Software Architecture
B.ACT.DUCD Develop Use Case Details
B.ACT.AE Analyze Elaboration
B.ACT.DE Design Elaboration
B.ACT.DCCTSE Develop Custom Component Test Scripts - Elaboration
B.ACT.DSTSE Develop System Test Scenarios - Elaboration
B.ACT.DVCSP Develop and Validate Custom Software Prototypes
B.ACT.PCCTE Perform Custom Component Testing - Elaboration
B.ACT.PSTE Perform System Test - Elaboration
B.ACT.VUPE Validate Upgrade Process - 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
The following checklist is available to assist with determination of completeness for this activity:
Checklist Name Comments
Elaboration Phase / Lifecycle Architecture (LA) Milestone Checklist MS Word
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[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-
Based Business Solutions for further information on the scalability and adaptability of OUM.
Back to Top
OBJECTIVES
#TOP
The following is a list of the objectives of this phase:
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
The following processes are active in this phase:
Business Requirements (RD)
Requirements Analysis (RA)
Mapping and Configuration (MC)
Analysis (AN)
Design (DS)
Implementation (IM)
Testing (TE)
Performance Management (PT)
Technical Architecture (TA)
Data Acquisition and Conversion (CV)
Documentation (DO)
Organizational Change Management (OCM)
Training (TR)
Transition (TS)
Back to Top
KEY WORK PRODUCTS
Refer to Key Work Products for a complete list of key work products in OUM.
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.
Business Requirements
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.
Requirements Analysis
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.
Mapping and Configuration
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).
Performance Management
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).
Technical Architecture
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.
Data Acquisition and Conversion
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.
Organizational Change Management
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
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product
Business Requirements
RD.042.2 Develop Glossary Glossary
RD.045.2 Prioritize Requirements (MoSCoW) Moscow List
RD.130.2 Develop Baseline Architecture Description Architecture Description
Requirements Analysis
RA.021.3 Capture User Stories User Story
RA.023.3 Develop Use Case Model Use Case Model
RA.024.2 Develop Use Case Details Use Case Specification
RA.025.3 Identify Candidate Services Service Portfolio - Candidate Services
RA.026.2 Populate Services Repository Populated Services Repository
RA.027.3 Identify Candidate Business Rules Candidate Business Rules
RA.028.3 Populate Business Rules Repository Populated Business Rules Repository
RA.055.2 Document Business Procedures Business Procedure Documentation
RA.170.2 Conduct Data Quality Assessment High-Level Data Quality Assessment
RA.180.2 Review Use Case Model Reviewed Use Case Model
Mapping and Configuration
MC.050.2 Define Application Setups Application Setup Documents
Analysis
AN.035.2 Update Existing Analysis Specification Updated Analysis Specification
AN.040.2 Develop Analysis Architecture Description Architecture Description
AN.050.2 Analyze Data Data Analysis
AN.060.2 Analyze Behavior Behavior Analysis
AN.070.2 Analyze Business Rules Business Rules Analysis
AN.080.2 Analyze Services Service Portfolio - Proposed Services
AN.085.2 Design Service Service Definition
AN.090.2 Analyze User Interface User Interface Analysis
AN.100.2 Prepare Analysis Specification Analysis Specification
AN.110.2 Review Analysis Model Reviewed Analysis Model
Design
DS.035.2 Update Existing Design Specification Updated Design Specification
DS.040.2 Develop Design Architecture Description Architecture Description
DS.080.2 Design Software Components Software Component Design
DS.090.2 Design Data Component Data Design
DS.100.2 Design Behavior Component Behavior Design
DS.110.2 Design Business Rules Business Rules Design
DS.120.2 Design Services Service Design
DS.130.2 Design User Interface User Interface Design
DS.140.2 Prepare Design Specification Design Specification
DS.150.2 Develop Database Design Logical Database Design
DS.160.2 Review Design Model Reviewed Design Model
Implementation
IM.007.2 Prepare Development Environment Development Environment
IM.040.2 Implement Database Implemented Database
IM.050 Implement Components Implemented Components
IM.053.2 Register Services Populated Services Registry
IM.055.2 Perform Business Rules Implementation (Rules Engine) Implemented Business Rules (Rules Engine)
IM.060.2 Perform Component Review Component Review Results
IM.070 Assemble Components Assembled Components
IM.080 Integrate Services Integrated Services
IM.090 Create Installation Routines Installation Routines
Testing
TE.015.2 Develop Integration Test Plan Integration Test Plan
TE.018.2 Prepare Static Test Data Static Test Data
TE.019.2 Collect, Assess and Refine KPI Measurements Key Business Strategies and Objectives
TE.020.2 Develop Unit Test Scripts Unit Test Scripts
TE.025.3 Create System Test Scenarios System Test Scenarios
TE.030.2 Perform Unit Test Unit-Tested Components
TE.035.2 Create Integration Test Scenarios Integration Test Scenarios
TE.038.2 Prepare Integration Test Environment Integration Test Environment
TE.040.2 Perform Integration Test Integration-Tested Components
TE.050.2 Develop System Test Plan System Test Plan
TE.060.2 Prepare System Test Environment System Test Environment
TE.065 Perform Installation Test Tested Installation Routines
TE.070.2 Perform System Test System-Tested Applications
TE.072.2 Test Pre-Upgrade Steps Packaged Software Upgrade Checklist
TE.073.2 Test Packaged Software Upgrade Pre-Upgrade Checklist
TE.074.2 Test Post-Upgrade Steps Post-Upgrade Checklist
TE.075.2 Perform Post-Upgrade Reconciliation Testing Reconciliation Test Report
TE.076.2 Review Upgrade Test Results Upgrade Test Analysis
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
Performance Management
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
Technical Architecture
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
Data Acquisition and Conversion
CV.027.2 Perform Data Mapping Data Mapping
CV.030.2 Prepare Conversion Environment (Initial Load) Conversion Environment (Initial Load)
CV.035.2 Define Manual Conversion Procedures (Initial Load) Manual Conversion Procedures (Initial Load)
CV.040.2 Design Conversion Components (Initial Load) Conversion Component Designs (Initial Load)
CV.050.2 Prepare Conversion Test Plans (Initial Load) Conversion Test Plans (Initial Load)
CV.055.2 Implement Conversion Components (Initial Load) Conversion Components (Initial Load)
CV.060.2 Perform Conversion Component Unit Test (Initial Load) Unit-Tested Conversion Components (Initial Load)
CV.062.2 Perform Conversion Component Business Object Test (Initial Load) Business Object-Tested Conversion Components (Initial Load)
CV.063.2 Perform Conversion Component Validation Test (Initial Load) Validation-Tested Conversion Components (Initial Load)
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
Organizational Change Management
OCM.150.3 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
OCM.155.2 Monitor Change Management Roadmap / Communication Campaign Effectiveness Change Management Roadmap / Communication Campaign 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
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.020.2 Define Cutover Strategy Cutover Strategy
TS.030 Develop Installation Plan Installation Plan
TS.040 Design Production Support Infrastructure Production Support Infrastructure Design
Back to Top
ACTIVITY FLOW DIAGRAM
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
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
C.ACT.FR - FINALIZE REQUIREMENTS
This activity consists of updating and finalizing the requirements.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
ID Task Name
RD.042.3 Develop Glossary
RD.045.3 Prioritize Requirements (MoSCoW)
RD.130.2 Develop Baseline Architecture Description
RA.021.3 Capture User Stories
RA.023.3 Develop Use Case Model
RA.024.2 Develop Use Case Details
RA.025.3 Identify Candidate Services
RA.027.3 Identify Candidate Business Rules
RA.028.3 Populate Business Rules Repository
RA.180.2 Review Use Case Model
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 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.
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
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
C.ACT.AC - ANALYZE - CONSTRUCTION
This activity allows for analyzing the captured requirements by refining and structuring them in the Analysis Model .
*This activity has Application Implementation supplemental activity guidance.
Back to Top
OBJECTIVES
The objective for this activity is to analyze the use cases and requirements.
Back to Top
TASKS
The tasks included in this activity are:
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
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 perform analysis of the use cases and prepare and review the Analysis Model.
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.
PREREQUISITES
You will need the following for this activity:
C.ACT.FR Finalize Requirements
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
C.ACT.DC - DESIGN - CONSTRUCTION
This activity allows for designing the system to meet all functional and supplemental requirements.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
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
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 realize the use cases into a software Design Model.
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
You will need the following for this activity:
C.ACT.AC Analyze - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TE.015.2 Develop Integration Test Plan
TE.050.2 Develop System Test Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to 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
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
C.ACT.PEC - PREPARE ENVIRONMENTS - CONSTRUCTION
This activity consists of preparing all the the Development and Integration Test Environments.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Development and Integration Test Environments required during the Construction phase. It also includes the preparation of
Static Test Data for all tests.
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
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TE.020.2 Develop Unit Test Scripts
TE.035.2 Create Integration Test Scenarios
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the Unit Test Scripts and the Integration Test Scenarios.
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 Elaboration activity-specific supplemental
guidance or the Construction activity-specific supplemental guidance.
Back to Top
PREREQUISITES
#TOP #TOP
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TE.025.2 Create System Test Scenarios
The tasks included in the Develop System Test Scenarios - Construction activity are:
ID Task Name
TE.025.3 Create System Test Scenarios
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the System Test Scenarios.
Back to Top
PREREQUISITES
You will need the following for these activities:
B.ACT.DSTSE - Develop System Test Scenarios - Elaboration
B.ACT.DE Design - Elaboration
C.ACT.DSTSC - Develop System Test Scenarios - Construction
B.ACT.LCAR Lifecycle Architecture Milestone (if no custom development)
#TOP #TOP
C.ACT.DC Design - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TE.090 Develop Systems Integration Test Scenarios
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.
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
You will need the following for this activity:
B.ACT.DC Design - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
C.ACT.IS - IMPLEMENT CUSTOM COMPONENTS
This activity allows for implementing the database, components, and services.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
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
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 perform the installation test and implement the components of the system as they become available during the Construction phase.
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
You will need the following for this activity:
C.ACT.DC Design - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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.
*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 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
TE.030.2 Perform Unit Test
TE.040.2 Perform Integration Test
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 performed unit and integration tests when and as needed.
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 Elaboration activity-specific supplemental
guidance or the Construction activity-specific supplemental guidance.
Back to Top
PREREQUISITES
#TOP #TOP
You will need the following for these activities:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
MC.050.2 Define Application Setups
TE.060.2 Prepare System Test Environment
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 double check the Application Setups and prepare the System Test Environment.
Back to Top
PREREQUISITES
You will need the following for these activities:
C.ACT.ICC Implement Custom Components
C.ACT.ACDC Acquire and Convert Data - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for these activities:
C.ACT.PCCTC Perform Custom Component Testing - Construction
C.ACT.CSTE Configure System Test Environment
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TE.085 Prepare Systems Integration Test Environment
TE.100 Perform Systems Integration Test
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.
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
You will need the following for this activity:
B.ACT.PSTC Perform System Test - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define 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
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TS.020.2 Define Cutover Strategy
TS.030 Develop Installation Plan
TS.040 Design Production Support Infrastructure
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define 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
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
C.ACT.PT Prepare for Transition
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define and prepare 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
You will need the following for this activity:
A.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
C.ACT.PACDC Prepare to Acqure and Convert Data - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
#TOP #TOP
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TE.072.2 Test Pre-Upgrade Steps
TE.073.2 Test Packaged Software Upgrade
TE.074.2 Test Post-Upgrade Steps
TE.075.2 Perform Post-Upgrade Reconciliation Testing
TE.076.2 Review Upgrade Test Results
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 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
You will need the following for these activities:
B.ACT.VUPE Validate Upgrade Process - Elaboration
B.ACT.SSC Specify Software Configuration
C.ACT.VUPC Validate Upgrade Process - Construction
C.ACT.ACDC Acquire and Convert Data - Construction
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare documentation for the users and technical support of the system.
Back to Top
PREREQUISITES
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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,
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
The tasks included in these activities are:
ID Task Name
OCM.150 Conduct Change Management Roadmap / Communication Campaign
OCM.155 Monitor Change Management Roadmap / Communication Campaign Effectiveness
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 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.
#TOP #TOP
Back to Top
PREREQUISITES
You will need the following for these activities:
B.ACT.DCMRCCE Deploy Change Management Roadmap / Communication Campaign
- Elaboration
A.ACT.LCOB Lifecycle Objective Milestone
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
OCM.200 Design Managers' Unit/Department Impact Workshop
OCM.210 Conduct Managers' Unit/Department Impact Workshop
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the materials for and conduct the Managers' Unit/Department Impact Workshop.
Back to Top
PREREQUISITES
You will need the following for this activity:
C.ACT.CJIA Conduct Job Impact Analysis
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TR.060 Conduct User Learning Needs Analysis
TR.070 Develop User Learning Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to conduct an analysis of the user learning needs and develop the User Learning Plan for meeting those needs.
Back to Top
PREREQUISITES
You will need the following for this activity:
B.ACT.LCAR Lifecycle Architecture Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TR.080 Develop User Learningware
TR.090 Develop User Learning Environment
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the User Learningware and the Configured User Learning Environment.
Back to Top
PREREQUISITES
You will need the following for this activity:
C.ACT.DUET Design End-User Training
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TR.100.2 Conduct User Learning Events
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 these activities is to conduct the training events as planned.
Back to Top
PREREQUISITES
You will need the following for these activities:
C.ACT.TEUC Train End Users - Construction
C.ACT.BEUT Build End-User Training
D.ACT.TEUT Train End Users - Transition
C.ACT.IOCM Initial Operational Capability Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
C.ACT.IOCM - INITIAL OPERATIONAL CAPABILITY 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 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.
Estimate cost and plan.
Back to Top
ACTIVITIES
The following activities are included in this milestone:
C.ACT.FR Finalize Requirements
C.ACT.AC Analyze - Construction
C.ACT.DC Design - Construction
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.ICC Implement Custom Components
C.ACT.PCCTC Perform Custom Component Testing - Construction
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.PT Prepare for Transition
C.ACT.PCO Prepare for Cutover
C.ACT.TI Test Infrastructure
C.ACT.PACDC Prepare to Acquire and Convert Data - Construction
C.ACT.ACDC 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.CJIA Conduct Job Impact Analysis
C.ACT.CMAWC Conduct Managers' Alignment Workshop - Construction
C.ACT.DEUT Design End-User Training
C.ACT.BEUT Build End-User Training
C.ACT.TEUC Train End Users - Construction
Back to Top
ACTIVITY CHECKLISTS
The following checklist is available to assist with determination of completeness for this activity:
Checklist Name Comments
Construction Phase / Initial Operational Capability (IOC) Milestone Checklist MS Word
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[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.
This phase overview is written from the perspective of a Full Method View, utilizing ALL of the processes, activities and tasks in this phase. Therefore, all of the
following sections provide comprehensive information. If your project is utilizing a tailored approach (for example, Technology Full Lifecycle View, Application
Implementation View, Middleware Architecture View), not everything in this overview may be appropriate for your project. Please keep this in mind, especially when
reviewing the Prerequisites, Processes, Key Work Products, Tasks and Work Products and Task Dependencies sections. You should use OUM as a guideline for
performing all types of information technology projects, but keep in mind that every project is different and that you need to adjust project activities according to each
situation. Do not hesitate to add, remove, or rearrange tasks, but be sure to reflect these changes in your estimates and risk management planning. You should also
consider the depth to which you address and complete each task based on the characteristics of your particular project or project increment. See Oracle's Full Lifecycle
Method for Deploying Oracle-Based Business Solutions for further information on the scalability and adaptability of OUM.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
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
The following processes are active in this phase:
Testing (TE)
Performance Management (PT)
Data Acquisition and Conversion (CV)
Documentation (DO)
Organizational Change Management (OCM)
Training (TR)
Transition (TS)
Back to Top
KEY WORK PRODUCTS
Refer to Key Work Products for a complete list of key work products in OUM.
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.
Performance Management
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.
Data Acquisition and Conversion
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.
Organizational Change Management
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
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product
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
Performance Management
PT.100 Execute Performance Test Performance Test Results
PT.110 Create Performance Test Report Performance Test Report
Data Acquisition and Conversion
CV.064.2 Install Conversion Components (Initial Load) Installed Conversion Components (Initial Load)
CV.065.2 Convert and Verify Data (Initial Load) Converted and Verified Data (Initial Load)
CV.068.2 Clean Data Clean Legacy Data
Documentation
DO.110 Finalize Documentation Final Documentation Work Products
Organizational Change Management
OCM.150.4 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
OCM.155.3
Monitor Change Management Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication Campaign Effectiveness
Assessment
OCM.220 Prepare Assessment of Impact on IT Groups IT Alignment Diagnosis Grid
OCM.230 Prepare IT Transition Plan IT Transition Plan
Training
TR.100.2 Conduct User Learning Events Skilled Users
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
ACTIVITY FLOW DIAGRAM
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
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TE.105 Prepare Users for Testing
TE.110 Prepare Acceptance Test Environment
TE.120 Support Acceptance Test
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 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
You will need the following for this activity:
C.ACT.IOCM Initial Operational Capability Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
PT.100 Execute Performance Test
PT.110 Create Performance Test Report
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 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
You will need the following for this activity:
C.ACT.IOCM Initial Operational Capability Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
You will need the following for this activity:
C.ACT.IOCM Initial Operational Capability Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
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 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
You will need the following for this activity:
D.ACT.PPE Prepare Production Environment
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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,
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
The tasks included in these activities are:
ID Task Name
OCM.150 Conduct Change Management Roadmap / Communication Campaign
OCM.155 Monitor Change Management Roadmap / Communication Campaign Effectiveness
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 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.
#TOP #TOP
Back to Top
PREREQUISITES
You will need the following for these activities:
B.ACT.DCMRCCE Deploy Change Management Roadmap / Communication Campaign
- Elaboration
A.ACT.LCOB Lifecycle Objective Milestone
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
OCM.220 Prepare Assessment of Impact on IT Groups
OCM.230 Prepare IT Transition Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to 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
You will need the following for this activity:
C.ACT.IOCM Initial Operational Capability Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
TR.100.2 Conduct User Learning Events
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 these activities is to conduct the training events as planned.
Back to Top
PREREQUISITES
You will need the following for these activities:
C.ACT.TEUC Train End Users - Construction
C.ACT.BEUT Build End-User Training
D.ACT.TEUT Train End Users - Transition
C.ACT.IOCM Initial Operational Capability Milestone
Back to Top
#TOP #TOP
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
DO.110 Finalize Documentation
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 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
You will need the following for this activity:
D.ACT.IOCM Initial Operational Capability Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
You will need the following for this activity:
D.ACT.SUAT Support User Acceptance Test
D.ACT.CPTST Conduct Performance Test
D.ACT.PPE Prepare Production Environment
D.ACT.CDT Convert Data - Transition
D.ACT.TEUT Train End Users - Transition
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
D.ACT.SIP - SYSTEM IN PRODUCTION 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 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
The following activities are included in this milestone:
D.ACT.SUAT Support User Acceptance Test
D.ACT.CPTST Conduct Performance Test
D.ACT.PPE Prepare Production Environment
D .ACT.CDT Convert Data - Transition
D.ACT.DCMRCCT Deploy Change Management Roadmap / Communication Campaign - Transition
D.ACT.CITA Conduct IT Alignment
D.ACT.TEUT Train End Users - Transition
D.ACT.FD Finalize Documentation
D.ACT.GP Go Production
Back to Top
ACTIVITY CHECKLISTS
The following checklist is available to assist with determination of completeness for this activity:
Checklist Name Comments
Transition Phase / System in Production (SP) Milestone Checklist MS Word
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[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.
This phase overview is written from the perspective of a Full Method View, utilizing ALL of the processes, activities and tasks in this phase. Therefore, all of the
following sections provide comprehensive information. If your project is utilizing a tailored approach (for example, Technology Full Lifecycle View, Application
Implementation View, Middleware Architecture View), not everything in this overview may be appropriate for your project. Please keep this in mind, especially when
reviewing the Prerequisites, Processes, Key Work Products, Tasks and Work Products and Task Dependencies sections. You should use OUM as a guideline for
performing all types of information technology projects, but keep in mind that every project is different and that you need to adjust project activities according to each
situation. Do not hesitate to add, remove, or rearrange tasks, but be sure to reflect these changes in your estimates and risk management planning. You should also
consider the depth to which you address and complete each task based on the characteristics of your particular project or project increment. See Oracle's Full Lifecycle
Method for Deploying Oracle-Based Business Solutions for further information on the scalability and adaptability of OUM.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
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
The following processes are active in this phase:
Business Requirements (RD)
Performance Management (PT)
Organizational Change Management (OCM)
Transition (TS)
Operations and Support (PS)
Back to Top
KEY WORK PRODUCTS
Refer to Key Work Products for a complete list of key work products in OUM.
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.
Performance Management
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.
Organizational Change Management
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
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product
Business Requirements
RD.160 Convert Project Views to Reusable Viewpoints New Reusable Viewpoints
Performance Management
PT.120 Conduct Production Performance Management Managed Production Environment
Organizational Change Management
OCM.150.5 Conduct Change Management Roadmap / Communication Campaign Change Management Roadmap / Communication Events
OCM.155.4
Monitor Change Management Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication Campaign Effectiveness
Assessment
OCM.250 Measure Organizational Change Effectiveness Organizational Effectiveness Assessment
OCM.260 Implement IT Transition Plan Aligned IT Organization
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
ACTIVITY FLOW DIAGRAM
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
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
PT.120 Conduct Production Performance Management
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 monitor and tune system performance after initial system Go Production.
Back to Top
PREREQUISITES
You will need the following for this activity:
D.ACT.SIP System in Production Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
TE.019.2
Collect, Assess and Refine KPI
Measurements
PS.010 Audit System
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 audit the system functionality.
Back to Top
PREREQUISITES
You will need the following for this activity:
D.ACT.SIP System in Production Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
E.ACT.RPP- RESOLVE PRODUCTION PROBLEMS
This activity consists of analyzing and resolving production problems.
*This activity has Application Implementation supplemental activity guidance.
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
The tasks included in this activity are:
ID Task Name
PS.050 Analyze Problems
PS.060 Monitor and Respond to System Problems
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 monitor the production system and detect any production issues. Problems that are found are analyzed and resolved during this activity.
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
You will need the following for this activity:
D.ACT.SIP System in Production Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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,
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
The tasks included in these activities are:
ID Task Name
OCM.150 Conduct Change Management Roadmap / Communication Campaign
OCM.155 Monitor Change Management Roadmap / Communication Campaign Effectiveness
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 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.
#TOP #TOP
Back to Top
PREREQUISITES
You will need the following for these activities:
B.ACT.DCMRCCE Deploy Change Management Roadmap / Communication Campaign
- Elaboration
A.ACT.LCOB Lifecycle Objective Milestone
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
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
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the 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
You will need the following for this activity:
D.ACT.SIP System in Production Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
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
The tasks included in this activity are:
ID Task Name
OCM.260 Implement IT Transition Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to 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
You will need the following for this activity:
D.ACT.SIP System in Production Milestone
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
E.ACT.SO - SIGN-OFF 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 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
The following activities are included in this milestone:
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
The following checklist is available to assist with determination of completeness for this activity:
Checklist Name Comments
Production Phase / Sign Off (SO) Milestone Checklist MS Word
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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
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
SUPPLEMENTAL GUIDANCE
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
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
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.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
Elaboration Phase
RD.011.2 Develop Future Process Model Future Process Model
RD.042.2 Develop Glossary Glossary
RD.045.2 Prioritize Requirements (MoSCoW) Moscow List
RD.140.2 Create Requirements Specification Requirements Specification
RD.150.2 Review Requirements Specification Reviewed Requirements Specification
Construction Phase
RD.042.3 Develop Glossary Glossary
RD.045.3 Prioritize Requirements (MoSCoW) Moscow List
RD.130.2 Develop Baseline Architecture Description Architecture Description
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
Refer to Key Work Products for a complete list of key work products in OUM.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
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
CRITICAL SUCCESS FACTORS
The critical success factors of this process are:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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 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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 all project team members
to stakeholders that have an interest in the Business and System Objectives, such as the clients management
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to all project team members
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
DETAILED DESCRIPTION
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Facilitate the workshop, interviews or meetings. Lead the modeling activity. Record/document the model.
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
RD.011.2
B.ACT.GBRE Gather Business Requirements - Elaboration
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
You should follow these steps:
No. Task Step Component Component Description
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
meeting or workshop that is being held to gather business requirements.
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).
Enterprise Repository
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
SUPPLEMENTAL GUIDANCE
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.
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 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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance Implementation
(ENV.GV.100)
If an Enterprise Repository is 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.
Enterprise Stakeholder Inventory
(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
The following techniques are available to assist with this task:
Technique Comments
Functional or Process Modeling
This technique provides assistance in utilizing business process models as a requirements gathering technique and describes the
different levels of business process models.
Enterprise Requirements
Management
Use this technique to understand how to manage requirements at the enterprise level.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
Future Process Model-Level 0
Future Process Model-Level 1
Future Process Model-Level 2
Future Process Model-Level 3
Tool Comments
Activity Diagram Viewlet JDeveloper
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.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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
addressed in a meeting or workshop that is being held to gather business requirements.
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
SUPPLEMENTAL GUIDANCE
Application Implementations
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Facilitate the workshop, interviews or meetings. Lead the modeling activity. Record/document the work product.
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
Ambassador User Provide information about the business organization. *
IS Operations Staff Provide information about existing systems and their operation. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Enterprise Organization Structures
(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.
Business and System Objectives
(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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-012_PRESENT_AND_FUTURE_ORG_STRUCTURES.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to all project team members
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-015_KEY_BUS_STRATEGIES_AND_OBJECTIVES.DOC None
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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
addressed in a meeting or workshop that is being held to gather business requirements.
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.
Enterprise Repository
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
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Ambassador User Provide information about business processes, organization units and external interfaces. Participate in modeling. *
Advisor User Provide information about a particular business process. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern
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
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements
Management
Use this technique to understand how to manage requirements at the enterprise level.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-020_HIGH_LEVEL_BUSINESS_DESCRIPTIONS.DOC
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to all project team members
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.ECBB Establish Current Business Baseline
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Facilitate the development of the Current Process Model. 100
Business Line Manager *
Project Sponsor *
User *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Functional or Process Modeling
This technique provides assistance in utilizing business process models as a requirements gathering technique and describes the
different levels of business process models.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-030_CURRENT_PROCESS_MODEL.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.
Example Comments
Current Process Model
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.ECBB Establish Current Business Baseline
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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 *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management Plan
(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
Organization Structures
(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.
Current Process Model
(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
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-034_CURRENT_BUSINESS_BASELINE_METRICS.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GR Gather Solution Requirements
RD.042.2
B.ACT.CS Consolidate Specification
RD.042.3
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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 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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Develop the Glossary. 100
Ambassador User Provide information about business terms. *
IS Support Staff Provide information about system terms. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
System Context Diagram (RD.005)
Future Process Model (RD.011)
High-Level Business Descriptions (RD.020)
Current Process Model (RD.030)
Current Business Baseline Metrics
(RD.034)
Supplemental Requirements (RD.055)
Domain Model (RD.065)
Business Use Case Model (RA.015)
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
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-042_GLOSSARY.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Have all of the identified terms been explained with a proper definition, preferably with examples?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GR Gather Solution Requirements
RD.045.2
B.ACT.CS Consolidate Specification
RD.045.3
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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.
Enterprise Repository
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Facilitate the workshop, interviews or meetings. Lead the prioritizing 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
Ambassador User Provide information about the business organization. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
RD.045.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
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.
Therefore, if it is not available, you should obtain this information prior to beginning 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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern
requirements. Use the Governance Implementation to prioritize the requirements from in the repository.
MoSCoW List (RD.045.1) Update the initial MoSCoW List, as appropriate.
RD.045.3
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
requirements. Use the Governance Implementation to prioritize the requirements from in the repository.
MoSCoW List (RD.045.2) Update the initial MoSCoW List, as appropriate.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
Getting Started with Use Case 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.
Use Case Diagram Viewlet JDeveloper
Example Comments
RD-045_MOSCOW_LIST_EXAMPLE.XLSX MS EXCEL - Ski-NOW Case Study Example
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 all project team members
to the visionary, project sponsor and other steering committee members
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GR Gather Solution Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Consolidate requirements into a single Supplemental Requirements document.
If a Business Requirements (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 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Supplemental Enterprise
Requirements (ENV.ER.100)
Future State Enterprise
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.
Project Management Plan
(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)
Current Process Model
(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
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements Management Use this technique to understand how to manage requirements at the enterprise level.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
The Supplemental Requirements is used in the following ways:
to capture supplemental requirements and business rules.
Distribute the Supplemental Requirements as follows:
to all project team members
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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.
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.
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.
Enterprise Repository
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
SUPPLEMENTAL GUIDANCE
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.
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 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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Resolve any conflicts that arise between teams concerning the definition of shared domains.
Role Responsibility %
Business Analyst Develop the Domain Model. 100
Designer Advisory
Ambassador User Provide information about domain objects related to the business. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Therefore, if it is not available, you should obtain this information prior to beginning this task.
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
Domain Model and business entities. Check for existing business entities and ensure that the the Domain Model and business entities are
added/updated in the repository.
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
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements
Management
Use this technique to understand how to manage requirements at the enterprise level.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-065_DOMAIN_MODEL.DOC MS WORD
Example Comments
Domain Model
Tool Comments
Class Diagram Viewlet JDeveloper
Getting Started with UML Class
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GSP Gather Supporting Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
6 Secure acceptance of the
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
SUPPLEMENTAL GUIDANCE
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Present and Future
Organization Structures
(RD.012)
Consider Audit and Control Requirements for each organization.
Current Process Model (RD.030)
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.
Technical Architecture
Workshop Results (TA.010)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-070_AUDIT_AND_CONTROL_REQUIREMENTS.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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GR Gather Solution Requirements
RD.130.2
C.ACT.FR Finalize Requirements
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
DS.040 - Develop Design 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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect Facilitate the workshop, interviews or meetings. Formulate technological risk factors.
If a Business Requirements (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 workshop, interviews or meetings.
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
task. Therefore, if it is not available, you should obtain this information prior to beginning this task.
Future Process Model
(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
application architecture.
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to all project team members
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.PSUIA Perform Software Upgrade Impact Analysis
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business and System Objectives (RD.001)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to all project team members
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.PSUIA Perform Software Upgrade Impact Analysis
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Software Release Changes Summary (RD.134)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.PSUIA Perform Software Upgrade Impact Analysis
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to all project team members
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.CR Consolidate Solution Requirements
RD.140.2
B.ACT.CS Consolidate Specification
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
You should follow these steps:
No. Task Step Component Component Description
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)
Supplemental Requirements (RD.055)
Domain Model (RD.065)
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
SUPPLEMENTAL GUIDANCE
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 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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Consolidate requirements into a single Requirements Specification document.
If a Business Requirements (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 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
task. Therefore, if it is not available, you should obtain this information prior to beginning this task.
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.
Future Process Model
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
RD-140_REQUIREMENTS_SPECIFICATION.DOC MS WORD
Tool Comments
Getting Started with Use Case Modeling JDeveloper
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
The Requirements Specification is used in the following ways:
to consolidate all the requirements into a unique document
Distribute the Requirements Specification as follows:
to all project team members
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.CR Consolidate Solution Requirements
RD.150.2
B.ACT.CS Consolidate Specification
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect Facilitate the review meetings. Review Requirements Specification.
If a Business Requirements (or other) team leader has been designated, 20% of this time would be allocated to this individual,
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
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.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)
High-Level Business Descriptions
(RD.020)
Domain Model (RD.065)
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
The following templates and tools are available to assist with this task:
Template File Name Comments
REVIEW_RESULTS.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to all project team members
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
E.ACT.PF Plan for Future
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Enterprise Architect Convert project views to reusable viewpoints. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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,
Guidelines and Standards
(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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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:
#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.
*This process has Application Implementation supplemental process guidance.
Back to Top
SUPPLEMENTAL GUIDANCE
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 Requirements Analysis process supplemental
guidance.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
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
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
Elaboration Phase
RA.021.2 Capture User Stories User Story
RA.023.2 Develop Use Case Model Use Case Model
RA.024.1 Develop Use Case Details Use Case Specification
RA.025.2 Identify Candidate Services Service Portfolio - Candidate Services
RA.026.1 Populate Services Repository Populated Services Repository
RA.027.2 Identify Candidate Business Rules Candidate Business Rules
RA.028.2 Populate Business Rules Repository Populated Business Rules Repository
RA.030.2 Validate Conceptual Prototype Validated Conceptual Prototype
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
Construction Phase
RA.021.3 Capture User Stories User Story
RA.023.3 Develop Use Case Model Use Case Model
RA.024.2 Develop Use Case Details Use Case Specification
RA.025.3 Identify Candidate Services Service Portfolio - Candidate Services
RA.026.2 Populate Services Repository Populated Services Repository
RA.027.3 Identify Candidate Business Rules Candidate Business Rules
RA.028.3 Populate Business Rules Repository Populated Business Rules Repository
RA.055.2 Document Business Procedures Business Procedure Documentation
RA.170.2 Conduct Data Quality Assessment High-Level Data Quality Assessment
RA.180.2 Review Use Case Model Reviewed Use Case Model
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
Refer to Key Work Products for a complete list of key work products in OUM.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
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
CRITICAL SUCCESS FACTORS
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GBRI Gather Business Requirements - Inception
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
DETAILED DESCRIPTION
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
A.ACT.GBRI Gather Business Requirements - Inception
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.
You should follow these steps:
No. Task Step Component Component Description
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
meeting or workshop that is being held to gather business requirements.
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.
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
SUPPLEMENTAL GUIDANCE
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.
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Enterprise Stakeholder Inventory
(ENV.BA.015)
System Context Diagram (RD.005)
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)
Governance Policies Catalog
(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.
High-Level Business Descriptions
(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
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements
Management
Use this technique to understand how to manage requirements at the enterprise level.
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
Use Case Diagram Viewlet JDeveloper
Activity Diagram Viewlet JDeveloper
Example Scenario Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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)
Applications Architecture (EA.140)
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
A.ACT.GR Gather Solution Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect Define SOA Reference Architecture. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Technology Reference
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.
Future State Transition
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
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GR Gather Solution Requirements
RA.021.2
B.ACT.DUCM Develop Use Case Model
RA.021.3
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
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
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
DETAILED DESCRIPTION
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
A.ACT.GR Gather Solution Requirements
RA.023.2
#TOP #TOP
B.ACT.DUCM Develop Use Case Model
RA.023.3
C.ACT.FR Finalize Requirements
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.
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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 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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Analyst Develop the Use Case Model and use cases. Facilitate the workshops where the use cases are modeled.
If a Requirements Analysis (or other) team leader has been designated, 20% of this time would be allocated to this individual,
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. *
* Participation level not estimated.
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 )
Future Process Model (RD.011.1)
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.
High-Level Business Descriptions (RD.020)
Current Process Model (RD.030)
Current Business Baseline Metrics (RD.034)
Domain Model (RD.065)
MoSCoW List (RA.045.1)
RA.023.2
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)
Future Process Model (RD.011.1)
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)
Business and System Objectives (RD.001)
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
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.
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.
Reviewed Analysis Model (AN.110.2)
Reviewed Design Model (DS.160.2)
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
The following techniques are available to assist with this task:
Technique Comments
Enterprise Requirements Management Use this guidance to understand how to manage requirements at the enterprise level.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE
UNIFIED METHOD (OUM)
Provides a scenario example that will be useful when performing this task
Use Case Model MS Visio
Tool Comments
Activity Diagram Viewlet JDeveloper
Getting Started with Use Case Modeling JDeveloper - You can use JDeveloper use case diagram complemented with some casual-
dressed descriptions.
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.
Use Case Diagram Viewlet JDeveloper
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DUCD Develop Use Case Details
RA.024.2
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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 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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Analyst Detail the use cases. 100
Ambassador User Provide information to detail the use cases. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Reviewed Analysis Model
(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.
Reviewed Requirements Specification
(RD.150.2)
The Reviewed Requirements Specification may influence the use case details.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
Getting Started with Use Case Modeling JDeveloper
Getting Started with Activity Modeling JDeveloper
Use Case Details Viewlet JDeveloper - You can use JDeveloper use case templates in fully-dressed and casual formats.
Activity Diagram Viewlet JDeveloper
Example Scenario Comments
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
RA-
024_SKI_NOW_UC001_USE_CASE_SPECIFICATION.DOC
UC001 Monitor Supplier Performance for Ski-NOW Case Study Example
RA-
024_SKI_NOW_UC002_USE_CASE_SPECIFICATION.DOC
UC002 Acknowledge Product Receipt for Ski-NOW Case Study Example
RA-
024_SKI_NOW_UC003_USE_CASE_SPECIFICATION.DOC
UC003 Create Online Sales Order for Ski-NOW Case Study Example
RA-
024_SKI_NOW_UC004_USE_CASE_SPECIFICATION.DOC
UC004 Request Online Bid for Ski-NOW Case Study Example
RA-
024_SKI_NOW_UC005_USE_CASE_SPECIFICATION.DOC
UC005 Apply Rebates for Ski-NOW Case Study Example
RA-
024_SKI_NOW_UC006_USE_CASE_SPECIFICATION.DOC
UC006 Process Supplier Financial Entries for Ski-NOW Case Study Example
RA-
024_SKI_NOW_UC007_USE_CASE_SPECIFICATION.DOC
UC007 Capture Recycling Pickup for Ski-NOW Case Study Example
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.GR Gather Solution Requirements
RA.025.2
B.ACT.CS Consolidate Specification
RA.025.3
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
RA.025.1
Prerequisite Usage
Glossary (RD.042.1)
Future Process Model (RD.011.1)
Current Process Model (RD.030)
Domain Model (RD.065)
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 Case Model (RA.023.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.
Project Reference Architecture (RA.019) Use the Project Reference Architecture to determine to which layer each service belongs.
RA.025.3
Prerequisite Usage
Glossary (RD.042.3)
Use Case Model (RA.023.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.
Project Reference Architecture (RA.019) Use the Project Reference Architecture to determine to which layer each service belongs.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
IP-
014_SERVICE_PORTFOLIO.XLS
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 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 Scenario Comments
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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:
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 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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Governance Implementation
(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
The following techniques are available to assist with this task:
Technique Comments
IT Asset Management Use this technique to access information on the meta data descriptions for services and usage agreements.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
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.027.1
A.ACT.GR Gather Solution Requirements
RA.027.2
B.ACT.CS Consolidate Specification
RA.027.3
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
candidate business rules.
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
candidate business rules.
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 Work Products
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Identify and document candidate business rules. If possible, you may want use a business analyst with extensive business
rules experience.
100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
Future Process Model (RD.011)
Domain Model (RD.065)
Use Case Model (RA.023.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.
Use Case Model (RA.023.2)
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 Case Model (RA.023.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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
The Oracle Enterprise Repository is a COTS Enterprise Repository tool solution that is used to establish and maintain an Enterprise
Repository.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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).
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 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.
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.028.1
A.ACT.GR Gather Solution Requirements
RA.028.2
B.ACT.CS Consolidate Specification
RA.028.3
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Populate the Business Rules Repository. If possible, you may want use a business analyst with extensive business rules
experience.
100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
Glossary (RD.042.2) The vocabulary used in the business policy should be consistent consistent with the Glossary.
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
Glossary (RD.042.3) The vocabulary used in the business policy should be consistent consistent with the Glossary.
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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 describing business rules and integrating them into business processes.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
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 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
consider including this task in your project.
ACTIVITY
RA.030.1
A.ACT.CCPI Create Conceptual Prototype - Inception
RA.030.2
B.ACT.CCPE Create Conceptual Prototype - Elaboration
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Developer Prepare for, and walkthrough the Conceptual Prototype, and gather new understanding of requirements. Prepare the
workshop, invite participants, and lead the workshop.
If a Requirements Analysis (or other) team leader has been designated, 40% of this time would be allocated to this individual,
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Conceptual Prototype (IM.005) This is the prototype that should be validated.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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.
SAMPLE_WORKSHOP_PLAN.DOC MS WORD - This file contains a sample workshop plan/agenda.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
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
B.ACT.BSA Baseline Software Architecture
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.035 - Develop High Level Software Architecture Description
AN.040 - Develop Analysis Architecture Description
DS.040 - Develop Design Architecture Description
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
2 x 2 Use this technique to prioritize use cases for each iteration group.
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 Use this technique to prioritize items on the MoSCoW List work product.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.GBRE Gather Business Requirements - Elaboration
RA.055.2
C.ACT.PSTC Perform System Test - Construction
Back to Top
WORK PRODUCT
Business Procedure Documentation - The Business Procedure Documentation documents the procedures supporting the business processes.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Business Line Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
RA-055_BUSINESS_PROCEDURE_DOCUMENTATION.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
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
Productivity Kit Professional (UPK Pro) and
Oracle Tutor Supplemental Guide.
process documentation and UPK for everything else. Oracle Corporation uses Tutor to document its business
processes.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DVCSP Develop and Validate Custom Software Prototypes
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles when the Functional Prototype being validated is built with custom software (e.g., custom application code and/or custom
extension of a COTS product):
Role Responsibility %
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.
*
* Participation level not estimated.
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):
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Functional Prototype (IM.010) The Functional Prototype is validated in this task
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM040_REVIEW_COMMENTS_LIST.DOC MS WORD
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DVCSP Develop and Validate Custom Software Prototypes
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
User Interface Standards Prototype (IM.085) The User Interface Standards Prototype is validated in this task
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM-040_REVIEW_COMMENTS_LIST.DOC MS WORD
A tracking tool can also be used to log defects.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.PACDE Prepare to Acquire and Convert Data - Elaboration
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect
(Information 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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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)
High-Level Business Descriptions (RD.020)
Current Business Baseline Metrics (RD.034)
Domain Model (RD.065)
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
The following templates and tools are available to assist with this task:
Template File Name Comments
RA_160_DATA_SOURCE_GAP_MATRIX.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.PACDE Prepare to Acquire and Convert Data - Elaboration
RA.170.2
C.ACT.PACDC Prepare to Acquire and Convert Data - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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.
Data Quality Measures
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect
(Information 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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
High-Level Business Descriptions
(RD.020)
Domain Model (RD.065)
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
The following templates and tools are available to assist with this task:
Template File Name Comments
RA_170_HIGH_LEVEL_DATA_QUALITY_ASSESSMENT.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 manager
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.CS Consolidate Specification
RA.180.2
C.ACT.FR Finalize Requirements
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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 Model (RA.023.3)
Use Case Specification (RA.024.2)
The Use Case Model and Specification are under review in this task.
Reviewed Use Case Model
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
QM-040_REVIEW_COMMENTS_LIST.DOC MS WORD
REVIEW_RESULTS.DOC MS WORD
A tracking tool can also be used to log defects.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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:
#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
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
Inception Phase
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
Elaboration Phase
MC.010.2 Define Business Data Structures Business Data Structures
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.090.2 Conduct Reporting Fit Analysis Reporting Fit Analysis
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
Refer to Key Work Products for a complete list of key work products in OUM.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
APS Application/Product
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
CRITICAL SUCCESS FACTORS
The critical success factors of this process are:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.SKSD Specify Key Structure Definition
MC.010.2
B.ACT.SSC Specify Software Configuration
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
You should follow these steps:
No. Task Step Component Component Description
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.).
MC.020 Define Business Data
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Provide knowledge and guidance regarding the functionality and capabilities of the product(s) being implemented. 20
Ambassador User Participate in working sessions and help identify setup parameters. *
* Participation level not estimated
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-010_BUSINESS_DATA_STRUCTURES.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
A.ACT.SKSD Specify Key Structure Definition
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
You should follow these steps:
No. Task Step Component
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.
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.).
MC.020 Define Business Data
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-020_BUSINESS_DATA_STRUCTURE_SETUPS.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.GBRE Gather Business Requirements - Elaboration
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Supplemental Requirements (RD.055)
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
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-
030_BUSINESS_REQUIREMENTS_MAPPING_FORM.DOC
MS Word
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.SSC Specify Software Configuration
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
You should follow these steps:
No. Task Step Component Component Description
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:
Business and System Objectives (RD.001)
System Context Diagram (RD.005)
Future Process Model (RD.011)
Present and Future Organization Structures (RD.012)
High-Level Business Descriptions (RD.020)
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.
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.).
MC.020 Define Business Data
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Provide knowledge and guidance regarding the clients 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.
50
Business Line Manager Provide specific examples of business rules and procedures. *
Ambassador User Provide specific examples of business transaction forms, reports, data etc. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Future Process Model (RD.011) The Future Process Model describes the future-state business processes.
Present and Future Organization
Structures (RD.012)
This work product describes the current and future organizational state of the client's business.
High-Level Business Descriptions
(RD.020)
The High-Level Business Descriptions provides contextual business information collected during the high-level
requirements definition workshops.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Nominal Group Use this technique to help drive group consensus and decision making.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-040_SETUP_INFORMATION.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.SSC Specify Software Configuration
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
You should follow these steps:
No. Task Step Component Component Description
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.
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.).
MC.020 Define Business Data
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.
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Business Line Manager Provide specific examples of business rules and procedures. *
Ambassador User Provide specific examples of business transaction forms, reports, data, etc. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following techniques are available to assist with this task:
Technique Comments
Nominal Group Use this technique to help drive group consensus and decision making.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-050_APPLICATION_SETUP.XLS MS EXCEL
MC-
050_APPLICATION_SETUP_DOCUMENT.DOC
MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.SSC Specify Software Configuration
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Provide knowledge and guidance regarding the clients existing business procedures, and system access requirements. 60
Application/Product
Specialist
Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for the product(s) being
implemented.
30
System Administrator Set up the administration of security and associated privileges. 10
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-060_FUNCTIONAL_SECURITY_SETUP_INFORMATION.XLS MS EXCEL
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Are users assigned to roles that map to their job responsibilities for the new system?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.PVC Prototype and Validate Configuration
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
You should follow these steps:
No. Task Step Component
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Provide knowledge and guidance regarding the clients existing business procedures, activities and functions. 35
Application/Product
Specialist
Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for the product(s) being
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
The Configuration Prototype Environment is used to prototype the configuration during the Configuration Prototyping Workshop.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.PVC Prototype and Validate Configuration
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst 50
Application/Product
Specialist
30
System Architect 10
System Administrator 10
Client Staff Member *
Ambassador User *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-080_CPW_STRATEGY_AND_PLAN.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.PVC Prototype and Validate Configuration
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
You should follow these steps:
No. Task Step Component
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
MC-090_REPORTING_FIT_ANALYSIS.XLS MS EXCEL
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
Does the Reporting Fit Analysis include the disposition of every report requirement?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.PGA Perform Gap Analysis
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
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect 80
Business Analyst 20
Business Line Manager *
Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.PGA Perform Gap Analysis
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
No. Task Step Component
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
This section is not yet available.
Back to Top
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
Business Line Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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.
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
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 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:
#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.
*This process has Application Implementation supplemental process guidance.
Back to Top
SUPPLEMENTAL GUIDANCE
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 Analysis process supplemental guidance.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
Elaboration Phase
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
Construction Phase
AN.035.2 Update Existing Analysis Specification Updated Analysis Specification
AN.040.2 Develop Analysis Architecture Description Architecture Description
AN.050.2 Analyze Data Data Analysis
AN.060.2 Analyze Behavior Behavior Analysis
AN.070.2 Analyze Business Rules Business Rules Analysis
AN.080.2 Analyze Services Service Portfolio - Proposed Services
AN.085.2 Define Service Service Definition
AN.090.2 Analyze User Interface User Interface Analysis
AN.100.2 Prepare Analysis Specification Analysis Specification
AN.110.2 Review Analysis Model Reviewed Analysis Model
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
Refer to Key Work Products for a complete list of key work products in OUM.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
APS Application / Product
Specialist
Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for the product(s) being
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
CRITICAL SUCCESS FACTORS
The critical success factors of this process are:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.AE Analyze - Elaboration
AN.035.2
C.ACT.AC Analyze - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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:
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
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 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.
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. 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
include this task in your project.
ACTIVITY
AN.040.1
B.ACT.BSA Baseline Software Architecture
AN.040.2
C.ACT.AC Analyze - Construction
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.035 - Develop High Level Software Architecture Description
AN.040 - Develop Analysis Architecture Description
DS.040 - Develop Design Architecture Description
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
You should follow these steps:
No. Task Step Component Component Description
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
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
AN.050.1
B.ACT.AE Analyze - Elaboration
AN.050.2
C.ACT.AC Analyze - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
You need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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 Use Case Modeling JDeveloper
Getting Started with UML Class Modeling JDeveloper
Use Case Diagram Viewlet JDeveloper
Use Case Details Viewlet JDeveloper
Activity Diagram Viewlet JDeveloper
Class Diagram Viewlet JDeveloper
Example Scenario Comments
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
Class Model
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 development team
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.AE Analyze - Elaboration
AN.060.2
C.ACT.AC Analyze - Construction
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.
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You will need the following for this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
ANALYSIS_MODEL.DOC MS WORD - Update the Analysis Model created in AN.050 with the Behavior Analysis details.
Tool Comments
Getting Started with UML Class Modeling JDeveloper
Class Diagram Viewlet JDeveloper
Example Comments
Analysis Model-Activity Model
Analysis Model-Collaboration Model
Analysis Model-Sequence Model
Class Model
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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:
to the development team
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.AE Analyze - Elaboration
AN.070.2
C.ACT.AC Analyze - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Analyze the business rules. If possible, you may want use a business analyst with extensive business rules experience. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.AE Analyze - Elaboration
AN.080.2
C.ACT.AC Analyze - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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.
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 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
SUPPLEMENTAL GUIDANCE
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.
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Analyze services. 50
System Architect Analyze services. If possible, you may want use a system architect with extensive SOA experience. 50
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
AN.080.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
proposed services and their relationships to other IT assets. In addition, ensure that the final proposed services and their relationships are
added/updated in the repository.
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)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
proposed services and their relationships to other IT assets. In addition, ensure that the final proposed services and their relationships are
added/updated in the repository.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
IT Asset Management Use this technique to access information on the meta data descriptions for services and usage agreements.
SOA Service Lifecycle Use this technique to understand the service lifecycle and the Enterprise Repository assets used.
SOA Service Boundary
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
The following templates and tools are available to assist with this task:
Technique Comments
IP-
014_SERVICE_PORTFOLIO.XLS
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 candidate service into the Service Portfolio at a later point, as
appropriate.
Example Scenario Comments
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
to decision makers (individuals or boards) for final decision
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.AE Analyze - Elaboration
AN.085.2
C.ACT.AC Analyze - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Define services. 50
System Architect Define services. If possible, you may want use a system architect with extensive SOA experience. 50
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance
Implementation
(ENV.GV.100)
If an Enterprise Repository is in use, the Governance Implementation (that is, the related policies and processes) describes how to govern the
proposed services and their relationships to other IT assets. In addition, ensure that the final proposed services and their relationships are
added/updated in the repository.
Proposed Services
(AN.080)
The Proposed Services provides you with the list of services you need to define.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
Template File Name Comments
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.
Example Scenario Comments
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.AE Analyze - Elaboration
AN.090.2
C.ACT.AC Analyze - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Lead facilitated sessions and develop resulting storyboards. 100
User Participate in the facilitated sessions and critique the storyboards. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You will need the following for this task:
B.AN.090.1
Prerequisite Usage
Use Case Model
(RA.023)
Use Case Specifications
(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 Model (RA.023)
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
Getting Started with UML Class Modeling JDeveloper
Class Diagram Viewlet JDeveloper
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.AE Analyze - Elaboration
AN.100.2
C.ACT.AC Analyze - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
Business and System Objectives (RD.001)
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
SUPPLEMENTAL GUIDANCE
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.
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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.
*
* Participation level not estimated.
Back to Top
PREREQUISITES
You will need the following for this task:
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.
Architecture Description
(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.
Use Case Specifications
(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.
Conceptual Prototype
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
to the development team
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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?
Are all of the assumptions clearly documented and agreed to by the users?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
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
AN.110.1
B.ACT.AE Analyze - Elaboration
AN.110.2
C.ACT.AC Analyze - Construction
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:
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)
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
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 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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Architecture Description
(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 Behavior (AN.060)
Analyze Business Rules (AN.070)
Analyze Services (AN.080)
Define Service (AN.085)
Analyze User Interface (AN.090)
Develop Analysis Specification (AN.100)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
REVIEW_RESULTS.DOC MS WORD
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[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).
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
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 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
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.
*This process has Application Implementation supplemental process guidance.
Back to Top
SUPPLEMENTAL GUIDANCE
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 Design process supplemental guidance.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
ID Task Work Product
Elaboration Phase
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
Construction Phase
DS.035.2 Update Existing Design Specification Updated Design Specification
DS.040.2 Develop Design Architecture Description Architecture Description
DS.080.2 Design Software Components Software Component Design
DS.090.2 Design Data Component Data Design
DS.100.2 Design Behavior Component Behavior Design
DS.110.2 Design Business Rules Business Rules Design
DS.120.2 Design Services Service Design
DS.130.2 Design User Interface User Interface Design
DS.140.2 Prepare Design Specification Design Specification
DS.150.2 Develop Database Design Logical Database Design
DS.160.2 Review Design Model Reviewed Design Model
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.
*This process has Application Implementation supplemental process guidance.
Back to Top
KEY WORK PRODUCTS
Refer to Key Work Products for a complete list of key work products in OUM.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
APS Application / Product
Specialist
Provide knowledge and guidance regarding the functionality, capabilities and implementation strategies for the product(s) being
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
CRITICAL SUCCESS FACTORS
The critical success factors of this process are:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DPS Define Project Strategy
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
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect 75
Business Analyst 25
Client Project Manager *
Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management Plan
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
DS-020_APPLICATION_EXTENSION_STRATEGY.DOC MS WORD
Tool Comments
Getting Started with Use Case Modeling JDeveloper
Getting Started with UML Class Modeling JDeveloper
Use Case Diagram Viewlet JDeveloper
Use Case Details Viewlet JDeveloper
Activity Diagram Viewlet JDeveloper
Class Diagram Viewlet JDeveloper
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
Distribute the Application Extension Strategy as follows:
to the project team
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DE Design - Elaboration
DS.035.2
C.ACT.DC Design - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
Technical Specifications
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
Technical Specifications
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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?
Are all of the assumptions clearly documented and agreed to by the users?
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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:
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
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 (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.
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. 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
include this task in your project.
ACTIVITY
DS.040.1
B.ACT.BSA Baseline Software Architecture
DS.040.2
C.ACT.DC Design - Construction
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.035 - Develop High Level Software Architecture Description
AN.040 - Develop Analysis Architecture Description
DS.040 - Develop Design Architecture Description
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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:
Analyze Data Analysis (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
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
The following techniques are available to assist with this task:
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
The following templates and tools are available to assist with this task:
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
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.
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DE Design - Elaboration
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
You should follow these steps:
No. Task Step Component Component Description
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.
*Use the following to access task-specific Application Implementation supplemental guidance.
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.
*Use the following to access task-specific Application Implementation supplemental guidance.
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
SUPPLEMENTAL GUIDANCE
Application Implementations
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Architecture Principles, Guidelines and
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
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
In a commercial off-the-shelf (COTS) application implementation, business rules may be realized through standard configuration options, through custom-built
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
B.ACT.DE Design - Elaboration
Back to Top
WORK PRODUCT
Business Rules Implementation Strategy
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
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
Review Work Products
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
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Business Rules Implementation Strategy
(ENV.EA.160)
Use this Envision work product, if available.
Architecture Requirements and Strategy
(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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
"Implementing Rules in ADF Business
Components" - White Paper
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 Business Rules
http://www.oracle.com/appserver/rules.html
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DE Design - Elaboration
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
SUPPLEMENTAL GUIDANCE
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.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
System Architect Define the SOA Implementation Strategy. If possible, you may want use a system architect with extensive SOA experience. 100
#TOP #TOP
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Technology Reference
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.
Technical Architecture
Requirements and Strategy
(TA.020)
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
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.
Service Modeling Use this technique to understand how you can model services.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
This section is not yet available.
Back to Top
QUALITY CRITERIA
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
This task is executed in parallel with the following tasks:
Design Data (DS.090)
Design Behavior (DS.100)
Design User Interface (DS.130)
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
B.ACT.DE Design - Elaboration
DS.080.2
C.ACT.DC Design - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
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.
*Use the following to access task-specific Application Implementation supplemental guidance.
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
SUPPLEMENTAL GUIDANCE
Application Implementations
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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:
Analyze Data (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
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.
Architecture Description
(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.
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.
Use Case Model (RA.023) Updates to the Use Case Model may impact the Software Component Design.
Architecture Description
(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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
Getting Started with UML Class Modeling JDeveloper
Class Diagram Viewlet JDeveloper
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
This task is executed in parallel with the following tasks:
Design Software Components (DS.080)
Design Behavior (DS.100)
Design User Interface (DS.130)
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, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems.
ACTIVITY
DS.090.1
B.ACT.DE Design - Elaboration
DS.090.2
C.ACT.DC Design - Construction
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.
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 Component Data 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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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 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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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:
Analyze Data (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
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.
Architecture Description
(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.
Design and Build Standards (DS.050)
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:
Analyze Data (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
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.
Architecture Description
(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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
Getting Started with UML Class Modeling JDeveloper
Class Diagram Viewlet JDeveloper
Example Comments
Class Model
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
This task is executed in parallel with the following tasks:
Design Software Components (DS.080)
Design Data (DS.090)
Design User Interface (DS.130)
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, which extend the functionality of the COTS system and/or integrate the COTS system with other COTS or legacy systems.
ACTIVITY
DS.100.1
B.ACT.DE Design - Elaboration
DS.100.2
C.ACT.DC Design - Construction
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.
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 Component Behavior 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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Business Procedure Documentation
(RA.055.1)
Application Setup Documents
(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
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:
Analyze Data (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
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.
Architecture Description
(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.
Design and Build Standards (DS.050)
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
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:
Analyze Data (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
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.
Architecture Description
(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.
Design and Build Standards (DS.050)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
Getting Started with Activity Modeling JDeveloper
Class Diagram Viewlet JDeveloper
Example Comments
Class Model
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 development team
to the technical reviewer
to the test designer
to the system architect
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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).
In a commercial off-the-shelf (COTS) application implementation, business rules may be realized through standard configuration options, through custom-built
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
B.ACT.DE Design - Elaboration
DS.110.2
C.ACT.DC Design - Construction
Back to Top
WORK PRODUCT
Business Rules Design
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
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 (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
SUPPLEMENTAL GUIDANCE
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.
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 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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Business Analyst Design the business rules. If possible, you may want use a business analyst with extensive business rules experience. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
DS.110.1
Prerequisite Usage
Business Rules Analysis (AN.070.1) The Business Rules Analysis are being designed in this task.
Business Rules Implementation Strategy
(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.
Business Rules Implementation Strategy
(DS.060)
This work product defines the strategy for designing the rules.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
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
implementation format.
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DE Design - Elaboration
DS.120.2
C.ACT.DC Design - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Designer Design the services. If possible, you may want use a designer with extensive SOA experience. 100
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
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.
Architecture Description
(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
The following techniques are available to assist with this task:
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.
Service Modeling Use this technique to understand how you can model services.
IT Asset Management Use this technique to understand what kind of elements are relevant for service design.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Example Scenario Comments
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE UNIFIED METHOD (OUM) Provides a scenario example that will be useful when performing this task
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
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
This task is executed in parallel with the following tasks:
Design Software Components (DS.080)
Design Data (DS.090)
Design Behavior (DS.100)
ACTIVITY
DS.130.1
B.ACT.DE Design - Elaboration
DS.130.2
C.ACT.DC Design - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You will need the following for this task:
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:
Analyze Data (AN.050)
Analyze Behavior (AN.060)
Analyze Business Rule (AN.070)
Analyze Services (AN.080)
Analyze User Interface (AN.090)
Prepare Analysis Specification (AN.100)
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
The following templates and tools are available to assist with this task:
There are currently no templates available to assist with this task.
Tool Comments
Getting Started with UML Class Modeling JDeveloper
Class Diagram Viewlet JDeveloper
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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 the development team
to user stakeholders
Back to Top
QUALITY CRITERIA
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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
B.ACT.DE Design - Elaboration
DS.140.2
C.ACT.DC Design - Construction
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
You should follow these steps:
No. Task Step Component Component Description
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
SUPPLEMENTAL GUIDANCE
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.
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
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You will need the following for this task:
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 Specifications (RA.024) Use the Use Case Specification is used as a starting point for organizing the design of the component.
Architecture Description
(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
The following templates and tools are available to assist with this task:
Template File Name Comments
DS-140_DESIGN_SPECIFICATION.DOC MS Word
Back to Top
WORK PRODUCT DETAILS
Audience, Distribution and Usage
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
Use the following criteria to check the quality of this work product:
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
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.
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, 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
B.ACT.DE Design - Elaboration
DS.150.2
C.ACT.DC Design - Construction
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)
*Use the following to access task-specific Application Implementation supplemental guidance.
Back to Top
TASK STEPS
This section is not yet available.
Back to Top
APPROACH
This section is not yet available.
*Use the following to access task-specific Application Implementation supplemental guidance.
Back to Top
SUPPLEMENTAL GUIDANCE
Application Implementations
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.
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.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
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
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
DS.150.1
Prerequisite Usage
Design and Build Standards (DS.050)
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 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)
Updates and additions to the enterprise classes must be reflected in the final Logical Database Design.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
DS-150_LOGICAL_DATABASE_DESIGN.DOC MS WORD
Tool Comments
Getting Started with UML Class Modeling JDeveloper
Class Diagram Viewlet JDeveloper
Example Comments
Logical Database Design
For further detail on relational database design principles, refer to 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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 From Business Process to Use Case
Method Navigation Current Page Navigation
FROM BUSINESS PROCESS TO USE CASE WITH ORACLE
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.
Conceptual Prototype
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Requirements Traceability
Method Navigation Current Page Navigation
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
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
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.