I have recently started working on a new project, and we recently held our kick off meeting for the effort.  One of the standard items to review is the project summary, which is usually a couple of short statements on what the project is all about.

Since I was aware that most of the subject matter experts would be attending the kick off, including the main business sponsor, I decided to replace the project summary with the Requirements Objective Model (ROM).   This would give me an opportunity to introduce our first model, and to also get confirmation on the content of the ROM.

So for those of you who are not familar with the ROM, it is a way to create a foundation for the entire project, to help ensure the success of the effort.  The ROM consists of many parts:

• Business Problem – describes the problem(s) to be solved.
• Business Objectives – the desired metrics the business seeks in order to solve the problem.
• Product Concept – the proposed solution to accomplish one or more business objectives.  This becomes a project.
• Sucess Metrics – statements about the specific desired outcomes to meet the business objectives.  These may be at the project or product level, or both.
• Guiding Principles – the approach to meet the success metrics for the project.  These are common themes to be considered while creating the product.

There are other parts of the ROM which can be included, but this is the basic set of information.

Now the information for each of these parts can be displayed in a  table.  But more recently, we have been displaying them like we do many of our other models, in a more graphical format:

The advantage of this format is not only does it help show the relationships between the various parts of the model, but because it is graphical, it is much more interesting to look at.  And since it is more interesting to look at, I was able to grab the attention of my business sponsor and subject matter experts, and to really review the content of the model.  This led to a very productive discussion, with tweaks, deletions and additions along the way.

The end result?  Everyone in that room had a clear understanding of what we are attempting to achieve with this project, and we have a means to measure whether or not the project is successful.  We will continue to use this model as the project progresses, to help us control scope.  If a requirement does not map back to one of the business objectives, then the question must be asked if that requirements is in scope for the project?  Chances are, the answer will be no.