An Oracle blog about Unified Method

Make the Method Serve You

Guest Author
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?


Join the discussion

Comments ( 1 )
  • guest Monday, May 16, 2011
    Hi Tom, Great discussion. On a project, I remind myself to keep asking the following questions:
    How mission critical is the project?
    How many people are on the project?
    How experienced is the team?
    Does the team and customer handle uncertainty well, or do they prefer order?
    How dynamic can the changes to requirements be and do I understand the context under which the project is operating?
    What documentation is required by the scope of work?
    How do the work products relate to the business and system objectives?
    Is the work product the end goal or is it achieving a specific business and/or system objective?
    I am looking forward to hearing from other blog readers about their experiences and approaches for achieving the right balance on their projects.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.