What follows is our ROM defined. For context, you can see yesterday’s post on why we have a ROM now at ArgonDigital.

Definitions for the items in the ROM hierarchy:

• Business Problem: Describes a problem to be solved.
• Business Objectives: Desired metrics the business seeks to meet in order to solve the problem.
• Business Strategy: Approach to meet the business objectives. It is not specific to any one product or project solution.
• Product Concept: Proposed solution to follow the business strategy to accomplish one or more business objectives. This becomes a project.
• Success Metrics: Statements about the specific desired outcomes to meet the business objectives.
• Guiding Principles: The approach to meet the success metrics for the product. Common themes to be considered in creating a product. These will drive the feature set and specific requirements.
• Product Features: A collection of functionality that provides a set of services to the users.
• Product Qualities: A collection of desired qualities about the product.

Features and Qualities are derived from business objectives.

The important thing is that your features should trace from your Business Objectives. And in the end, if you cannot make this leap directly, then you use the product concept, success metrics and guiding principles to help define them.

To that point, most projects actually start with a product concept. The team might define success metrics (i.e. a launch date). But they quickly jump in to defining features and qualities and then requirements and design. There are no agreed upon Business Objectives and development strays from the intent of the project. If we lived in a perfect world, we could start with the business level problem and objectives, then define the product level, and out of that define the product requirements. But having worked with many customers, nothing is ever this clean.

So instead, we suggest you do start with a product concept if you have one, and put any pre-defined features aside. Then work back up from the product concept to understand what problem it is supposed to solve. Continuously ask “why is that a problem?” until you find a problem that relates to money and write your Business Objectives at that level. We make it this simple so that you clearly know if you have gone high enough to say you have defined Business Objectives. The reality is that most (if not all) businesses exist to make money so all of their objectives relate to that goal – either in the form of increasing revenue or decreasing costs. Before I go on, I will say that every time I speak about this topic, someone gasps in the audience when I make this claim. That said, we have yet to see a project that doesn’t relate to money (and that’s not to say they aren’t doing other good things too!).

Once you have good Business Objectives, you can determine appropriate strategies to meet them. These strategies may or may not include building software products. But if they do, then you write a clear product concept that may or may not look like your original one. Then you continue through the ROM, developing success metrics and guiding principles for the product. Again, realize that the features may have changed from the original suggestions, in order to map back to actual objectives.

A quick example for today, but tomorrow I’ll give a more complete example:

• Proposed feature: Online training
• Problem question: Why do we need online training?
• Problem answer that relates to money: Online training leads to more trained users. More trained users leads to more sales. Now we can relate this to revenue!