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 are the two sides of the same coin. Their skills and joined efforts make a project successful and deliver good value to the business. I would like to demonstrate how a PM and a BA could 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 lifecycle. 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.
PM-BA: Collaboration Model
The PM engages the BA to help with project scoping and definition of the business need, expected project outcome (deliverables) and 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, the BA works closely with the project stakeholders on clarifying the business need, specifying high level business requirements, conducting stakeholder analysis, identifying risks, assumptions and constraints, as well as tolerances to a solution. The BA determines solution scope, high level requirements, solution approach, 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: 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, 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 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 that the solution can be assembled in a way that enables cost efficiency and adherence to project time and resource constraints.
This phase flags even more close collaboration between PM and BA. They work together in requirements workshops to prioritise 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.
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 communication 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.
Having the project deliverables accepted by the business, the PM works on closing the project. The BA facilitates the 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.
From observing over the years how different PMs tackle their projects, I would like to highlight some things that can trigger a blaming attitude.
A bossy attitude to 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 for blame for not delivering on time and under budget.
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 make projects successful, the BA and PM should work in tandem pushing towards the finish line.
Shared responsibilities, mutual respect and support combined with collaborative attitude pave a way to project success.
Don't forget to leave your comments below.