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;
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”?
Maybe 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.
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.