A partnership between a Project Manager (PM) and a Business Analyst (BA) is key to a successful project. When the PMI® released their Guide to Business Analysis and the PMI-PBA® certification, it was based on a role delineation study that finally recognized the profession of Business Analysis as a separate and distinct skill set apart from Project Management. However, while this is true, there’s is still a lot that can overlap between these roles and there are many opportunities for collaboration. Read on to learn how PMs and BAs can work well together.
Project and Business Analysis Planning
In Agile environments, planning is very different; it’s iterative and ongoing throughout a project. Traditional Project Managers create formal project plans that include everything the project will entail. In Waterfall, the plan is developed upfront, and then the Project Manager works the plan.
Business Analysts also create a plan for how they will tackle business analysis tasks. BA planning includes decisions such as where to store documents, how to elicit requirements, the level of traceability, etc. The BA plan is usually an input to the Project Plan.
Regardless of the development approach, the PM and the BA should work together to align their plans. Suppose the Business Analyst decides to take an iterative approach to elicit, analyze, and document requirements, but the Project Manager says that the project will be waterfall. If this happens, you’re going to run into some problems.
By working together as a team (I like to refer to this relationship as a dynamic duo), the outcome will be comprehensive and include all the plans you intend to follow to deliver your project.
Stakeholder Identification and Analysis
As a Business Analyst, I usually start any new project by identifying and analyzing possible stakeholders. Well, guess what? Project Managers do the same thing, although their interest in doing this task might be different.
BAs want to understand who the stakeholders are, their interest in the project, how the people feel about the change, and what influence each person has on the project. We also want to know about the people to develop rapport with them when eliciting and validating requirements.
Project Managers are more interested in people’s politics and who is for or against a change. They manage those stakeholder relationships to use their influence to change people’s opinions if they are against a project that negatively impacts them.
Combining the stakeholder identification and analysis done by both the Project Manager and Business Analyst can provide a more holistic view of each stakeholder and help them manage stakeholder attitudes and expectations jointly.
Risk Identification and Management
I always say that everyone involved in a project plays a part in risk identification, but it’s usually the Project Manager who is directly responsible for actively managing risk. Risk management is an excellent opportunity for collaboration between a PM and a Business Analyst. The reason is that BAs are often way down in the weeds with stakeholders, compared to PMs, who look at the big picture and might miss the forest for the trees.
Project Managers should create the risk register, but anyone on the team can identify risks and bring them to the attention of the PM. Then it’s the BA’s responsibility to communicate the risks to the PM for mitigation. BAs are especially good at this because they are intimately involved with eliciting requirements, discovering risks during analysis. BAs can also help to rate the likelihood and impact of a threat.
The PM and BA should also work together on the mitigation plan. If it’s a positive risk that you want to happen, they should decide how to enhance the possibility of the risk occurring. If it’s a negative risk, they should collaborate to decide whether to accept the risk, mitigate it, or transfer it.
Scope Definition
Another area where PMs and BAs can work together is scope definition. Business Analysts excel at identifying what is essential in a project and what should be in and out of scope. BAs can create models that visually depict the scope, which is more appealing than a written scope statement.
Unfortunately, Business Analysts aren’t often brought in during the early stages of project definition. Scope statements tend to be very high-level and are generally vague. Project Managers typically don’t have the right skills to write a good statement (sorry, PMs). In contrast, BAs are excellent analysts and writers who are adept at capturing well-defined requirements, even if high-level.
Project Managers should bring BAs in as early as possible to help ensure that any scope definition is clear and concise, without ambiguity; this will prevent misunderstandings and unanticipated scope changes in the future.
Work Breakdown Structure
Who is responsible for a project’s work breakdown structure (WBS)? Well, it could be either a Project Manager or a Business Analyst, so I see this as another great activity on which they should collaborate. There’s no one right way to create a WBS, so they must work together to create a breakdown that works for everyone.
You can build the WBS in the form of a story map if you’re taking an Agile approach. Or it could be defined in a more hierarchical and traditional approach. Another option is an outline. The key is to make sure that whatever WBS is defined is workable and understandable.
After a WBS is created, depending on your project approach, you can manage it either in a spreadsheet or a requirements management tool, a traditional Microsoft project plan or as a visual story map on a wall. The PM is interested in ensuring that things are delivered, and the BA wants to ensure that the correct requirements are elicited, analyzed, and documented.
Project Schedule
The Project Manager is typically responsible for managing the project schedule, but a Business Analyst can provide valuable input. BAs have a lot of experience working with developers to understand how much time tasks take, the sequencing of the items, and any dependencies. A PM might not have that depth of understanding, and therefore their estimates are unlikely to be even close to accurate.
If operating in an Agile environment, the schedule almost becomes a moot point because the time and budget are fixed – instead, the scope is variable. However, if a customer wants additional work added, they need to trade off or provide extra money or time.
Solution Evaluation and Verification
Another area in which Project Managers and Business Analysts can join forces is in evaluating solution delivery. A Project Manager wants to know when tasks are done. A Business Analyst wants to know whether the solution satisfies the acceptance criteria and provides the intended business value.
Project Managers seek acceptance of deliverables, formal (or informal, depending on the environment and project plan). Gaining approval is a “check the box” activity for a PM to ensure that the customer has received the promised scope.
Business Analysts want to satisfy the customer’s expectations rather than just checking the box. If the project is Agile, reviewing an increment often leads to feedback that spawns new requests, which is perfectly acceptable. However, in a waterfall world, this will give the Project Manager heartburn, as they will need to find a way to reject or accept the change.
Final Thoughts
I’m always looking for ways to improve the partnership between PMs and BAs; I’m pretty sure there are many other ways that Project Managers and Business Analysts can collaborate, and these were the ones that jumped into my brain when I started writing. If I missed anything significant that you have experienced, I would love to hear more about it in the comments below.