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.
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.
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.
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.
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.
Don't forget to leave your comments below.
Sergey Korban has been in the IT industry for over 25 years and has hands on experience in business analysis, project management and software development management. He is passionate about making businesses more effective. You can find more of his articles on the Aotea Studios blog