Recently a fellow BA asked this question in the IIBA(R) LinkedIn forum: “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?” He received several timely and insightful responses, so it is worth reading the entire chain.
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 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 requirements elicitation until you have a 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?
Common sense tells me that you should always do a simple business case. 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.
When should you refuse to do anything until a business case is in place?
This is really a tough question. The answer cannot be generalized. This is a personal and professional decision. You are likely to take a different position depending on your professional clout (perceived seniority in the profession and organization) and your ability to take a professional risk (could you lose this job or contract?).
The answer to this question may be in the realm of yes if you trust an instinct that the project under question may waste a lot of your organization’s money or fail to deliver on it’s potential return on investment.
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 time line. My point is that 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.
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
Loading ...
{ 2 comments… read them below or add one }
I think it’s worth making the distinction between a business case and business need.
The business case according to the BABOK is
To determine if an organization can justify the investment
required to deliver a proposed solution.
and is in my experience primarily a financial exercise performed in earnest before the 40 programmers are authorized, i.e. when there is a clear idea what is going to be delivered and what effort it will take. While the BA is a stake holder this is generally something owned by the project manager accountable for the bulk of the cost.
Business Goals and Objectives along with Stated Requirements seem like the more crucial elements for proceeding with BA work. Business Need, “why the business needs change”, and the tactical or strategic value it’s satisfaction can provide to the business is a BA contribution to the business case, but also has crucial independent role as the context for Requirement Analysis.
Hi Nathan,
Thanks for your comment. I suppose I am taking a broader view of “business case” as a document that might contain the elements of business goals and objectives and business needs whether or not funding is approved or not.
I have fewer experiences as a contributor to very formal business cases and more experiences doing what I would consider “business case work” that produces documents much shorter in nature and where the focus is on understanding the goals, not so much on justifying the resources.
I also have many experiences doing very micro-level business cases, especially as I am working in an agile environment. So we might make these decisions on a feature-by-feature level, ensuring that each feature adds business value. I still consider this part of the “business case work” even though I am not producing a business case document. This might seem questionable, but we are consistently throwing out requests that would require a “mere” 3-5 days of developer time because the value of the request is simply not worth the effort.
Your distinction is a good one, as it helped surface my tendency to conflate the formal understanding of a specific document with the value I see that document generating within an organization.
Thank you.