I recently taught our Visual Modeling class to a group of project managers. Coming from a software development point of view, it’s always a bit of a challenge to provide useful context and examples for folks who are engaged in different kinds of projects. The one model I’ve found that everyone gets excited about is the Business Objectives Model (BOM).
The BOM ties business problems to business objectives to product features in order to support scope prioritization and management. Below is an example, based on a hypothetical non-profit organization that conducts an annual fundraising event run by its constituent local organizations:
When I asked my students about their key takeaway from the class, they all enthused about the BOM and how it could be applied to their organizations.
“My boss is a consensus builder. She isn’t comfortable making decisions until everyone has bought in. This model will help me support the decision-making process with facts.”
“In my agency, anyone can recommend a project. Sometimes projects get approved that shouldn’t be. If we incorporate this model into our project approval process, we’ll have fewer wasteful projects.”
“We’ve just gotten a 23-page list of requirements from our stakeholder. The BOM will give us a tool to sift through those requirements and prioritize them or take them out of scope. It’s a lot better than ‘because I said so.’”
If the BOM is such a useful model, we should definitely create one for every project, right? Yes, but the BOM is one of the hardest models to create. You may need to iterate through multiple drafts before you get a strong BOM that will serve its purpose well. One of the challenges is writing problems and objectives that are atomic and concrete. In order to practice this, I encourage my students to try drafting a BOM for their real-life projects.
Here are some examples that my class drafted and then improved to make them stronger.
• Draft Problem – The current system is out of compliance.
• Improved Problem – As of 2021, the government will not accept reports generated by our existing system.
• Draft Problem – The project management system does not use real-time data.
• Improved Problem – The project management system doesn’t integrate with the resource management system, so we don’t have visibility to actuals, resulting in people being over- or under-allocated.
• Draft Problem – The canned reports are inflexible and don’t meet the organization’s needs.
• Improved Problem – It costs $50k a year to support custom report development because the system reporting capabilities are insufficient.
• Draft Objective – The agency web site should be easy to use.
• Improved Objective – A scientist should be able to upload and submit project data in three minutes or less.
• Draft Objective – The new project management system will reduce project costs.
• Improved Objective – Integration with the resource management system will reduce overtime pay by 50%.
• Draft Objective – Reduce the number of emails between the project team and grant-writing team.
• Improved Objective – Workflow management will increase grant-writing team efficiency resulting in an average 1-week reduction in the time to complete a grant application.
Even within the constraints of the classroom environment, teams were able to greatly improve their drafts by looking for metrics and being as specific as possible. In organizations where speaking in generalizations is the comfort zone, it can be difficult at first to drill down to the next level, but without it, the Business Objectives Model just won’t deliver the promised value. Challenge yourself by drafting a BOM for your current project to see if you really know the business value and associated metrics! You might find opportunities for improving project communication and refining priorities.