Why is it so hard to develop a high-quality business objectives model?
The business objectives model (BOM) is one of the most powerful visual models that we use on our projects. A good BOM not only defines scope, but it also provides a mechanism for prioritizing product features and measuring project success. Not bad for a one-page diagram! Our guidance is that every project/product team should create a business objectives model, ideally in the project initiation phase.
Yet, my own experience is that business objectives models are often incomplete or not done at all. It should be one of the most straightforward models to create, and yet it is the hardest. Why is that?
The BOM is deceptively simple – a string of related problems and objectives that lead us logically to the product concept and its constituent features. But developing a good one requires both intellectual rigor and honesty. The process of creating one as a team reveals our dysfunctions. It can be painful.
Sometimes when we’re teaching people how to create a model, we use a simplified scenario so as not to get lost in the details. But for the purpose of exploring the challenges of the BOM, I want to use a more realistic example. If you have an emotional response to it, that’s good! Because that’s what it’s really like to do this process on a project.
For this thought experiment, we are going to pretend to be members of a public interest group researching and crafting educational policy recommendations to the state legislature.
Let’s start with something most people could agree is a problem – that only 24% of American high school seniors demonstrate a “proficient” level of skill in writing. It’s easy to see that lack of proficiency would negatively impact college and work success for students. Let’s put that as our #1 problem in the model.
Then we go to the first level of objectives. Already the possibility for uncertainty and disagreement arises! Even if we agree that writing proficiency should be improved, we need to be as specific as possible, and pinning down specifics is hard. Let’s imagine that we can agree that an increase to 40% proficiency in 5 years is a good stretch goal.
The next step in our modeling process is to document the second layer of problems, those blockers that are currently preventing us from achieving that 40% proficiency goal. Now our stakeholders will bring a lot of statistics and studies and opinions to bear. We’ll need to evaluate these with rigor and honesty, because these are going to lead us straight to our recommended solution. If we are vague or inconsistent here, the whole model starts to fall apart.
We researched and discovered three important factors that are contributing to students’ failure to achieve writing proficiency. These are lack of time spent doing persuasive writing, lack of teacher education and resources, and lack of underlying grammar skills necessary to achieve better writing proficiency. This is a high-level model, so we’ll include all of these, but of course each of these issues has a lot of underlying complexity. How much analysis of these problems needs to be done at this point depends on your organization and your existing expertise. It may be that these are already pretty well understood.
Next we get to the really hard part – the final set of measurable objectives that tie directly to the recommended solution. In my experience, this is where the model can get really subjective. Who decides what metrics should be used? Are the metrics actually measurable in real life? Are these objectives realistically obtainable? What are the hidden downsides to these objectives? I’ve seen too many real-world projects where we were unable to get stakeholders to commit to metrics and had to resort to “x” as a placeholder that never got updated. This makes the model weak, because without those metrics we can’t successfully use it to evaluate and prioritize the recommended features. Consider our example. If we stated an objective of developing a grammar tutorial without the metric to roll it out to 100% of elementary schools, then later on, an argument could be made that a 10% rollout was success. But that wouldn’t actually have the desired impact on the original problem! Behind each of these final objectives lies analysis, because in order to narrow it down to this list, we need to have done sufficient research to identify that these are the best possible choices to guide our product design. There could have been other approaches, but we’ve eliminated those from consideration because they are unproven or impractical or prohibitively expensive. Therefore, our model does not present the entire universe of possibilities, but only those which have survived our analysis.
Finally, we list the recommended features of our solution. Each of these must clearly tie to one or more of our objectives. The next logical step in the process is to develop a cost/return on investment profile of each of these features in order to determine the best way to spend limited funds to achieve the most value! For that, an Objective Chain is the perfect tool.
Now I bet you’re already thinking of flaws in this example model and ways that you can improve it. Great! The best way to master the use of the Business Objectives Model is to apply it to a variety of practice scenarios and work through the logic yourself. The goal is to come up with the best possible solution design given the problems we’re working to overcome.