Project Phase for Business Analyst

This article is focused on enabling better performance in business analysts and aspiring business analyst professionals. In this case, I think knowing the basics of project phases can be useful reading. Basically I hope to touch on different aspects of technology projects that achieve specific business outcomes in which business analysts play an important role.

Why choose a technology project phase for business analyst discussion?

Our world today is governed by technology. From the moment we wake up in the morning to the moment we sleep at night, we are ruled by technology. The role of the business analyst is in a better way appreciated when there is technology involved. As mentioned earlier in my post, anywhere in the world, combining people, processes and technology will result in problems.

If there is a business analyst, who works exclusively on processes without any impact on technology or without involving any aspect of technology, I would like to meet him. So coming to our topic – let’s try to understand from the point of view of business analysts and consulting in a simple way the different phases of a functional business project involving technology.

Note – Please note that I refrain from getting into the Software Development Lifecycle (SDLC) or Agile. I’d like to keep the context of this post brief and non-specific to a particular project management style although what I stated would align with most methodologies.

Is a business analyst actively involved in the sub-phases of the project?
Business projects involving technology are often divided into 2 major phases in the consulting world. The first stage is called Scoping and the second stage is called Delivery. These two phases contain several sub-phases in which a business analyst plays an important role. We will look at them in detail.

Sub-phase Scope of the consulting project phase is usually divided into Scope Definition, Functional Analysis and Design.

Sub-stages of the Delivery effort in the consulting assignment include the Technical Design, Construction/Build Stage, Test which includes System Integration Testing (SIT) and User Acceptance Testing.

Scope definition – From my experience, I often write a project scope definition before a business analyst is assigned to the project. In some cases, the business analyst may get lucky and may fall within the definition of the project scope. But usually in this phase a project/functional manager, program manager and subject matter expert play a major role. In some cases, this phase is also called a blueprint.

In certain cases, the scope phase includes the requirements gathering process, while in some cases, this phase is pushed to the project analysis phase.

Analysis Phase – Again, while the term Analysis strictly refers to analyzing the collected business requirements, more often than not, the requirements gathering process begins in this phase. The project analysis phase actively involves business analysts interacting with stakeholders and gathering business requirements and analyzing requirements to better understand which requirements fit into the defined scope area and which do not.

It is a big challenge that in some cases business requirements often exceed the scope of a particular project and may need to be identified by business analysts and De-scoped. On the other hand, in some cases, the scope is getting wider and many business requirements are not documented. The analysis phase is definitely an area where a business analyst plays an important role.

Functional Design – In the consulting world, the design phase is divided into functional design and technical design. Functional design is the phase where the design elements relate to the data flow, mapping the requirements to the data flow, the functional requirements that can be met through the design, etc. will be documented.

Technical Design – A technical design as the name suggests is a design document that provides the technology that defines the system that will specifically be used to meet the functional business requirements documented by the business analyst. Whereas functional design documents detail the functions that will be fulfilled as part of the design implementation, technical design refers to the technology used, type of server to be used (Windows vs Linux), type of database to be used, etc. .

Often in organizations, these two documents are combined into one design document. The usefulness of a comprehensive design document depends entirely on the methodology followed by the organization. In some cases, where the business analyst is more functional, parts of a comprehensive design document can be challenging to understand.

A business analyst in the design phase plays the role of a solutions expert. The business analyst is required to validate that the design document and the proposed solution meet the project objectives and the specific business requirements that have been taken.

Build/Construct – While in a strict sense the role of a functional business analyst would be limited to requirements planning, requirements gathering and documentation until it is handed over to the IT team, organizations today are taking a holistic view of the business analyst function. A business analyst may not play a very active role in the construction phase of a project. That certainly doesn’t mean that a business analyst moves on to another project at this stage or has a relaxing time. While the IT team is working on the construction phase of the project, a business analyst may be asked to work on Test preparation support together with the project manager.

In addition to potentially supporting change management results, business analysts may be needed to help drive reviews of test strategies, test plans, test scenarios, cases, and scripts.

The CBAP handbook specifically mentions that creating design documents, test strategies, test plans, or executing test cases is not considered relevant work experience for CBAP certification. I’m sure most of us would agree that despite our likes and dislikes and what the handbook says, for all practical reasons, a business analyst usually catches this result.

In my opinion, getting our hands dirty on this post is good because you are no longer limiting yourself to a role as a business analyst but stepping into a management consultant.

Test Phase – I don’t want to break it down to you, but further testing is divided into sub components.

A business analyst will know that system integration tests are more often the key to solving most problems and issues in technology projects. While in the build phase, the IT team will ensure that they perform selected core tests on what they build, more often the role of a business analyst to support integration testing. System integration testing involves passing data through source systems and downstream systems to frequently test interfaces/data flows between systems via predefined test cases/scenarios that have specific test results.

User Acceptance Test (UAT) successfully tested the system integration. In this phase, testing is carried out from the perspective of the end user/customer. It is hoped that this system integration test raises some issues and bugs that need to be resolved before entering UAT. During UAT, end users or customers are given the flexibility to help select the business scenarios they want to test. Expected results (which should match user expectations) are often shared with users to increase their confidence and get out of the testing phase.

Testing is always done in a server environment outside of a real-time production environment. So if you’re in a meeting and hear people discussing the test environment, don’t get confused. It’s just a server environment that often replicates a production environment but lets you make mistakes and fix them.

Implementation / Go Live – The implementation phase of a project is when code and solutions tried and tested through other phases of the project are moved to the production environment. Once the code is moved to production and the system is ready to go live, at the push of a button, the changes are posted to production and live for reflection.

As you will notice, the role of a business analyst is more often exemplified in the early stages of a project. During the early stages of a project, there is a greater need for business analysts to interact with stakeholders, collect requirements, document them, analyze requirements, etc. As such, BA becomes a bridge between business stakeholders and the IT team which makes it a very important role. At the same time, it is also important for BAs to understand the impact of their role and their work in other areas of the project.

For all BA aspirants, I hope this article, although lengthy, gave you a good insight into what’s going on outside of your role. Hope you like it. Feel free to share your comments.