Business objectives define what value means in the context of whatever work it is that you’re doing. It could be a change, an initiative, a product backlog item, or an individual user story. And they answer questions like:
What results are you trying to create? What problem are you trying to solve? And what is the potential ROI (return on investment) in this change versus anything else that we might put our attention into?
When we have clear business objectives, we do the upfront work that circumvents significant downstream issues that honestly can bring a project to a screeching halt. Some of those issues tend to be detailed requirements churn while stakeholders start to advocate for solutions to completely different problems, or the implementation of a solution that the business rejects or simply can’t even use because it doesn’t meet their actual need.
And while this might sound counter-intuitive, clarifying business objectives can often take the scope and reduce the scope of an initiative, allowing that organization to invest less to generate more value. Even a small change or a seemingly minor enhancement request, when you take the time to clarify a business objective, it’s going to make the best use of resources by ensuring that the right requirements get discovered and implemented.
Business Objectives: Examples
Here we have two examples of quantifiable business objectives for a home insurance claim application where homeowner and contractor could use to submit their claim data to an insurance company.
- Reducing the average time a claim agent spends preparing and submitting a claim from 8 business hours to 6 or less.
- Reducing follow-up calls to check on claim status by homeowners by 50%.
Business objectives can also be qualitative and less specific. Here are two versions of those same objectives without the specific numbers:
- Reduce the time a claim agent spends on a claim.
- Reduce follow-up calls by homeowners.
Business objectives are not scope
Scope describes the solution. Examples include:
- Implement a new Customer Relationship Management (CRM) system.
- Retool the lead management process.
- Automate the contract management process using newly available technology.
Those are all descriptions of solutions. They are outcomes in that they are generated outcomes of the project, but they’re not really the business objectives or why we would be putting those initiatives into place.
Business objectives articulate outcomes
A CRM might increase visibility into the sales lifecycle. Retooling the lead management process might reduce the days to close a new lead from 90 to 60. Automating the contract management process could reduce the effort to produce a new contract from 20 hours to 5 hours.
It’s really important to get that difference. I see way too many BAs thinking they’ve got this whole business objectives thing figured out, but they’re really just talking about the output, not the high-level outcome.
Business objectives can come by many different labels
The other thing I want to draw your attention to is that your organization might not call these “business objectives.” You want to look for where they are using terms like:
- Business requirements.
- Business needs.
- Business value.
- Desired outcomes.
- ROI (Return on investment).
- KPIs (Key performance indicators).
All of these are often business objective-related information, where your organization might be calling it something different.
We want to meet people where they’re at. It would be easier if everyone is calling them “business requirements” or “desired outcomes” to use that language internally. Ensure that those desired outcomes or KPIs are actually business objectives and are clearly understood and aligned by everyone, versus trying to also change the terminology and insist, “We need to call these business objectives now.”
Look at what terminology your organization might be using and opt into that wherever you can.
You’ll find outcomes in many different documents
Scope statements. Business cases. Project charters. Epics. Etc.
At Bridging the Gap, we teach a scope statement because it’s a simplified way of really capturing the scope of a project, the business objectives, the constraints, the capabilities of the solution, and the risks and the out-of-scope items. It’s just a really simple document to communicate that core information.
But your organization might do this in a business case, or a project charter, or an epic. Look at what documents have some information related to why we’re investing in this.
And again, put yourself into the position of being part of that document or part of that review, or validating those business objectives, or asking questions around those business objectives in the document it’s already in, versus trying to create like a standalone document that just has this piece of information. Or, if nothing has it but there’s a document that’s often reviewed upfront, typically by higher-level business stakeholders, advocate for adding a section to that existing document versus creating something from scratch.
Leveraging AI to help draft business objectives
A lot of BAs get stuck because stakeholders don’t really know what their business objectives are. It can be helpful to suggest ideas that people can react to. We might, though, not really know what those ideas are. And so we can use AI to help us come up with some of those ideas. And this AI prompt is a great template to use:
The business sponsor in the role of {role name} wants to implement {solution} for a {type of company}.
{Summarize any context you have around the goals}
I’m struggling to get them to define their objectives. What are the primary benefits that our organization can realize from implementing a solution like this?
You can use this even without a company-sanctioned, licensed AI, as long as you’re not sharing anything proprietary in there. You could use it just to get some ideas and make it a little more general, even outside of your company.
Of course, you always want to abide by those policies, but there’s nothing in this prompt specifically that mandates you share proprietary information.
Prompt AI with additional questions to gain more insight
Now once you have that thread going, you can ask all kinds of additional questions.
- “They’ve shared that they want to [blank], but I don’t think that’s the real or only reason. What do you think?”.
- “Our organizational objectives are [list]… How could this solution help us achieve those outcomes?”. (Take your organizational strategy—this you wouldn’t want to load into a non-protected system—and ask how the solution helps achieve it).
- “What objectives related to sustainability and social justice might we want to propose for consideration?”. (If there’s a value that you find really important and you’d like to at least encourage people to talk about that, you could bring that into the discussion).
- “What additional questions should I be asking about their motivations?”.
- “What is the potential financial return on these objectives, and how can those be measured?”.
- “What baseline data should we be looking at to quantify this opportunity?”.
Looking for more support with AI prompt engineering? Here’s a video tutorial specifically for business analysts:
Go even deeper with an organizational AI knowledge base
One other piece I want to mention is that when you have access to an organizational AI knowledge base, you could even go deeper:
You could ask:
- “How can this initiative support our overall organizational goals?”.
- “What other projects under consideration are also tackling these objectives?”. (So that you can find opportunities for synergy and overlap and shared resources and maybe combine a project together).
- “What changes have we implemented so far to impact these objectives and what can I learn from those projects to consider here?”.
Now these assume you have robust amounts of information and history loaded into your AI system. Not all BAs have this, but if you do you can start to ask these next-order questions and get even better results from what you get from AI.
Business objectives cultivate alignment and clarity
I hope this tutorial helps you think through how you can bring more attention to business objectives in your work. And, critically, ensuring everyone is truly in agreement on what problem we’re trying to solve, where we’re going, before we start the other work of the project. This will save you loads of time down the road and make everything not easy, but a bit easier as you go.
If you’d like to go deeper with me, I teach these sorts of concepts inside The Business Analyst Blueprint training program.
We have conversations about what problem we’re solving, how can we make the scope work within that problem, how can we handle challenging stakeholders who may be resistant to these kinds of questions. And I’d love to work with you or your organization to help you and your business analysis practice get better.