Business Objectives Model
A Business Objectives Model (BOM) is an RML®️ model that iterates through business problems and business goals/objectives of a project to arrive at the software product concept. The BOM for a product aligns the team on why they are building the product and what benefit the product will provide. If you’ve made BOMs already or are attempting one for the first time, this article can help you make it better! The BOM is challenging to elicit and create, so you’ve come to the right place.
Create Your Business Objectives Model Early
The BOM is made at the very beginning of a project, either sprint 0 or the planning phase with input from a light-weight business case, project charter, cost-benefit analysis or interviews with stakeholders. Unfortunately, it’s often the case that the Product Manager/Business Analyst is given a solution to build and must work backwards in order to understand and articulate the problem. Don’t be afraid to point out if the solution you’ve been given doesn’t align with business problems or objectives.
Agile projects acknowledge that change is constant, so you may need to revisit the BOM throughout the project. Be prepared to remind stakeholders what the problems and objectives are and to update the BOM as needed throughout the life of the project.
Begin With A Draft Model
You may be starting with known problems, objectives, or a product concept. If you’re lucky, you have a project charter or some other project initiating documentation to work from. If you can, begin by making a draft model. This makes starting the conversation with your stakeholders easier. Your draft may look something like this:
Once you have a draft, you can start interviewing stakeholders. Try using the questions and gut checks below to help build the BOM. You can start with any piece of the BOM that you already have and elicit the rest of the model.
Getting From Product Concept To Business Problems
- What happens if we don’t have the product?
- What happens if we don’t have a particular high-level feature?
- Why is not having the product or a feature a problem?
- Business problems should not be the lack of a solution. When interviewing, push back on those types of problems until you understand why the lack of a product or feature is an issue. Keep in mind that your users have a job to do even if you take their laptops away. The lack of a solution should somehow tie into money (such as a process taking too long and therefore being costly).
Getting From Top-Level Problems To Objectives
- What would it look like if this problem were solved?
- When do we need to have the problem solved?
- Objectives should be verifiable at the end of the project.
- Use the SMART (Specific, Measurable, Attainable, Relevant and Time bound) acronym to ensure that you’ve captured good business objectives.
- Sometimes business objectives can be too large to easily measure throughout the project to know if you’re on the right track. Use success metrics to get earlier feedback.
- When defining business objectives, avoid unbound percentages. Always have a starting value and target value to truly know if you have achieved your objective.
Getting From Objectives To Lower-Level Problems
- What is preventing us from achieving this objective today?
- What is blocking us from achieving this goal?
Getting From Objectives To Product Concept
- What can I build or do that would achieve this objective?
- The lowest-level objectives should tie directly to a feature that achieves them.
- Each High-Level Feature should tie to a single business objective for traceability. If a feature supports multiple objectives, select the highest impact one. It’s ok if objectives tie to multiple
Using Your Business Objectives Model
After the BOM is completed (for now), BOMs can be used to:
- Identify the MVP. Which business objectives are the most important to enable?
- Prioritize features. Which features support the most important business objectives?
- Derive epics or high-level features for the backlog.
- Reduce or eliminate scope creep. For each new feature request, ask your stakeholder how the feature ties back to business objectives.
- Value user stories. Because business objectives at the highest level relate to money, user stories inherit value by tracing it to the feature and through to the highest-level objective. Assigning values to your stories allows you to easily stack rank the backlog.
Want to explore BOM creation further? Check out How to Create a Business Objectives Model.
If you’d like to explore coaching or training in using Visual Models on your projects, we’d love to help! We’ve worked with hundreds of organizations who wanted to improve their project processes and communications. Let’s talk.
