Reader question:
 “If a project is approved, do I still need to do enterprise analysis as defined in the BABOK? Do I need to do a business case?”
This question got me thinking about the distinction between creating a deliverable and facilitating the understanding that the deliverable is intended to produce. We’re not always brought in on a project when we “should” be and we aren’t always formally assigned to each step of the business analysis process. And we may or may not have the flexibility to start the project exactly the way we’d like. Oftentimes our management expects us to get started on requirements and would perceive work on a business case as backward momentum for a project that has already been approved.
At the same time, to be effective as a business analyst, you must understand the business case of the project in question. What is the scope? What is the budget? What are the key risks? How does the organization see the value of the project?
So, let’s consider some questions around the when, what, and how of the business case. When do you need it? What should you do? How can you approach business case work without creating a business case? And when should your ethics as a business analyst tell you that you should refuse to start in on the detailed requirements until you have one? These are all very different questions. But oftentimes our answers muddy the waters because we feel we need to answer all of these questions in one consistent way.
When do you need a business case?
A business case can serve many needs, but most often it is the document you use to help the project secure funding. Funding might come in the form of a specific budget to deliver a project or an allocation of resources. The business case will justify the project spend and help the executive team make an informed decision about funding the project.
When should you do business case work?
You should always do a simple business case because you always need to understand the business needs and objectives driving your project. Even a one page statement of scope, goals, risks, and potential cost does wonders to align a team of people around what needs to be accomplished. A meeting to discuss these points moves things in the right direction. Meeting notes can serve as a business case in disguise for a particularly process-wary organization.
But common sense also says you should invest more time in your business case as the potential costs and risks of the project increase. The more money you intend to spend, the more time you should invest in figuring out why to spend that money and what a successful project looks like.
What are the alternatives to a formal business case?
Any experienced BA will tell you they’ve been doing business case work for a long time even if it’s been called something else. In my career, we’ve done what have been called project scope documents, project charters, project “service requests”, and project proposals. These were all variations on the business case as prescribed by the organization I was working in at the time.
If your organization has no such document that is used to get a project started, there is a style to elicitation that allows you to answer some of the key questions. Taking time to understand what problem will be solved is part of enterprise analysis. As is a project kick-off meeting that discusses scope, benefits, and timeline. You can approach the business case in many ways, some formal, others very informal.
When in doubt, lead your teams toward a common understanding of the benefits, costs, and risks of a project as part of beginning your requirements efforts. You may not need to call this a business case, but you can be sure that you will be leading business case work.
>> Define Your Business Analyst Process
Join us for the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations.
Click here to learn more about the BA Essentials Master Class
