Skip to main content

Author: billy morton

PM and BA: In Tandem for Success

I’ve been working in project management and business analysis domains for many years. The projects I’ve been engaged in cover regulatory compliance, business process improvements, software development, ERP implementation and ITIL adherence just to name a few.

Heated discussions about relationships between a project manager (PM) and a business analyst (BA) are often focused on their non-aligning sides rather than on their mutual efforts to ensure project success.

I tend to think about PMs and BAs working together in projects as two hands carrying a baby. Here is my view on the PM-BA tandem and how it comes together to make a project successful.

How It Works

I’ve been involved in multiple projects for the last two decades. The projects were of different scales and nature. However, there is one common element in all of them: a project manager and a business analyst were the two sides of the same coin. Their skills and joined efforts made a project successful and delivered good value to the business. I would like to demonstrate how a PM and a BA can work on a project, and explore each project phase in more detail. Please note that project phases and the documentation involved follow PRINCE2®.

Project Start Up

PM and BA work with project stakeholders throughout the entire project life cycle. Before the project starts, a PM deals with business stakeholders to identify the business need at a high level. The outcome of this interaction is a project initiation document. This document outlines the business need, the impact of the current state on the business, the desired target state, project complexity, estimated project duration and expected benefits.

 

 INSERT GRAPH HERE. 

 

 

 

 

 

 

 

PM-BA: Collaboration Model

Project Initiation

The PM engages the BA to help with project scoping and defining the business need, the expected project outcome (deliverables) and the project acceptance criteria.

While the PM works on drafting a project plan, the BA develops a BA plan outlining BA deliverables, communication patterns with stakeholders, requirements management approach and estimation of effort. The BA agrees the BA plan and requirements management plan with the PM.

Once the plans are agreed upon, the BA works closely with the project stakeholders to clarify the business need, specifying high level business requirements, conducting stakeholder analysis, identifying risks, assumptions and constraints, and tolerances to a solution. The BA determines solution scope, high-level requirements, solution approach, and reusable and new components to be used in the final solution. The BA works closely with the PM to align solution scope with project scope. The BA informs the PM about all identified and potential risks.

The PM maintains the risk register and develops mitigation strategies for the identified risks.

The joined efforts result in two key documents: the project vision and solution vision. The former contains the problem statement, desired outcome statement, acceptance criteria for deliverables, stakeholder analysis, business context, assumptions, constraints and scoping definitions (in scope/out of scope).

The latter describes the problem statement, solution statement, provides a solution overview, stakeholder summary (RASCI), determines “to be” capabilities and business context, and defines what is in and what is out of solution scope.

These two documents support the business case document in medium and large projects, supporting the project sponsor’s decision making on whether to go ahead with the project.

The PM and BA work jointly on developing a WBS to ensure the solution can be assembled in a way that is cost efficient and adheres to the project timeline and resource constraints.

Project Execution

This phase requires even more close collaboration between PM and BA. They work together in requirements workshops to prioritize and validate requirements. They conduct workshops with vendors of components to the solution (where applicable).

Changes to solution scope lead to changes in project scope so the PM applies change management process to ensure that only justified changes will be accepted. The PM maintains the change request register throughout the project.

The BA’s reporting on progress in turn supports the PM’s reporting on project progress to the project sponsor and other interested parties.

The PM supports the BA in communicating with solution architects, software developers and other engaged third parties with regards to solution validation activities. The same is true when it comes to user acceptance testing. The PM’s support is invaluable here. The duo works hard to ensure that solution acceptance criteria will be met within the predefined tolerances. The BA facilitates solution implementation to ensure a smooth transition to the “business as usual” mode.

Project Closure

With the project deliverables accepted by the business, the PM works on closing the project. The BA facilitates project closure by providing feedback for the post-implementation review. The BA reports on how well the solution met the business requirements. They jointly work on the lessons learned log to ensure that all valuable information has been captured for further use in future projects.

The BA hands over artifacts such as business requirements, functional requirements, use cases, non-functional requirements and solution technical specification to the business. These artifacts form a basis for business documentation on how to use the solution.

When the project has been formally closed, the BA files all approved BA artifacts in a central repository.

Pain Point

From observing how different PMs tackle their projects over the years, I would like to highlight some things that can trigger a blaming attitude.

A bossy attitude towards a BA, a lack of understanding of the business domain, skipping important project background where the rotation of PMs takes place, “managing” customer expectations without involving the BA, expectations of having the final solution requirements identified by the BA after a single requirements elicitation iteration with project stakeholders—all these elements create a foundation of blame for not delivering on time and under budget.

Conclusion

The complexity of modern projects has increased to a great degree. Changes to business processes are coupled with changes to business applications, IT infrastructure, and interfaces with the company’s environment. The PMs and BAs are required to be more productive in projects of different nature. My experience gained from over 35 projects confirms that to deal with the changing demands and to make projects successful, the BA and PM should work in tandem pushing towards the finish line.

Shared responsibilities, mutual respect and support combined with a collaborative attitude pave the way to project success.