Project management and business analysis

Abstract

Project management and business analysis are in fact two disciplines that are becoming more and more strategic for many companies. Project management focuses on the creation of the “product, service, or result” of the project in order to meet its objectives. Business analysis aims at understanding the needs of the business stakeholders and at defining the characteristics of the solution to meeting those needs. Through the integration of these two disciplines, organizations can achieve superior project performance, both from the standpoint of the realization of project deliverables and from the creation of business value.

This paper explores how to integrate, in a virtuous cycle, the project management and business analysis disciplines, starting from the Project Management Institute (PMI) standard, A Guide to the Project Management Body of Knowledge(PMBOK^® Guide) and the International Institute for Business Analysis (IIBA^®) standard, A Guide to the Business Analysis Body of Knowledge (BABOK^® Guide).

Recently, in Italy, we experienced some companies moving in this direction and they are beginning to define a new generation of project managers, called the “project business managers,” (i.e., professionals who are able to integrate both project management and business analysis competences. Also, some project management offices (PMOs) are beginning to feel the need to develop superior business analysis skills.

Introduction

Several years ago, I was assigned to a project for creating a new product line and was given the responsibility of preparing the business case. Both the creation of a business case according to “best practices” and the product line under study were new to the company I was working for. The creation of the business case involved several business functions and brought out the “strengths” and “weaknesses” of the organization.

After the approval of the business case, I was asked to set up the project for the realization of the new product line. By following PMBOK^® Guide principles, I began to prepare the Project Charter and develop the Project Management Plan. I noticed that the planning process for this project was smooth, and compared with similar projects the effort required for planning was minor. Certainly, the preparation of the business case had facilitated this process, but that was not point! By reflecting on how I was building the Project Charter and the Project Management Plan, I wondered: “If I was not directly involved in the preparation of the business case, would I have planned the project the same way?” My answer was: ”No, not in the same way!”

According to the PMBOK^® Guide, the preparation of the business case is not part of the Project Management processes, but it is an Input to the Develop Project Charter process (PMBOK^® Guide—Fourth Edition, p. 74). The PMBOK^® Guide states: “The business case or similar document provides the necessary information from a business standpoint to determine whether or not the project is worth the required investment. Typically, the business need and the cost-benefit analysis are contained in the business case to justify the project.”(PMBOK^® Guide—Fourth Edition, p. 75). This statement is certainly correct, but it describes only partially the importance of a business case for a project. A properly defined business case:

Several years later, I came across the IIBA^® (International Institute of Business Analysis^®) and discovered the existence of A Guide to the Business Analysis Body of Knowledge (BABOK^® Guide), which provides guidelines on the Business Requirements elicitation process (called “Enterprise Analysis”) and the topic of the business case. When I started reading these guidelines, I realized that they could help in improving my project management skills. The interest for this new discipline was so strong that it convinced me to earn the CBAP^® certification (Certified Business Analysis Professional^TM) shortly thereafter.

Business and Projects

PMI's brand promise, “Making project management indispensable for business results”^® .emphasizes the link between a project and business value.

Every project initiates, as a response to a business need that, according to the BABOK^® Guide, “describes a problem that the organization is (or is likely to) face or an opportunity that it has not taken, and the desired outcome. The business need will guide the identification and definition of possible solutions.” (BABOK^® Guide—Version 2.0, p. 85), and the purpose of the task Define Business Need is to “Identify and define why a change to systems or organizational capabilities is required.” (BABOK^® Guide—Version 2.0, p. 81) To summarize this concept, we can say that from the Business Need arises a request for changing the organization's capabilities, and this change should deliver benefits to the business.

On the other hand, projects are the means through which changes are implemented. Project management best practices suggest that, after the project is “formally authorized,” it should be planned—starting with defining “what” has to be delivered (project scope) and “how” (Process)—and then carried out in order to build these project deliverables. Through the use of the project deliverables, the organization will realize the expected business benefits. Exhibit 1 describes this concept:

Exhibit 1 – Business and Projects

In order to create project deliverables that produce the expected business benefits, it is essential first to understand the need for change of the organization (and this is not a simple task, because business stakeholders always speak a “business language,” not a “project language”; furthermore, they are also used to speaking in terms of “solutions” rather than “needs”); then, the business needs must be prioritized and translated into a set of “implementable” requirements and, eventually, the project must be planned and executed, and during the execution, the project team must “listen,” continuously and carefully, to the new needs that might arise from the business. And, still, when the project is completed and the deliverables are released to the business, the performance of the solution must be assessed in order to capture the limits and opportunities for creating more business value.

It is obvious then to realize why organizations must develop both project management and business analysis skills in order for a project to deliver value to the business, because this value is in fact created before, during, and after the project. Project management focuses on the implementation of the change, and business analysis leads the project toward the understanding of the needs and the realization of business value.

But there's also another interesting point worth mentioning. The integrated use of the two disciplines, project management and business analysis, allows the organizations to achieve superior project management capabilities. In one of his articles, Professor Harold Kerzner says (The Future of Project Management, 2009, p. 2):

”With project management viewed as a strategic competency, it is natural for the companies to be strong believers in “engagement project management” or “engagement selling.” Years ago, the salesforce would sell a product or services to a client, and then move on to find another client. Today, the emphasis is on staying with the client and looking for additional work from the same clients. In a marital context, an engagement can be viewed as the beginning of a life-long partnership. The same holds true with engagement project management. Companies like IBM and Hewlett-Packard no longer view themselves as selling products or services. Instead, they view themselves as business solution providers for their clients, and you cannot remain in business as a business solution provider without having superior project management capability. As part of engagement project management, you must convince the client that you have the project management capability to provide solutions to their business needs on a repetitive basis. In exchange for this, you want the client to treat you as a strategic partner rather than as just another contractor. Decades ago, the salesforce (and marketing) had very little knowledge about project management. The role of the salesforce was to win contracts, regardless of the concessions that had to be made. The project manager then “inherited” a project with an underfunded budget and an impossible schedule. Today, sales and marketing must understand project management and be able to sell it to the client as part of engagement selling. The salesforce must sell the company's project management methodology and the accompanying best practices. Sales and marketing are now part of project management.”

Organizations that want to evolve toward Engagement Project Management need to develop and integrate both business analysis and project management skills. Business analysis aims at understanding the business needs before (through the BABOK^® Guide “Enterprise Analysis” Knowledge Area), during and after the project (through the BABOK^® Guide “Requirements Analysis” and “Solution Assessment and Validation” Knowledge Areas); project management aims at satisfying these needs.

Project Management and Business Analysis: The Dynamic Duo

In the PMBOK^® Guide, we can read these definitions for Project, Project Management, and Project Manager:

These definitions focus on the “project” part of the scenario described in Exhibit 1 and clarify the meaning of project deliverables (i.e., a product, a service, a result with characteristics of “uniqueness”), highlight the conformity to the requirements as the criteria for the successful application of project management, and establish the role of the project manager as the person in charge of achieving the project objectives.

In the BABOK^® Guide, we can read these other definitions for Business Analysis and Business Analyst:

These definitions focus on the “Business” part of the scenario described in Exhibit 1 and clarify the purpose of the Business Analysis, which aims at defining the Business Need and identifying and describing the solution (Solution Scope) in a way that it can be properly implemented by the project. They also underline the importance of the role of the Business Analyst, who acts as a “liaison” among business and project stakeholders, to keep the two scenarios, Project and Business, aligned.

Looking beyond the meanings of the two roles of Project Manager and Business Analyst, we want to highlight the importance of the two disciplines of Project Management and Business Analysis, and their integrated application, to ensure that projects are properly carried out and directed toward the creation of business value. The Business Analysis provides value to Project Management through a clear understanding of the business need, the definition of the solution components and its translation into feasible project requirements, as well as ensuring the continuous involvement of the business stakeholders throughout the project (thanks to the Business Analyst who acts as a “liaison” among business and projects stakeholders). According to the IIBA^®, collecting requirements is not “simply” a project management process, but rather a profession for business analysis professionals. Also, the business analysis receives value from project management, through the proper planning and implementation of requirements to meet the business need.

In this sense we can call the integrated use of these two disciplines a “dynamic duo.” Exhibit 2 describes this concept.

Exhibit 2 – Business and Projects: The “dynamic duo”

It is also quite understandable that the integrated application of these two disciplines might create an overlap between the two roles of Project Manager and Business Analyst, especially on common topics such as Scope definition, Communication, and Risk management. This topic has been addressed in joint research conducted both by PMI^® and the IIBA^®. This research is titled “Partnering for Success: An IIBA/PMI Joint Collaboration, by Elizabeth Larson” and it is available on the IIBA^® website (free for IIBA^® members); for the sake of simplicity, we will only report on the conclusions of this research: “The PM/BA is a peer-to-peer relationship. When we started our work, most of the project managers viewed the business analyst as subordinate to the project manager. By the time we concluded, we all agreed that both play leadership roles in the organization. Both are accountable to the sponsor—the project manager for leading the team and delivering the solution and the business analyst for ensuring that the solution meets the business need and aligns with business and project objectives. And both roles, equally, are required for project success.”

It must be clear that this peer-to-peer relationship should be standardized into a wider scenario that integrates both Project Management and Business Analysis guidelines, which should be tailored based on the characteristics of the organization and on its needs. As discussed, this paper intends to go beyond the two roles of Project Manager and Business Analyst and will focus on how the integration of Business Analysis and Project Management can create value for the project and the business.

The BABOK^® Guide—Version 2.0

Exhibit 3 shows the structure of the BAB0K^® Guide in terms of the Business Analysis Knowledge Areas (extracted from the BABOK^® Guide—Version 2.0, p. 7):

Exhibit 3 – The BABOK^® Guide—Version 2.0 Knowledge Areas

“Knowledge Areas define what a practitioner of Business Analysis needs to understand and the tasks a practitioner must be able to perform.” (BABOK^® Guide—Version 2.0, p. 6)

This paragraph summarizes the Knowledge Areas (KA) of the BABOK^® Guide—Version 2.0, to provide some common elements for understanding the importance of this discipline for the projects. Most of the definitions here below are derived from the BABOK^® Guide – Version 2.0, pp 6–8.

Integrating the PMBOK^® Guide and the BABOK^® Guide

As I have already mentioned, the integration of the Project Management and Business Analysis disciplines can improve project performance and lead organizations toward higher maturity in project management. But how can business analysis bring project management to a superior level? To clarify this concept, we want to start with the BABOK^® Guide and show how this standard can reinforce the Project Management Processes described in the PMBOK^® Guide. Following are some insights:

1. How the BABOK^® Guide's “Elicitation” Knowledge Area can improve the PMBOK^® Guide's Initiating, Planning, and Monitoring and Controlling Process Groups. The PMBOK^® Guide states that Project Management is “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.” (PMBOK^® Guide—Fourth Edition, p. 6). The BABOK^® Guide clarifies that project requirements are derived from the stakeholder's needs. These needs must first be understood and then translated into a set of project requirements for their implementation. The understanding of the stakeholders needs is a process of “elicitation,” which means (BABOK^® Guide—Version 2.0, p. 53):
   1. To draw forth or bring out (something latent or potential)
   2. To call forth or draw out (as information or a response).

   The word “elicitation” is derived from the Latin verb “ex-ducere”; today we say “educate.” A requirement cannot simply be a statement of what a stakeholder says or wants (often directly the solution), but arises from the understanding of its needs, which are often hidden (sometimes the stakeholder does not know them or isn't able to describe them). The stakeholders’ needs first must be “elicited.” Do you remember the importance of the business case that I described in the Introduction to this paper? I stated that the development of the business case made the Develop Project Charter and Develop Project Management Plan processes easier, smoother: in that example, the preparation of the business case represented an important elicitation effort; many elements of the business needs were initially hidden (some were unknown, some not clear) and came out and were clarified through this “elicitation” process. Eliciting the stakeholder needs is the most delicate part of Business Analysis and should be done in a professional way. The BABOK^® Guide—Version 2.0 describes the elicitation process in four steps: Prepare for Elicitation, Conduct Elicitation Activity, Document Elicitation Results, and Confirm Elicitation Results. Without a professional elicitation, effort is nearly impossible to collect good project requirements. A good elicitation process impacts directly the PMBOK^® Guide Develop Project Charter, Collect Requirements, Define Scope, and Plan Quality processes, which indirectly provides some benefits to the Perform Integrated Change Control process. For example, think of projects that may have problems because the business need is not completely understood, although in the presence of a detailed list of requirements;

2. How the BABOK^® Guide's “Enterprise Analysis, Requirements Analysis, Solution Assessment and Validation” Knowledge Areas can improve the PMBOK^® Guide's Initiating, Planning, and Monitoring and Controlling Process Groups. The PMBOK^® Guide shows that identifying project requirements is an iterative, top-down process. In the Project Charter are usually declared the “high-level” requirements, what the BABOK^® Guide defines as “Business Requirements” (“are higher-level statements of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. (BABOK^® Guide—Version 2.0, p. 5).” In the Collect Requirements process the focus is more on the “Stakeholder Requirements” (“are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements (BABOK^® Guide—Version 2.0, p. 5). ” In the Define Scope process, the Solution Scope is translated into the Project Scope. This process focuses more both on the “Solution Requirements” (“describe the characteristics of a solution that meet business requirements and stakeholder requirements…They are divided into Functional and Non-functional Requirements (BABOK^® Guide —Version 2.0, pp 5–6)” and the “Transition Requirements” (“describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. (BABOK^® Guide—Version 2.0, p. 6).”Along with the Solution and Transition Requirements, the “Assumptions and Constraints” are also derived. The BABOK^® Guide stresses that this order of “Business – Stakeholder – Solution – Transition” Requirements should be followed to make project results that produce business benefits: if we want to improve the business results, the starting point of every project must be the business need, not the characteristics of the product to be delivered. And also, when writing requirements, different “grades” of language can be used: for Business and Stakeholder Requirements a “high level” language can be used, but for Solution and Transition Requirements, the language must be precise, rigorous, unambiguous, because these requirements will drive the realization of the product of the project. For example, think of projects that may have problems because of ambiguous, inconsistent, or incomplete requirements;
3. How the BABOK^® Guide's “Requirements Analysis, Requirements Management and Communication” Knowledge Areas can improve the PMBOK^® Guide's Communication Knowledge Area. In these two BABOK^® Guide Knowledge Areas, the Stakeholder and Solution Requirements are modeled and specified, and grouped together into complete “requirement packages” “to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups. (BABOK^® Guide—Version 2.0, p. 72).” These Knowledge Areas support directly all Project Communications Management processes, above all the Manage Stakeholder Expectations process;
4. How the BABOK^® Guide's “Techniques” can improve the PMBOK^® Guide's Planning and Executing Process Groups. Collecting requirements through interviews is certainly useful and also the most common approach, but the BABOK^® Guide shows a variety of techniques to be used in different project contexts, depending on the characteristics of the stakeholders (some of these techniques are Benchmarking, Brainstorming, Focus Groups, Observation, Workshops, Survey, etc.). The application of these elicitation techniques can reduce the efforts of identification and documentation of requirements, as well as increase its effectiveness (i.e., a Group Task Analysis approach can reduce up to six times the effort for a process reengineering analysis). The PMBOK^® Guide calls the process of maximizing the value of project activities as a Perform Quality Assurance process. In addition, the proper use of these techniques can improve the Collect Requirements process by improving the stakeholder involvement. For example, think of how many projects focus the Collect Requirements process on a subset of stakeholders not properly identified and analyzed, especially when a large number of stakeholders are involved because this would make the requirements gathering process too time consuming and expensive. The BABOK^® Guide shows how to use different techniques in different contexts to maximize the effectiveness and efficiency for the Collect Requirements process;
5. How the BABOK^® Guide's “Requirements Management and Communication” Knowledge Area can improve the PMBOK^® Guideⁱs Initiating, Planning, Monitoring and Controlling, and Closing Process Groups. The ability of the Business Analyst to manage conflicts arising during the requirements approval process (sign-off) helps to keep the project tight linked to the business needs and to keep the business stakeholders involved in the project. Also, the definition of a Requirements Traceability Matrix creates a relationship between all categories of requirements (Business, Stakeholder, Solution, and Transition) and supports the impact analysis, which is performed by the Perform Integrated Change Control process, as well as the coverage analysis (Did we collect all Stakeholder requirements? Are there only partially analyzed Business Requirements?) for improving the Risk Management, Collect Requirements, and Verify Scope processes. The Requirements Management and Communication Knowledge Area also shows how to maintain requirements for future use, which will reduce the analysis effort for future projects. For example, think of projects that may have problems during the Verify Scope process because of partially elicited requirements, although with a list of requirements approved by the stakeholders. And think also of projects that must exert much effort during the Collect Requirements process because of a lack of documentation about already implemented requirements, or project requirements changes that are approved or rejected with a weak impact analysis;
6. How the BABOK^® Guide's “Enterprise Analysis” Knowledge Area can improve the PMBOK^® Guide's Initiating Process Groups. The proper definition of the Business Need (and the Desired Outcome), the identification of capability gaps, the definition of the solution approach and solution scope, and the set up of the business case are all Enterprise Analysis tasks that give the project the proper start and the right direction. Actually, how the Business Need is stated can completely change the objectives of a project. Some projects are started without a business case or, even worse, without having identified the Business Need. They might actually have a need stated, but not expressed in terms of business problems or opportunities, only at an intermediate or lower level (e.g.,,“We have data inconsistency. We need a new data warehouse”). The Business Analyst must be able to address any problem at a business need level (in the example above, “What is the impact of this data inconsistency on the business? Will the benefit of a new data warehouse justify the costs for this project? Are there any other solutions that might better satisfy the business need?”). When a project is started without understanding and describing the business need, it cannot be properly budgeted and the return on investment is often incorrectly estimated;
7. How the BABOK^® Guide's “Solution Assessment and Validation” Knowledge Area can improve the PMBOK^® Guide's Planning, Executing, and Monitoring and Controlling Process Groups. This BABOK^® Guide Knowledge Area focuses on assessing the proposed solutions (”in order to determine how closely they meet Stakeholder and Solution requirements”), as well as on allocating the requirements on the designed solution components for maximizing the business value. It improves the Manage Stakeholders Expectations process, especially during the execution phase of the project when the project manager is more involved in solving the project issues, and the Implementation Team has to make decisions that will influence the result of the project from a business perspective. Furthermore, the Solution Assessment and Validation Knowledge Areas analyze the impacts of the solution on the organization and help plan the effort and manage the risks for changing the organization. For example, think of projects that may have problems because the impact and risk analysis for changes in the organization are overlooked;
8. How the BABOK^® Guide's “Business Analysis Planning and Monitoring” Knowledge Area can improve the PMBOK^® Guide's Planning, Monitoring and Controlling, and Closing Process Groups. This Knowledge Area describes the planning and monitoring tasks carried out by the Business Analyst on the Business Analysis activities. This Knowledge Area provides important input to the Develop Project Plan process (in particular, the procedures for approving and prioritizing the requirements), the Plan Communications process (the Business Analysis Communication Plan), the Define Scope process (tailoring the Business Analysis deliverables and activities), the Risk Management processes (identifying and analyzing risks). This Knowledge Area also contributes to improving the Monitoring and Controlling processes, as well as documenting the Business Analysis lessons learned for future projects.

The concepts described in this paragraph represent only some contributions (the most evident ones) that the Business Analysis can offer project management. Other considerations will emerge through a more consistent and mature application of both disciplines by the project manager and Business Analyst in a “dynamic duo” scenario.

Final Words

For “Making project management indispensable for business results.^®”, Project Management and Business Analysis must be integrated into a “dynamic duo.” The BABOK^® Guide describes the Business Analysis guidelines “…used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.” These guidelines are useful for understanding and documenting the business needs in the beginning of the project, to keep the project linked to the business during its execution, and to assess the performances of the implemented solution in order to catch the limits and the opportunities for creating business value. The PMBOK^® Guide describes the Project Management guidelines that should be applied “to project activities to meet the project requirements.” Through the integration of the two disciplines of Project Management and Business Analysis, organizations can achieve superior project performance, both from the standpoint of the realization of project deliverables, as well as from the creation of business value.

This continuous research for new competences in order to create business value is the primary responsibility of every professional, and above all, Project Managers and Business Analysts.