This paper will present the working relationship of the roles between a project manager and a business analyst (BA) based upon A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (Project Management Institute, 2013) and the Business Analysis for Practitioners: A Practice Guide (Project Management Institute, 2015), which provides supporting information to PMI's foundational standards. The PMBOK® Guide provides project managers with the fundamental practices needed to achieve organizational results and excellence in the practice of project management and addresses the stakeholder's needs, concerns, and expectations; balances competing project constraints; and applies applicable processes and resources. The Business Analysis for Practitioners: A Practice Guide provides guidance on how to apply effective business analysis practice and includes a collection of techniques and practices, describing how these techniques can be used.
PMBOK® Guide – Fifth Edition
The PMBOK® Guide is recognized as a global standard for the project management profession. It has always provided good practices for project managers.
Starting with the fourth edition, and then expanded in the fifth edition, additional tasks and references to business analysis (BA) work were introduced. These were mainly in the Project Scope Management Knowledge Area, as that is where the emphasis on requirements fits the best in the current project management framework. Even the term “elicit” comes from the BA community, and is used, rather than the previous references to “gathering” requirements.
Project Management versus Business Requirements
The objective of project management is to get authorization to initiate the project, plan the project in detail, monitor and control it, and then celebrate the success and closing of the project. Business analysis is mostly concerned with identifying problems and business needs; eliciting, documenting, and managing stakeholder requirements; recommending viable solutions; and implementing the solution into the business.
By definition, a project is a temporary endeavor that produces a unique result, service, or product and requirements for those results, services, or products are the conditions, features, or capabilities that must be included. The project, and the agreed upon requirements, must be able to satisfy stakeholder expectations as to what is needed for the final result, service, or product that will be delivered. The scope of the project is based on the specified features and functions, or various types of requirements, which have been approved.
The project manager is assigned by the performing organization, through the project charter, to lead the team that is assembled to achieve the project objectives and results. Thus, the project manager becomes the link between the organizational strategy and the team engaged to deliver the results. In that role, the project manager must oversee what is required to deliver a timely and accurate completion, in addition to satisfying the needs of the team as a whole, as well as the individual members of the team, often including a business analyst.
As a discipline, business analysis is not as clearly defined. It has been around in some form for many years and with many “titles” associated with the role. Even today, there is little consensus on the role of a business analyst, as can be seen by job postings for this position. It can range from a business analyst who is a business person, imbedded in the business organization, and involved with the strategic and tactical business function. Another business analyst role might involve a more analytical, and often technical person, responsible for generating reports and graphs based on data analytics. The third role is more of an analytical person who is part of a project effort and is able to discover, understand, and communicate the business requirements to satisfy the project result. In the agile world, a product owner who provides and verifies that the requirements needed have been understood and delivered may provide this role. Since we are concerned with the BA in conjunction with the project manager as part of a project effort, we will be referring to this last role of a BA in this paper.
The BA needs to be able to understand the business problems, opportunities, and needs and should be able to identify and recommend viable solutions. This may be done through the elicitation, documentation, and management of the requirements that have been identified by the stakeholders. Their role is to make sure that those needs are implemented in the final project solution or result.
PMI has developed an initial practice guide for business analysts and has included it as part of PMI's foundational standards. This guide provides guidance on how to apply effective business analysis practices as part of a project or program effort. Just as with the PMBOK® Guide, the Business Analysis for Practitioners: A Practice Guide is a collection of techniques and practices. These techniques and practices are not based on any specific “vendor” tools, but rather on generic practices that the BA determines are appropriate to the given situation.
There are a few terms that we will use in very specific ways. We will examine how these terms apply to the role of either the project manager or the business analyst.
- As mentioned earlier, a project is a temporary endeavor that produces a unique result, service or product.
- A requirement is a condition or capability that is required to be present in the project result, service, or product.
- A product is the “quantifiable” artifact that is produced as a result of the project and can be either an end-item in itself or a component of an item.
Project Management Process Groups
In order to put the two roles and their relationships in perspective, we will look at these from the Process Groups as identified in the PMBOK® Guide.
When we look at the Initiating Process Group, we are mainly interested in why the project is being done and who will be involved in the effort. The Planning Process Group identifies what will be included, and when and how project activities will be done. During the Executing Process Group, the actual project work is being performed, while concurrently, the Monitoring and Controlling Process Group is checking on the progress and the result. Of course, we must not forget the Closing Process Group, when we not only wrap up the dreaded paperwork, but we also take time to celebrate our accomplishments.
Initiating Process Group
The initiating of a project is the official start of the project. There are two processes identified in the PMBOK® Guide: Develop the Project Charter (Exhibit 1, PMBOK® Guide Figure 4-2) and Identify Stakeholders. Even though this is where the project manager is officially authorized to begin the project, the business analyst has often been working on this project before it actually was formally declared a project.
It is often the business analyst that has prepared the business case that is a key input to prepare the project charter. This business case often specifies the results of extensive needs assessment, which may have been used to help select this project as part of a portfolio management effort. The business case identifies the initial scope, organizational needs, and business strategic objectives, as well as possibly including the results of cost/benefit analysis using various benefit measurement methods (e.g., ROI, NPV, IRR).
Exhibit 1. PMBOK® Guide, Figure 4-2.
In the Identify Stakeholders Process (Exhibit 2, PMBOK® Guide Figure 13-2), the business analyst and project manager work together to identify the people, groups, or organizations that may be impacted by, or could actually impact the result of the project. This includes seeking out the specific stakeholders with knowledge of business, as well as those who can make decisions. In addition to identifying those people, this process also analyzes and documents additional information to further understand how and why those stakeholders might have an impact on the project. Even though the project charter is only developed and written once for any project, this process of identifying stakeholders is done every time new stakeholders are discovered or introduced into the project. This especially happens each time a contract is finalized.
The result of the analysis of the stakeholders should be documented in the stakeholder register. The project manager often will show the results of this analysis through the use of matrices such as the Power/Interest, Power/Influence, or Influence/Impact grid. A salience model is often used to show the power, urgency, and legitimacy of each stakeholder.
The business analyst is going to take this analysis of stakeholders further and specifically determine which stakeholders have in-depth knowledge of various areas in the business, as well as those who are authorized to make decisions. To the business analyst, these stakeholders become the subject matter experts (or SMEs) that are key resources on the project. As a result, the business analyst often extends the information on the stakeholder register to include additional stakeholder categories. This information will also often be used to develop a stakeholder/requirement RACI, as the project requirements are identified.
Exhibit 2: PMBOK® Guide, Figure 13-2.
Planning Process Group
Alice: Which road do I take?
Cheshire cat: Where do you want to go?
Alice: I don't know
Cheshire cat: Then it doesn't matter
- Lewis Carroll from Alice in Wonderland
The basic premise of this quote is that the planning does matter to a great degree. The purpose of planning is to determine what and when activities are to be done, clarify assumptions and constraints, and determine how the project will be done. In other words, identifying where are we going—because it does matter.
Of the ten Knowledge Areas, the project manager and the business analyst do three of them jointly: Scope, Quality, and Risk.
Plan Scope Management
Plan Scope Management Process (PMBOK® Guide, Figure 5-2) provides guidance and direction as to how the project scope will be managed throughout the project. It describes how the project scope will be defined, developed, monitored, controlled, and verified, which helps reduce the risk of dreaded scope creep. The project manager is mostly responsible for the development of the scope management plan.
As you see in Exhibit 3, from the PMBOK® Guide's Figure 5-2, there is a second output, namely the requirements management plan, also known as the business analysis plan in the Business Analysis for Practitioners – A Practice Guide. This plan, which is the one that is of the most interest to the business analyst, identifies the requirements planning activities that are needed to create, track, and report the business requirements to be included in the final result, product, or service. This is often done through the use of a traceability matrix, and even though it is not shown on this process, the structure and content of that matrix is determined and included in the requirements management plan. The various roles and responsibilities, especially of the SMEs (and often shown by the stakeholder/requirements RACI) are identified in this plan. How the various requirements will be prioritized and the acceptance process that will be used would also be included.
Exhibit 3: PMBOK® Guide, Figure 5-2.
Collect Requirements
The Collect Requirements Process (Exhibit 4, PMBOK® Guide Figure 5-4) has been included since the fourth edition and involves the stakeholders actively participating in identifying what should be included as part of the project. This is an activity where the business analyst normally takes the lead. There are many tools and techniques that are very familiar to a business analyst to help identify the initial requirements and the documentation that is necessary to make sure that they are well understood as the project progresses.
Exhibit 4: PMBOK® Guide, Figure 5-4.
The first output of this Process is the requirements documentation itself. The initial requirements actually were identified at a very high level and included in the project charter as a business need. These requirements are usually categorized into various types, including business requirements, stakeholder requirements, and project solution requirements, all of which refer to the requirements needing to be present in the final result, product, or service, or product requirements.
Another type of requirement that is more specific to project management is the project requirements, usually identified by organizational policies and procedures, and may specify deliverables as well as other project management activities that must be included in the project. In addition to identifying the requirements, additional assumptions, dependencies, and constraints are added to those that were initially identified as part of the project charter.
As this process is performed, those high-level requirements become progressively more detailed and are then able to be prioritized. These combined requirements describe what needs to be included in the project and why. Because there are often more requirements identified than can be possibly included within the project constraints, these requirements are prioritized to best satisfy the business need. The requirements traceability matrix is used to link and track requirements to deliverables and ensures that requirements are developed and delivered as specified.
Define Scope
In the Define Scope Process (Exhibit 5, PMBOK® Guide Figure 5-7), the detailed description about the project and the product components that will be part of this effort are defined. The inputs include the scope management plan, which helps determine how the scope will be managed, as well the final set of requirements that have been selected along with a detailed description for each of these. The final scope also should identify what has been included, as well as what is excluded from the final scope of the project. The initial risks, assumptions, and constraints may have been included in the project charter, but as more detail analysis is done, additional items will be added and continuously updated throughout the project.
In most cases today, because of our desire to deliver in a shorter time frame, the scope is done in a more iterative manner. The individual requirements for the current iteration may be identified in detail, whereas the detail may be delayed until a later point in time for other requirements.
Just as a reminder, the project scope statement has two components. The project scope, or what we have to do to accomplish the result, which is key for the project manager, as well as the product scope, which identifies those features and functions that must be present in the final result, and that portion that the business analyst will be tracking. The project scope will be measured against the project management plan, whereas the product scope will measure the actual delivered results against the requirements that were specified.
Exhibit 5: PMBOK® Guide, Figure 5-7.
Create Work Breakdown Structure (WBS)
The process of creating the work breakdown structure (WBS, as shown in Exhibit 6) has been, at times, confusing as the definition refers to a “deliverable-oriented, hierarchical decomposition” of the project work. Taking this definition literally, it would refer to the “project scope” and the deliverables and work packages required to complete the work. This specifically refers to those items that the project manager must track and monitor to ensure that everything is completed.
There is a second WBS that has been part of manufacturing, engineering, construction, and software development for years that refers to how the final product and its various components are decomposed and related. For the business analyst, this structure depicts the way that the various “product” requirements are related. In the PMBOK® Guide – Fifth Edition, examples of both types of WBS are shown on pages 129 and 130.
The main output is the scope baseline, which consists of three documents; the scope statement (including both project and product requirements), the WBS(s), and the WBS dictionary. These are reviewed and upon approval, the scope baseline is created. Once that baseline has been approved, changes can only be made through a change control procedure. The scope baseline will be used to continually compare the actual results and work being done on the project to the original, approved scope.
Exhibit 6: PMBOK® Guide, Figure 5-9.
The requirements identified in the scope baseline mean different things to a project manager and a BA. To a project manager, this is what needs to be accomplished. To the BA, it is only a beginning. It identifies the requirements that need to be included in the final result, product, or service, but there is a lot more work to be done to fully define what is required to make sure that the initial requirement can be and will be delivered to the satisfaction of the stakeholders. This is where the BA will continue to “drill down” the accepted requirements as part of the Executing Process Group.
Project Schedule Planning Processes
The next series of processes regarding the schedule for the project is the main responsibility of the project manager. Lead project team members, as well as the BA involvement are often limited to clarification of the requirements activities and related costs.
The main difference that occurs when a business analyst is involved in the project is that, in addition to the core team members, the SMEs also become key members of the team. In the past, the SMEs were included at the beginning of the project so that their requirements could be understood and captured. They then went back to their “day job” and were only seen when it was time to test the final solution.
Today, that expectation of engagement has changed and SMEs are often involved, not only in the identification of the requirements, but also in the review of requirements documentation and interim results, as well as being key players in the final acceptance of each requirement.
Because of this increased involvement, those time commitments must be clearly planned, communicated, and included as part of the project schedule. This work is typically completed by the BA and closely coordinated with the project manager.
Risk Management Planning Processes
Because risks are the result of uncertainty, organizations may have their own risk appetite and the approach to the amount of risk they are willing to accept is best understood by the BA, along with the SMEs. Some organizations have overall positions toward risk that often determines how they perform in the marketplace. Those that are risk seeking are willing to try new ideas, and often are on the bleeding edge of technology. Others are averse to taking risks and are willing to wait until an idea has been fully tested before embracing it. The majority of organizations take a more neutral position toward risks, in general, leaving the risk position to be determined by the managers of individual functions.
Both organizations and stakeholders may be influenced by a number of factors including their risk appetite, tolerance, and threshold.
Based on this understanding of the organization, the project manager and BA work closely to help identify project risks, qualify and quantify those identified risks, and determine the most appropriate response for the risks.
Quality Management Planning Processes
The Project Quality Management Knowledge Area is concerned with the quality delivery of both the product and project deliverables, as well as the execution of the processes required to produce those deliverables. This area, more than most of the others, will rely on any organizational policies, procedures, and resources that are already in place. These quality resources often become an integral part of the extended project team.
The BA leads in the development of the product specifications and should be responsible to assure that the delivered product meets the quality specifications through the verification process. The BA is key to ensuring that the appropriate stakeholders accept the various components/requirements product through the Validate Scope Process.
Executing Process Group
In the Executing Process Group, mainly the project team members accomplish the work defined in the project plan. The project manager does have a few specific processes that pertain to the acquisition, development, and management of the team, as well as various communication activities.
The Requirements Elaboration Process is not a project management process but rather a BA process. During this time, the BA more fully elaborates and documents the accepted requirements. This often includes additional discovery and elicitation sessions with the involvement of cross-functional stakeholders to help further analyze the requirements, using many of the same tools and techniques that were identified in the Collect Requirements Process in the Planning Process Group.
The main purpose of requirement analysis is for the BA to focus on what has to be done, not how it is to be done. The BA may use various types of models in the elicitation process to communicate with stakeholders and team members. The models can be in form of a picture or text such as: scope models, function models, process models, rule models, data models, and interface models.
These more-detailed requirements are analyzed and grouped into various categories including: solution (functional and non-functional), stakeholder, interface, transition, project, and quality.
During this process, the requirements are continually being verified by the SMEs with the BA to make sure that they have captured the true requirement before creating the final documentation that will be used to produce the items identified in the product scope.
If the final acceptance criteria had not been defined for the requirements as part of the scope statement, that criteria would be identified here. This includes measurable outcomes that become the basis of the testing as the results are developed.
Monitoring and Controlling Process Group
Controlling the project scope is a key part of project management, and the area most often thought of when controlling a project. The project manager is primarily concerned with controlling the scope baseline, and the BA is primarily concerned with the baseline of the requirements (product scope, not project scope) that were specified in the scope baseline, requirements documentation, and the requirements traceability matrix.
In the Monitoring and Controlling Process Group, the main objective of the project manager and the BA is to control the project and product scope that was agreed upon in the scope baseline. In addition to the Control Scope Process in the PMBOK® Guide, the Business Analysis for Practitioners: A Practice Guide has an additional Control Requirements process.
Exhibit 7: PMBOK® Guide, Figure 5-16.
In the Control Scope Process (Exhibit 7), the project manager uses the requirements documentation and the requirements traceability matrix, along with the work performance data and project management plan to perform variance analysis, determining if changes to the scope have occurred.
The BA is not only monitoring the documentation and baseline for the product requirements, but also making sure that no changes are made without proper approval. The usage and updating of the traceability matrix is the key tool used by the BA to determine the status of each product requirement as it progresses to completion.
Control Quality
The process of the controlling quality (Exhibit 8, PMBOK® Guide Figure 8-11) is concerned with the inspection, measurement, and testing of the deliverables to make sure that they conform to the specified quality standards. This includes both project and product deliverables, and is done continually throughout the project, and not just at the end.
The project manager is making sure that the development and testing of the product are being done and the project remains on track. The approach to be used for this testing should have been defined as part of the requirements management plan. This would also specify the criteria to be used for testing and verification, as well as potential methods and resources to be utilized.
Exhibit 8: PMBOK® Guide, Figure 8-11.
Evaluate Solution
It is the responsibility of the BA to assist in overseeing that a quality product, service, or result is produced from the project effort during development and testing. During the evaluation of the solution, as included in the Business Analysis for Practitioners: A Practice Guide, the BA will conduct various reviews, walkthroughs using models, or simulations and/or demonstrations to verify the results that all requirements were met. This is all part of the effort to obtain verified deliverables that meet the approved specifications.
The results of this effort will either produce accepted or rejected deliverables. For those items that were rejected, there is often a change request submitted to correct the problem causing the negative response. Any needed updates to the requirements documentation would also be made at this time.
Once the various requirements have been verified, they are now ready to be accepted by the stakeholders as part of the validation process.
Validate Scope/Solution
The process of validating the project and product scope (as shown in Exhibit 9) includes the activities that are required to accept the various deliverables, using the acceptance criteria specified in the scope statement. Validating or accepting each deliverable using these objective methods increases the chance that the final result, product or service is accepted. Often, this incremental method of acceptance is started as early as possible to understand the potential concerns that stakeholders may have and, therefore, make small adjustments to ensure that the final result will meet their approval.
In an agile or incremental project, a more informal validation is often done with a demonstration of a small working component, known as a “minimally marketable feature,” being able to facilitate the acceptance of individual requirements, or portions of a requirement, on a more frequent basis. Through this periodic validation, not only are the SMEs or stakeholders more continually involved in the project effort, but also the project is able to show actual progress toward the completion of the final result.
Exhibit 9: PMBOK® Guide, Figure 5-14.
In order to validate these individual deliverables, the WBS and work packages, which defined the deliverable, as well as the associated requirements and other attributes from the scope statement, the project manager uses them to ensure that the results meet the specified requirements.
During the validation of the project scope and solution, the BA will work with the stakeholders to facilitate the acceptance of the deliverables. Those that are rejected may require additional work to comply with the requirements. It is often the BA who assists the stakeholders in submitting any required change requests.
Closing Process Group
In the Closing Process Group, the project manager is primarily concerned with the activities of capturing lessons learned, archiving all relevant project documents, performing the team members’ assessment, and releasing project resources—as well as taking time to celebrate the successful completion of the project.
The next phase of the BA's involvement in the solution begins.
There are usually transition activities that require the guidance of the BA to make sure that the new result is successfully implemented in the business as it moves from a project result to part of the operational activities. This often includes additional training requirements, as well as minor “fixes” that may be found as the new product is used and the solution evaluated.
If this is part of an incremental project effort, the product roadmap is updated to show this part as completed—and time to move on to the next phase or release.
Since the selection of the project was based on some pre-determined measurements, the BA now becomes involved with the measurement of the ongoing project result, monitoring the status of what was delivered, perhaps any service level agreements, additional training, unexpected problems or failures, and making adjustments.
Skillsets of the Project Manager and BA
The skillsets of the two roles are very similar, but do contain a few differences.
The project manager skillset includes the knowledge of project management, the application of that knowledge to achieve desired performance, and the appropriate application of soft skills to team members and stakeholders.
The BA skillsets include the knowledge of business and industry experience, cultural and political awareness, performance analytical skills, creative, critical, and systems thinking, facilitation, and presentation techniques, decision making and problem solving, influencing, negotiation, leadership, communication, conflict and issue management, and the ability to work effectively in a team environment.
This last skillset is the critical one to ensure that a BA and project manager are able to work together to deliver the most successful result to the stakeholders through their combined skills and efforts.
PMI offers a new certification for any role performing business analysis to individuals who are involved in projects or programs. If anyone is interested in achieving the PMI Professional in Business Analysis (PMI-PBA)® certification, please review the requiements (Exhibit 10) and go to the PMI website: https://www.pmi.org/certification/business-analysis-pba.aspx to submit an application and to schedule a certification exam.
Exhibit 10: Requirements for PMI-PBA® certification.
Conclusion
We hope that this white paper has enabled you to understand the working relationships between a project manager and a business analyst and the increased value that can be realized as part of your project by the two roles working together.
