Wednesday Mar 19, 2014

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?

Monday Apr 22, 2013

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:
  1. Don’t eliminate anything in the Core Workflow without carefully consideration.
  2. Review any available supplemental guidance.
  3. Consider removing activities/tasks NOT included in the Estimate and/or Proposal.
  4. 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 Resources

  • OUM 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).

Friday Mar 22, 2013

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 Model

Once 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 Approach

Congratulations!  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!

Thursday Mar 21, 2013

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 Team

As 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 Model

Before 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 Level

As 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 Approach

You 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 estimate

For 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!

Wednesday Mar 20, 2013

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

Tuesday Mar 19, 2013

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 Model

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

Monday Mar 18, 2013

Steps to Create an OUM Estimating Model

Welcome to my 5-part series – “Steps to Create an OUM Estimating Model”

Introduction

I am a methodologist.  Together with my Oracle Method colleagues, numerous hours have been spent defining method structure and developing collateral to support Oracle Services delivery.   We also facilitate the development of estimating models for a variety of technologies and applications.

Estimating models come in many shapes and sizes.   I have been exposed to different estimating tools and approaches for estimating services -- both from the legacy Oracle estimating models and acquired estimating models.   Oracle’s own internal estimating models continue to evolve as the nature of service delivery changes and as best of breed approaches are identified.

Although I cannot provide specifics of Oracle’s internal estimating models, I can provide tips that I have learned over the years that may help you build your own estimating model, specifically an Oracle Unified Method (OUM) estimating model.

Join me tomorrow as we begin to explore how to develop an OUM estimating model.

Monday Mar 11, 2013

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!

Wednesday Jan 30, 2013

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 OUM

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

Monday Jan 28, 2013

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.

Friday Jan 25, 2013

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.

Friday Jan 18, 2013

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.

Thursday Jan 17, 2013

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 project

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

Thursday Jan 10, 2013

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!

Thursday Dec 13, 2012

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:

  1. Unit Testing
  2. Integration Testing
  3. System Testing, and
  4.  Systems Integration Testing

See 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:

  1. (D)
  2. (B)
  3. (C)
  4. (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.

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