Oracle Unified Methodology (OUM)

 

ORACLE UNIFIED METHOD (OUM) OVERVIEW 


INTRODUCTION
Oracle is evolving the Oracle Unified Method (OUM) to achieve 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 projects, Software Upgrade projects, and the complete range of technology projects including initial support for Business Intelligence and Enterprise Performance Management and deep support for Service-Oriented Architecture (SOA), Enterprise Integration, and Custom Software. 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. OUM’s 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 best 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 Oracle’s 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 while assuring 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 engagement 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 of interactions with customers and users of Oracle's software products. Please contribute your thoughts, comments, ideas, and work products or artifacts to Oracle's Global Methods team so that we may continue to improve this body of work. Contact Oracle's Global Methods team at ominfo_us@oracle.com.

OUM Approach

OUM is built on five main principles derived from the Unified Process, the Dynamic Systems Development Method, and Oracle's existing 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.

Why Use OUM?
More Focused Effort
OUM enables projects to clearly define business scope as well as the need to create enterprise business process models. This planning results in tighter scope control, more accurate business understanding, and a firm foundation for client acceptance.
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 ensures that the most critical risks are addressed as early as possible in the project lifecycle, which results in a measurable reduction of schedule and budget risks.

KEY CONCEPTS

OUM has several key concepts and significant milestones that are used to manage the development cycle. These key concepts and milestones are demonstrated in the MS Project OUM Full Method Example Workplan.  The example workplan provides a template for the phases, processes, milestones, and concepts used in a OUM project.

This section provides a brief overview of the following concepts and significant milestones used to manage a OUM project:

• Iterations/Increments/Releases
• Activities
• Work Products

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 that may be a subset of the complete vision, but useful from some engineering or user perspective.

The OUM definition of an iteration is consistent with the Unified Process, but may be slightly different from the iterations in a CDM FT or DSDM-like approach.  In OUM, the result of an iteration is an increment. 

At the end of each iteration, the active set of work products 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 development organization, as part of a milestone, or for a demonstration to users or customers. 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 development 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.

Activities

In OUM, tasks are grouped into Activities.  An activity groups “cross view” tasks together. Generally, 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.

Work Products

In OUM, the output of a task or activity is called a work product 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 work products, but they may also reference additional deliverables not documented by the method.

In addition, not every work product referenced in the method material is required for a given project. The required work products are based on specific project scope. In this case, the "optional" work products are part of the OUM method material, but are not included in the project workplan.

What’s New?

The Oracle Unified Method (OUM) Release 5.4 features:

• Accelerated OUM for Solution-Driven Implementations Supplemental Guide (Oracle Only)
• Oracle Support Services Supplemental Guide
• Service-Oriented Architecture (SOA) Tactical Project Delivery View
• Manage technique: Metrics for Agile Projects
• Envision Models View
• Envision techniques: Accelerating SOA Maturity, Measuring SOA for Improved Business Value, Operational Troubleshooting, Service Engineering Process Monitoring, SOA Capacity Planning
• Enhanced / Updated:
• Core Workflow View
• "Planning a Project Using the Oracle Unified Method (OUM) - An Iterative and Incremental Approach" White Paper
• "Managing an OUM Project using Scrum" White Paper
• Manage Work Breakdown Structure
• Template Styles and Format - Refer to the What's New with OUM Templates for a complete list of changes.

Method Navigation

• Views
• Select a View pull-down: Reorganized by Manage, Implement, Envision and Other views. Other views provides access to the SOA in OUM views selector page and the Full Method and Focus Areas views selector page.
• All Views
• Key Components section: Added View-appropriate Supplemental Guides
• Key Components section: Added link to Supplemental Guidance
• Key Components section: Added link to OUM Mapping Documents
• Key Components section: Added link to Key Work Products
• Tasks and Work Products sections: Added Work Product column
• Manage View
• Updated
• Project Start Up and Project Execution and Control phases: Reorganized/added Activities
• Implement Views
• Updated
• Requirements-Driven Application Implementation
• Solution-Driven Application Implementation
• Software Upgrade
• Technology Full Lifecycle
• Business Intelligence (BI) and Enterprise Performance Management (EPM) Implementation
• Business Intelligence and Analytics Custom Development
• Enterprise 2.0
• Implement Core Workflow
• Implement Models
• Envision Views
• Added
• Envision Models

Updated

• Oracle Architecture Development Process (OADP)
• The Open Group Architecture Framework (TOGAF)
• Sales - Insight
• Strategy
• Enterprise Optimization Roadmap
• Envision
• Service-Oriented Architecture (SOA) in OUM Views
• Added
• Service-Oriented Architecture (SOA) Tactical Project Delivery View
• Updated
• SOA Project Delivery
• SOA Engineering Planning
• SOA Modeling Planning
• SOA Governance Planning
• SOA Reference Architecture Planning
• SOA Core Workflow
• Full Method and Focus Areas Views
• Updated
• Manage
• Envision
• Implement
• Full Method
• Full Method Activities and Tasks

Method Guidelines

• Activity Guidelines
• Added new tasks to various activities
• Phase and Process Overviews
• Added Key Work Products
• Task Guidelines
• Updated Envision content to support Service-Oriented Architecture (SOA) views:
• Provided additional tasks to support Service-Oriented Architecture (SOA) Engineering Planning view
• Added new tasks for Service Metrics
• Updated task guidance for Envision tasks
• Updated task overview descriptions and guidelines in all processes to accommodate Service-Oriented Architecture (SOA) views
• Added new tasks and templates to support the Tactical SOA Project Delivery view:
• Define Service task with Service Contract and Project Contracts Portfolio templates
• Services Portfolio template
• Updated tasks in the following processes:
• Business Requirements
• Requirements Analysis
• Analysis
• Expanded MoSCoW List guidance
• Updated task overview and template for MoSCoW List (RD.065)
• Added a MS Excel version of the MoSCoW List template that can be used to track requirements traceability
• Added OUM Technique Guidelines for SOA guidance from BEA Liquid Enterprise Method
• Updated Task to Technique Cross reference for Envision, Manage, and Implement
• Work Product Templates
• All MSWord templates have been reformatted and updated for 5.4. Refer to the What's New with OUM Templates for a complete list of changes.
• Technique Guidelines
• Added techniques:
• Metrics for Agile Projects
• Accelerating SOA Maturity
• Measuring SOA for Improved Business Value
• Operational Trouble Shooting
• Service Engineering Process Monitoring
• SOA Capacity Planning
• Added new techniques to tasks in:
• Manage
• Service-Oriented Architecture (SOA) Engineering Planning
• Service-Oriented Architecture (SOA) Reference Architecture Planning
• Updated techniques
• IT Asset Management
• Service Modeling
• Updated techniques for tasks in:
• Manage
• Envision
• Implement
• Integrated the former BEA Liquid Enterprise Method material, SOA Instrumentation for Monitoring and Management (SIMM)
• Supplemental Guidance
• Added:
• Oracle Support Services Supplemental Guide 1.0
• Accelerated OUM for Solution-Driven Implementations Supplemental Guide 1.0 (Oracle Only)
• Updated Overview, Task Supplement, and Technique Supplement for the following Supplemental Guides
• Service-Oriented Architecture (SOA) Engineering Planning Supplemental Guide
• Service-Oriented Architecture (SOA) Project Delivery Supplemental Guide
• Technical Guidelines page reorganized and renamed to Supplemental Guidance
• White Papers
• Added:
• Managing an Oracle Unified Method (OUM) Project Using Scrum
• Planning a Project Using the Oracle Unified Method (OUM) – An Iterative and Incremental Approach
• WBS (see details of WBS revisions)
• Updated WBS for the following focus areas:
• Manage
• Envision
• Implement

What's New with OUM Templates?

In our ongoing efforts to improve OUM, we have updated our template formats. The updates include:

• Font changed from Book Antiqua to Arial
• Addition of Heading 1 Style and renumbering of all other Headings up one level, e.g., Heading 2 becomes Heading 1; Heading 3 becomes Heading 2, etc.
• Addition of Outline numbering to Headings
• New Heading 2 style (previously Heading 3) includes Heading Bar as part of the style, not a separate paragraph
• Top margin increased to .75 inch to allow for Header to show up properly
• Left margin decreased to 1 inch from 1.75 inches
• As appropriate, tables made consistent with OM menu table style
• Copy Number removed from Title Page
• Distribution Table removed
• Table of Contents reformatted

In order to disrupt users of OUM as little as possible, we have added these updates through a new OUMGuide.dot template in order to preserve the current OMGuide.dot template. In this way, any existing documents based on the OMGuide.dot will not be adversely affected. However, this presents the challenge of having two OUM templates, the old OMGuide.dot and the new OUMGuide.dot.

Any existing word documents that you have created using OUM 5.3 or earlier were based on the OMGuide.dot and should continue with no problems. Any new word documents that you create using OUM 5.4 will be based on the new OUMGuide.dot.

Should you encounter any Visual Basic (VB) errors while working with these documents, we have also provided new associated patch files. The Method_Desktop_Patch-v2.0.doc patch file should be used to correct VB errors in files that use the OMGuide.dot. The Method_Desktop_OUMGuide_Patch.doc file should be used to correct VB errors in files that use the OUMGuide.dot. The previous patch file, Method_Desktop_Patch.doc still works for files using OMGuide.dot for Word 2003 and earlier.

It is important that you run the Method_Desktop_Patch-v2.0.doc patch on Word documents using the OMGuide.dot and the Method_Desktop_OUMGuide_Patch.doc patch on Word documents using the OUMGuide.dot. The new templates and the associated patch and patch readme files are all located in the following directory:

C:\METHOD\OMTE\

NOTE: The default subdirectory is\OMTE. The drive is the one you selected during installation of either a method pack or the stand alone Oracle Method Template Engine. For example, if the Method Packs or Oracle Method Template Engine are installed on your C drive - C:\METHOD\OMTE; if the Method Packs or Oracle Method Template Engine are installed on your D drive - D:\METHOD\OMTE; and so on.

You can run the Method_Desktop_Patch-v2.0.doc patch against an OUMguide.dot file and the Method_Desktop_OUMGuide_Patch.doc patch against an OMguide.dot. This will switch the template file that is loaded with your document. If you do apply the incorrect patch to your Word document, you can simply apply the correct patch to the Word document and correct it.

If you are interested in converting a Word document that uses the old OMGuide.dot to using the new OUMGuide.dot, refer to Section 7 of the Template User’s Guide, Converting from OMGuide.dot to OUMGuide.dot.

Configuring MS Office Macro Security Settings

To assure trouble free operation of method materials, the macro security settings associated with MS Word and MS Excel must be modified. During product installation, the Microsoft install program establishes all MS Office components with the maximum security setting enabled. The affect of this setting is to prohibit the execution of any macro code instructions embedded in either an MS Word document or MS Excel workbook. Because method materials use extensive macro code, the MS Office security level options must be adjusted prior to utilizing the method pack.

To adjust the security level for MS Word 2003:

1. Start Word.
2. Navigate to Tools > Macro > Security…
3. Select the Security Level tab and select the Medium radio button option. This option allows you to choose whether or not to execute macro code instructions.
4. Select the Trusted Publishers tab and make sure that Trust all installed add-ins and templates and Trust access to Visual Basic Project at the bottom are checked.
5. Click OK.

To adjust the security level for MS Word 2007:

1. Start Word.
2. Navigate to Office Button > Word Options > Trust Center > Trust Center Settings >.
3. Select Macro Settings.
4. Make sure that Disable all macros with notification button is selected in the Macros Settings and that Trust access to the VBA project object model is in the Develop Macro Settings.
5. Click OK twice.
6. Exactly the same procedure must be performed with MS Excel to enable the operation of workbook macro codes. Resetting these options assures the operation of our method materials without jeopardizing the built-in security features of MS Office.

Requirements Traceability:

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 the UP, differs from the definition used in Oracle’s Custom Development Method Fast Track (CDM FT), Oracle’s Data Warehouse Method Fast Track (DWM FT), or any Dynamic Systems Development Method (DSDM) based approach. 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.

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 work products – i.e. 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 work products. Therefore, during the Construction phase, an iteration will more likely result in an internal release of software.

OUM’s 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 work product 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 satisfied by a particular business process. To complement business process models, use cases 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 customer

Architecture-Centric

In the context of the software lifecycle, architecture-centric means that the system’s 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 satisfying the contents of a requirements document or rigorously conforming to an existing set of work products. 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 meets 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 work products 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 meet 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. Work products 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 warranted, 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 ensure that the project team addresses the most critical risks as early as possible in the project lifecycle.

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 Project Management 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.
• 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.

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:  

• Document a work product to 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 or a work product from 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 plan.

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.