Tuesday Jan 08, 2013

What's New in OUM 5.6: Updated Manage Homepage

Have you seen the updated Manage Focus Area homepage in the latest release of OUM?  If you have downloaded the recently released OUM 5.6, you may have noticed the Manage homepage was redesigned so that the primary navigation is now by activity, rather than by process as in prior releases. This was done based on feedback from our global PM community that they prefer to view and manage their projects at the activity level. The new activity diagram navigation allows a PM to see the major blocks of work that must be accomplished by phase. This enhancement provides a flexible checklist and high-level perspective preferred by many OUM project management practitioners.

If you still want to navigate through Manage via the process view (aka the Whale Diagram), you still can. Go to the bottom of the ‘Select a View’ list from the OUM homepage and select ‘Full Method and Focus Areas’. On this page, you can then select the both the primary Manage view or the Manage Process view.

Haven’t downloaded OUM 5.6 yet? Check out the official announcement for more information about how you can download the method pack and start taking advantage of the updates in OUM 5.6. In the meantime, your comments and feedback are very welcome.

Wednesday Nov 21, 2012

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 Name

 

Process Model

 

Use Case

 

Notes

 

Manage outbound calls

 

Ö

 

 

A series of linked human and system tasks for calling and following up with prospects

Manage content revision

 

 

Ö

Updating the content on a website

Update User Preferences

 

 

Ö

Updating a users display preferences

Assign Lead

 

Ö

 

Reviewing a lead, then assigning it to a sales person

Convert 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 considered

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

 

 

 

Thursday Aug 23, 2012

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?

Tuesday May 08, 2012

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.

Tuesday Apr 17, 2012

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.

Monday Feb 06, 2012

Back to the Strategy

Methodologists are much like everyone else in that we are all too crazy busy to spend time reflecting on the past.  However, as I was preparing for a presentation at the 2012 JDE Summit last week, I found myself reflecting on the fact that I had returned to the site of an important milestone in the evolution of OUM.

It was seven years ago, in a conference room at the Oracle campus in Broomfield, Colorado, that several legacy Oracle, PeopleSoft and JD Edwards folks got together and sketched out what became Oracle’s method integration strategy.  We may have tweaked the actual wording since that meeting, but the foundations of the strategy have remained:

  • Support current methods (Compass, AIM, ABF, Siebel, DWM FT, etc.)
  • Develop a single, integrated method, to support the entire Oracle ecosystem, across all Oracle products (OUM).
  • Decommission legacy methods as the field transitions to OUM.

In the seven years since the initial meeting in Broomfield, this strategy has served as a solid foundation as OUM has evolved and many acquisitions have subsequently been brought into Oracle.  So I suppose that for even crazy busy people, there is benefit in reflecting back on the fundamental decisions that continue to drive our day-to-day tasks.

Tuesday Nov 08, 2011

OUM is Business Process and Use Case-Driven

Business Process and Use Case-Driven

Business processes and use cases are used as the primary artifacts for establishing the desired behavior of the system and for communicating this behavior among the stakeholders.

OUM projects are able to document requirements through business process models, through use cases, and through written supplemental and quality of service requirements. OUM guidance helps implementers to understand where each technique is appropriate and how they fit togehter

Business processes modeling helps stakeholders and implementers to understand the business processes of an organization, and look at the business requirements that are satisfied by a particular business process. To complement business process models, use cases models and use cases may be used to:

  • Provide a consistent mechanism to link system requirements to design and test tasks
  • Bridge the gap between business modeling, business processes, and software system functionality
  • Provide a consistent thread through OUM – use cases help amplify and consolidate the many other benefits of the method
  • Identify implicit or unstated requirements
  • Manage traceability of requirements through testing

Often business process models for predefined solutions exist and contain some form or description of how the user interacts with the system or how a system interacts with another system. Where these business process models already exist, they should be reviewed as a means of gathering business requirements. The need for additional use case modeling would depend on how well the business process models have captured the requirements of the business. Use cases become particularly important where there is a significant gap between the functionality required by the business and the functionality provided by the predefined solution or software product that is being employed. OUM proposes that implementers develop only the set of models and artifacts required to understand and document requirements and trace those requirements through the implementation lifecycle.

As the project progresses and where the need to develop use cases arises, the use cases are analyzed and the system is designed and implemented to meet the requirements captured in the use cases. The implemented components are tested to verify that they provide the business benefit described by the use cases. All of the models (Use Case Model, Analysis Model, Design Model, Architectural Implementation, and Performance Test Transaction Models) are related to each other through trace dependencies. Use cases are prioritized to:

  • Define the architecture before committing too much resource
  • First deliver the components with the highest value to the customer
About

OUM Logo
The Oracle® Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle.

Read:

· Brief

· White Paper

· Customer Program Data Sheet

Connect:

· OUM on Twitter

· OUM on LinkedIn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds