X

Recent Posts

Release 6.4

Oracle Unified Method (OUM) 6.4

ORACLE® UNIFIED METHOD RELEASE 6.4 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About 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. OUM provides an implementation approach that is rapid, broadly adaptive, and business-focused. OUM includes a comprehensive project and program management framework and materials to support Oracle's growing focus on enterprise-level IT strategy, architecture, and governance. Release OUM release 6.4 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 are provided, including a supplemental guide related to Oracle Tutor and UPK. This release features: Cloud Home Page – Added to Highlight Cloud Support in OUM CAS OUM (Cloud Application Services OUM) [previously OUM Cloud Application Services Implementation Approach] – Updated Task and Activity/Task Group Identifiers, Updated Terminology Operate Focus Area – Added to Provide Visibility into Services Offered by Oracle Managed Cloud Services (OMCS) Establish Governance Activity [previously Complete Project Management Plan] – Renamed and reframed to place greater emphasis on its main objective, which is to establish project governance by engaging in a dialogue to collaboratively define the processes which will be used to govern and control the project from start to finish. This approach recognizes that the delivery of documentation, while necessary and important, should be the byproduct of rather than the driver for conversation. Project Management Plan (PMP) template [previously Project Management Framework] – Developed to streamline the process for documenting project governance. The BT.070 task was renamed to Create Project Management Plan and the guidance was updated. All related tasks that contribute to the PMP were revised to refer to the new PMP template eliminating the prior individual templates. The PMP should be used to document the processes that govern the project.  Once defined, the PMP will remain relatively fixed and only require updates if there are material changes to the governance. Acceptance Certificate [SM.040] Updated and Delivery Note [SM.040] Added - Clarified that acceptance, agreement, and acknowledgment should be secured using one of these templates.  Removed signature boxes / sign-off pages and project manager countersignature from all templates. Risk Management Process, Tasks, and Templates – Streamlined Flow and Clarified Content Access Oracle Customers The OUM Customer Program allows customers to obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure in one of two ways: OUM Customer Program – No-Cost Option: Customers, who have a signed contract with Oracle for a consulting engagement of two weeks or longer meeting some additional minimum criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three year access period. OUM Customer Program – Purchase Option:Customers who do not qualify for the free option, and who do not wish to engage Oracle consultants, can opt to purchase the OUM Method Pack. The price for an unlimited, perpetual license is 16,000 USD. This allows the customer to distribute OUM within their enterprise for internal use. At the time of purchase, customers are also able to purchase an initial three year subscription for 15% of the purchase price or 2,400 USD. After the initial subscription period, the subscription may be renewed annually for 2,400 USD. This subscription allows them to download updates to OUM during the subscription period. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners OPN Diamond, Platinum, and Gold Partners are able to access the OUM method pack, training courses, and collateral from the OPN Portal at no additional cost: Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link. Previous Announcements Oracle Unified Method (OUM) Release 6.4 Oracle Unified Method (OUM) Release 6.3 Oracle Unified Method (OUM) Release 6.2 Oracle Unified Method (OUM) Release 6.1 Oracle Unified Method (OUM) Release 6.0 Oracle Unified Method (OUM) Release 5.6 Oracle Unified Method (OUM) Release 5.5 Oracle Unified Method (OUM) Release 5.4 Oracle EMM Advantage Retired Retirement of Oracle EMM Advantage Planned for December 01, 2011

ORACLE® UNIFIED METHOD RELEASE 6.4 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About Oracle is evolving the Oracle® Unified Method (OUM) to achieve the vision of...

Release 6.3

OUM Key Work Products

Wondering about which tasks and work products are essential for your project? A good resource provided by OUM is a list of key work products for each phase of Implement to assist you in planning, estimating and delivering projects. A key work product is a work product that represents the culmination or end result of work effort that contributes to the achievement of milestone objectives for a phase. Key work products may be considered as candidate deliverables. Not every key work product is created for every project and most likely a project would not be completed by only completing key work products. Additional work products may be required as prerequisites for completing key work products. For example, the Reviewed Use Case Model (RA.180) is a key work product. Both the Use Case Model (RA.023) and the Use Case Specifications (RA.024) contribute to this work product and therefore, would need to be completed. In addition, the unique characteristics of each particular project will necessitate completing additional work products. For the most part, OUM recommends these key work products for all project types. However, there are some work products that become key depending on the specific project requirements. In this case, there is guidance provided in the "Usage Criteria" column of the list. You can locate the link to the list of key work product at the top of the Implement views (except Cloud Application Services) and the Manage view under the "Method Resources" heading.  Check it out the next time you need to build up from the essential work products for your project.

Wondering about which tasks and work products are essential for your project? A good resource provided by OUM is a list of key work products for each phase of Implement to assist you in planning,...

Release 6.3

Access to the Oracle Unified Method (OUM) for Oracle Customers and Partners

This blog entry contains the process and navigation steps for Oracle customers and partners who wish to access OUM, including the Cloud Application Services Approach. Oracle Customers The OUM Customer Program allows customers to obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure in one of two ways: OUM Customer Program – No-Cost Option: Customers, who have a signed contract with Oracle for a consulting engagement of two weeks or longer meeting some additional minimum criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three year access period. OUM Customer Program – Purchase Option: Customers who do not qualify for the free option, and who do not wish to engage Oracle consultants, can opt to purchase the OUM Method Pack. The price for an unlimited, perpetual license is 16,000 USD. This allows the customer to distribute OUM within their enterprise for internal use. At the time of purchase, customers are also able to purchase an initial three year subscription for 15% of the purchase price or 2,400 USD. After the initial subscription period, the subscription may be renewed annually for 2,400 USD. This subscription allows them to download updates to OUM during the subscription period. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners OPN Diamond, Platinum, and Gold Partners are able to access the OUM method pack, training courses, and collateral from the OPN Portal at no additional cost: Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link.

This blog entry contains the process and navigation steps for Oracle customers and partners who wish to access OUM, including the Cloud Application Services Approach. Oracle Customers The OUM Customer...

Planning and Managing

MoSCoW Grooming

I was recently asked whether the MoSCoW List (list of known business requirements classified by the first letter of: Must, Should, Could or Won’t) is a static document. The short answer to this is No – the MoSCoW List is intended to be evolved, some use the term “groomed”, as the project progresses. MoSCoW grooming is a good process to indicate what is inside or outside scope for the project as a whole, as well as for a given phase and/or iteration. 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 groom the MoSCoW list using prioritization techniques 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. 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. The ultimate MoSCoW List should be a mutually exclusive and completely exhaustive set of functional and supplemental requirements. Each requirement should relate to at least one of the objectives stated in the Business and System Objectives (RD.001).   Do you have any tips for MoSCoW grooming?  Please share them in the comments.

I was recently asked whether the MoSCoW List (list of known business requirements classified by the first letter of: Must, Should, Could or Won’t) is a static document. The short answer to this is No...

Release 6.3

Can OUM Support Agile Development?

We are asked from time-to-time whether OUM is considered to be "agile".  There is not really a short answer to this question so this blog entry addresses the key characteristics of OUM that make it an agile method. First of all, OUM is not "waterfall", but instead promotes an iterative and incremental approach to development and deployment of information systems. Any of the tasks within OUM may be iterated. Tasks may be iterated to increase quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand the work products on the basis of user feedback. In addition to having an agile iterative and incremental development approach, OUM also: Is flexible and scalable – OUM is designed to support a broad range of project types. As such, it must be flexible and scalable. The appropriate point of balance for a given project will vary based on a number of project risk and scale factors. The method has been developed with the intent that the approach for a given project be “built up” from a core set of activities to implement an appropriate level of discipline, rather than tailored down. Allows for frequent customer interaction and feedback – OUM encourages regular sessions with stakeholders to review and confirm priorities, and ensure the project continues to meet the overall objectives. Through several prototyping and testing tasks, business stakeholders are given the opportunity to review the development work completed to that point, and provide feedback in time to catch missed requirements and/or possible errors. Employs a layered planning approach – OUM recognizes that plans need to be scalable for different project sizes and complexity, and contain the right level of detail for the current planning horizon. The layered approach to planning an OUM project allows project teams to take an agile approach to their immediate project tasks, while keeping a focus on the major milestones, controls, and objectives of the project. Encourages the use of an empowered team – OUM encourages cross-functional and technical team training and knowledge sharing. In addition, the use of OUM’s common language and visual models (use cases and business process models) throughout the project helps ensure the development team and other project stakeholders are on the same page, which promotes team communication and collaborative decision making. Integrates testing throughout the development lifecycle – Testing in OUM starts early in the project, and developed components are integrated and tested as an integrated set as soon as possible. This allows for early discovery of errors that eventually reduces the risk of project delays that often are caused by heightened error detection at the end of the project. Promotes an architecture-centric approach –  People will sometimes question whether spending time and energy on architecture is compatible with an agile approach. The answer is that a robust architecture is crucial to the project’s success since it is the blueprint upon which requirements are transformed into a working system. Poor architecture decisions can result in software that is not stable, is unable to support business requirements, could require substantial re-work, may not accommodate future development, or could even prevent the application from working properly in a production environment. Nothing about poor architecture sounds too agile, does it? I could go on for a while about OUM’s agile underpinnings; the bottom line is that OUM supports all kinds of projects – from the very lean and adaptable, to those that require more rigor and discipline. If you want to find out more about how OUM can be applied in an agile manner, check out the Scrum View which brings together in once place all of the OUM tasks associated with managing a Scrum project as well as all the OUM supplemental content.   So the answer then is a resounding "yes" (which I suppose is actually the short answer to the question posed in the title of this blog) - OUM is indeed considered to be "agile" and can support agile development.

We are asked from time-to-time whether OUM is considered to be "agile".  There is not really a short answer to this question so this blog entry addresses the key characteristics of OUM that make it an...

Release 6.3

Oracle Unified Method (OUM) 6.3

ORACLE® UNIFIED METHOD RELEASE 6.3 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About 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. OUM replaces Legacy Methods, such as AIM Advantage, AIM for Business Flows, EMM Advantage, PeopleSoft's Compass, and Siebel's Results Roadmap. OUM provides an implementation approach that is rapid, broadly adaptive, and business-focused. OUM includes a comprehensive project and program management framework and materials to support Oracle's growing focus on enterprise-level IT strategy, architecture, and governance. Release OUM release 6.3 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 are provided, including a supplemental guide related to Oracle Tutor and UPK. This release features: OUM Cloud Application Services Implementation Approach to the Application Implementation Method (AIM) Mapping OUM Project Workplan, available in Primavera format, includes Tasks from OUM's Manage and Implement Focus Area RACI - Responsibility Assignment Technique, Template, and Examples Document Application Configuration Changes [MC.055] Task and Template Top-Level Business Capabilities Diagram [EA.040] Template and Capability Analysis Results Presentation [EA.040] Template Maturity Analysis Presentation [ER.015] Template Access to Oracle Managed Cloud Services (OMCS) Implementation Training to Aid Project Managers Interfacing with OMCS Updated/Enhanced: OUM Cloud Application Services Implementation Approach Guidance and Templates updated based on Field Input Template Functionality and Format revised based on Field Requests, specifically removed Oracle Method Template Engine (OMTE) and converted to Microsoft Office 2007 format Template User's Guide revised to address Template Functionality and Format revisions such as Changing Variables, Updating Field Codes, and Removing Yellow Notes OUM Microsoft Project Workplan updated to include Document Application Configuration Changes [MC.055] Task and Activity Filter, converted to MS Project 2007 format, and removed reliance on OUM-specific Microsoft Project Template [Global.mpt] *OUM Microsoft Project Workplan User's Guide updated to reflect changes to OUM Microsoft Project Workplan Project Management Framework supporting Tasks and Templates updated based on Subject Matter Experts Feedback For a comprehensive list of features and enhancements, refer to the What's New page of the Method Pack Upcoming releases will provide expanded support for Oracle's Enterprise Application suites including product-suite specific materials and guidance for tailoring OUM to support various engagement types. Access Oracle Customers The OUM Customer Program allows customers to obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure in one of two ways: OUM Customer Program – No-Cost Option: Customers, who have a signed contract with Oracle for a consulting engagement of two weeks or longer meeting some additional minimum criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three year access period. OUM Customer Program – Purchase Option: Customers who do not qualify for the free option, and who do not wish to engage Oracle consultants, can opt to purchase the OUM Method Pack. The price for an unlimited, perpetual license is 16,000 USD. This allows the customer to distribute OUM within their enterprise for internal use. At the time of purchase, customers are also able to purchase an initial three year subscription for 15% of the purchase price or 2,400 USD. After the initial subscription period, the subscription may be renewed annually for 2,400 USD. This subscription allows them to download updates to OUM during the subscription period. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners OPN Diamond, Platinum, and Gold Partners are able to access the OUM method pack, training courses, and collateral from the OPN Portal at no additional cost: Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link. Previous Announcements Oracle Unified Method (OUM) Release 6.3 Oracle Unified Method (OUM) Release 6.2 Oracle Unified Method (OUM) Release 6.1 Oracle Unified Method (OUM) Release 6.0 Oracle Unified Method (OUM) Release 5.6 Oracle Unified Method (OUM) Release 5.5 Oracle Unified Method (OUM) Release 5.4 Oracle EMM Advantage Retired Retirement of Oracle EMM Advantage Planned for December 01, 2011    

ORACLE® UNIFIED METHOD RELEASE 6.3 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About Oracle is evolving the Oracle® Unified Method (OUM) to achieve the vision of...

Planning and Managing

Questions to Ask When Organizing Your OUM Workplan

So you’ve read all the tips and blogs about how to tailor OUM for your project and you’ve figured out what tasks you need. Now you have to put them into a workplan. What do you do? Do you use the traditional activity wbs structure highlighted in the method or do you need something else? The possibilities are endless. Think about how you implement your projects now. Think about what works now and what doesn’t. Consider this blog my Questions to Ask When Organizing Your OUM Workplan. Does the traditional OUM activity-work-breakdown structure fit my project? Does your project involve more than one custom-off-the-shelf (COTS) product? If so, maybe you want to do this work in partitions. Determine which activities/tasks should be duplicated into each partition. Do you need to consider copying sections of your workplan and putting them into iterations for accommodating use case packages? Can certain processes be run as “mini projects?” Some processes can almost be run as a side project on their own, for example, Technical Architecture (TA), Performance Management (PT), Documentation (DO), Training (TR), and Organizational Change Management (OCM). If so, it may make more sense to group and track these tasks under a process/activity heading and not space them out into the various phases. Do you use one workplan or a master workplan with individual plans that report or roll up into the master? This might work if you have Team Leaders that manage specific pieces of work. Use a placeholder activity/task in the master workplan and the detail can be managed in a sub workplan. The bottom line is, be creative. Build your workplan(s) to suit your project. As you start another project, don’t be afraid to change something that isn’t working. Finally, share your workplans and experiences.

So you’ve read all the tips and blogs about how to tailor OUM for your project and you’ve figured out what tasks you need. Now you have to put them into a workplan. What do you do? Do you use the...

Planning and Managing

Checklists Are Leading Edge

I recently ran across this blog on The Power of Checklists by Ivar Jacobson. In it he describes the value of using checklists on software projects since they: “keep software projects on track, and help maximize the delivery of value, and minimize the risk of project failure.” OUM practitioners know this since the method contains checklists in many places - templates, phase overviews, activities, tasks, etc.  In fact, the WBS itself could be considered a checklist since the activities and tasks are merely “placeholders for work.” The OUM checklists which I find particularly valuable are the Activity Checklists found in each of the Lifecycle Milestone Summaries. These checklists are designed to assist you with the determining “completeness” of the project at that point. They also contain lists of key decisions and common risks that should be addressed during that particular phase of the project – kind of like a “you are here” checkpoint for the project's progress. I think Ivar would agree with me about the value of the OUM Activity Checklists since he is a fan of Barry Boehm’s standard project milestones. You can read more about Barry Boehm’s standard project milestones in his seminal work – “Anchoring the Software Process” [Barry Boehm, November 1995]. Which OUM checklists do you find to be of the most value? Please share your opinion in the comments.

I recently ran across this blog on The Power of Checklists by Ivar Jacobson. In it he describes the value of using checklists on software projects since they: “keep software projects on track,and help...

Planning and Managing

Guard Against the Multitasking Brain Drain with OUM

Most people are aware of the perils of multitasking – it is bad for productivity, increases the possibility of distractions, and basically creates a mental traffic jam. It not only wreaks havoc in everyday life but also causes major problems on projects. If you look at OUM you might be thinking, “Hey wait! Isn’t the fact that OUM’s processes run in parallel and that it takes a cross-functional approach really multitasking?” My response to you (to borrow from Lee Corso) is, “Not So Fast, My Friend!” The answer is directly related to magnitude of the shifts in focus. We know that those broad deviations in requirements and technology require more adjustment and time to switch gears. Human brains are okay with shifting tasks within reasonable limits. On a well managed OUM project, the team is focused on a discrete, prioritized list of functionality and technology. Only a limited number of logically grouped requirements are being worked at a time in order to achieve specific milestones. This means there is a narrow span of scope being addressed at any point in the project, even there may be a wide range of tasks and processes in play. Extensive detours such as new requirements and major shifts in priorities are the catalysts that can lose the project to the nemesis known as multitasking. Fortunately, OUM has a number of tools to keep the focus and guard against the multitasking brain drain – timeboxes, MoSCoW lists, use cases, and system context diagrams...just to name a few. What are some tools you use to keep your projects focused? Please share with us in the comments section below!

Most people are aware of the perils of multitasking – it is bad for productivity, increases the possibility of distractions, and basically creates a mental traffic jam. It not only wreaks havoc in...

Training

OUM Training Program: Project Workplan Overview

Course Description | Access | Training Program Course DescriptionThe Oracle® Unified Method (OUM) Project Workplan Overview training consists of a collection of short, independent modules that provide information about and a demonstration of key features of the OUM Project Workplan.The OUM Project Workplan, available in Microsoft Project format, includes tasks from OUM's Manage and Implement Focus Areas and can be: executed at the activity-level or task-level, tailored easily for most OUM Implement views, and updated with effort from the OUM Estimating Model.Audience: Bid Management, Risk Management, Quality Management, Project Management, Program Management, Solution Architects, Team Leads, Delivery Consultants Prerequisites: None Delivery: This training can be taken on-line or downloaded and taken off-line at your leisure Time Required: The duration of the modules ranges from 3 to 40 minutesAccessOracle CustomersCustomers enrolled in the OUM Customer Program are able to access the training courses from the Oracle Learning Library.Go to the OUM page on the Oracle Learning Library. Select the "OUM Project Management Skills" tab.  Learn about the OUM Customer Program.Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold PartnersOPN Diamond, Platinum, and Gold Partners are able to access the training courses from the OPN Portal.Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link.Expand the "Training " section.Select the "OUM Training Program" link.Expand the "Level 2" section.Go to the "Level 2 - OUM Project Workplan Overview" sub-section.Training ProgramThe Oracle® Unified Method (OUM) Training Program helps to ensure that individuals in delivery and management roles have the level of knowledge about OUM that is required for them to competently perform their job.The Program consists of four levels of training:Level 1 – Overview and Awareness Level 2 – Focus Area Overviews for Manage, Envision, Implement Level 2 – Cloud Application Services Implementation Approach Overview Level 2 – Use Case Overview Level 3 – Gathering Requirements using OUM Level 4D – Discipline-specific Delivery ReadinessLevels 1, 2, and 4 are online, self-service courses. Level 3 is a two-day, instructor-led course available for a fee. 

Course Description | Access | Training Program  Course Description The Oracle® Unified Method (OUM) Project Workplan Overview training consists of a collection of short, independent modules that provide...

Eleven Questions to Ask When Tailoring OUM for Your Project

I’ve posted several blogs in the past on tailoring OUM. Here’s one more. As you can see from the title, I call this one Eleven Questions to Ask When Tailoring OUM for Your Project.  Start with the Core Workflow and adjust it based on the following questions.Do you need additional Business Requirements (RD) and Requirements Analysis (RA) tasks?  If so, add them.Are you implementing a custom-off-the-shelf (COTS) product?  If yes, review the Mapping and Configuration (MC) process and add any tasks not already included in the Core Workflow.  If no, remove the Configuration Sub-Flow tasks.Is there custom work?  If yes, add additional Analysis (AN), Design (DS), Implementation (IM) and Testing (TE) tasks, as appropriate.  If no, you may be able to remove the tasks in the Custom Development Sub-Flow.What are the Technical Architecture (TA) requirements?  Add TA tasks as appropriate.Will there be any data conversion?  Add any Data Acquisition and Conversion (CV) tasks as appropriate.Are there any Performance Management (PT) requirements?  Add PT tasks as appropriate.What are the Documentation (DO) requirements?  Add DO tasks as appropriate.What are the Organizational Change Management (OCM) requirements?  Add OCM tasks as appropriate.What are the Training (TR) requirements?  Add TR tasks as appropriate.What are the Transition (TS) requirements?  Add TS tasks as appropriate.What are the Operations and Support (PS) requirements?  Add PS tasks as appropriate.Now that you’ve identified all the tasks you need, consider how you want to approach your project.  Can you use the traditional OUM WBS approach or do you need to configure your workplan a little differently.  The possibilities are endless, but that’s a discussion for my next blog.

I’ve posted several blogs in the past on tailoring OUM. Here’s one more. As you can see from the title, I call this one Eleven Questions to Ask When Tailoring OUM for Your Project.  Start with the Core...

General

OUM Success Story: Multi-Product Implementation for a Leading Travel and Transportation Client

More success! Or in honor of the 2014 World Cup in Brazil we should say: "¡GOL!"  As follow-on to my previous blog entry on the OUM Success Quote, here we have an example of how OUM was used successfully on a highly complex, multi-product project. Project Profile:  A leading Travel and Transportation Company increased customer satisfaction and streamlined accounting functions through an implementation of Oracle E-Business Suite, Oracle Business Intelligence Applications, and Hyperion Solution.  Use of OUM provided significant value to the project by providing the framework to establish an Integrated Project Plan: Using the same phasing and terminology on the overall project workplan for the separate E-Business Suite, OBI EE / OBIA, and Hyperion project partitions, enabled the project to leverage an Iterative and Incremental approach while enabling a complete view of the major milestones and touch points between the different partitions. One aspect of particular significance is that this project utilized the technique of partitioning the project plan so that the work was divided into more manageable pieces. When dealing with large and/or complex projects it is advisable to split the functionality that is targeted to be implemented into smaller bits of effort.  We call these partitions in OUM, but they can also referred to as workstreams, subsystems, pillars, etc..  No matter what they are called, the whole idea is to logically break up the work, while still allowing for a common approach and integration of the tasks at key points in the project.  As you can see, the result on this project was a successful implementation and a very satisfied client.   Do you have an OUM project success you would like to share?  Please let us know in the comments.     

More success! Or in honor of the 2014 World Cup in Brazil we should say: "¡GOL!"  As follow-on to my previous blog entry on the OUM Success Quote, here we have an example of how OUM was...

Planning and Managing

Success Quote: A Hybrid Approach for Success

We recently received this quote from a project that successfully used OUM: “On our project, we applied a combination of the Oracle Unified Method (OUM) and the client's methodology. The project was organized by OUM's phases and a subset of OUM's processes, tasks, and templates. Using a hybrid of the two methods resulted in an implementation approach that was optimized for the client-specific requirements for this project." This hybrid approach is an excellent example of using OUM in the flexible and scalable manner in which it was intended. The project team was able to scale OUM to be fit-for-purpose for their given situation. It's great to see how merging what was needed out of OUM with the client’s methodology resulted in an implementation approach that more closely aligned to the business needs. Successfully scaling OUM is dependent on the needs of the particular project and/or engagement. The key is to use no more than is necessary to satisfy the requirements of the implementation and appropriately address risks. For more information, check out the "Tailoring OUM for Your Project" page, which can be accessed by first clicking on the "OUM should be scaled to fit your implementation" link on the OUM homepage and then drilling into the link on the subsequent page. Have you used OUM in conjunction with a partner or customer methodology? Please share your experiences with us.

We recently received this quote from a project that successfully used OUM: “On our project, we applied a combination of the Oracle Unified Method (OUM) and the client's methodology. The project was...

General

Oracle Unified Method (OUM) Partner Program

Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners The Oracle Unified Method (OUM) is available to Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners as a benefit of membership.  Partners at these three levels are able to download OUM from the Oracle Unified Method Knowledge Zone on the Oracle PartnerNetwork (OPN) Portal at no additional cost. Authorized use of OUM materials by Oracle PartnerNetwork Diamond, Platinum, and Gold Partners is described in Section G. of the Oracle PartnerNetwork Agreement entitled Methodology/Engagement Materials. It grants Oracle PartnerNetwork Diamond, Platinum, and Gold Partners a non-exclusive, non-transferable, limited license to use and make copies of the materials, subject to OPN policies, for the following purposes: Use the materials in connection with the implementation of programs for end users who have acquired valid licenses for such programs; Provide training to partner employees in use of the materials; Demonstrate the materials to end users; and Copy the materials for archival or backup purposes. Oracle PartnerNetwork Diamond, Platinum, and Gold Partners may allow their agents and contractors to use the materials for these purposes, subject to the terms of the Oracle PartnerNetwork Agreement. All titles, trademarks, and copyright and restricted rights notices contained in the materials shall be reproduced in any copies of the materials. All copies of the materials shall be subject to the terms of this agreement. Partners meeting the access requirements described above can obtain the OUM materials.  To access the method pack, related collateral, and training courses: Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link.

Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners The Oracle Unified Method (OUM) is available to Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners as a benefit of...

Release 6.2

Where’s My View?

With release 6.1 and continued with 6.2, the Home page access pull down was renamed from Select a View to Access Method By and the options were changed.  The view access is still available, but now you also can access applicable OUM content by role (Project Manager or Team Member) or by Supplemental Guidance (Solution Delivery Guide or Supplemental Guide) or by Method Repository.  So let’s talk about each of these options as well as review the View option.By RoleAccess is defined for two roles; Project Manager and Team Member.The OUM for Project Managers access page provides quick links into OUM content that is applicable to Project Managers.  This includes the Manage views, the templates, and valuable resources such as Planning a Project using OUM and Tailoring OUM for your Project.The OUM for Team Members access page provides quick links for all other roles.  This includes the Method Repository, the templates, examples, mappings and techniques.By Supplemental GuidanceSupplemental Guidance access is by Solution Delivery Guide or Supplemental Guide.  Selecting either of these takes you to the appropriate section of the Supplemental Guide Index.  This access selection enables you to go straight to the supplemental guidance that best fits your immediate needs.  Choose Solution Delivery Guide to access the Cloud Application Services Implementation Approach Solution Delivery Guide.  OUM contains a good number of Supplemental Guides.  The guides are presented in alphabetical order.  By Method RepositoryThe Method Repository section of the Access Method By pull down provides access to the core OUM process overviews, task overviews and templates for each focus area.By ViewIf you are familiar with previous releases of OUM and you want to know what happened to your view, start with the ==VIEW== section of the Access Method By pull down.  This section is organized as follows, Manage, Envision, Implement, Business Process Management (BPM), Service-Oriented Architecture (SOA) and Full Method.  Selecting the ==VIEW==, Manage, Envision, Implement or Full Method takes you to the appropriate section of the View Catalog.  Once in the View Catalog, choose your view.  Selecting Business Process Management (BPM) or Service-Oriented Architecture (SOA) takes you to the associated landing page and you can then choose your view.

With release 6.1 and continued with 6.2, the Home page access pull down was renamed from Select a View to Access Method By and the options were changed.  The view access is still available, but now...

Planning and Managing

New in OUM - The Abbreviated PMP Template

Did you know that OUM now contains an Abbreviated Project Management Plan (PMP) template in the BT.070 – Create Project Management Framework task?  If you have been around OUM for a while, or have been a project manager using another methodology that aligns to PMI's global standards, you know that the PMP is key to promoting project success. The PMP is the work product that captures the project approaches for all of the OUM Manage processes. The Abbreviated PMP template in OUM is a MS-PowerPoint deck that serves to encapsulate the essential elements of the overall plan into a single presentation. The Abbreviate PMP is applicable for smaller (<500 day projects is the general recommendation) and/or agile projects which call for lightweight, low-ceremony documentation. It is also well-suited to the PMP index approach where planning documents are written as separate documents and then linked within the master presentation. In any kind of project, it can serve as a scalable presentation which may be used during the project kick-off or other team meetings. Regardless of which approach you take on your project, the PMP template (or any OUM work product for that matter) should be revised to fit the needs of your project. Check out the new Abbreviate PMP template and let us know your thoughts.

Did you know that OUM now contains an Abbreviated Project Management Plan (PMP) template in the BT.070 – Create Project Management Framework task?  If you have been around OUM for a while, or have...

Release 6.2

Oracle Unified Method (OUM) 6.2

ORACLE® UNIFIED METHOD RELEASE 6.2 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About 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. OUM replaces Legacy Methods, such as AIM Advantage, AIM for Business Flows, EMM Advantage, PeopleSoft's Compass, and Siebel's Results Roadmap. OUM provides an implementation approach that is rapid, broadly adaptive, and business-focused. OUM includes a comprehensive project and program management framework and materials to support Oracle's growing focus on enterprise-level IT strategy, architecture, and governance. Release OUM release 6.2 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 are provided, including a supplemental guide related to Oracle Tutor and UPK. This release features: OUM Cloud Application Services Implementation Approach Templates Updated/Enhanced: OUM Cloud Application Services Implementation Approach Guidance and Templates fully integrated The Open Group Architecture Framework (TOGAF) View updated to align with TOGAF Version 9.1 Scrum View enhanced based on feedback from Subject Matter Experts, including additional Tasks and Technique Guidance Implement Core Workflow refined based on feedback from Subject Matter Experts Manage Work Breakdown Structure (WBS) refined based on feedback from Subject Matter Experts, specifically CMM.060 Submit Final Reports task moved to Close Processes and Contract activity and QM.030 Conduct Project Team Quality Management Orientation task moved to Orient and Manage Team activity OUM Microsoft Project Workplan Template realigned with Manage WBS Compliance with Oracle's Accessibility Guidelines - Phase Two For a comprehensive list of features and enhancements, refer to the "What's New" page of the Method Pack. Upcoming releases will provide expanded support for Oracle's Enterprise Application suites including product-suite specific materials and guidance for tailoring OUM to support various engagement types. Access Oracle Customers The OUM Customer Program allows customers to obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure – in one of two ways: OUM Customer Program – No-Cost Option: Customers, who have a signed contract with Oracle for a consulting engagement of two weeks or longer meeting some additional minimum criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three year access period. OUM Customer Program – Purchase Option: Customers who do not qualify for the free option, and who do not wish to engage Oracle consultants, can opt to purchase the OUM Method Pack. The price for an unlimited, perpetual license is 16,000 USD. This allows the customer to distribute OUM within their enterprise for internal use. At the time of purchase, customers are also able to purchase an initial three year subscription for 15% of the purchase price or 2,400 USD. After the initial subscription period, the subscription may be renewed annually for 2,400 USD. This subscription allows them to download updates to OUM during the subscription period. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners OPN Diamond, Platinum, and Gold Partners are able to access the OUM method pack, training courses, and collateral from the OPN Portal at no additional cost: Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link. Previous Announcements Oracle Unified Method (OUM) Release 6.2 Oracle Unified Method (OUM) Release 6.1 Oracle Unified Method (OUM) Release 6.0 Oracle Unified Method (OUM) Release 5.6 Oracle Unified Method (OUM) Release 5.5 Oracle Unified Method (OUM) Release 5.4 Oracle EMM Advantage Retired Retirement of Oracle EMM Advantage Planned for December 01, 2011

ORACLE® UNIFIED METHOD RELEASE 6.2 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About Oracle is evolving the Oracle® Unified Method (OUM) to achieve the vision of...

General

Scrum Teams -- Do you feel the rhythm?

Hi, I’m Terri Merenkov a member of the Global Methods team at Oracle. This month I celebrate my 18th year with Oracle. You might be surprised by that, but many in the Global Methods team have more tenure than I do. This is part of what makes my job so interesting. If I don’t know the answer to something about Oracle Implementation projects of a certain type, I don’t have to go far to find someone who does. Even though some concepts have been around for a while, there is always something new coming so we are constantly adapting and changing.We have many things to learn about, today, even though they may have been around for a while, for example Scrum. Scrum was created in 1993 by Jeff Sutherland. The term “scrum” is borrowed from an analogy used in the 1986 study by Takeuchi and Nonaka (Takeuchi), published in the Harvard Business Review. In the study, the authors equated high-performance, cross-functional teams to the packs formed by Rugby teams.Here we are nearly two decades later actually applying Scrum in our software development projects. Yet some people think that Scrum is new,maybe it is coming into the mainstream perhaps because we realize that often taking something large and breaking it down helps support a successful software implementation.  It is only now that we're seeing teams celebrate success using Scrum.  Of course, not everyone is successful. Scrum seems so simple, it's often the human factor that really determines how well things go.In the 80’s I was very into music, I started in University as a music education major. My major was percussion as well as piano, with a minor in French. At the time, I had no idea what a computer was, however, I was playing electric keyboards “synthesizers” with built-in percussion instruments of course I was enamored with the Mellotron and Moog synthesizers that were being used by some of the progressive rock bands. Once I discovered that music was being cut from the curriculum of many schools, I decided to re-think my major. A software “recruiter” lived across the street from me. She suggested that I try taking some computer courses, since often people who are good at music and language happen to excel in using computers. I began taking classes in computer science, and the more I learned, the more I wanted to know!I find it interesting at this point in my life, I’m being reminded of good things that I learned about when I was younger, that are actually useful in my adult life – today.Just the other day, I was working on some updates to the Scrum View in OUM and I came across the word “Cadence”. Oh, I thought, I know about Cadence! Any good drummer knows that a cadence is needed to get the marching band to stay in step when marching across the football field or in a parade.  Of course the percussionists are experts in various percussion instruments, The percussionists in a marching band have a natural rhythm, in fact when the band is marching in between songs, the percussionists are keeping a cadence that allows everyone to step together, as part of a group, each individual takes nice even steps until we’re in place to play the next song.  This rhythm can me a steady tapping on the drum "rims" or use of the full percussion instrument.So think about a Scrum team, just the way you would think about a group of musicians in a band. Good Scrum teams “feel the rhythm” they have a cadence that allows the team to work together easily, almost naturally. With each Sprint retrospective, they examine what worked and what didn’t. Over the course of several Sprints, a true cadence is achieved by the team. A sustainable team cadence leads us to another term used in the Scrum approach; velocity. When I think of velocity, I think of speed, but in a software development effort, speed isn’t always our main focus. In Scrum, velocity is obtained by calculating the number of units of work that can be completed by the team during a specific timeframe (Sprint). Velocity refers to the speed at which a team can implement and test use cases (user stories) and change requests (that is, how much of the product backlog the team can complete). This is reflected in the Burndown Charts by showing the progress made so far versus the planned/estimated progress. Of course with each Scrum Sprint, the team becomes more experienced, and can determine velocity based on how many units of work they have completed during previous Sprints. Contrary to what some may say, even though Scrum uses the word Sprint, we aren’t necessarily only focused on going as fast as we can until we burn out the team. Rather, we work on building teams that can develop, test and integrate working software in a collaborative, yet agile fashion.  This results in a sustained rhythm. So I ask you - can YOU feel the rhythm? What experiences have you had in building expert teams that work well together?  Have you used Scrum successfully and why?  Listen... do you feel it?

Hi, I’m Terri Merenkov a member of the Global Methods team at Oracle. This month I celebrate my 18thyear with Oracle. You might be surprised by that, but many in the Global Methods team have more...

General

Oracle Unified Method (OUM) Customer Program

PURCHASE OPTION NOW AVAILABLE! Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions The Oracle® Unified Method (OUM) Customer Program has been expanded to include a purchase option. The Program allows customers to obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure – in one of two ways: 1.) OUM Customer Program – No-Cost Option: Customers, who have a signed contract with Oracle for a consulting engagement of two weeks or longer meeting some additional minimum criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three year access period. 2.) OUM Customer Program – Purchase Option: Customers who do not qualify for the free option, and who do not wish to engage Oracle consultants, can opt to purchase the OUM Method Pack. The price for an unlimited, perpetual license is 16,000 USD. This allows the customer to distribute OUM within their enterprise for internal use. At the time of purchase, customers are also able to purchase an initial three year subscription for 15% of the purchase price or 2,400 USD. After the initial subscription period, the subscription may be renewed annually for 2,400 USD. This subscription allows them to download updates to OUM during the subscription period. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program.

PURCHASE OPTION NOW AVAILABLE! Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions The Oracle® Unified Method (OUM) Customer Program has been expanded to include a purchase...

Release 6.1

Oracle Unified Method (OUM) 6.1

ORACLE® UNIFIED METHOD RELEASE 6.1 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About 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. OUM replaces Legacy Methods, such as AIM Advantage, AIM for Business Flows, EMM Advantage, PeopleSoft's Compass, and Siebel's Results Roadmap. OUM provides an implementation approach that is rapid, broadly adaptive, and business-focused. OUM includes a comprehensive project and program management framework and materials to support Oracle's growing focus on enterprise-level IT strategy, architecture, and governance. Release OUM release 6.1 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 are provided, including a supplemental guide related to Oracle Tutor and UPK. This release features: Project Manager and Consultant views provide quick access to material relevant to each role OUM Cloud Application Services Implementation Approach Solution Delivery Guide 3.0 and Project Workplan Template OUM Microsoft Project Workplan Template and User's Guide updated to facilitate review and removal of out-of-scope Activities and Tasks MC.050 Application Setup Template available in Microsoft Excel format in addition to Microsoft Word format BT.070 Abbreviated Project Management Framework Presentation Template Envision Examples for Enterprise Organization Structures (BA.020), Enterprise Business Context Diagram (BA.045), and High-Level Use Cases (BA.060) Implement Examples for System Context Diagram (RD.005), Business Use Case Model (RA.015), Use Case Model (RA.023), MoSCoW List (RD.045), and Analysis Specification (AN.100) Home Page drop-down menu allows access to the method by Role, Supplemental Guidance, Method Repository, or View For a comprehensive list of features and enhancements, refer to the "What's New" page of the Method Pack. Upcoming releases will provide expanded support for Oracle's Enterprise Application suites including product-suite specific materials and guidance for tailoring OUM to support various engagement types. Access Oracle Customers Oracle customers may obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure – by contracting with Oracle for a consulting engagement of two weeks or longer and meeting some additional minimum criteria. Customers, who have a signed consulting contract with Oracle and meet the engagement qualification criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three-year access period. Training courses are also available to these customers. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners OPN Diamond, Platinum, and Gold Partners are able to access the OUM method pack, training courses, and collateral from the OPN Portal at no additional cost: Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link. Previous Announcements Oracle Unified Method (OUM) Release 6.1 Oracle Unified Method (OUM) Release 6.0 Oracle Unified Method (OUM) Release 5.6 Oracle Unified Method (OUM) Release 5.5 Oracle Unified Method (OUM) Release 5.4 Oracle EMM Advantage Retired Retirement of Oracle EMM Advantage Planned for December 01, 2011

ORACLE® UNIFIED METHOD RELEASE 6.1 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About Oracle is evolving the Oracle® Unified Method (OUM) to achieve the vision of...

New in OUM 6.0: Scrum View and Project Plan

Have you checked out the newly released OUM 6.0?  Amongst the many items on the "What's New" list you will notice that there is a new Scrum view and project plan, which are the direct result of collaboration by many global subject matter experts.  The Scrum view and associated project plan provide a conceptual look at managing a Scrum-based project using OUM as the method and source of work products. The Scrum view brings together into one place all the OUM tasks associated with managing a Scrum projects as well as all OUM Scrum supplemental content.  The view provides navigation via a familiar Scrum Framework diagram, as well as by the more textual "Task and Work Products" section.  The content within the view is grouped according to the Scrum Framework components of Project Kickoff, Sprint Planning, Sprint Review and Sprint Retrospective.  This grouping allows those who are new to Scrum as well as those who are Scrum experts to be able to find relevant materials for their engagements. Although a formal project plan may not be considered part of a highly agile environment, the Scrum project plan is provided to give projects a starting point for their plans and to leverage when the project situation calls for it.  Also, the plan may be helpful as an education tool for those audiences less familiar with Scrum.  As with any OUM project, this project plan should be tailored to suit the individual engagement. Be sure to take a look at the new content within OUM 6.0 and provide your comments.

Have you checked out the newly released OUM 6.0?  Amongst the many items on the "What's New" list you will notice that there is a new Scrum view and project plan, which are the direct result of...

Oracle Unified Method (OUM) 6.0

ORACLE® UNIFIED METHOD RELEASE 6.0 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About 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. OUM replaces Legacy Methods, such as AIM Advantage, AIM for Business Flows, EMM Advantage, PeopleSoft's Compass, and Siebel's Results Roadmap. OUM provides an implementation approach that is rapid, broadly adaptive, and business-focused. OUM includes a comprehensive project and program management framework and materials to support Oracle's growing focus on enterprise-level IT strategy, architecture, and governance. Release OUM release 6.0 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 are provided, including a supplemental guide related to Oracle Tutor and UPK. This release features: OUM Cloud Application Services Implementation Approach Solution Delivery Guide and Project Workplan Scrum View and Project Workplan Mapping and Configuration (MC) Process Nominal Group Technique Compliance with Oracle's Accessibility Guidelines - Phase One Enhanced / Updated: Business Intelligence and Analytics Custom Development and Business Intelligence and Enterprise Performance Management Implementation Views and Supplemental Guides merged into Business Intelligence (BI) View and Supplemental Guide OUM Microsoft Project Workplan Template and User's Guide aligned with OUM 6.0 Work Breakdown Structure (WBS) and Activity-level Dependencies, consolidated Views, and enhanced Row Filtering Oracle Support Services Supplemental Guide expanded for Incident Management Activities and Tasks in Implement Focus Area reorganized to achieve commonality of discipline and required skills for all Tasks within an Activity in order to facilitate planning using Partitions (for Configuration and Custom Work) and Iterations Organizational Change Management Process aligned with current Leading Practices, specifically Activities and Tasks in the Inception and Elaboration Phases Scrum to OUM Mapping For a comprehensive list of features and enhancements, refer to the "What's New" page of the Method Pack. Upcoming releases will provide expanded support for Oracle's Enterprise Application suites including product-suite specific materials and guidance for tailoring OUM to support various engagement types. Access Oracle Customers Oracle customers may obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure – by contracting with Oracle for a consulting engagement of two weeks or longer and meeting some additional minimum criteria. Customers, who have a signed consulting contract with Oracle and meet the engagement qualification criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three-year access period. Training courses are also available to these customers. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners OPN Diamond, Platinum, and Gold Partners are able to access the OUM method pack, training courses, and collateral from the OPN Portal at no additional cost: Go to the OPN Portal at partner.oracle.com. Select "Sign In / Register for Account". Sign In. From the Product Resources section, select "Applications". From the Applications page, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, locate the "I want to:" section. From the I want to: section, locate and select "Implement Solutions". From the Implement Solution page, locate the "Best Practices" section. Locate and select the "Download Oracle Unified Method (OUM)" link. Previous Announcements Oracle Unified Method (OUM) Release 6.0 Oracle Unified Method (OUM) Release 5.6 Oracle Unified Method (OUM) Release 5.5 Oracle Unified Method (OUM) Release 5.4 Oracle EMM Advantage Retired Retirement of Oracle EMM Advantage Planned for December 01, 2011

ORACLE® UNIFIED METHOD RELEASE 6.0 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About Oracle is evolving the Oracle® Unified Method (OUM) to achieve the vision of...

Planning and Managing

Tailoring the OUM Workplan

Did you know that OUM has guidance for tailoring your project?Located in the Supplemental Guidance section of the Key Components on the Manage view is the Tailoring OUM for Your Project guidance.  This guidance describes a step-by-step process for tailoring OUM for your project.  This process starts with the Estimate and/or Proposal and ends with Assigning Resources and Duration to Activities and Tasks.  What this blog focuses on is the tailoring of the actual OUM Project Workplan for your project for activities and tasks (tailoring steps 2.0 through 5.2) including tips for applying a bottom-up as well as a top-down technique for tailoring the Project Workplan.  So let’s get started.For our example, we are starting with the OUM Project Workplan that is located in the Method Resources section of the Key Components of most view pages. In OUM 5.6, a new Project Workplan template was introduced with pre-tailoring capability for most Implement views.  Our example project also is most closely aligned with the Requirements-Driven Application Implementation view.To develop our Project Workplan, we have several options.  We can employ a top-down approach and start with all of OUM and tailor it down.  We can employ a bottom-up approach and start with the Core Workflow and build up from there.  The best approach is probably to start with the workplan that most closely matches our engagement and tailor up and down.  That is, immediately tailor down to a pre-tailored Workplan and continue to tailor from there based on the requirements of the engagement, while simultaneously keeping in mind the Core Workflow and building up from there.So for our example, we are starting with the Requirements-Driven Application Implementation pre-tailored OUM Project Workplan.Our next step is to eliminate activities/tasks that are not needed. Consider the following:Don’t eliminate anything in the Core Workflow without carefully consideration. Review any available supplemental guidance. Consider removing activities/tasks NOT included in the Estimate and/or Proposal. Determine if it’s possible to eliminate all if not most of some processes. For example, consider removing the following processes and corresponding activities and/or tasks, if your project does not include ANY requirements for them: Performance Management Organizational Change Management Training Data Acquisition and Conversion Now that we have tailored down, we should consider if we need to add any activities/tasks.  These include two types of activities/tasks:Activities/Tasks that were excluded from the Requirements-Driven Application Implementation pre-tailored Project Workplan, and Project-Specific (Custom) Activities/Tasks For the excluded activities/tasks, use the 01_OUM_Set_Project_Filter view of the OUM Project Workplan to review any activities/tasks that were not included in the Requirements-Driven Application Implementation pre-tailored OUM Project Workplan and determine if they are needed for the engagement.Project-specific custom activities/tasks are activities/tasks that are not already included in OUM. Add these to the Project Workplan.Now we have a tailored OUM Project Workplan for our engagement.  However, we still need to apply partitioning, if applicable, and iteration planning.  This however is a topic for another blog.  In the meantime, I encourage you to peruse the following OUM guidance:From the Manage view, Key Components, Supplemental Guidance:Planning a Project using OUM Tailoring OUM for Your Project Form the Manage view, Key Components, Method ResourcesOUM Project Workplan – This link accesses the Project Workplan page which allows you to download a zipped file containing the Project Workplan and the Project Workplan User’s Guide. Finally, you might also want to review the Task Overviews for WM.010 (Develop Baseline Project Workplan) and WM.030 (Manage Project Workplan).

Did you know that OUM has guidance for tailoring your project?Located in the Supplemental Guidance section of the Key Components on the Manage view is the Tailoring OUM for Your Project guidance. ...

Estimating

Steps to Create an OUM Estimating Model - Part 5

Welcome to Part V of the Five Part Blog Series -- “Steps to Creating an OUM Estimating Model”.  Developing the estimating model is only part of the process.  Equally important is the testing and refinement of the estimating model.Test and Refine the Estimating ModelOnce the implementation approach is identified, the conditions for whether the individual estimating components are included, and the factors that influence the effort for the estimating components have been identified and quantified, it is time to test the results.Testing, refining and re-testing the estimating model is an iterative process.  It is important to test many scenarios and to use top-down estimates to both validate the overall estimating result, and the distribution of effort to the phases.  Top down estimating is an effective way to identify red-flags and omissions that need to be fixed and retested.Using OUM’s Iterative and Incremental Development ApproachCongratulations!  You have learned how to develop an OUM estimating model.  The next step is to maintain and improve the model.  The most effective way to create an estimating model is to apply the iterative and incremental development approach.  Start simple and iterate with continuous improvement increments based on actual usage or expanded functionality.Good luck with your estimating model development efforts!

Welcome to Part V of the Five Part Blog Series -- “Steps to Creating an OUM Estimating Model”.  Developing the estimating model is only part of the process.  Equally important is the testing...

Estimating

Steps to Create an OUM Estimating Model - Part 4

Welcome to Part IV of the Five Part Blog Series -- “Steps to Creating an OUM Estimating Model”.  In today’s blog, I will share with you, from my experience, the key steps in creating a reasonable, repeatable estimating model.Steps for Developing an OUM Estimating Model A.   Assemble the Estimating Model Development TeamAs discussed, the goal of an estimating model is to estimate a scope of work yielding consistent effort for consistent scope regardless of the experience of person or people creating the estimate.  In order to achieve this goal, a team of diverse, experienced Subject Matter Experts (SMEs) must be assembled.B.   Defining the Scope of the Estimating ModelBefore you begin building an estimating model, always clearly define what is in and out of scope for the estimate.  Technology has become complex and product suites include multiple products and technologies.  Be sure to clearly define and document the scope of what you estimate, and what you do not estimate.  For example, if you are estimating integration effort for a particular product, you will need to define whether you are estimating the development of the entire integration, or simply the integration point (SOA enablement, API, etc) for your product.  C.  Determine the Estimating Component LevelAs you know, the lowest level of detail in OUM is the task level, but OUM also groups tasks into Activities.  For the purpose of a bottom up estimate, you will need to determine what level of detail you want to achieve in your estimating model – either the task level or the activity level.While the task level estimating model provides a higher degree of accuracy, the development and maintenance effort is increased.  For the purpose of estimating, the activity level may provide the level of detail that you need.  Once you identify the estimating component level – either the task or the activity level -- you will want to identify those OUM tasks or activities that are typically in-scope for the estimating model.   D. Understand the Implementation ApproachYou will not be successful in creating a reasonable estimate if you do not understand the implementation approach – in this case OUM.   This is one of the most important steps in creating your estimating model, especially a bottom-up estimate.  As you identify your implementation approach, think about whether the estimating component is always needed (required) or if it is optional.  If the estimating component is optional, then think about the conditions that will trigger it to be needed.  An estimating model will need to identify these conditions to add the optional estimating components and associated effort when the conditions are met.E.  Determine the “standard” effort and Identify factors that influence estimateFor each estimating component regardless of whether they are required or optional, determine the “standard” effort and the conditions that increase or decrease the standard effort.  Here are a couple of approaches to doing this step:  include a base number, and then ask questions to either add or subtract effort Identify a range of effort for each estimating component and ask questions to help determine where in this range of effort you need to be. Keep in mind that you can create a simple estimating model with each question influences the effort of one estimating component, or a more complex estimating model where multiple questions are asked to determine the effort of an estimating component, or one question influences the effort of multiple estimating components,  or both ( multiple questions are asked which influence multiple estimating components’ effort).  The correct level of complexity for an estimating model typically reveals itself during the development process.  My advice is to start simple and add complexity where and when it is needed. This step is the most time consuming and difficult for estimating model developers to perform.  I normally see a lot of passionate discussion from the development team reflecting unique experiences and past pain!  If you experience this when developing your estimating model, then take a deep breath and know you are on the right path!

Welcome to Part IV of the Five Part Blog Series -- “Steps to Creating an OUM Estimating Model”.  In today’s blog, I will share with you, from my experience, the key steps in creating a reasonable,...

Estimating

Steps to Create an OUM Estimating Model - Part 3

Welcome to Part III of the Five Part Blog Series -- “Steps to Create an OUM Estimating Model”.  Today we will explore the different types of estimating models commonly used in the industry.Types of Estimating Models                Bottom Up Estimating – A bottom up estimate decomposes the project down to very small components of work, for example, an Activity or a Task.   It estimates each component to arrive at the estimate for the whole.  This estimating approach is the most time consuming, but typically results in the most accurate estimate.                Top Down Estimating – A top down estimate applies experience from similar projects to arrive at an estimated overall effort, or a distribution of effort to project phases.  For example, if you are estimating a WebCenter Portal engagement, you may create a top down estimate by reviewing past Portal projects with similar high-level requirements.  Based on this information, you may arrive at a broad estimate for the project as a whole.  You can also evaluate similar projects to understand high-level project metrics such as the % of overall effort consumed in each project phase.  This information provides a good starting point for creating an estimating model, and it can provide a key role in validating a bottom up estimate.In this blog, I will primarily be focusing on providing tips for creating a bottom-up estimating model as this type of estimating model is generally thought to be both the most accurate, and the most difficult to create.  Although the bottom-up estimate tends to create the most accurate estimate, it is worthwhile to apply a top-down estimate as a sanity check.  This is especially useful during the testing and initial roll-out of a new estimating model.Before we jump into the steps for creating an OUM estimating model, it is important to establish that this blog focuses on estimating effort (# days or # hours), not duration or price.  Both duration of the engagement and the price of the engagement are highly dependent how the engagement is staffed and the cost of each resource, and; therefore, highly dependent on your individual organization.Join tomorrow’s blog as the steps for developing an OUM Estimating Model are detailed.

Welcome to Part III of the Five Part Blog Series -- “Steps to Create an OUM Estimating Model”.  Today we will explore the different types of estimating models commonly used in the industry. Types of...

Estimating

Steps to Create an OUM Estimating Model - Part 2

Welcome to Part II of the Five Part Blog Series -- “Steps to Create an OUM Estimating Model”.  Creating an Estimate vs. Creating an Estimating ModelFirst, let’s establish the difference between an estimate and an estimating model.   A one-time estimate based on one’s unique experience is NOT an estimating model.  Rather, this is an experienced based estimate.    Often this “experienced based estimate” resembles a Work-breakdown Structure (WBS) with number of hours or days filled in based on one’s experience with each task.  Although this type of estimate is slightly better than arriving at a number solely based on the high level attributes of a similar project, an experienced-based estimate is highly dependent on the experience of the person or people completing the estimate.The goal of an estimating model is to create a repeatable model that will provide an estimate that yields the same result for the same scope of work regardless of who completes the estimate.  To accomplish this effectively, the experience of many must be incorporated into the model in such as way as that the internal thought process that one goes through to determine the effort for a particular task is decomposed into questions and answers that can be presented by the estimator model and consistent effort calculated based on the answers.    Sounds simple so far, right??  Before we discuss the steps on how to create an estimating model, join tomorrow’s blog as we distinguish between various types of estimating models commonly found.  

Welcome to Part II of the Five Part Blog Series -- “Steps to Create an OUM Estimating Model”.  Creating an Estimate vs. Creating an Estimating Model First, let’s establish the difference between an...

Navigating OUM

OUM’s Oracle Support Services Supplemental Guide – What’s in it for you?

As highlighted in this previous post, the Oracle® Unified Method (OUM) includes supplemental guides to provide product, technology, and business area specific guidance, which complement and expand on the general guidance found in OUM’s baseline method materials. There are a number of Supplemental Guides currently available in OUM covering a variety of areas from Commercial Off-the-Shelf (COTS) Application Implementations to WebCenter.  Because they provide targeted guidance, most supplemental guides are applicable only to projects that include the subject area being addressed in that guide.  However, there is one supplemental guide, which is applicable to virtually all projects – the Oracle Support Services Supplemental Guide. The Oracle Support Services Supplemental Guide provides OUM practitioners, and Oracle customers alike, with the guidance needed to effectively manage and support the lifecycle of Oracle environments during an implementation and after go-live. So, what’s in this guide for you?  Well, in a word, plenty.  Like all of OUM’s supplemental guides, the Oracle Support Services Supplemental Guide is comprised of several sections, including: Oracle Support Services Lifecycle Management Strategy Overview Oracle Support Services Lifecycle Management Methodology Mapping Supplemental Task Guidelines for Lifecycle Management of the My Oracle Support Services Portal, and Supplemental Task Guidelines for IT Change Management The Oracle Support Services Lifecycle Management Strategy Overview section describes the lifecycle management strategy along with an overview of the Information Technology Infrastructure Library (ITIL) Service Lifecycle upon which it is based.  The Oracle Support Services Lifecycle Management Methodology Mapping provides a mapping between the OUM and ITIL lifecycle management methodologies.  This mapping should be used to gain an understanding of the relationship between OUM and ITIL, as well as how to leverage the value of the ITIL best practices to achieve excellence in the lifecycle management of any Oracle investment. The Supplemental Task Guidelines for Lifecycle Management of the My Oracle Support Services Portal should be used in conjunction with the standard OUM task guidelines to supplement baseline guidance for affected tasks when planning and implementing the processes, policies and procedures used for lifecycle management of the My Oracle Support Services portal.  This section contains very helpful guidance regarding the recommended configuration of client environments, and establishment of best practices, to take full advantage of the My Oracle Support Services portal. The Supplemental Task Guidelines for IT Change Management likewise should be used in conjunction with the standard OUM task guidelines to supplement baseline guidance for affected tasks when planning and implementing the processes, policies and procedures used for implementing changes in Oracle environments. Accessing the Oracle Support Services Supplemental Guide is fast and easy.  A link to the guide can be found in the Key Components area of nearly all Implement Focus Area Views – look for it in the “Other Supplemental Guidance” section in the middle of the screen.  Alternatively, you can access it by selecting the “Supplemental Guidance” option in the Method Navigation drop down menu from any OUM page.  On the Supplemental Guidance page you’ll find it listed in the table of Supplemental Guides, which are listed in alphabetical order. Take the time to check it out and revisit with each new release, since new sections are being added over time.  I think you’ll find the information very helpful!

As highlighted in this previous post, the Oracle® Unified Method (OUM) includes supplemental guides to provide product, technology, and business area specific guidance, which complement and expand on...

Navigating OUM

A Method Store – Supplemental Guidance (Understanding the Structure of OUM)

My last blog in this series on understanding the structure of OUM discusses supplemental guidance.  This is the final section of the OUM Repository “store” that you need to consider.Going back to our grocery store comparison, the grocery store contains additional specialty items.  These items complement the groceries.  You don’t always need these items, but sometimes they come in handy.  These items might include sections for gourmet or hard to find groceries, a book section with cookbooks or a section with small kitchen appliances and utensils.  While you don’t need these items all the time, different items may be useful for different recipes or occasions.OUM has supplemental guidance that complements the base method materials.  This is additional supplemental inventory that might be useful for your project.  Just as you narrowed down the base method materials based on your type of project, you can also narrow down the supplemental guidance based on your type of project.If you have decided to use a particular view, applicable supplemental guidance can be found in the Key Components section at the top of the view.  The first column contains view-specific supplemental guidance.  For example, if your project is a Requirements-Driven Application Implementation, this view includes links to the Application Implementation Overview and Supplemental Guide.  Additional supplemental guidance is found in the second column of the Key Components.  This can be anything from additional supplemental guides, such as Oracle Support Services, to additional resource links.  The last link in this column is to the OUM Supplemental Guidance page that provides an Index to ALL supplemental guidance in OUMThe final column in the Key Components section of the view is to method resources.  This includes the OUM Project Workplan, Key Work Products and the OUM mappings.Review the resources found in the Key Components section of your selected view or go straight to the Supplemental Guidance page from the Method Navigation pull-down menu of any view in OUM and see what additional guidance is available in OUM and if it is useful for your current project.

My last blog in this series on understanding the structure of OUM discusses supplemental guidance.  This is the final section of the OUM Repository “store” that you need to consider.Going back to our...

Navigating OUM

A Method Store – Views (Understanding the Structure of OUM)

This is the fourth blog in a series of blogs on the structure of OUM.  In the previous blogs, I compared the OUM repository to a grocery store or a store with method materials with three main departments (focus areas); Manage, Envision and Implement and each of these having sections for phases, processes, activities and tasks.So now you have your project and you know you don’t need to use everything in OUM but with all this material, where do you start?Start with a view, or a pre-populated shopping list that provides access to the method materials (or inventory) for a particular type of project, for example, Application Implementation, Software Upgrade, etc.  The OUM views have been determined with the help of experienced subject matter experts (SMEs).Views can be selected from the OUM Home page using the Select a View pull-down menu.  Alternatively, you can use the Resources button on the Home page to go to the Resources page and from there open the View Catalog.  The View Catalog describes each of the views supported in the current release of OUM.Each view is organized similarly to the original focus area views.  If applicable, there will be Guidelines sections for each focus area that allow you to access the phases and processes.  At the bottom will be a filtered list of Tasks and Work Products.Start with the view that most closely matches your project and then tailor it for your project requirements.  You can even start with the OUM Implement Core Workflow and add additional method components based on your project requirements.My next and last blog in this series will discuss OUM Supplemental Guidance.

This is the fourth blog in a series of blogs on the structure of OUM.  In the previous blogs, I compared the OUM repository to a grocery store or a store with method materials with three...

Navigating OUM

A Method Store – Base Materials (Understanding the Structure of OUM)

Once again, building on my previous blogs where I compared the OUM repository to a grocery store or basically a store with method materials with three main sections (focus areas); Manage, Envision and Implement.Each focus area is organized similarly.  Within each focus area of the OUM repository, there are sections (or departments) for phases, processes, activities and tasks.Phase guidance is found in the Phase Overviews.  Phases are a chronological grouping of tasks.  In OUM, services are delivered by phase in order to reduce project risk.  Each phase allows a checkpoint against project goals, and measurement against quality criteria.  Phases are temporal groupings, that is, they are bound by time.  They cut vertically through project activities and provide natural points for establishing project milestones for progress checkpoints.Process guidance is found in the Process Overviews.  A process is a discipline or subproject that defines a set of tasks related by subject matter, required skills and common dependencies.  A process usually spans several phases.Activity guidance is found in the Activity Overviews.  An Activity is a set of tasks related either by topic, dependencies, data, common skills/roles, or work products. The tasks in an activity may come from different processes.  Activities in OUM begin and end in the same method phase.  Activities are spread within the project phases according to the time and ordering where they logically occur during the life of the project.Task guidance is found in the Task Overviews.  A task is a unit of work that is done as part of a project and results in a new or revised work product.  A task is the smallest traceable item on a project workplan, and forms the basis for a work breakdown structure.  A work product is simply the output of a task.  Many OUM tasks have work product templates.Once again go to the Select a View menu on the OUM Home page and select “Full Method and Focus Areas”.  From this page, choose the focus view.  Once in any of the focus area view pages, expand the Guidelines window or choose it from the Current Page Navigation menu.  From within this window, you can access the focus area phases and processes.  You can access the tasks and their associated work products by expanding the appropriate Tasks and Work Products sections at the bottom of each focus area view.Okay now that you know how the base method materials are organized in the OUM repository, my next blog will discuss the OUM views, or your pre-populated shopping lists.

Once again, building on my previous blogs where I compared the OUM repository to a grocery store or basically a store with method materials with three main sections (focus areas); Manage, Envision and...

Navigating OUM

A Method Store - Focus Areas (Understanding the Structure of OUM)

If you remember my previous blog entry, I compared the OUM repository to a grocery store, that is, a store with method materials.  Just as the grocery store is organized into sections or departments, the OUM repository is segmented into three main sections or focus areas; Manage, Envision and Implement.  Each of these focus areas has its own view.  From the OUM Home page, use the Select a View menu to go to the Full Method and Focus Areas page.  From there choose the focus area view.The focus areas provide the framework for all the other method materials. Specifically, the Manage focus area provides the framework for program and project management.  The Envision focus area provides the framework for enterprise-level planning and the Implement focus area provides the framework for project implementation.  In OUM, focus area guidance is found in the Focus Area Overviews.So, if you are making your shopping list for your project, ask yourself the following questions:Do I need project management for my project?  In most cases, you always need project management and therefore, should consider the Manage focus area. Is my project an enterprise-level planning project?  If so, consider the Envision focus area. Am I implementing a COTS product, or doing a BI/EPM, WebCenter or custom project?  If so, consider the Implement focus area. Once you know what focus area(s) you need, use the Select a View menu on the OUM Home page and select “Full Method and Focus Areas”.  From this page, choose the focus view.  Once in the view page, you can access the method materials available within each focus area, which is the topic for my next blog.

If you remember my previous blog entry, I compared the OUM repository to a grocery store, that is, a store with method materials.  Just as the grocery store is organized into sections or departments,...

Navigating OUM

A Method Store (Understanding the Structure of OUM) - Introduction

This blog entry is the first in a series of blog entries to assist you in understanding the structure of the Oracle Unified Method.The Oracle Unified Method (OUM) is a repository of information that can be used to support the entire enterprise IT lifecycle, including support for the successful implementation of every Oracle product.Think of OUM as a grocery store filled with inventory (method materials) that can be used to implement your project.  When you shop, you never select everything in the grocery store.  You pick and choose what inventory is appropriate based on your grocery needs.  The same is true for the OUM repository.  You pick and choose the method materials appropriate for your projectWhen you shop at the grocery store, you have some idea of the inventory and how it is organized.  Even if you have never been in a grocery store, you know that the inventory is organized by sections or departments, such as, a bakery, and departments for meat, produce, dairy, canned goods, etc.  The OUM repository or “store” contains a comprehensive set of method materials to support your projects.  These materials are organized as well.  The OUM inventory is organized by focus areas, phases, processes, activities, tasks, and work products.Last, when you shop at the grocery store, you usually have a shopping list of what you need.  This list is based on experience, habit and planning.  OUM has views, or pre-populated shopping lists that provide access to the method materials (or inventory) for particular types of projects, for example, Application Implementations, Software Upgrades, etc.Now that we have been briefly introduced to the OUM repository and what it contains, my next few blogs will discuss how the OUM repository or “store” is organized.

This blog entry is the first in a series of blog entries to assist you in understanding the structure of the Oracle Unified Method.The Oracle Unified Method (OUM) is a repository of information...

Planning and Managing

OUM Manage - The Key to Marital Bliss

During a recent blog on “Applying the Iterative and Incremental Principle”, a follower commented that the waterfall approach was responsible for the demise of his marriage.  He mused that his marriage may have had a chance if he had followed an iterative and incremental approach! Although this exchange was meant to be amusing, it prompted me to think about the similarity between a conventional marriage and the “marriage” that occurs when an OUM project is initiated.   Without getting into a political debate on the definition of marriage, for the purpose of this blog, let’s consider an OUM Implementation a type of marriage entered into by the Project Manager and the Project Sponsor for the term specified in the contract or Statement of Work (SOW).  What makes a one marriage successful while another fails?  If you ask five people this question, you would likely receive five different answers based on their unique experience, but I speculate the answers would fall into similar themes: Communication Trust Ability to manage expectations In OUM Manage, one of the first activities that occur during the Project Startup phase involves the Project Manager and the client (Project Sponsor) jointly creating the Project Management Framework.  This framework establishes the ground rules for the project and is the first step in communicating, establishing trust, and setting expectations. The key focus for the remainder of the Project Startup Phase is to evolve the Project Management Framework into a detailed Project Management Plan based on the agreed upon foundation.   In prior versions of OUM Manage, the equivalent work product was named the “Terms of Reference”.  Literally, this was the work product referenced to sort out problems when future misunderstandings occurred.    The PMP establishes, early on, what needs to be done, who should do it, and how it will get done.  Issues and problems are anticipated and resolution approaches are agreed to in advance.  Once the PMP details the who, what, and how, the plan is monitored and updated as the relationship matures and the parties have a better understanding of what works and does not work in their relationship.  Specifically, the PMP addresses Work Management, Financial Management, Communications Plan, Risk Management, Issue Management, Problem Management, Staff Management, Procurement Management, Infrastructure Management, Quality Management, Organizational Change Management Strategy and more!  I am not a marriage therapist, but I can clearly see the advantage to sitting down and agreeing to these areas early on, and of refining as the relationship grows.   Clearly, the Project Management Plan or PMP is a critical success factor for marital bliss!  If you think about the positive affect that creating a PMP equivalent would have on a conventional marriage, you should appreciate the value of creating a PMP for every project to increase its chance of success.  Think about the potential issues (risks) that can be mitigated by having a candid discussion on the approach to finances (need I say more?), work responsibilities (who cooks? Who cleans?), staffing (housekeeper or no housekeeper?), Risks (in-laws next door), and Organizational Change Management (kids!) and so on.  If these areas are not discussed until there is a conflict, without a clear approach to how to deal with the potential conflict, the likelihood that trust will erode and the relationship deteriorate increases. For anyone contemplating marriage – whether conventional or in the project sense, I strongly advice that you emulate OUM Manage and create an equivalent to the Project Management Framework when you are engaged, and that you detail this framework during your engagement -- prior to the nuptials!  If this is done, then you should have much more confidence in the success of the union!

During a recent blog on “Applying the Iterative and Incremental Principle”, a follower commented that the waterfall approach was responsible for the demise of his marriage.  He mused that his marriage...

Release 5.6

Oracle Unified Method (OUM) Release 5.6

ORACLE® UNIFIED METHOD RELEASE 5.6 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About 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. OUM replaces Legacy Methods, such as AIM Advantage, AIM for Business Flows, EMM Advantage, PeopleSoft's Compass, and Siebel's Results Roadmap. OUM provides an implementation approach that is rapid, broadly adaptive, and business-focused. OUM includes a comprehensive project and program management framework and materials to support Oracle's growing focus on enterprise-level IT strategy, architecture, and governance. Release OUM release 5.6 provides support for Application Implementation, Cloud Application Implementation, and Software Upgrade projects as well as the complete range of technology projects including Business Intelligence (BI) and Enterprise Performance Management (EPM), 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 are provided, including a supplemental guide related to Oracle Tutor and UPK. This release features: Business Process Management (BPM) Project Engineering Supplemental Guide Cloud Roadmap View and Supplemental Guide Enterprise Security View and Supplemental Guide Service-Oriented Architecture (SOA) Governance Implementation Supplemental Guide "Tailoring OUM for Your Project" White Paper OUM Microsoft Project Workplan Template and User's Guide Mappings: OUM to J.D. Edwards OneMethodology, OUM Roles to Task Techniques: Determining Number of Iterations, Managing an OUM Project using Scrum Templates: Scrum Workplan (WM.010), Siebel CRM Enhanced / Updated: Manage Focus Area reorganized by Activities for all Views Oracle Architecture Development Process (OADP) View updated for OADP v3.0 Oracle Support Services Supplemental Guide expanded to include guidance related to IT Change Management Oracle User Productivity Kit Professional (UPK Pro) and Tutor Supplemental Guide expanded guidance for UPK Pro Service-Oriented Architecture (SOA) Application Integration Architecture (AIA) Supplemental Guide updated for SOA Tactical Project Delivery View Service-Oriented Architecture (SOA) Tactical Project Delivery View expanded to include additional tasks Siebel CRM Supplemental Guide expanded task guidance and added select Siebel-specific OUM templates WebCenter View and Supplemental Guide updated for WebCenter Portal and Content Management For a comprehensive list of features and enhancements, refer to the "What's New" page of the Method Pack. Upcoming releases will provide expanded support for Oracle's Enterprise Application suites including product-suite specific materials and guidance for tailoring OUM to support various engagement types. Access Oracle Customers Oracle customers may obtain copies of the method for their internal use – including guidelines, templates, and tailored work breakdown structure – by contracting with Oracle for a consulting engagement of two weeks or longer and meeting some additional minimum criteria. Customers, who have a signed consulting contract with Oracle and meet the engagement qualification criteria, are permitted to download the current release of OUM for their perpetual use. They may also obtain subsequent releases published during a renewable, three-year access period. Training courses are also available to these customers. Contact your local Oracle Sales Representative about enrolling in the OUM Customer Program. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners OPN Diamond, Platinum, and Gold Partners are able to access the OUM method pack, training courses, and collateral from the OPN Portal at no additional cost: Go to the OPN Portal at partner.oracle.com. Select the "Partners (Login Required)" tab. Login. Select the "Engage with Oracle" tab. From the Engage with Oracle page, locate the "Applications" heading. From the Applications heading, locate and select the "Oracle Unified Method" link. From the Oracle Unified Method Knowledge Zone, select the "Implement" tab. From the Implement tab, select the "Tools and Resources" link. Locate and select the "Oracle Unified Method (OUM)" link. Previous Announcements Oracle Unified Method (OUM) Release 5.6 Oracle Unified Method (OUM) Release 5.5 Oracle Unified Method (OUM) Release 5.4 Oracle EMM Advantage Retired Retirement of Oracle EMM Advantage Planned for December 01, 2011

ORACLE® UNIFIED METHOD RELEASE 5.6 Oracle’s Full Lifecycle Method for Deploying Oracle-Based Business Solutions About Oracle is evolving the Oracle® Unified Method (OUM) to achieve the vision of...

Testing

Do You Know How OUM defines the four, basic types of business system testing performed on a project? Why not test your knowledge?

Testing is perhaps the most important process in the Oracle® Unified Method (OUM). That makes it all the more important for practitioners to have a common understanding of the various types of functional testing referenced in the method, and to use the proper terminology when communicating with each other about testing activities.OUM identifies four basic types of functional testing, which is sometimes referred to as business system testing.  The basic functional testing types referenced by OUM include:Unit TestingIntegration TestingSystem Testing, and Systems Integration TestingSee if you can match the following definitions with the appropriate type above?A.  This type of functional testing is focused on verifying that interfaces/integration between the system being implemented (i.e. System under Discussion (SuD)) and external systems functions as expected.B.     This type of functional testing is performed for custom software components only, is typically performed by the developer of the custom software, and is focused on verifying that the several custom components developed to satisfy a given requirement (e.g. screen, program, report, etc.) interact with one another as designed.C.  This type of functional testing is focused on verifying that the functionality within the system being implemented (i.e. System under Discussion (SuD)), functions as expected.  This includes out-of-the -box functionality delivered with Commercial Off-The-Shelf (COTS) applications, as well as, any custom components developed to address gaps in functionality. D.  This type of functional testing is performed for custom software components only, is typically performed by the developer of the custom software, and is focused on verifying that the individual custom components developed to satisfy a given requirement  (e.g. screen, program, report, etc.) functions as designed. Check your answers below:(D)(B)(C)(A)If you matched all of the functional testing types to their definitions correctly, then congratulations!  If not, you can find more information in the Testing Process Overview and Testing Task Overviews in the OUM Method Pack.

Testing is perhaps the most important process in the Oracle® Unified Method (OUM). That makes it all the more important for practitioners to have a common understanding of the various types of...

Navigating OUM

Finding "Stuff" In OUM

 One of the first questions people asked when they start using the Oracle Unified Method (OUM) is “how do I find X ?”Well of course no one is really looking for “X”!! but typically an OUM user might know the Task ID, or part of the Task Name, or maybe they just want to find out if there is any content within OUM that is related to a couple of keys words they have in their mind.Here are three quick tips I give people:1. Open up one of the OUM Views, then click “Expand All”, and then use your Browser’s search function to locate a key Word. For example, Google Chrome or Internet Explorer: <CTRL> F, then type in a key Word, i.e. ArchitectureThis is fast and easy option to use, but it only searches the current OUM page2. Use the PDF view of OUMOpen up one of the OUM Views, and then click the PDF View button located at the top of the View. Depending on your Browser’s settings, the PDF file will either open up in a new Window, or be saved to your local machine. In either case, once the PDF file is open, you can use the built in PDF search commands to search for key words across a large portion of the OUM Method Pack.This is great option for searching the entire Full Method View of OUM, including linked HTML pages, however the search will not included linked Documents, i.e. Word, Excel.3.  <!--[endif]-->Use your operating systems file index to search for key wordsThis is my favorite option, and one I use virtually every day. I happen to use Windows Search, but you could also use Google Desktop Search, of Finder on a MAC.All you need to do (on a Windows machine) is to make sure your local OUM folder structure is included in the Windows Index. Go to Control Panel, select Indexing Options, and ensure your OUM folder is included in the Index, i.e. C:/METHOD/OM40/OUM_5.6Once your OUM folders are indexed, just open up Windows Search (or Google Desktop Search) and type in your key worlds, i.e. Unit TestingThe reason I use this option the most is because the Search will take place across the entire content of the Indexed folders, included linked files.Happy searching!

  One of the first questions people asked when they start using the Oracle Unified Method (OUM) is “how do I find X ?” Well of course no one is really looking for “X”!! but typically an OUM user might...

Planning and Managing

The Workshop Technique Handbook

The #OUM method pack contains a plethora of information, but if you browse through the activities and tasks contained in OUM, you will see very few references to workshops.  Consequently, I am often asked whether OUM supports a workshop-type approach.  In general, OUM does not prescribe the manner in which tasks should be conducted, as many factors such as culture, availability of resources, potential travel cost of attendees, can influence whether a workshop is appropriate in a given situation.  Although workshops are not typically called out in OUM, OUM encourages the project manager to group the OUM tasks in a way that makes sense for the project. OUM considers a workshop to be a technique that can be applied to any OUM task or group of tasks.  If a workshop is conducted, it is important to identify the OUM tasks that are executed during the workshop.  For example, a “Requirements Gathering Workshop” is quite likely to Gathering Business Requirements, Gathering Solution Requirements and perhaps Specifying Key Structure Definitions. Not only is a workshop approach to conducting the OUM tasks perfectly acceptable, OUM provides in-depth guidance on how to maximize the value of your workshops.  I strongly encourage you to read the “Workshop Techniques Handbook” included in the OUM Manage Focus Area under Method Resources. The Workshop Techniques Handbook provides valuable information on a variety of workshop approaches and discusses the circumstances in which each type of workshop is most affective.  Furthermore, it provides detailed information on how to structure a workshops and tips on facilitating the workshop. You will find guidance on some popular workshop techniques such as brainstorming, setting objectives, prioritizing and other more specialized techniques such as Value Chain Analysis, SWOT analysis, the Delphi Technique and much more. Workshops can and should be applied to any type of OUM project, whether that project falls within the Envision, Manage or Implementation focus areas.  If you typically employ workshops to gather information, walk through a business process, develop a roadmap or validate your understanding with the client, by all means continue utilizing them to conduct the OUM tasks during your project, but first take the time to review the Workshop Techniques Handbook to refresh your knowledge and hone your skills. 

The #OUM method pack contains a plethora of information, but if you browse through the activities and tasks contained in OUM, you will see very few references to workshops.  Consequently, I am often...

Navigating OUM

Finding Tools Guidance in OUM

OUM is not tool – specific. However, it does include tool guidance.  Tool guidance in OUM includes: a mention of a tool that could be used to complete a specific task(s) templates created with a specific tool example work products in a specific tool links to tool resources Tool Supplemental Guides So how do you find all this helpful tool information? Start at the lowest level first – the Task Overview.  Even though the task overviews are written tool-agnostic, they sometimes mention suggestions, or examples of a tool that might be used to complete the task.  More specific tool information can be found in the Task Overview, Templates and Tools section.  In some cases, the tool used to create the template (for example, Microsoft Word, Powerpoint, Project and Visio) is useful. The Templates and Tools section also provides more specific tool guidance, such as links to: White Papers Viewlets Example Work Products Additional Resources Tool Supplemental Guides If you’re more interested in seeing what tools might be helpful in general for your project or to see if there is any tool guidance for a specific tool that your project is committed to using, go to the Supplemental Guidance page in OUM.  This page is available from the Method Navigation pull down located in the header of almost every OUM page. When you open the Supplemental Guidance page, the first thing you see is a table index of everything that is included on the page.  At the top of the right column are all the Tool Supplemental Guides available in OUM.  Use the index to navigate to any of the guides. Next in the right column is Discipline/Industry/View Resources and Samples.  Use the index to navigate to any of these topics and see what’s available and more specifically, if there is any tool guidance available.  For example, if you navigate to the Cloud Resources, you will find a link to the IT Strategies from Oracle page that provides information for Cloud Practitioner Guides, Cloud Reference Architectures and Cloud White Papers, including the Cloud Candidate Selection Tool and Cloud Computing Maturity Model. The section for Method Tool and Technique Cross References can take you to the Task to Tool Cross Reference.  This page provides a task listing with possible helpful tools and links to more information regarding the tools.  By no means is this tool guidance all inclusive.  You can use other tools not mentioned in OUM to complete an OUM task. The Method Tool and Technique Cross References can also take you to the various Technique pages (Index and Cross References).  While techniques are not necessarily “tools,” they can certainly provide valuable assistance in completing tasks. In the Other Resources section of the Supplemental Guidance page, you find links to the viewlets and white papers that are included within OUM.

OUM is not tool – specific. However, it does include tool guidance.  Tool guidance in OUM includes: a mention of a tool that could be used to complete a specific task(s) templates created with a...

Requirements, Analysis, and Design

When should I use a Process Model versus a Use Case?

This Blog entry is a follow on to https://blogs.oracle.com/oum/entry/oum_is_business_process_and and addresses a question I sometimes get asked…..i.e. “when I am gathering requirements on a Project, should I use a Process Modeling approach, or should I use a Use Case approach?”Not surprisingly, the short answer is “it depends”!Let’s take a scenario where you are working on a Sales Force Automation project. We’ll call the process that is being implemented “Lead-to-Order”.I would typically think of this type of project as being “Process Centric”. In other words, the focus will be on orchestrating a series of human and system related tasks that ultimately deliver value to the business in a cost effective way. Put in even simpler terms……implement an automated pre-sales system.For this type of (Process Centric) project, requirements would typically be gathered through a series of Workshops where the focal point will be on creating, or confirming, the Future-State (To-Be) business process. If pre-defined “best-practice” business process models exist, then of course they could and should be used during the Workshops, but even in their absence, the focus of the Workshops will be to define the optimum series of Tasks, their connections, sequence, and dependencies that will ultimately reflect a business process that meets the needs of the business.Now let’s take another scenario. Assume you are working on a Content Management project that involves automating the creation and management of content for User Manuals, Web Sites, Social Media publications etc. Would you call this type of project “Process Centric”?.......well you could, but it might also fall into the category of complex configuration, plus some custom extensions to a standard software application (COTS).For this type of project it would certainly be worth considering using a Use Case approach in order to 1) understand the requirements, and 2) to capture the functional requirements of the custom extensions.At this point you might be asking “why couldn't I use a Process Modeling approach for my Content Management project?” Well, of course you could, but you just need to think about which approach is the most effective. Start by analyzing the types of Tasks that will eventually be automated by the system, for example: Best Suited To?Task NameProcess ModelUse CaseNotesManage outbound callsÖ A series of linked human and system tasks for calling and following up with prospectsManage content revision ÖUpdating the content on a websiteUpdate User Preferences ÖUpdating a users display preferencesAssign LeadÖ Reviewing a lead, then assigning it to a sales personConvert Lead to QuoteÖ Updating the status of a lead, and then converting it to a sales order As you can see, it’s not an exact science, and either approach is viable for the Tasks listed above. However, where you have a series of interconnected Tasks or Activities, than when combined, deliver value to the business, then that would be a good indicator to lead with a Process Modeling approach. Another good indicator, is when the majority of the Tasks or Activities are available from within the standard COTS application.On the other hand, when the Tasks or Activities in question are more isolated, tend not to cross traditional departmental boundaries, or involve very complex configuration or custom development work, then a Use Case approach should be consideredNow let’s take one final scenario…..As you captured the To-Be Process flows for the Sales Force automation project, you discover a “Gap” in terms of what the client requires, and what the standard COTS application can provide. Let’s assume that the only way forward is to develop a Custom Extension. This would now be a perfect opportunity to document the functional requirements (behind the Gap) using a Use Case approach. After all, we will be developing some new software, and one of the most effective ways to begin the Software Development Lifecycle is to follow a Use Case approach.As always, your comments are most welcome.

This Blog entry is a follow on to https://blogs.oracle.com/oum/entry/oum_is_business_process_andand addresses a question I sometimes get asked…..i.e. “when I am gathering requirements on a Project,...

General

The Birth of a Method - Where did OUM come from?

It seemed fitting to start this blog entry with the OUM vision statement.The vision for the Oracle® Unified Method (OUM) is to support the entire Enterprise IT lifecycle, including support for the successful implementation of every Oracle product.  Well, it’s that time of year again; we just finished testing and packaging OUM 5.6.  It will be released for general availability to qualifying customers and partners this month.  Because of this, I’ve been reflecting back on how the birth of Oracle’s Unified method - OUM came about.As the Release Director of OUM, I’ve been honored to package every method release.  No, maybe you’d say it’s not so special.  Of course, anyone can use packaging software to create an .exe file.  But to me, it is pretty special, because so many people work together to make each release come about.  The rich content that results is what makes OUM’s history worth talking about.  To me, professionally speaking, working on OUM, well it’s been “a labor of love”.  My youngest child was just 8 years old when OUM was born, and she’s now in High School!  Watching her grow and change has been fascinating, if you ask her, she’s grown up hearing about OUM.  My son would often walk into my home office and ask “How is OUM today, Mom?”  I am one of many people that take care of OUM, and have watched the method “mature” over these last 6 years.  Maybe that makes me a "Method Mom" (someone in one of my classes last year actually said this outloud) but there are so many others who collaborate and care about OUM Development.I’ve thought about writing this blog entry for a long time just to reflect on how far the Method has come. Each release, as I prepare the OUM Contributors list, I see how many people’s experience and ideas it has taken to create this wealth of knowledge, process and task guidance as well as templates and examples.  If you’re wondering how many people, just go into OUM select the resources button on the top of most pages of the method, and on that resources page click the ABOUT link.So now back to my nostalgic moment as I finished release 5.6 packaging.  I reflected back, on all the things that happened that cause OUM to become not just a dream but to actually come to fruition.  Here are some key conditions that make it possible for each release of the method:A vision to have one method instead of many methods, thereby focusing on deeper, richer contentPeople within Oracle’s consulting Organization  willing to contribute to OUM providing Subject Matter Experts who are willing to write down and share what they know.Oracle’s continued acquisition of software companies, the need to assimilate high quality existing materials from these companiesThe need to bring together people from very different backgrounds and provide a common language to support Oracle Product implementations that often involve multiple product familiesWhat came first, and then what was the strategy?Initially OUM 4.0 was based on Oracle’s J2EE Custom Development Method (JCDM), it was a good “backbone”  (work breakdown structure) it was Unified Process based, and had good content around UML as well as custom software development.  But it needed to be extended in order to achieve the OUM Vision.What happened after that was to take in the “best of the best”, the legacy and acquired methods were scheduled for assimilation into OUM, one release after another.  We incrementally built OUM.  We didn’t want to lose any of the expertise that was reflected in AIM (Oracle’s legacy Application Implementation Method), Compass (People Soft’s Application implementation method) and so many more.When was OUM born? OUM 4.1 published April 30, 2006.  This release allowed Oracles Advanced Technology groups to begin the very first implementations of Fusion Middleware.  In the early days of the Method we would prepare several releases a year.  Our iterative release development cycle began and continues to be refined with each Method release.  Now we typically see one major release each year.The OUM release development cycle is not unlike many Oracle Implementation projects in that we need to gather requirements, prioritize, prepare the content, test package and then go production.  Typically we develop an OUM release MoSCoW (must have, should have, could have, and won’t have) right after the prior release goes out.   These are the high level requirements.  We break the timeframe into increments, frequent checkpoints that help us assess the content and progress is measured through frequent checkpoints.  We work as a team to prioritize what should be done in each increment. Yes, the team provides the estimates for what can be done within a particular increment.  We sometimes have Method Development workshops (physically or virtually) to accelerate content development on a particular subject area, that is where the best content results. As the written content nears the final stages, it goes through edit and evaluation through peer reviews, and then moves into the release staging environment.  Then content freeze and testing of the method pack take place.  This iterative cycle is run using the OUM artifacts that make sense “fit for purpose”, project plans, MoSCoW lists, Test plans are just a few of the OUM work products we use on a Method Release project.In 2007 OUM 4.3, 4.4 and 4.5 were published.  With the release of 4.5 our Custom BI Method (Data Warehouse Method FastTrack) was assimilated into OUM.  These early releases helped us align Oracle’s Unified method with other industry standardsThen in 2008 we made significant changes to the OUM “Backbone” to support Applications Implementation projects with that went to the OUM 5.0 release.  Now things started to get really interesting.  Next we had some major developments in the Envision focus area in the area of Enterprise Architecture.  We acquired some really great content from the former BEA, Liquid Enterprise Method (LEM) along with some SMEs who were willing to work at bringing this content into OUM.  The Service Oriented Architecture content in OUM is extensive and can help support the successful implementation of Fusion Middleware, as well as Fusion Applications. Of course we’ve developed a wealth of OUM training materials that work also helps to improve the method content.  It is one thing to write “how to”, and quite another to be able to teach people how to use the materials to improve the success of their projects.  I’ve learned so much by teaching people how to use OUM.What's next?So here toward the end of 2012, what’s in store in OUM 5.6, well, I’m sure you won’t be surprised the answer is Cloud Computing.   More details to come in the next couple of weeks!  The best part of being involved in the development of OUM is to see how many people have “adopted” OUM over these six years, Clients, Partners, and Oracle Consultants.  The content just gets better with each release.   I’d love to hear your comments on how OUM has evolved, and ideas for new content you’d like to see in the upcoming releases.

It seemed fitting to start this blog entry with the OUM vision statement. The vision for the Oracle® Unified Method (OUM) is to support the entire Enterprise IT lifecycle, including support for the...

Transitioning from AIM and AIM for Business Flows

Where's my MD.070?

In a previous Blog entry titled “Where’s My MD.050” I discussed how the OUM Analysis Specification is the “new-and-improved” version of the more traditional Functional Design Document (or MD.050 for Oracle AIM stalwarts). In a similar way, the OUM Design Specification is an evolution of what we used to call the Technical Design Document (or MD.070).Let’s dig a little deeper……In a traditional software development process, the “Design Task” would include all the time and resources required to design the software component(s), AND to create the final Technical Design Document.However, in OUM, we have created distinct Tasks for pure design work, along with an optional Task for pulling all of that work together into a Design Specification.Some of the Design Tasks shown above will result in their own Work Products (i.e. an Architecture Description), whilst other Tasks would act as “placeholders” for a specific work effort. In any event, the DS.140 Design Specification can include a combination of unique content, along with links to other Work Products, together which enable a complete technical description of the component, or solution, being designed.So next time someone asks “where’s my MD.070” the short answer would be to tell them to read the OUM Task description for DS.140 – Design Specification!

In a previous Blog entry titled “Where’s My MD.050” I discussed how the OUM Analysis Specification is the “new-and-improved” version of the more traditional Functional Design Document (or MD.050 for...

Planning and Managing

Iterative and Incremental Principle Series 5: Conclusion

Thank you for joining me in the final segment in the Iterative and Incremental series.  During yesterday’s segment, I discussed Iteration Planning, and specifically how I planned my daily exercise (iteration) each morning by assessing multiple factors, while following my overall Implementation plan. As I mentioned in yesterday’s blog, regardless of the type of exercise or how many increment sets I decide to complete each day, I apply the 6 minute interval sets and a timebox approach.  When the 6 minutes are up, I stop the interval, even if I have more to give, saving the extra energy to apply to my next interval set.   Timeboxes are used to manage iterations.  Once the pre-determined iteration duration is reached – whether it is 2 weeks or 6 weeks or somewhere in between-- the iteration is complete.  Iteration group items (requirements) not fully addressed, in relation to the iteration goal, are addressed in the next iteration.  This approach helps eliminate the “rolling deadline” and better allows the project manager to assess the project progress earlier and more frequently than in traditional approaches. Not only do smaller, more frequent milestones allow project managers to better assess potential schedule risks and slips, but process improvement is encouraged.  Even in my simple example, I learned, after a few interval sets, not to sprint uphill!  Now I plan my route more efficiently to ensure that I sprint on a level surface to reduce of the risk of not completing my increment.  Project managers have often told me that they used an iterative and incremental approach long before OUM.   An effective project manager naturally organizes project work consistent with this principle, but a key benefit of OUM is that it formalizes this approach so it happens by design rather than by chance.    I hope this series has encouraged you to think about additional ways you can incorporate the iterative and incremental principle into your daily and project life.  I further hope that you will share your thoughts and experiences with the rest of us.

Thank you for joining me in the final segment in the Iterative and Incremental series.  During yesterday’s segment, I discussed Iteration Planning, and specifically how I planned my daily exercise...

Planning and Managing

Iterative and Incremental Principle Series 4: Iteration Planning – (a.k.a What should I do today?)

Welcome back to the fourth of a five part series on applying the Iteration and Incremental principle.  During the last segment, we discussed how the Implementation Plan includes the number of the iterations for a project, but not the specifics about what will occur during each iteration.  Today, we will explore Iteration Planning and discuss how and when to plan your iterations. As mentioned yesterday, OUM prescribes initially planning your project approach at a high level by creating an Implementation Plan.  As the project moves through the lifecycle, the plan is progressively refined.  Specifically, the details of each iteration is planned prior to the iteration start. The Iteration Plan starts by identifying the iteration goal.  An example of an iteration goal during the OUM Elaboration Phase may be to complete the RD.140.2 Create Requirements Specification for a specific set of requirements.  Another project may determine that their iteration goal is to focus on a smaller set of requirements, but to complete both the RD.140.2 Create Requirements Specification and the AN.100.1 Prepare Analysis Specification.  In an OUM project, the Iteration Plan needs to identify both the iteration goal – how far along the implementation lifecycle you plan to be, and the scope of work for the iteration.  Since each iteration typically ranges from 2 weeks to 6 weeks, it is important to identify a scope of work that is achievable, yet challenging, given the iteration goal and timeframe.  OUM provides specific guidelines and techniques to help prioritize the scope of work based on criteria such as risk, complexity, customer priority and dependency.  In OUM, this prioritization helps focus early iterations on the high risk, architecturally significant items helping to mitigate overall project risk.  Central to the prioritization is the MoSCoW (Must Have, Should Have, Could Have, and Won’t Have) list.   The result of the MoSCoW prioritization is an Iteration Group.  This is a scope of work to be worked on as a group during one or more iterations.  As I mentioned during yesterday’s blog, it is pointless to plan my daily exercise in advance since several factors, including the weather, influence what exercise I perform each day.  Therefore, every morning I perform Iteration Planning.   My “Iteration Plan” includes the type of exercise for the day (run, bike, elliptical), whether I will exercise outside or at the gym, and how many interval sets I plan to complete.    I use several factors to prioritize the type of exercise that I perform each day.  Since running outside is my highest priority, I try to complete it early in the week to minimize the risk of not meeting my overall goal of doing it twice each week.  Regardless of the specific exercise I select, I follow the guidelines in my Implementation Plan by applying the 6-minute interval sets.  Just as in OUM, the iteration goal should be in context of the overall Implementation Plan, and the iteration goal should move the project closer to achieving the phase milestone goals. Having an Implementation Plan details the strategy of what I plan to do and keeps me on track, while the Iteration Plan affords me the flexibility to juggle what I do each day based on external influences thus maximizing my overall success. Tomorrow I’ll conclude the series on applying the Iterative and Incremental approach by discussing how to manage the iteration duration and highlighting some benefits of applying this principle.

Welcome back to the fourth of a five part series on applying the Iteration and Incremental principle.  During the last segment, we discussed how the Implementation Plan includes the number of the...

Planning and Managing

Iterative and Incremental Principle Series 3: The Implementation Plan (a.k.a The Fitness Plan)

Welcome back to the Iterative and Incremental Blog series.  Yesterday, I demonstrated how shorter interval sets allowed me to focus on my fitness goals and achieve success.  Likewise, in a project setting, shorter milestones allow the project team to maintain focus and experience a sense of accomplishment throughout the project lifecycle.  Today, I will discuss project planning and how to effectively plan your iterations. Admittedly, there is more to applying the iterative and incremental principle than breaking long durations into multiple, shorter ones.  In order to effectively apply the iterative and incremental approach, one should start by creating an implementation plan.   In a project setting, the Implementation Plan is a high level plan that focuses on milestones, objectives, and the number of iterations.  It is the plan that is typically developed at the start of an engagement identifying the project phases and milestones.  When the iterative and incremental principle is applied, the Implementation Plan also identified the number of iterations planned for each phase.  The implementation plan does not include the detailed plan for the iterations, as this detail is determined prior to each iteration start during Iteration Planning.  An individual iteration plan is created for each project iteration. For my fitness regime, I also created an “Implementation Plan” for my weekly exercise.   My high level plan included exercising 6 days a week, and since I cross train, trying not to repeat the same exercise two days in a row.  Because running on the hills outside is the most difficult and consequently, the most effective exercise, my implementation plan includes running outside at least 2 times a week.   Regardless of the exercise selected, I always apply a series of 6-minute interval sets.  I never plan what I will do each day in advance because there are too many changing factors that need to be considered before that level of detail is determined.  If my Implementation Plan included details on the exercise I was to perform each day of the week, it is quite certain that I would be unable to follow my plan to that level.  It is unrealistic to plan each day of the week without considering the unique circumstances at that time.  For example, what is the weather?  Are there are conflicting schedule commitments?  Are there injuries that need to be considered?  Likewise, in a project setting, it is best to plan for the iteration details prior to its start. Join me for tomorrow’s blog where I will discuss when and how to plan the details of your iterations.

Welcome back to the Iterative and Incremental Blog series.  Yesterday, I demonstrated how shorter interval sets allowed me to focus on my fitness goals and achieve success.  Likewise, in a project...

Requirements, Analysis, and Design

Iterative and Incremental Principle Series 2: Finding Focus

Welcome back to the second blog in a five part series where I recount my personal experience with applying the Iterative and Incremental principle to my daily life.  As you recall from part one of the series, a conversation with my son prompted me to think about practical applications of the Iterative and Incremental approach and I realized I had incorporated this principle in my exercise regime.    I have been a runner since college but about a year ago, I sustained an injury that prevented me from exercising.  When I was sufficiently healed, I decided to pick it up again.  Knowing it was unrealistic to pick up where I left off, I set a goal of running 3 miles or approximately for 30 minutes.    I was excited to get back into running and determined to meet my goal.  Unfortunately, after what felt like a lifetime, I looked at my watch and realized that I had 27 agonizing minutes to go!  My determination waned and my positive “I can do it” attitude was overridden by thoughts of “This is impossible”.   My initial focus and excitement was not sustained so I never met my goal.   Understanding that the 30 minute run was simply too much for me mentally, I changed my approach.   I decided to try interval training.  For each interval, I planned to walk for 3 minutes, then jog for 2 minutes, and finally sprint for 1 minute, and I planned to repeat this pattern 5 times.  I found that each interval set was challenging, yet achievable, leaving me excited and invigorated for my next interval.  I easily completed five intervals – or 30 minutes!!  My sense of accomplishment soared. What does this have to do with OUM?  Have you heard the saying -- “How do you eat an elephant?  One bite at a time!”?  This adage certainly applies in my example and in an OUM systems implementation.  It is easier to manage, track progress and maintain team focus for weeks at a time, rather than for months at a time.   With shorter milestones, the project team focuses on the iteration goal.  Once the iteration goal is met, a sense of accomplishment is experience and the team can be re-focused on a fresh, yet achievable new challenge.  Join me tomorrow as I expand the concept of Iterative and incremental by taking a step back to explore the recommended approach for planning your iterations.

Welcome back to the second blog in a five part series where I recount my personal experience with applying the Iterative and Incremental principle to my daily life.  As you recall from part one of the...

Planning and Managing

Iterative and Incremental Principle Series 1: The Dreaded Assignment

A few days ago, while making breakfast for my teenage son… he turned to me and happily exclaimed, “I really like how my high school Government class assigns our reading homework.  In middle school, we had to read a chapter each week.  Everyone dreaded it.  In high school, our teacher assigns us a section or two every day.  We still end up reading a chapter each week, but this way is so much easier and I’m actually remembered what I’ve read!” Wow!  Once I recovered from my initial shock that my high school son actually initiated conversation with me, it struck me that he was describing one of the five basic OUM principles -- Iterative and Incremental.   Not only did he describe how his teacher divided a week long assignment into daily increments, but he went on to communicate some of the major benefits of having shorter, more achievable milestones.  I started to think about other applications of the iterative and incremental approach and I realized that I had incorporated this approach when I recently rededicated myself to physical fitness.  Join me over the next four days as I present an Iterative and Incremental blog series where I relate my personal experience incorporating the iterative and incremental approach and the benefits that I achieved.

A few days ago, while making breakfast for my teenage son… he turned to me and happily exclaimed, “I really like how my high school Government class assigns our reading homework.  In middle school, we...

Planning and Managing

Reflections on the Agile2012 Conference

Last week, I had the great fortune to attend the Agile2012 conference at the lovely Gaylord Texan Hotel in Grapevine, TX, just a short drive (at least by Texas standards) from where I live.  Overall, the conference was a great experience and I am very glad to have had the opportunity to participate.   I picked up a number of ideas for tools and techniques that will most likely find their way into OUM at some point.   It was encouraging to hear real-world agile success stories described at a number of the sessions and to see the passion and energy from the conference attendees.  Discussions with fellow agile practitioners were extremely valuable, as is usually the case at such conferences.  I plan to include some of these topics in future blogs. I found that many of the ideas we promote in OUM about balancing agility and discipline are now becoming increasingly in vogue within the agile community.  Teams are finding it valuable to produce plans and documentation at the appropriate level depending on the particular project situation.   Keeping an eye on enterprise architecture and establishing a solid technical architecture was a common theme in several of the sessions I attended.  Whether people use the term iteration or sprint, there was a true appreciation of how the agile approach to managing projects drives out risks and identifies possible errors early on in the project.  To sum it up, I got the impression from the conference that there is a growing recognition of the benefits of flexible and scalable methods like OUM. I heard several people mention that the Wild West days of agile are coming to an end.  It is my theory that the wider approval of agile techniques, coupled with the growing practice among agile teams to apply a certain amount of discipline, is probably leading to the Wild West impression fading away into the sunset.  In any case, I thought the phrase was rather appropriate given the venue. What do you think?  Are the Wild West days of agile coming to an end?  Are those days a perception, reality or both?

Last week, I had the great fortune to attend the Agile2012 conference at the lovely Gaylord Texan Hotel in Grapevine, TX, just a short drive (at least by Texas standards) from where I live.  Overall,...

Requirements, Analysis, and Design

A Use Case for the Olympic 100m Final

 Unless you have been hiding away on a desert island, you would probably have seen Usain Bolt win the 100m Gold Medal at the London 2012 Olympics!It would clearly be “absurd” to write a Use Case for such an event, but nevertheless, it serves as a good memory jogger for the various components of a Use Case.Let’s set the scene by having a quick recap, along with a very brief (summarized) description of the major components of a fully dressed1 Use Case:Use Case Name: 4 words or less, and conveys the goal of the Primary ActorPrimary Actor: The actor who has the primary reason for interacting with the business/systemSecondary Actor(s): actors who support the completion of the Use CaseAssumptions: what do we believe to be true, but may later prove to be untruePre-Conditions: that which must be true before the use case can startTrigger: event(s) that initiate/start the Use CaseMain Success Scenario: the ‘Happy Path’ to achieve the goal of the Primary ActorAlternate Scenario: alternate paths that still achieve the goal of the Primary ActorException Scenario: exception paths where the goal of the Primary Actor is not metLet’s now overlay those terms onto our 100m Olympic RaceUse Case ComponentContentCommentsUse Case Name:Run 100m Race4 words or less!Primary Actor:Athlete Secondary Actor(s): Starting Official Assumptions: The Primary Actor has no injuries We can’t be 100% sure of this, and we certainly cannot test for it with absolute accuracy, therefore we make it an assumption Pre-Conditions: Primary Actor has passed the doping test, and has a valid qualifying timeWe can verify these conditions before the Use Case starts, and in fact, we would not want the Use Case to start if any of these conditions could not be verified Trigger: Starting Official fires the starting pistolThis is somewhat controversial in the sense that one could argue that the trigger could be the Athlete ‘hearing’ the starting gun, or even the Athlete taking the first step out of the blocks. However for the purpose of this ‘memory jogger’ let’s just go with the fact that the Use Case cannot start until the starting pistol is fired!Main Success Scenario:  <!--[if !supportLists]-->· <!--[endif]-->The Use Case begins when the Primary Actors launches out of the blocks<!--[if !supportLists]-->· <!--[endif]--> The ‘System’ responds by………… <!--[if !supportLists]-->· <!--[endif]-->The Use Case ends when the Primary Actor crosses the finish line Alternate ScenarioA false start occurs, resulting in a restartThe Athlete will still cross the finish line, therefore the ‘goal’ of the Use Case is still achievedException Scenario: The Primary Actor tears a muscle during the race and is not able to cross the finish lineOne of our assumptions proves to be incorrect, and therefore the Use Case ‘goal’ cannot be met We could extend this analogue even further by thinking of Post Conditions for each of the scenarios, but hopefully you get the idea!Cleary this is a very basic example, and we don’t even touch upon timing devices, photo finish etc. This is just a ‘Memory Jogger’ so don’t worry about whether this is a Business Use Case, or a System Use Case. We’ll leave that topic for another Blog entry! 1 Cockburn, A, 2000, Writing Effective Use Case, Addison-Wesley Professional; Edition 1

  Unless you have been hiding away on a desert island, you would probably have seen Usain Bolt win the 100m Gold Medal at the London 2012 Olympics! It would clearly be “absurd” to write a Use Case for...

Transitioning from AIM and AIM for Business Flows

Where’s my MD.050?

A question that I’m sometimes asked is “where’s my MD.050 in OUM?” For those not familiar with an MD.050, it serves the purpose of being a Functional Design Document (FDD) in one of Oracle’s legacy Methods. Functional Design Documents have existed for many years with their primary purpose being to describe the functional aspects of one or more components of an IT system, typically, a Custom Extension of some sort.So why don’t we have a direct replacement for the MD.050/FDD in OUM? In simple terms, the disadvantage of the MD.050/FDD approach is that it tends to lead practitioners into “Design mode” too early in the process. Whereas OUM encourages more emphasis on gathering, and describing the functional requirements of a system ahead of the formal Analysis and Design process.So that just means more work up front for the Business Analyst or Functional Consultants right?Well no…..the design of a solution, particularly when it involves a complex custom extension, does not necessarily take longer just because you put more thought into the functional requirements. In fact, one could argue the complete opposite, in that by putting more emphasis on clearly understanding the nuances of functionality requirements early in the process, then the overall time and cost incurred during the Analysis to Design process should be less.In short, as your understanding of requirements matures over time, it is far easier (and more cost effective) to update a document or a diagram, than to change lines of code.So how does that translate into Tasks and Work Products in OUM?Let us assume you have reached a point on a project where a Custom Extension is needed. One of the first things you should consider doing is creating a Use Case, and remember, a Use Case could be as simple as a few lines of text reflecting a “User Story”, or it could be what Cockburn1 describes as a “fully dressed Use Case”. It is worth mentioned at this point the highly scalable nature of OUM in the sense that “documents” should not be produced just because that is the way we have always done things. Some projects may well be predicated upon a base of electronic documents, whilst other projects may take a much more Agile approach to describing functional requirements; through “User Stories” perhaps.In any event, it is quite common for a Custom Extension to involve the creation of several “components”, i.e. some new screens, an interface, a report etc. Therefore several Use Cases might be required, which in turn can then be assembled into a Use Case Package.Once you have the Use Cases attributed to an appropriate (fit-for-purpose) level of detail, and assembled into a Package, you can now create an Analysis Model for the Package. An Analysis Model is conceptual in nature, and depending on the solution being developing, would involve the creation of one or more diagrams (i.e. Sequence Diagrams, Collaboration Diagrams etc.) which collectively describe the Data, Behavior and Use Interface requirements of the solution. If required, the various elements of the Analysis Model may be indexed via an Analysis Specification. For Custom Extension projects that follow a pure Object Orientated approach, then the Analysis Model will naturally support the development of the Design Model without any further artifacts. However, for projects that are transitioning to this approach, then the various elements of the Analysis Model may be represented within the Analysis Specification.If we now return to the original question of “Where’s my MD.050”. The full answer would be:Capture the functional requirements within a Use Case Group related Use Cases into a Package Create an Analysis Model for each Package Consider creating an Analysis Specification (AN.100) as a index to each Analysis Model artifact An alternative answer for a relatively simple Custom Extension would be:Capture the functional requirements within a Use Case Optionally, group related Use Cases into a Package Create an Analysis Specification (AN.100) for each package 1 Cockburn, A, 2000, Writing Effective Use Case, Addison-Wesley Professional; Edition 1

A question that I’m sometimes asked is “where’s my MD.050 in OUM?” For those not familiar with an MD.050, it serves the purpose of being a Functional Design Document (FDD) in one of Oracle’s legacy...

Requirements, Analysis, and Design

The Use-Case Driven Approach to Change Management

In the third entry of the series on OUM and PMI’s Pulse of the Profession, we took a look at the continued importance of change management and risk management. The topic of scope change management and OUM’s use-case driven approach has come up in few recent conversations. So I thought I would jot down a few thoughts on how the use-case driven approach aids a project team in managing the project’s scope. Use-case models are one of several tools in OUM used to establish and manage the project's scope.  Because use-cases can be understood by both business and IT project team members, they can serve as a bridge for ongoing collaboration as well as a visual diagram that encapsulates all agreed-upon functionality. This makes them a vital artifact in identifying changes to the project’s scope. Here are some of the primary benefits of using the use-case driven approach as part of the effort for establishing and managing project scope:Use-cases quickly communicates scope in a straightforward manner. All project stakeholders can have a common foundation for the decisions regarding architecture and design and how they relate to the project's objectives. Once agreed upon, a use-case can be put under change control and any updates to the model can then be quickly identified as potentially affecting the project’s scope.  Changes requested or discovered later in the project can be analyzed objectively for their impact on project's budget, resources and schedule. A modular foundation for the design of the software solution can be established in Elaboration.  This permits work to be divided up effectively and executed in so that the most important and riskiest use-cases can be tackled early in the project. Use-cases help the team make informed decisions about implementation priorities, which allows effective allocation of limited project resources.  This is very helpful in not only managing scope, but in doing iterative and incremental planning which relies heavily on the ability to identify project priorities. Bottom line is that use-cases give the project team solid understanding of scope early in the project.  Combine this understanding with effective project management and communication and you have an effective tool for reducing the risk of overruns in budget and/or time due to out of control scope changes.Now that you’ve had a chance to read these thoughts on the use-case driven approach and project scope, please let me know your feedback based on your experience.

In the third entry of the series on OUM and PMI’s Pulse of the Profession, we took a look at the continued importance of change management and risk management. The topic of scope change management and...

Planning and Managing

OUM and PMI's Pulse of the Profession: The Fifth In a Series

Welcome to the fifth (and final) blog entry of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #4: Organizations will renew their focus on talent development as they look to grow and gain competitive advantage in new markets.  That entry highlighted how the OUM Training Program prepares project team members in various roles to be effective on an OUM project.In this blog entry we will look at PMI’s Key Finding #5: Despite tight economic conditions, organizations have been and will continue to increase their focus on benefits realization success metrics.  PMI’s research shows project/program managers must maintain a focus on the strategic objectives of the project.  Anyone who has been on a project knows it is not easy to keep the big picture in mind when we are caught up in our day-to-day tasks.  So in this blog entry we will take a look at some of the key elements in OUM that help keep projects aligned with the organization’s strategic goals.Whenever we talk strategy in OUM we turn our attention to the Envision Focus Area.  The development and maintenance of enterprise level IT strategy, architecture, and governance done in Envision helps to ensure IT delivery is in alignment with the organization’s strategy.  Ideally, every enterprise should be executing the processes in Envision or similar processes.  I am going to get on my soapbox at this point and say, because the processes in Envision provide the glue between the business and IT strategies, true benefits realization will be very difficult (or nearly impossible)to achieve without an Envision or similar engagement.  We discussed in the first blog entry of this series how Envision helps ensure projects will align with an organization’s objectives by providing the processes to support effective portfolio management.   We know that organizations who focus only at the project level will wind up with a collection of stovepipe projects that have limited ability to address the organization’s strategic needs or provide return on investment.  We also know that project teams starting out without an enterprise IT strategy and architecture, or the appropriate IT governance in place will often find it necessary to gather enough information to establish the project’s objectives, scope, and estimates for the solution.  This can cause significant project delays and possibly lead to costly re-work.  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, project teams should be aware of the Envision Touch Points found in the OUM Method Overview page.  These touch points are potential prerequisites from Envision work products to Implement tasks.  As we know, an Envision engagement does not always precede an Implement engagement and, therefore, these touch points are not always available to the project as artifacts.  The project team must then determine the degree to which the Envision tasks should be executed to generate the necessary information to proceed.The project manager should also look to the Envision artifacts when establishing the project structure to make sure the project is set up to achieve the expected benefits of the project.  During the Project Start Up phase of the OUM Manage Focus Area, resources are allocated to achieve specific objectives, satisfy needs, and set expectations through a planned and organized approach.   The project manager should start with the enterprise IT strategy and governance when formulating this approach, and then document the approach as part of the Project Management Framework (the precursor to the Project Management Plan). As you can tell, I am a big fan of Envision.  I put a great deal of value in this focus area of OUM because I have seen so many projects that benefited by having a view of the big picture.  But, if you disagree with my assessment of how important enterprise-level work is to benefits realization, please let me know in the comments section.  For some really good advice on the role of an Oracle Enterprise Architect and how they can benefit a project, check out a blog entry written by my colleague called “When to Call an Oracle Enterprise Architect”.This wraps up the series on PMI’s 2012 Pulse of the Profession.  I hope you enjoyed reading these entries as much as I did writing them.  It’s been a great opportunity to demonstrate how OUM is in-tune with leading industry trends.  The series has generated quite a bit of inspiration for future blog entries. So please keep watching this blog, as well as our LinkedIn Group and Twitter for OUM information, tips, and techniques.  If you have a suggestion for a future blog entry or have a question, you can reach us at ominfo_us@oracle.com.

Welcome to the fifth (and final) blog entry of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #4: Organizations will renew their focus on talent...

Planning and Managing

OUM and PMI's Pulse of the Profession: The Fourth In a Series

Welcome to the fourth blog entry of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #3: As organizations continue to strive for agility, change management and project risk management will become even more important.   That entry discussed how change management and risk management s are documented in the OUM Manage Focus Area, as well as woven into the fabric of the Envision and Implement Focus Areas.In this blog entry we will look at PMI’s Key Finding #4: Organizations will renew their focus on talent development as they look to grow and gain competitive advantage in new markets.  This finding shows a continued awareness that as we look at improving the project management maturity and capabilities of an organization, we must take a three pronged approach of people, processes, and tools.  We know that even with the best tools in place to support our projects, it is still just as important to have proven processes, and a well-trained and informed project team.  Previous blog entries focused on how OUM supports organizational development by providing processes and tools in the form of content, guidance, templates, and samples.  Since we are focusing on the people part of the equation in the form of talent development, I thought this would be a good opportunity to talk about the OUM Training Program.OUM Training ProgramThe OUM Training Program helps to ensure that individuals in various roles have the level of delivery knowledge required for them to competently perform their job.  The OUM training program takes an incremental approach in which the courses are arranged in a series of levels.  This approach allows students to build on their knowledge of OUM in manageable increments by progressing from the foundation level courses to those that cover more in-depth material.  You are probably not surprised that we take an iterative and incremental approach to OUM training!Where to Find OUM TrainingEach level of OUM training is available as a self-service, self-paced training course online, except for the Level 3 course which is delivered in the classroom for a fee.  The OUM training can be accessed as follows:Oracle OPN Partners at the level of Diamond, Platinum or Gold can access the online training through the secure OUM Training Page on Oracle University.Oracle Customers enrolled in the OUM Customer Program may obtain access to the OUM online training by sending an email to oum-training_us@oracle.com.Oracle Employees can find the links to the training through the Global Methods internal MyOracle site on the ‘Training’ tab.Partners and Customers are able to take the Level 3 – Gathering Requirements with OUM course from our partner DevelopMentor.  DevelopMentor has broad training experience and extensive knowledge of the Unified Process, use case practices, and agile development techniques.  For more information and class schedule, please visit their website.OUM SpecializationWe recently launched an OUM Specialization through the Oracle Partner Network.  The OUM Specialization recognizes partner organizations that have proven their extensive understanding of OUM.  Partners who are interested in finding out more about the OUM Specialization can go to the OUM Knowledge Zone on the Oracle Partner Network and click on the ‘Specialize’ tab.If you have not had an opportunity to take the OUM training, I encourage you to take a look at the various courses and begin your learning with the Level 1 – Overview and Awareness course.  If you have any questions about the OUM Training Program, feel free to email us at oum-training_us@oracle.com.Stay tuned for the next entry in the series which will address Key Finding #5: Despite tight economic conditions, organizations have been and will continue to increase their focus on benefits realization success metrics.

Welcome to the fourth blog entry of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #3: As organizations continue to strive for agility, change management...

Planning and Managing

OUM and PMI's Pulse of the Profession: The Third in a Series

Welcome to the third blog entry of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #2: The desire for organizational agility will also lead to increased use of iterative and/or incremental project management methods such as agile and extreme.   That entry discussed how agile methodologies, such as OUM, help to enable agility because they are designed to significantly reduce project risk and deliver value much earlier in the lifecycle than traditional waterfall methodologies.In this blog entry we will jump into a look at PMI’s Key Finding #3:  As organizations continue to strive for agility, change management and project risk management will become even more important.  It is apparent from the survey results that even with a move to more agile approaches, project management fundamentals are still important in managing a project to a successful conclusion.   In OUM, both change management and risk management are specifically addressed from the perspective of the project manager’s role in the Manage Focus Area.  Since change management and risk management are vital to the success of a project, the concepts are also intertwined into many of the principles and guidance in the in the Implement and Envision Focus Areas.First up is a look at change management, which is a key aspect of agile methodologies like OUM, because such methodologies recognize the reality that requirements will evolve throughout the life cycle of a software project.  This does not mean the project should succumb to project killers like scope creep or gold plating.  It does mean that the necessary change management controls need to be in place that so we can be proactive in identifying potential changes, analyzing the impact of the change , and determining the appropriate trade-offs and alternatives.  In OUM, the change management controls and procedures are established in Project Start Up (the first phase of the Manage Focus Area) as part of the [SM] Scope Management process.  This means the scope change management procedures for the project are established early in the project lifecycle.  These procedures then serve as the basis for responding to possible scope changes throughout the life of the project.The heart of OUM, as with any agile method, is the iterative and incremental approach.  The iterative and incremental approach helps to allow scope changes to be proactively managed because it breaks the development cycle into shorter durations and allows for more frequent customer feedback.  Potential changes are identified early on in the development cycle, when there is still time and budget to make corrections.  When potential changes are identified, the project manager and team can be proactive in following the scope change management procedures established in Project Start Up to evaluate and deal with the scope change.Risk management is also inherent in the iterative and incremental approach.  We talk about OUM being risk-focused because a key goal of each iteration is to identify 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.Risk management in OUM can start at the enterprise level in the [ER] Envision Roadmap process in Envision.  This process contains the ER.120 – Identify and Mitigate Future State Risks task in which possible technology and business risks related to the future state are identified. This may be a list of identified architectural improvement options or a list of candidate projects identified to realize the future state.  Also as part of this task, a recommendation for each risk is developed which provides for 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.  Risk management for a given project starts during Project Start Up in the [RKM] Risk Management process.  In the beginning of the project, 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.  The list of risks developed during the Envision Roadmap can serve as a starting point for identifying the risks specific to the project.During the project lifecycle, OUM recommends first starting to work on the most complex requirements or use cases, or those use cases that are the least well defined, or by creating prototypes to find out if specific technical solutions are feasible.  As the project progresses, each iteration should be planned and executed to reduce and/or eliminate specific project risks.  In this manner, the project’s overall risk will be systematically drawn down to zero by the end of the project.There have been numerous studies and stories in the recent press that show that a lack of change management and/or risk management is a major factor in project failure.  Therefore, both change management and risk management guidance is documented in the Manage Focus Area, as well as being woven into the fabric of the Envision and Implement Focus Areas.   Also, the OUM Level 3 Gathering Requirements course contains in-depth coverage of scope definition and risk management from an OUM perspective.Stay tuned for the next entry in the series which will address Key Finding #4: Organizations will renew their focus on talent development as they look to grow and gain competitive advantage in new markets.    In the meantime, you may want to look at the Project Management in OUM and Tips for Project Managers documents, which contain practical tips and advice on using OUM from experienced project managers.  Both of these documents are found in the References section of the Manage Focus Area. 

Welcome to the third blog entry of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #2: The desire for organizational agility will also lead to increased...

Planning and Managing

OUM and PMI's Pulse of the Profession: Second in a Series

Welcome to the second of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #1: Tight economic conditions will continue to force the issue of strong project portfolio management.   We saw how project portfolio management is supported in OUM by the Envision and Manage Focus Areas.   In this blog entry we will take a look at PMI’s Key Finding #2: The desire for organizational agility will also lead to increased use of iterative and/or incremental project management methods such as agile and extreme.  The first thing we need to do is define “organizational agility”.  If you do a search on the term, you come up with a wide variety of definitions which essentially boil down to this: the ability an organization to recognize changes (whether they be threats or opportunities), and respond to these changes in a timely, cost-effective, and appropriate manner.  Notice there are two parts to the definition:  part one is the ability to recognize the need for change; the other part is being effective in the response to the change.If an organization as a whole is striving to be agile, it makes sense that their IT organization must also be agile. In many cases the IT organization not only supports the overall organization’s agility, but drives it by introducing enabling tools and technologies.  On the other hand, IT can also inhibit an organization’s ability to be agile by being late to deliver IT solutions, slow to react to change, and/or not being in tune with the business’s changing requirements.Agile methods, like OUM, help to enable IT and organizational agility because they are designed to significantly reduce project risk, and deliver value much earlier in the lifecycle than traditional waterfall methods.  The time it takes to get working software into users hands can be accelerated by releasing important features first, and pushing off the lower priority items to later releases.  This in turn, provides a rapid improvement of an organization’s capabilities and/or competitive position.  Agile methodologies also encourage regular involvement by business stakeholders, which helps ensure the IT solutions match the organization’s objectives.As PMI indicates in Key Finding #2, iterative and incremental development is at the heart of any agile methodology.  OUM recognizes the advantages of an iterative and incremental approach to development and deployment of information systems.  Any of the tasks within OUM may be iterated. Tasks may be iterated to increase quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand the work products on the basis of user feedback.In addition to having an agile iterative and incremental development approach, OUM also:Is flexible and scalable – OUM is designed to support a broad range of project types. As such, it must be flexible and scalable. The appropriate point of balance for a given project will vary based on a number of project risk and scale factors. The method has been developed with the intent that the approach for a given project be “built up” from a core set of activities to implement an appropriate level of discipline, rather than tailored down.Allows for frequent customer interaction and feedback – OUM encourages regular sessions with stakeholders to review and confirm priorities, and ensure the project continues to meet the overall objectives.  Through several prototyping and testing tasks, business stakeholders are given the opportunity to review the development work completed to that point, and provide feedback in time to catch missed requirements and/or possible errors. Employs a layered planning approach – OUM recognizes that plans need to be scalable for different project sizes and complexity, and contain the right level of detail for the current planning horizon.  The layered approach to planning an OUM project allows project teams to take an agile approach to their immediate project tasks, while keeping a focus on the major milestones, controls, and objectives of the project.  Encourages the use of an empowered team – OUM encourages cross-functional and technical team training and knowledge sharing.  In addition, the use of OUM’s common language and visual models (use cases and business process models) throughout the project helps ensure the development team and other project stakeholders are on the same page, which promotes team communication and collaborative decision making.Integrates testing throughout the development lifecycle – Testing in OUM starts early in the project, and developed components are integrated and tested as an integrated set as soon as possible. This allows for early discovery of errors that eventually reduces the risk of project delays that often are caused by heightened error detection at the end of the project.Promotes an architecture-centric approach –  People will sometimes question whether spending time and energy on architecture is compatible with an agile approach.  The answer is that a robust architecture is crucial to the project’s success since it is the blueprint upon which requirements are transformed into a working system.   Poor architecture decisions can result in software that is not stable, is unable to support business requirements, could require substantial re-work, may not accommodate future development, or could even prevent the application from working properly in a production environment.  Nothing about poor architecture sounds too agile, does it?I could go on for a while about OUM’s agile underpinnings; the bottom line is that OUM supports all kinds of projects – from the very lean and adaptable, to those that require more rigor and discipline.  If you want to find out more about how OUM can be applied in an agile manner, check out the Scrum guidance which includes the “Managing an OUM Project Using Scrum” whitepaper, User Story Task and Template, Product Backlog and Sprint Backlog Templates, and Scrum to OUM Mapping.  For information on OUM’s layered approach to project planning, the “Planning a Project Using OUM” whitepaper contains guidance on OUM’s layered approach to project planning.  The OUM Read Me First is a valuable reference if you want to become familiar with the method’s philosophy, key concepts, and principles.  Finally, if you have not already done so I recommend reading an excellent blog entry written by my colleague called Build Up or Tailor Down.Stay tuned for the next blog entry in the series when we will explore PMI’s Key Finding #3:  As organizations continue to strive for agility, change management and project risk management will become even more important.

Welcome to the second of the series on PMI’s 2012 Pulse of the Profession .  The previous blog entry focused on Key Finding #1: Tight economic conditions will continue to force the issue of strong project...

Planning and Managing

OUM and PMI's 2012 Pulse of the Profession: The First in a Series

Taken your pulse lately?  Recently, PMI released their 2012 Pulse of the Profession which contains five key findings based on the results of their global survey:Tight economic conditions will continue to force the issue of strong project portfolio management. The desire for organizational agility will also lead to increased use of iterative and/or incremental project management methods such as agile and extreme. As organizations continue to strive for agility, change management and project risk management will become even more important. Organizations will renew their focus on talent development as they look to grow and gain competitive advantage in new markets. Despite tight economic conditions, organizations have been and will continue to increase their focus on benefits realization success metrics. Since of PMI’s 2012 key findings are highly relevant to the ever expanding Oracle ecosystem, I thought it would be beneficial to put together a series of blog entries to discuss each of PMI’s key finding in the context of OUM.  Through the entries, I hope you find some useful tips and techniques you can apply to your projects right away.Let’s jump into Key Finding #1:  Tight economic conditions will continue to force the issue of strong project portfolio management, which is defined by Wikipedia as “methods for analyzing and collectively managing a group of current or proposed projects based on numerous key characteristics.”  We all know there has never been a time when organizations intentionally threw money away on frivolous projects.  During times of constrained and uncertain economic conditions, it is even more critical to make sure money is allocated to projects and programs which will provide the most business value and highest return on investment.  When guidance is needed for project identification and prioritization, we look to where projects are born in OUM:  The Envision Focus Area. The Envision Focus Area comprises the areas OUM that deal with development and maintenance of enterprise level IT strategy, architecture, and governance.  Every project that affects an organization’s IT landscape should have its origins here.   Envision also assists in the transition from enterprise-level planning and strategy activities to the identification and initiation of specific projects further supported by the Manage and Implement focus areas. I think the Envision Focus Area is one of the areas that make OUM unique in that it addresses the business at the enterprise level, rather than just at the tactical project level.  You can read more about the Envision Focus Area and its touch points to the Implement and Manage Focus Areas in the OUM Overview section, as well as by reading the detailed content in the Envision view itself.   This brings us to the Manage Focus Area, which is the standard framework and reference guide that provides a consistent and repeatable approach for managing Oracle-related information technology projects.  The Manage Focus Area includes guidance for managing both projects and programs.  While there is no substitute for good project management skills, Manage is essentially a tool that can be used to facilitate and support the program or project management process.  For more details about Manage and its relationship to Envision and Implement, check out the OUM Overview section and the in-depth guidance found in the Manage view.Stay tuned for the next blog entry in the series which will focus on PMI’s Key Finding #2: The desire for organizational agility will also lead to increased use of iterative and/or incremental project management methods such as agile and extreme.  In the meantime, please provide your feedback on your experience with the Envision and Manage Focus Areas.

Taken your pulse lately?  Recently, PMI released their 2012 Pulse of the Profession which contains five key findings based on the results of their global survey: Tight economic conditions will continue...

Requirements, Analysis, and Design

Use Case Actors - Primary versus Secondary

The Unified Modeling Language (UML1) defines an Actor (from UseCases) as:An actor specifies a role played by a user or any other system that interacts with the subject.In Alistair Cockburn’s book “Writing Effective Use Cases” (2) Actors are further defined as follows:Primary Actor: The primary actor of a use case is the stakeholder that calls on the system to deliver one of its services. It has a goal with respect to the system – one that can be satisfied by its operation. The primary actor is often, but not always, the actor who triggers the use case.Supporting Actors: A supporting actor in a use case in an external actor that provides a service to the system under design. It might be a high-speed printer, a web service, or humans that have to do some research and get back to us.In a 2006 article (3) Cockburn refined the definitions slightly to read:Primary Actors: The Actor(s) using the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal of the primary actor.Secondary Actors: Actors that the system needs assistance from to achieve the primary actor’s goal.Finally, the Oracle Unified Method (OUM) concurs with the UML definition of Actors, along with Cockburn’s refinement, but OUM also includes the following:Secondary actors may or may not have goals that they expect to be satisfied by the use case, the primary actor always has a goal, and the use case exists to satisfy the primary actor.Now that we are on the same “page”, let’s consider two examples:A bank loan officer wants to review a loan application from a customer, and part of the process involves a real-time credit rating check. Use Case Name: Review Loan Application Primary Actor: Loan Officer Secondary Actors: Credit Rating System A Human Resources manager wants to change the job code of an employee, and as part of the process, automatically notify several other departments within the company of the change. Use Case Name: Maintain Job Code Primary Actor: Human Resources Manager Secondary Actors: None The first example is quite straight forward; we need to define the Secondary Actor because without the “Credit Rating System” we cannot successfully complete the Use Case. In other words, the goal of the Primary Actor is to successfully complete the Loan Application, but they need the explicit “help” of the Secondary Actor (Credit Rating System) to achieve this goal.The second example is where people sometimes get confused. Within OUM we would not include the “other departments” as Secondary Actors and therefore not include them on the Use Case diagram for the following reasons: The other departments are not required for the successful completion of the Use Case We are not expecting any response from the other departments (at least within the bounds of the Use Case under discussion) Having said that, within the detail of the Use Case Specification Main Success Scenario, we would include something like:“The system sends a notification to the related department heads (ref. Business Rule BR101)”Now let’s consider one final example. A Procurement Manager wants to place a “bid” for some goods using an On-Line Trading Community (B2B version of eBay)Use Case Name: Create Bid Primary Actor: Procurement Manager Secondary Actors: On-Line Trading Community You might wonder why the Trading Community is listed as a Secondary Actor, i.e. if all we are going to do is place a bid for a specific quantity of goods at a given price and send that off to the Trading Community, then why would the Trading Community need to “assist” in that Use Case?Well, once again, it comes back to the “User Experience” and how we want to optimize that when we think about our Use Case, and ultimately, when the developer comes to assembling some code.In this final example, the Procurement Manager cannot successfully complete the “Create Bid” Use Case until they receive an affirmative confirmation back from the Trading Community that the Bid has been accepted. Therefore, the Trading Community must become a Secondary Actor and be referenced both on the Use Case diagram and Use Case Specification.Any astute readers who are wondering about the “single sitting” rule will have to wait for a follow-up Blog entry to find out how that consideration can be factored in!!! Happy Use Case writing!(1) OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.4.1(2) Cockburn, A, 2000, Writing Effective Use Case, Addison-Wesley Professional; Edition 1 (3) Cockburn, A, 2006 “Use Case fundamentals” viewed 20th March 2012, http://alistair.cockburn.us/Use+case+fundamentals

The Unified Modeling Language (UML1) defines an Actor (from UseCases) as: An actor specifies a role played by a user or any other system that interacts with the subject. In Alistair Cockburn’s book...

Planning and Managing

Developing an Implementation Plan with Iterations by Russ Pitts

Developing an Implementation Plan with Iterations by Russ Pitts Ok, so you have come to grips with understanding that applying the iterative concept, as defined by OUM is simply breaking up the project effort you have estimated for each phase into one or more six week calendar duration blocks of work.Idea being the business user(s) or key recipient(s) of work product(s) being developed never go longer than six weeks without having some sort of review or prototyping of the work results for an iteration…”think-a-little”, “do-a-little”, and “show-a-little” in a six week or less timeframe…ideally the business user(s) or key recipients(s) are involved throughout.You also understand the OUM concept that you only plan for that which you have knowledge of. The concept further defined, a project plan initially is developed at a high-level, and becomes more detailed as project knowledge grows. Agreeing to this concept means you also have to admit to the fallacy that one can plan with precision beyond six weeks into a project…Anything beyond six weeks is a best guess in most cases when dealing with software implementation projects.Project planning, as defined by OUM begins with the Implementation Plan view, which is a very high-level perspective of the effort estimated for each of the five OUM phases, as well as the number of iterations within each phase.You might wonder how can you predict the number of iterations for each phase at this early point in the project. Remember project planning is not an exact science, and initially is high-level and abstract in nature, and then becomes more detailed and precise as the project proceeds.So where do you start in defining iterations for each phase for a project?The following are three easy steps to initially define the number of iterations for each phase:Step 1 => Start with identifying the known factors……Prior to starting a project you should know: <!--[if !supportLists]-->· <!--[endif]-->The agreed upon time-period for an iteration (e.g 6 weeks, or 4 weeks, or…) within a phase (recommend keeping iteration time-period consistent within a phase, if not for the entire project)<!--[if !supportLists]-->· <!--[endif]-->The number of resources available for the project<!--[if !supportLists]-->· <!--[endif]-->The number of total number of man-day (effort) you have estimated for each of the five OUM phases of the project<!--[if !supportLists]-->· <!--[endif]-->The number of work days for a weekStep 2 => Calculate the man-days of effort required for an iteration within a phase…Lets assume for the sake of this example there are 10 project resources, and you have estimated 2,536 man-days of work effort which will need to occur for the elaboration phase of the project. Let’s also assume a week for this project is defined as 5 business days, and that each iteration in the elaboration phase will last a calendar duration of 6 weeks. A simple calculation is performed to calculate the daily burn rate for a single iteration, which produces a result of…((Number of resources * days per week) * duration of iteration) = Number of days required per iteration((10 resources * 5 days/week) * 6 weeks) = 300 man days of effort required per iterationStep 3 => Calculate the number of iterations that can occur within a phaseNext calculate the number of iterations that can occur for the amount of man-days of effort estimated for the phase being considered…(number of man-days of effort estimated / number of man-days required per iteration) = # of iterations for phase(2,536 man-days of estimated effort for phase / 300 man days of effort required per iteration) = 8.45 iterations, which should be rounded to a whole number such as 9 iterations**Note - It is important to note this is an approximate calculation, not an exact science. This particular example is a simple one, which assumes all resources are utilized throughout the phase, including tech resources, etc. (rounding down or up to a whole number based on project factor considerations). It is also best in many cases to round up to higher number, as this provides some calendar scheduling contingency.

Developing an Implementation Plan with Iterations by Russ Pitts  Ok, so you have come to grips with understanding that applying the iterative concept, as defined by OUM is simply breaking up the...

Requirements, Analysis, and Design

Use Case Assumptions versus Pre-Conditions

Within the Oracle Unified Method (OUM) we define the following in relation to Use Cases: Assumptions: Facts we assume to be true, but may later prove to be untrue Pre-Conditions: That which must be true before the Use Case can start Seems pretty clear at this point! But in practice, when would it be appropriate to use an Assumption versus a Pre-Condition within a Use Case?Let’s look at a hypothetical Use Case which represents the creation of an On-Line Sales Order (Internet shopping). For the sake of this example, we will name the Use Case – Create On-Line Sales OrderIf a Business Analyst were writing such a Use Case, one question that might come up is…..”How should we deal with the possibility of the Credit Card Payment Gateway being unavailable during the on-line order creation process?”One option would be to use a Use Case “Pre-Condition”. In other words, we will not let the Use Case “start” unless the Payment Gateway is actually available. This would force the software developer into creating some logic that checks the Payment Gateway Status prior to the user beginning the shopping process, and if the Gateway was “down” then the user would not be allowed to even begin the shopping process, i.e. a Pre-Condition allows us to define “what must be true before the Use Case can begin”.Nothing wrong with that option you might think?Well……another option would be to use a Use Case “Assumption”. In other words, we will assume that the Credit Card Payment Gateway is available, and allow the Use Case to “start” without actually verifying its availability. The implication for this, in terms of software development, is that the developer will not check the Payment Gateway status when the user begins the “shopping” process, and if at the point of checkout, the Gateway is in fact “down”, then we would describe how that should be handled through a Use Case Exception Scenario.At this point we really need to step back from the semantics of the Use Case framework and think about how the business would prefer to handle this process, and specifically, what sort of user experience do they ideally want to provide to their on-line shoppers?If you were the on-line shopper, you would be pretty un-happy if you had just spent 30 minutes choosing a range of items, including size/color/style, only to find that you could not checkout due to a problem with the Payment Gateway. You might not want to come back and shop there again!So…..Pre-Condition sounds like the best option for this scenario?Perhaps not……Let’s put the shopper experience at the forefront of our approach. If we apply this type of thinking, then another option would be to allow the customer to go through the product selection process, and at the point of selecting the checkout option, we would only then check the status of the Payment Gateway. If it was “up” then the customer would checkout as normal. It the Payment Gateway was not available, an option would be provided for the customer to either abort the checkout, or save their items in the shopping cart, and the business would notify them as soon as the Payment Gateway was available.This latter option has many advantages, particularly in the area of analytics in terms of quantifying the number of customers who were not able to checkout due to a Payment Gateway issue, and the value of any lost business for those customer who do not return, even if they had previously saved items in their shopping cart.Let’s now return to our Use Case. If we assume the business decides to take the latter option, should we use a Pre-Condition or an Assumption? The preferred option would be as follows:Make the availability of the Payment Gateway a Use Case Assumption Create an independent (<<include>>) Use Case called “Verify Payment Gateway Status” and reference this in the main success scenario of the “Create On-Line Sales Order” Use Case at the point the user selects the Checkout option. If the Payment Gateway is available, then Use Case continues through the checkout process If the Payment Gateway is unavailable, then the User is presented with an option to either: “abort shopping” whereby an Exception Scenario would describe the subsequent steps “save items, pay later” whereby an Alternate Scenario would describe the subsequent steps before returning to the main success scenario In summary, on the face of things the difference between a Use Case Assumption and a Pre-Condition seems a little arbitrary. However these, along with other elements of a Use Case approach encourages an essential level of dialog between the Analyst and the Business; and it is this level of analytical rigor which makes a Use Case approach such a powerful approach to understanding complex requirements, and/or describing functional requirements prior to a potentially costly software development cycle.In short.....time invested in the structured analysis of requirements, is more efficient that leaving the Software Developer to "fill in the blanks".

Within the Oracle Unified Method (OUM) we define the following in relation to Use Cases:   Assumptions: Facts we assume to be true, but may later prove to be untrue Pre-Conditions: That which must be...

Planning and Managing

When to call an Oracle Enterprise Architect in on your project

When you aren’t sure about your physical health, what do you do?  Well, you may call in a doctor, maybe even a “specialist”.As a Project Manager, and a PMP, I understand the need to “protect the project”.  Risks should be mitigated early on so that they don’t become issues.  So “When do I call in an Oracle Enterprise Architect (OEA) on my project?”  What signs should I look for to indicate that an OEA is needed?Recently, I’ve had the opportunity to work with Oracle Consulting PM’s, Customers and Partners who saw the value of having an Oracle Enterprise Architect as a “trusted advisor” to the Project or Program Manager.   But some Project Managers may not be aware of what an OEA does, or when it is advisable to call an OEA in on a project.The Oracle Unified Method (OUM) includes an Oracle Enterprise Architecture Development Process (OADP) View.  This view includes only tasks from the OUM Envision focus area. However, many of these tasks are “touch points” or prerequisites to tasks in the Implement focus area.  The expertise of an OEA is important on a Software Implementation project.Did you know that the OADP View in OUM Envision was authored by a global group of Oracle Enterprise Architects (OEA)?  These subject matter experts were some of the earliest contributors to OUM and they continue to refine the guidance that OUM provides for Enterprise Architecture.What is the role of an Oracle Enterprise ArchitectAn OEA does five specific things – that are unique to the OEA role:Thinks in time (Current State / Future State / and more importantly – Intermediary or Transitional State)Examines “Multidimensional Processing” (People, Process, Strategy and Technology)Brings together Multi-pillar Architectures (Apps, Tech,  Hardware and Software)Performs “Environmental Contextualization” – The fit of the System Under Discussion (SuD) into overall ecosystem – not just designing the architecture in and of itselfProvides Trade-off Analysis for Best-fit architecture (Architecture alternatives: balance Business, Organizational, Financial and Technical factors) An OEA participates in specialized training that examines the current state architecture, discovers the Business Objectives and Strategy of the Enterprise and then develops future state architectures and practical roadmaps, that could be used to achieve those business objectives.When to call an Enterprise ArchitectSo, under what conditions, does an Oracle Software implementation project or program benefit from the role of an Oracle Enterprise Architect (OEA)? What are some of the characteristics of projects in the Enterprise IT Portfolio that would gain value and produce quantifiable return on investment, thereby truly benefitting from an OEA as a trusted advisor?In general, a project that has a high level of complexity could benefit from an OEA.  This complexity could be technical, architectural or business, or some combination these.Here is a list of some common project scenarios that provide increased benefit to the business by utilizing the skills of an Oracle Enterprise Architect as an implementation project trusted advisor:Project includes multiple Oracle products - from different product familiesLarge scale combined application and technology projectsProject duration is more than 1 year Project budget is in excess of $1MProject includes integration with more than ten legacy systemsComposite Applications includes several of those WebCenter Portals, Service Oriented Architecture, BPM Processes, Enterprise Security and Enterprise Applications such as CRM, Financials or HR. Of course many software implementation scenarios could benefit from an OAE as a trusted advisor.  The above list includes just a few of the project scenarios that really should consider including an OEA.Value of Enterprise Architecture and an OEA to the projectHaving a framework (such as Oracle's OEAF) and a well defined process for Enterprise Architecture development (OADP) is of critical importance. Together they help produce artifacts (work products) that ultimately align technology goals and initiatives to business strategy.An OEA participates in specialized training that examines the current state architecture, discovers the Business Objectives and Strategy of the Enterprise and then develops future state architectures and practical roadmaps, that could be used to achieve those business objectives.Enterprise architecture is the alignment of IT and IT assets to support business strategy. By achieving the business strategy of the enterprise, we have increased the business value of the enterprise.  In order to really identify the true value of enterprise architecture we need to understand how we measure business value and develop a portfolio of implementation projects that help us reach achievable and measurable goals.The OEA contributes to the success of a defined business strategy.  They help Software implementation project teams execute on a roadmap.  Each of these projects is part of a portfolio of implementation projects that combine to realize the defined future state architecture.  During the execution of the roadmap, they help to deliver the IT initiatives that provide measurable returns to the business.The OEA acts as an advisor to the Project or Program Manager.  They keep the various functional partitions in alignment with the technical partitions, thereby assuring the OUM Principle of remaining “Architecture Centric”.As the OEA examines the individual organizational units within the enterprise they can identify how the unit has performed by quantitatively measuring achievable goals as defined by the business for each unit. True business value may seem to be subjectively measured.  However, looking at the requirements of the System under Discussion (SuD) and determining the impact to the business with measurable goals, is more quantifiable.As a project manager, I can examine the project profile and determine if it meets the characteristics outlined above, if it does… Well, who am I going to call?  I will call an Oracle Enterprise Architect (OEA).What are your thoughts on this topic?For more information about Oracle Enterprise Architecture Services, look on http://www.oracle.com/us/products/consulting/enterprise-architecture-services/index.html Many thanks to Ajay Ailawadhi and Paul Silverstein - Oracle Consulting Advanced Technology Services, ESG organization for contributing to this blog entry.

When you aren’t sure about your physical health, what do you do?  Well, you may call in a doctor, maybe even a “specialist”.As a Project Manager, and a PMP, I understand the need to “protect the...

Requirements, Analysis, and Design

What comes first…Gap Analysis or Use Case development?

What comes first…Gap Analysis or Use Case development?It’s a good question and one we often get asked, but like most things in an imperfect World, the answer is “it depends!”If we look at the OUM Method Pack and examine the dependencies for the Gap Analysis Tasks, then we see that one of the key pre-requisites are Use Case Specifications.So that means we have to write a Use Case before doing any Gap Analysis…..right?.....well, it depends!!!Consider the following two examples:Let’s say you are implementing one of Oracle’s COTS applications, for example, eBS, Fusion or PeopleSoft etc. We might begin by capturing functional requirements by iteratively developing a Future Process Model. During that process you discover that the client has some requirements that cannot be met using the standard features of the application. If those requirements are reasonably well understood, then you would most likely drop into the OUM Gap Analysis “Process”. If the result of that process is a decision to go down a custom development path in order to close the “Gap” then one or more Use Cases could be created in order to fully describe the functional solution to the Gap.Now consider this scenario. Your client is designing a solution that includes Single Sign-On, Business Intelligence and some components of Content Management. In this type of environment, it’s especially important to ask ourselves “what is the best way to capture functional requirements?” Why you may ask?............well, for projects that are process centric (e.g. Order-to-Cash, Procure-to-Pay) one would tend to favor the development of a Future Process model in order to define functional requirements. However, for projects that are not centered around traditional business processes, then we might want to consider leading with a Use Case approach in order to capture the client’s functional requirements.In this second example, we probably won’t discover any Gaps until we go through the first iteration of Use Case development. But if we do uncover any Gaps, then our Use Cases will be an ideal direct input into the Gap Analysis process. So what comes first Gap Analysis or Use Case Development?…..well just like the Chicken-and-Egg story, it all depends!!

What comes first…Gap Analysis or Use Case development? It’s a good question and one we often get asked, but like most things in an imperfect World, the answer is “it depends!” If we look at the OUM...

Planning and Managing

The Project Management Plan (PMP) in OUM - Creation and Evolution

According to the Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition, the Project Management Plan is defined as a formal, approved document that defines how the project is executed, monitored and controlled.  In OUM, the Project Management Plan (better known as the PMP) defines the overall project management strategies and approaches applied to the project.  Since the PMP is considered to be the most important artifact created by the project manager, it is important to understand how the PMP is created and evolved in OUM.CreationThe creation of the PMP is started with the Project Management Framework in the task BT.070 – Create Project Management Framework, which is part of the OUM Manage Focus Area’s Project Startup Phase.  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.  Evolution and RefinementAfter 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 OUM 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 static document, but is evolved to become the project management artifact that details the tools and approach for each of the 13 OUM Manage processes.Need More Info?For more information on how the PMP evolves from the Project Management Framework, check out the BT.070 Task - Create Project Management Framework in OUM 5.5.

According to the Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition, the Project Management Plan is defined as a formal, approved document that defines how the project...

Training

Do you have OUM work product “samples” to share?

Often I am asked for examples of Oracle Unified Method (OUM) work products.  These requests come from many interested parties; clients, partners and Oracle consultants.  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. OUM refers to real-world project artifacts (work products and deliverables) --- “samples”.  For some tasks OUM provides “examples” these are somewhat helpful in understanding how to use an OUM work product template.  “Examples” are usually based on the “Ski Now” case study used in OUM training materials. But real-world sample artifacts are like “gold” to people who are using OUM for the first time.Of course, we all know sharing of actual project samples happens, especially within partner, client, and Oracle internal organizations.  But people are often hesitant to put forth a project artifact as a “leading practice” outside of their organization and often even exclude anyone outside of the immediate project from seeing how they used OUM to create a work product or deliverable.Early on in OUM history, people used this unwillingness to “share” samples as a form of resistance to change.  This was a true lesson in organizational change management resistance techniques for me, professionally speaking.  They would say, “Well you don’t have any project samples that must mean no one is using it”!  But, I had seen the samples!  I just didn’t have the authorization to share them, sometimes even within Oracle because of contractual agreements.In other cases, I’d review samples and think (to myself)… maybe better training up front would have avoided the mixed-results of the project team.  These aren’t leading practices; they are at best, people struggling because no one committed the time to train the project team.  The interesting thing is that samples exist, but they are “Top Secret”!  When, the simple act of sharing would benefit everyone!  It also helps OUM improve when we can see how people have tailored or combined the work products in their samples.  On some projects makes sense to combine several templates into one sample.No one seems to want to “share” samples across organizations.  How can it be that everyone wants to see them, but no one wants to share their project artifacts?  Often people are intimidated about putting their work out for review, because they expect to have to defend their choices. Sometimes, it is due to the fact that the System Under discussion (SuD) is highly proprietary in nature.  Most often, I think it is just a matter of having enough time, because we are all busy, working hard to get the work done, and sharing is a “nice to have”.  Those are my top three “assumptions” about why people aren’t motivated to share.  What do you think?OK, I am one of those people who expect that people want to do the “right thing”.   As professionals, we care about the work we do, and we want to be the best that we can be.  I’d really like to be able to say “Yes, here is a sample from a real project that implemented these Oracle products”OUM adoption is going very well, globally.  I am so impressed by the intern instructors and students, when I have an opportunity to teach OUM.  This is the time in OUM adoption where the walls need to be a bit more transparent.  What if, as a community of IT professionals, we could do as they do for the walls in a Japanese tea house and make the walls transparent, while also protecting privacy and any proprietary information?  Interesting thought, because as we are able to work together, everyone can benefit.  No, I’m not suggesting that we share trade secrets, especially in the case of competitors or top secret information, but I am suggesting that we can work together to make the overall results of IT projects more successful.One could argue that the “names could be changed to protect the innocent” in these samples, however, with enough scrubbing the samples often don’t make sense because the context of the implementation project is lost.  Some care needs to be given to the continuity of the sample library.  What type of project was it?  Which Oracle Commercial off-the-shelf software (COTS) was involved; eBusiness Suite, JD Edwards, PeopleSoft, with Fusion Middleware? You see what I mean, it’s really about knowledge management, but most organizations don’t have enough people to keep all this information/material organized, cleansed and vetted as a true “leading practice”.  Sharing of samples makes “process improvement” possible.  If we can see how someone used a template in a real world project, we can improve the templates.OUM templates are very good, method users, we also need to have samples that apply to certain project “conditions”.  This keeps it “real” for the person using OUM to conduct the day to day work of an IT project.  Because OUM is a Unified Process based method, it is meant to be Agile in nature.  It is highly scalable to many different types of projects.  This means that no one type of project would use every OUM work product, and no project would use every section in an individual OUM work product template. If a section in a work product doesn’t apply to your project simply eliminate it.   As we have referred to in past blog entries, OUM is highly scalable, so our samples will reflect this.  So don’t be afraid to share, if you get feedback, it will only serve to further educate and refine the process, and provide deeper, richer OUM content.There is no “perfect OUM project artifact”.   There are no “OUM police” to come and say “no, you didn’t do that properly”.   We all know that doing too much and using too much "ceremony” is just as bad as not using any method at all.  These real world samples are as different as snowflakes; each depends on the “current conditions” and the nature of the project.What are your thoughts on this topic?  Are you willing to share your samples?  Are you willing to share your examples (created from your samples with proprietary information removed)?  Yes, this is one of my Christmas wishes.... Happy Holidays!

Often I am asked for examples of Oracle Unified Method (OUM) work products.  These requests come from many interested parties; clients, partners and Oracle consultants.  In OUM, the output of a task or...

Planning and Managing

Build Up Or Tailor Down?

OUM is intended to be highly scalable. In our industry today we hear lots of buzzwords around Agile or Agility. We see many methods in today’s marketplace that have adopted an agile approach to software development. The Global Methods team is in strong agreement with the tenets put forth in the “Manifesto for Agile Software Development.” We also see a debate in our industry about agility versus discipline which has been well framed in the book “Balancing Agility and Discipline: A Guide for the Perplexed” by Barry Boehm and Richard Turner.To help OUM’s users determine just how much of OUM they should employ on a given project, we have adopted many of the philosophies and conclusions put forth in the book. It has helped to guide us in developing OUM and also in developing the guidance related to using OUM. By Boehm and Turner’s definition, at its highest level, OUM is a plan-driven method, which could be tailored down by an expert, to fit a particular situation. However, as the book points out, non experts tend to play it safe under these circumstances, and often tend to use to much or all of a method “at considerable unnecessary expense.”Therefore, we’ve taken the advice of Boehm and Turner and adopted the philosophy of “Build it Up – Don’t Tailor it Down.” OUM’s Implement Core Workflow, along with OUM’s diverse set of views, are intended to support this philosophy.In addition to the workflow and views, we advise you to follow 4 steps when considering the tasks to include in your OUM based workplan.The first step is to start from a core set of tasks. We recommend that you consider using the OUM Implement Core Workflow for this purpose along with an OUM view that best matches the needs of your project. Remember, though, that the views tend to be a superset of tasks related to a particular solution, discipline, or technology. Therefore, the core workflow and views should be used together to achieve the right balance for your project.Further information on tailoring OUM can be found in this White Paper: http://my.oracle.com/content/native/cnt723708An external version of this White Paper will be published early in 2012 along with recorded training for Oracle Consulting, along with our Partner and Customer community. 

OUM is intended to be highly scalable. In our industry today we hear lots of buzzwords around Agile or Agility. We see many methods in today’s marketplace that have adopted an agile approach to...

Requirements, Analysis, and Design

Everything is URGENT – a look at Use Case prioritisation.

Everything is urgent. How many times have you heard that? The business needs this functionality to launch a new product, we have to have that piece of functionality to comply with new legislation, our current software licence is expiring. There are a myriad of factors influencing priority how do you deal with them in a way that recognises and mitigates for risk. Yes, risk. How often have you been tempted to put off dealing with difficult or risky functionality? How often has your decision to take the low hanging fruit turned sour? In OUM we have an approach to prioritisation that is comprehensive and realistic, in other words fit for purpose. Before you start the list of Use Cases should be reviewed and approved by the key stakeholders to ensure expectations are managed. When that is done we can start evaluating use cases based on four perspectives. Customer priority - Importance of the use case to the business, and the urgency to have its functionality. Risk- you need to recognize risk early.  This needs to managed closely. Complexity – a measure of difficulty (requirements and development).  This also needs to managed closely. Dependencies – you need to know the connections.  Now let us drill down a little on each one. Customer Priority Identify whether functionality is highest priority and is the focus of the system, or borders on being out-of-scope with a real potential to be postponed. When it’s a challenge to get your customer to commit to prioritizing Use Cases, a 2 x 2 Urgency/Importance Matrix can be helpful. This gives you a way of seeing what the Importance of the use case to the business, and the urgency to have the functionality available .Used in combination they help to determine priority. The premise is that Importance is a measure of value to the business and Urgency is a measure of how quickly they need this functionality, so these can be used to differentiate priority. Risk Risk is a measure of uncertainty and for each Use Case you should identify the things that could occur and the impact to the project if it did A Risk Portfolio Chart can be used to plot each Use Case profile based on its probability of occurrence and the degree of impact if the risk(s) occurs. There are generally four categories of Risk. These four (4) categories should be used as a checklist by you to ensure all risks are identified. Each risk that is forgotten or mismanaged may cause schedule slips, implementation problems, or worse. It is important that people understand what gets elevated to management vs. what can be handled at project level - e.g., management risks often cannot be handled at the project level. Technological risks are the risk that project result will not comply with performance, functional, inter-operability, or quality requirements Project management risks are risks to cost or schedule.  What is the risk that the project cost will exceed the budget or schedule Organizational risks  are attributed to organizational changes at the client site External risks are those risks imposed by external factors such as Labour unions or trading community partner organizations ·         Sometimes it is useful to graphically plot the Use Cases on a Risk Portfolio Chart. Each use case is assessed and then plotted on a risk profile chart to show the probability that the risk(s) will occur and the degree of impact if it does. The higher the probability and the impact, the more emphasis a project manager should place on that Use Case to ensure the proper mitigation strategy is applied to eliminate or reduce the risks. Complexity You need to assess whether functionality contains simplistic input and output algorithms or intricate critical methods. Typical complexity factors to consider are: Number of Actor Profiles Number of proposed scenarios Kind of System Simplicity of the User System Real-time System Embedded System ·        Dependencies It is common for one Use Case to “depend upon’ one or more other Use Cases and/or external interfaces. Often the pre- and post- conditions of a Use Case will hint at these dependencies. Dependencies between Use Cases and/or external interfaces often will drive the sequence regarding how the Use Cases will need to be written and/or implemented. Conclusion These perspectives provide input into the planning process. Use cases do not have to be prioritized this way, there could be other factors. For example once you know the business delivery priorities, you can then plan the development priorities. However one best practice is to address the highest risk early in the project.  This minimizes the possibility of working on the least important things first, and then not having time. When the more complex or architecturally significant use cases are considered too late in the project lifecycle, you are at risk of missing requirements, which will severely impact the usefulness of the system to the end users. So, everything is urgent. Correct??

Everything is urgent. How many times have you heard that? The business needs this functionality to launch a new product, we have to have that piece of functionality to comply with new legislation, our...

Planning and Managing

Stakeholder Management in OUM

Where is Stakeholder Management in OUM?  Stakeholder Management typically falls into the purview of the Project Manager, which means much of the associated guidance is found in the OUM Manage Focus Area (a.k.a. Manage).  There is also a good deal of content related to the discipline of Stakeholder Management contained in the Implement Focus Area (a.k.a Implement). There is no process in Manage named Stakeholder Management, but this “touch point” can be found in a variety of other processes including Bid Transition (BT), Communication Management (CMM) and Organizational Change Management (OCHM). •         Stakeholder Management starts in the Bid Transition process with Stakeholder Analysis. •         This Stakeholder Analysis is used to build the Project Team Communication Plan in the Communication Management process. •         Stakeholder Management should be executed during the Execution and Control phase.  For example, as issues are resolved, the project manager should take the action item to follow up with the affected stakeholders to ensure they are aware that the issue has been resolved. •       The broader topic of Stakeholder Management is also addressed very thoroughly in the Organizational Change Management process in the Implement Focus Area, which is a touch point to the Organizational Change Management process in Manage. Check it out and let me know your thoughts!

Where is Stakeholder Management in OUM?  Stakeholder Management typically falls into the purview of the Project Manager, which means much of the associated guidance is found in the OUM Manage Focus...

Planning and Managing

OUM is Flexible and Scalable

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 fro the Perplexed.

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...

Requirements, Analysis, and Design

OUM is Business Process and Use Case-Driven

Business Process and Use Case-DrivenBusiness 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 togehterBusiness 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

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...

Planning and Managing

Iteration vs. Oscillation

What’s the difference between iteration and oscillation?  This is important distinction for an OUM practitioner to be able to articulate – that while OUM is indeed an iterative method; it does not mean you are endlessly oscillating on the same tasks like a washing machine stuck on the rinse cycle.   Since properly applying iterative development principles is vital to an OUM practitioner’s success, this blog explains why, in OUM, iteration doesn’t equate to oscillation. WHAT IT MEANS TO BE ITERATIVE:  Let’s first understand iterations. In OUM (or any other iterative approach), you divide each phase into periods of time, usually from 2 to 6 weeks (some prefer 2~4 weeks), called iterations. During each of these periods, the team executes tasks in order to achieve the iteration's goal(s).  Therefore, the term, "iterative" means that work on an OUM project is divided into a series of "iterations" that are essentially run as mini-projects. ARE WE THERE YET?  Now we have a solid understanding of iterations, but it still doesn’t completely explain why the project team isn’t oscillating into eternity.  The key here is that “iterative development” also includes the concept of growing the system incrementally. WHAT IT MEANS TO BE INCREMENTAL:  Turning our attention to incremental, this means that the system is developed in chunks, iteration by iteration.  Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.  At the end of an iteration, the resulting increment of functionality is presented to users and requirements are re-evaluated so as to plan the next iteration. PUTTING IT ALL TOGETHER:  Putting this all together, “iterative development” in OUM means that the system is developed through a series of mini-projects (iterative), and in smaller portions at a time (incremental), allowing the project team to take advantage of what was learned during earlier development, and incorporate feedback from project stakeholders.  As the project progresses, the emphasis given to a particular task shifts from phase to phase so that the appropriate phase milestones are met, and ultimately the project’s overall goals are achieved. ARE WE THERE YET (AGAIN)?  You can see that an OUM project team will be working in iterations, growing the software increment by increment, and finally achieving a stable solution that real end-users can employ.  This is much different than being caught in an endless re-run of the movie “Groundhog Day”, forever oscillating on the same tasks; achieving nothing. Now that you’ve read this blog entry, I’d love to hear your thoughts on the differences between iteration and oscillation.

What’s the difference between iteration and oscillation? This is important distinction for an OUM practitioner to be able to articulate – that while OUM is indeed an iterative method; it does not mean...

Planning and Managing

Why not use “just enough” OUM?

Sometimes I hear people say, “Oh, OUM is great, but I’m not sure I can use it for the work I’m doing”. I ask “Why not?”, often I hear one of three answers;I’m working as part of a staff augmentation contract, and there really isn’t a formal “project” for me within the Enterprise. The Enterprise has chosen to use their internal method for this project. Oracle Consulting is not leading the project or the Partner leading the project for the Enterprise is using a proprietary method. Of course, there are many other reasons why someone chooses not use OUM for Oracle product implementations, or other work with oracle products.  These responses make me ask the question “Why not”?    The Enterprise is using their internal methodMaybe the Enterprise has an “in house” method they’d like to use.  Of course, not every Oracle product implementation project requires that you make extensive use of OUM. If the other method seems capable of helping identify and manage risks, improves repeatability and quality, and encourages knowledge capture and reuse, maybe you don't need OUM.  However there may be situations, where you realize that the method doesn’t have adequate support for the type of work you’re doing.  What if the project includes a technical requirement to implement a Service Oriented Architecture the first time?  Perhaps the method you’ve been asked to use isn’t SOA enabled?  If you wanted to SOA Enable that method you might suggest that the Enterprise look at OUM’s SOA Engineering Planning View.  You might simply review the OUM SOA Core workflow view to determine additional tasks that you might recommend as candidates for the project plan using “just enough” OUM.  An Oracle Partner leading the project using a proprietary method or you are an Oracle Consultant assigned as an augmentation to staff.There should be some agreement between the stakeholders the consultant(s) and the partner, regarding the work they are to do on the project.  So I ask, why couldn’t you use “Just enough” of OUM to make sure you have a solid agreement on working together on the project, and the assigned resource responsibilities?  Could you use a portion of the OUM BT.070 Project Management Framework to agree and document how the project is organized?If you’re assigned to do some work within the Enterprise but not as part of a large project, maybe you could prioritize the work.  You could use a MoSCoW list (RD.045) to list out the things that you Must do, Should do, or Could do, in your role.  How about using a Business and System Objectives (RD.001)?  this could improve communication and discuss with the stakeholders regarding the work, you are being asked to do (and what you won’t be doing).  No matter how big the job, scoping the effort and having an agreement will often avoid misunderstandings.  It also gives a definition of what it looks like to call the work “finished”.What if you’re writing some custom components that are fairly complex and architecturally significant?  Can you gather the detailed functional requirements using some OUM?  Could you prepare a Use Case Model (RD.023 Use Case Diagram and RD.024 Use Case Details) just to verify your requirements?  Maybe you don’t need a detailed “fully dressed” use case.  Perhaps a high-level use case would work.  After all, you may need to develop some test scripts, right?  Why not use the use case details to get to the test case details.  Why not start with the answers to the test, and then develop the custom components, extensions, or integrations?When you use OUM think about using “just enough” to facilitate communication, clarify requirements, and protect the project. You’ll find yourself using the portions of OUM that make sense for the work at hand.  After all, it isn’t an all or nothing question.  As you’ve read before in the OUM Read Me First “Do not serve the method; make it serve you.”I’ve chosen to highlight only a few OUM tasks in this blog entry there are many others that could be considered in addition to these depending on your scenario.Using too much of a method, is just as bad as not using any method at all.   What are your thoughts on this topic?  I look forward to reading your ideas and suggestions.

Sometimes I hear people say, “Oh, OUM is great, but I’m not sure I can use it for the work I’m doing”. I ask “Why not?”, often I hear one of three answers; I’m working as part of a staff...

Requirements, Analysis, and Design

It's all down in Black and White.

  In the BI/EPM View of Oracle Unified Method we introduced the idea of Black and White box Use Cases.Black-Box Use Case Black-box use cases capture requirements at the level of observable behavior, but do not reveal the internal workings of the business or system. Most use cases are written at the black-box level to maintain the separation between requirements and design. Within this view, black-box use cases are most applicable to development of a custom BI system, but would also apply to the implementation of BI and EPM product-based systems that require custom extensions that support new data entry or reporting requirements.White-Box Use Case White-box use cases capture requirements that reveal the internal workings of a business or system. White-box use cases detail how the system will satisfy the requirements. White-box use cases are applicable on projects that will implement BI and EPM product-based systems to document requirements regarding changes in the way the product needs to work.Black-Box versus White-BoxIt is important to understand how black-box and white-box use cases are applied to support BI and EPM projects.Black-box use cases are typically used to capture requirements related to the development of new data entry, display, and reporting mechanisms. This includes new custom data entry and report components or data entry and reporting extensions being made to a BI or EPM product.White box use cases are used to capture requirements related to the development or customization of internal data extraction, transformation, and loading components. These requirements typically result in the configuration or customization of existing EPM or BI Apps products. When using white-box use cases, remember to keep the use cases at the level of requirements and not to delve into system design.All clear now? Tony Carpenter

  In the BI/EPM View of Oracle Unified Method we introduced the idea of Black and White box Use Cases. Black-Box Use Case Black-box use cases capture requirements at the level of observable behavior,...

Training

7 Tips for using Microsoft Word 2007 with OUM Templates

To ensure trouble free operation of the method material, the macro security settings associated with MS Word must be modified.  During product installation, the MS 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 an MS Word document.  Because the method material uses extensive macro code, the MS Office security level options must be adjusted prior to utilizing the method material. To adjust the security level for MS Word 2007: Launch MS Word. Navigate to "Office Button" > "Word Options" > "Trust Center" > "Trust Center Settings">. Select "Macro Settings". Verify that the "Disable all macros with notification button" is selected in the Macros Settings. Verify that "Trust access to the VBA project object model" selected in the Develop Macro Settings. Click "OK" Click "OK". In order to view the Yellow Notes in the MS Word Templates, Hidden text must be set to Show. Important: To avoid formatting issues in your MS Word Work Products, the Hidden text option must be set to Show before using the Strip Yellow Notes... feature of the OM pull-down menu. To set the Hidden text to show in MS Office 2007: Using the Office button, select "Word Options". Select "Display". From the Always Show these formatting marks on the screen section, select "Hidden Text". Click “OK”. In order to see the borders of list tables: Select the table. Select the Table Tools tab. Select Layout. Select View Gridlines.  To enable Macros when you open an Oracle Method template: Select the "Options" button associated with the Security Warning. Select the radio button adjacent to the "Enable this content" option in the Security Alert - Macro box. Click "OK". (You should now see an "Add-Ins" tab.) To use the OM Menu Options to edit your template:Click on the “Add-Ins" tab. Click on the OM drop-down menu item that appears in the ribbon below to access the OM menu options.Use Compatibility Mode.Save documents as “Word 97-2003 Document”.

To ensure trouble free operation of the method material, the macro security settings associated with MS Word must be modified.  During product installation, the MS install program establishes all MS...

Planning and Managing

The Tree

  A couple of weekends ago, my wife and I were out for a bicycle ride on the Washington & Old Dominion (W&OD) - a paved, multi-use trail that stretches 45 miles from Washington, D.C. to Purcellville, VA.We were westbound on a section of the trail between Route 7 and Dry Mill Rd. We were coming up behind a runner when the runner stopped suddenly and looked up. The upper two-thirds of a dead locust tree crashed down across the path. The tree fell harmlessly to the ground, but lay across a section with high-sloped sides. The tree had completely blocked the trail. Our initial attempts made it obvious that we didn't have enough muscle power to move the 10-inch diameter main trunk.Soon other cyclists and runners began to arrive. Most began to dismount - except one guy on a shiny new $5K+ bike who didn't seem interested in helping. Ideas were quickly tossed back and forth about how to get the thing out of the way. I even heard my wife say something like, "This tree isn't going to get moved unless everyone helps." (wink, wink, nudge, nudge…).As we organized to lift the main trunk, we noticed that part of the trunk was covered with a vine. It didn't look like poison ivy, but you never know. One woman said that she wasn't allergic to poison ivy, so she'd lift that section. One person with a bad back volunteered to clear smaller debris. By working together, in 10 minutes we had cleared that entire mess and we were back on our machines.As we rode up the trail, we talked about what we had observed. We chuckled about the able-bodied guy who seemed willing to stand there and watch everyone else clear the path for him. However, for the most part we were impressed by the way this ad hoc team had worked together.Of course, I began to pontificate about how this experience was an analog to software projects. We had been part of a self-organizing team. Each participant had different strengths and had contributed where they were best able. Some used their strength to lift. Some contributed their immunity. Others came behind and cleaned up. This simple project hadn’t required a detailed plan, but someone had worked to remove obstacles (i.e. "This tree isn't going to get moved unless… ").If we’d had many trees to move, we probably would have wanted a plan to tell us which trees to move and when. We would have wanted to be able to tell the W&OD trail users when they would be able to use each section of the trail. We might have organized a brief planning meeting before moving each tree to be sure that we were being as efficient as possible.To be sure we were on track, we would periodically ask everyone to briefly describe what they had done, what they were planning to do, and what was stopping them from being effective. That might have allowed us to discover that one team member was worried about scratching their new bicycle, but we certainly would have been able to understand everyone's contribution.Historically, humans have cooperated very effectively to solve problems. That's one of the things that has allowed us to survive as a species. When the problems are more complex, we've learned that it's important that someone create a plan so that things get done in the proper order, etc. However, I think we would also agree that sometimes we have fallen into the trap of focusing too much on the plan and not enough on the people.That’s why even when we're doing large, complex things it's essential that we make use of some of the same basic techniques that have worked on ad hoc projects.Work to a high level plan (10 trees in 3 hours, trail cleared by 6 pm) Employ short planning horizons (finish the current tree before starting the next tree) Prioritize work (clear trees at mile markers 4, 6 and 8.5 first) Employ self-organized teams (let the team decides how to clear each tree) Leverage individual strengths (take advantage of Patty’s poison ivy immunity and Fred’s ability to clear leaves very quickly) Improve the process (For the next tree, let’s be sure to…) Give everyone a brief chance to be heard ("I've cleared the small branches, now I'm going to clear the leaves", "I'm worried about scratching my new bike") Designate someone to clear impediments ("Next time, I'll arrange for a safe place to lean your bicycle so it won’t get scratched") I think that most agile practitioners would say - and I would agree - that agile software methods aren’t radically new or different. They’re simply a recognition and codification of the behaviors that have made humans successful as a species.What do you think?Tom

  A couple of weekends ago, my wife and I were out for a bicycle ride on the Washington & Old Dominion (W&OD) - a paved, multi-use trail that stretches 45 miles from Washington, D.C. to Purcellville,...

Planning and Managing

Make the Method Serve You

One bit of feedback that we sometimes hear about the Oracle Unified Method (OUM) is that it's too heavy or that it forces a project to produce too many documents. The implication is that using OUM is too costly. Of course, developing methods that makes it more expensive or difficult to implement Oracle products would be a disservice to Oracle's customers and in opposition to the mission of the Oracle Global Methods organization.This sort of feedback indicates that the individual may not yet have had the opportunity to fully explore OUM and to understand the philosophical basis upon which it has been developed. When you look more closely, you'll find a number of things that tell the real story:Views provide an initial pre-tailoring of the OUM materials (though still a superset). Supplemental Guides provide further tailoring recommendations along with product or discipline specific guidance to accelerate projects. The Implement Core Workflow view identifies core tasks at the heart of any project. It helps keep project teams focused on the essentials by providing a four-step process for building up a project plan. Guidance around iterative and incremental project planning and for managing an OUM project using Scrum illustrate our ongoing commitment to supporting agile project management.Even more basic than all of these is the OUM Read Me First. The Read Me First describes OUM's philosophical underpinnings. It supports our position that too much method can be as risky as too little and that what projects need is method support that is "fit for purpose" and "just enough." Here is an excerpt: Do not serve the method; make it serve you. The purpose of methods is to identify and manage risks, improve repeatability and quality, and encourage knowledge capture and reuse. If you’re not going to need it, don’t do it.OUM should be scaled to fit your project. You should do no more than is necessary to satisfy the requirements of the project and appropriately address risks. Be sure to not only think about which tasks you will do, but also consider the depth to which your project team will execute specific tasks during specific iterations. Under the proper circumstances, spending the time to simply consider a task can constitute executing that task. The output of a task (a work product) need not be a document. OUM provides templates for many of its tasks. Use of these templates is optional. They should be used only when appropriate to the context of the project. Work products can just as easily be a model in a repository, a prototype, a set of application code, or even the tacit knowledge contained in the brain of a developer. (Yes! This is an appropriate way to work, under the right circumstances.) Written documentation should be produced only when it is essential for the project’s success or the future operation and maintenance of the resulting software system and the business it supports.A focus on understanding the most significant risks and requirements of the system is more important than producing elegant models or perfect documents. For example, not every model needs to be fully attributed to adequately manage design or implementation risks. On the other hand, skipping tasks simply to save effort may be a false economy, especially when implementing sensitive or mission critical systems. Do just enough.OUM needs to support a broad range of projects; from those which must be very predictive to those which would benefit from being very adaptive. To be predictive, OUM needs to include materials that enable it to support a "heavy" level of ceremony. However, experienced practitioners will recognize the need to use careful forethought and judgment to employ "just enough ceremony" and produce "just enough documentation" to support the characteristics of a specific project. Click to read the entire OUM 5.4.0 Read Me First. Meanwhile are you going to Make the Method Serve You? What is your approach?Tom

One bit of feedback that we sometimes hear about the Oracle Unified Method (OUM) is that it's too heavy or that it forces a project to produce too many documents. The implication is that using OUM is...

Planning and Managing

Valuing "Working Software over Comprehensive Documentation"

I subscribe to the tenets put forth in the Manifesto for Agile Software Development - http://agilemanifesto.org. As leader of Oracle's Methods team, that might seem a self-deprecating attitude. After all, the agile manifesto tells us that we should value "individuals and interactions" over "processes and tools." My job includes process development.I also subscribe to ideas put forth in a number of subsequent works including Balancing Agility and Discipline: A Guide for the Perplexed (Boehm/Turner, Addison-Wesley) and Agile Project Management: Creating Innovative Products (Highsmith, Addison-Wesley). Both of these books talk about finding the right balance between "agility and discipline" or between a "predictive and adaptive" project approach. So there still seems to be a place for us in creating the Oracle Unified Method (OUM) to become the "single method framework that supports the successful implementation of every Oracle product." After all, the real idea is to apply just enough ceremony and produce just enough documentation to suit the needs of the particular project that supports an enterprise in moving toward its desired future state.The thing I've been struggling with - and the thing I'd like to hear from you about right now - is the prevalence of an ongoing obsession with "documents."OUM provides a comprehensive set of guidance for an iterative and incremental approach to engineering and implementing software systems. Our intent is first to support the information technology system implementation and, as necessary, support the creation of documentation. OUM, therefore, includes a supporting set of document templates. Our guidance is to employ those templates, sparingly, as needed; not create piles of documentation that you're not gonna (sic) need. In other words, don't serve the method, make the method serve you.Yet, there seems to be a "gimme" mentality in some circles that if you give me a sample document - or better yet - a repository of samples - then I will be able to do anything cheaply and quickly. The notion is certainly appealing AND reuse can save time. Plus, documents are a lowest common denominator way of packaging reusable stuff. However, without sustained investment and management I've seen "reuse repositories" turn quickly into garbage heaps. So, I remain a skeptic.I agree that providing document examples that promote consistency is helpful. However, there may be too much emphasis on the documents themselves and not enough on creating a system that meets the evolving needs of the business.How can we shift the emphasis toward working software and away from our dependency on documents - especially on large, complex implementation projects - while still supporting the need for documentation? I'd like to hear your thoughts.

I subscribe to the tenets put forth in the Manifesto for Agile Software Development - http://agilemanifesto.org. As leader of Oracle's Methods team, that might seem a self-deprecating attitude. After...

Transitioning from AIM and AIM for Business Flows

Oracle AIM, Oracle ABF, and Siebel Results Roadmap Officially Retired as of January 31, 2011

It seems somehow appropriate that the first entry of the Oracle® Unified Method (OUM) blog is about the retirement of several of our legacy methods, most notably AIM Foundation. You can click here to read the official Partner announcement. If you're reading this, you're probably aware that Oracle has been developing OUM to support the entire Enterprise IT lifecycle, including support for the successful implementation of every Oracle product. As Oracle has continued to acquire new companies and technologies, it has become essential that we also create a single, unified language and approach for implementation - across the Oracle ecosystem. With the release of OUM 5.1 in 2009, OUM provided full support for all enterprise application implementation projects including Oracle E-Business Suite R12, Siebel CRM, PeopleSoft Enterprise, and JD Edwards EnterpriseOne projects. In 2010, we released OUM training that supports the use of OUM on these types of projects. That support represented a major milestone in the evolution of OUM and enabled implementers to transition to OUM. Consequently, we announced a staggered retirement schedule for Oracle's legacy methods. On January 31, 2011 we announced the retirement of: Oracle Application Implementation Method (AIM) Oracle AIM for Business Flows (ABF) Siebel Results Roadmap Later this year, we will announce the retirement of Compass - the legacy PeopleSoft method - and Data Warehouse Method Fast Track. OUM is available free of charge to Oracle Gold, Platinum, and Diamond partners through the Oracle Partner Network (OPN) [OUM on OPN]. The OUM Customer Program allows customers to obtain copies of the method for their internal use by contracting with Oracle for an engagement of two weeks or longer meeting some additional minimum criteria. There be more retirement announcements in the coming months. For now it's "Adios AIM." Thanks for the memories...

It seems somehow appropriate that the first entry of the Oracle® Unified Method (OUM) blog is about the retirement of several of our legacy methods, most notably AIM Foundation. You can click here to...

Oracle

Integrated Cloud Applications & Platform Services