Have you ever wondered how a business analyst approaches a software project? Would you be interested in the general phases of work a business analyst completes and what activities are included in each phase?
Well, you’ll find plenty of answers out there about the one “right” way to do business analysis, but that’s never been the message here at Bridging the Gap. Here we know and believe that there are many right ways to do business analysis and what’s right for one project, one stakeholder group, and one organization may be completely wrong for another.
When you think about it, that makes sense, right?
Yet this doesn’t give you much to go on if you are a new business analyst on your first project or an aspiring business analyst beginning to look at what you’ve done using the filter of business analysis.
So let’s dig into this a little deeper and talk about how a business analyst approaches a software project.
When figuring out my approach to a project, I break my work up into three phases that I find to be particularly useful buckets in which to think about business analysis.
Here they are the three phases:
- Initiate the project,
- Elaborate the details, and
- Support the implementation.
In what follows, we’ll look at each phase in more detail, look at examples of what techniques and specifications you’d create in each phase, and define what it means to be done with each phase.
Initiate the Software Project
Initiating the project involves identifying the problem to be solved and establishing enough about what the solution looks like that a definitive go/no-go decision can be made about whether to fund the project.
This is the time that we bring together the stakeholders and kick off the project and ensure that we have all the information that we need to make an informed decision about the project direction. If you are working in a new business domain this phase would include understanding the key terminology, which is often captured in a glossary or domain model, as well as the organization’s current capabilities.
The deliverable from this phase of work is often a Scope Document (or vision document or business requirements document). And a Requirements Development Plan can prove very useful as well. And if the current business process is unknown, you might do some business process analysis as part of initiating the project too.
In my early days as a business analyst, this phase included a 50+-page functional requirements document. Over time, I realized that there was so much redundancy between the functional requirements document and a body of use cases that formed implementable functional requirements (we’re getting to that next), that I cut this document back significantly and save loads of time. I essentially replaced the list of detailed functional requirements with a high-level list of features (that’s what you’ll find in our Business Analyst Template Toolkit) and have never looked back.
Once you’ve got the go-ahead to move forward with the project, it’s time to elaborate the details. Let’s talk about this next.
Elaborate the Details of the Software Project
Elaborating the details is really the meat of the business analyst role, and it’s probably the piece that you think of most when you think about business analysis. This is where we get into analyzing the requirements and ensure the implementation team has all of the details they need to build or implement the solution. Often this phase involves working with multiple stakeholders across the organization to ensure their knowledge and needs are incorporated into the detailed decisions about what will actually get built.
In a more traditional or waterfall environment, this phase is combined with initiating the project and that means the decision of whether or not to fund the project may not be made until all of the functional requirements are detailed out. In my experience, that tends to be a bit late in the game, after a lot of stakeholder time and trust is absorbed into the project by then, not to imagine weeks or months of analysis time. More often than not, the cost estimates you can get from a high-level features list are more than adequate to support high-level scoping.
This is part of the reason I stopped doing functional specifications up front, streamlined my scope document template, and replaced the functional specification with a set of use cases and wireframes. (On an agile project, I’ll replace the use case list with a product backlog and the set of use cases with user stories.) Depending on the project, you may need a data specification or model as well.
Regardless of how you choose to specify it, this phase is complete when your stakeholders have signed off on what will be implemented and your developers have what they need to design and implement the software solution. In many organizations today, this part of the project is approached in an iterative fashion. That means that the BA prepares the functional specifications in phases, which are approved by the business and then designed and implemented by the software development team. Use cases and user stories are much more naturally suited to this iterative approach than a single functional specification.
As a certain set of requirements is ready for development to start, the business analyst role typically shifts from an active one to a reactive one.
Support the Implementation of the Software Project
Supporting implementation is when BAs are involved through the end of the life cycle. BAs are not typically involved directly in implementation unless they’re holding additional roles on the project. But they are typically brought in if issues come up during implementation that cause some new requirements to be addressed. This could involve facilitating a problem-solving meeting to discover how a particular business need can be met given newly discovered technology constraints.
For example, when redesigning this very website, we had made an assumption about how the author profiles would work. Then we discovered that WordPress no longer supported the functionality we needed. We revisited the author profile page and came up with a simple and elegant solution.
As the implementation is completed, sometimes business analysts do have a more active role. You might be asked to help the business accept the solution that’s being implemented. This can take the form of “to be” business process models that analyze how the business stakeholders will use the new solution to complete specific tasks and activities. It can also include training, user documentation, or user acceptance testing.
It’s becoming increasingly common for the business analyst to continue to be involved in the project through this stage, and this phase is complete when the software is released to a production environment and the business stakeholders are able to use it successfully to do their jobs.
Of course, during the process of implementing the solution, new needs and requirements may be discovered, and the business analyst might pick up new projects to initiate…and the cycle continues.
Find Your Approach
These phases are useful because they give you a simple framework to look at what stage of analysis you are in and decide what milestone you need to move your project team towards next. You can start analysis at any phase and sometimes you’ll find yourself moving backward and forward or cycling through the phases.
When in doubt about what step to take or what deliverable to create or what technique to use (no matter how experienced you get as a BA, you have these doubts), identify the phase you are in and determine what next step will move you closest to completing the phase.
Interested in Learning More?
Click here to read about the Requirements Specifications a Business Analyst Creates