The marriage of professions-- business analysis & project management can live happily ever after-- together!


Director of Program Management, Churchill Downs Incorporated


Research on why projects fail typically leads to a realization that there were poor or incomplete requirements. If users define requirements, and user perception determines project success, why are we not paying more attention to requirements? Sound project management practices, coupled with effective business analysis, can overcome this challenge. This paper addresses the project manager and business analyst’s complementary roles, identify sources of potential conflict, and recommend strategies for avoiding issues common to the marriage of two professions. The key to realizing the full potential of combining each partner’s acumen and focus is a mutual understanding of how each contributes to managing stakeholder expectations and managing requirements. Ultimately, project managers and business analysts have a common goal: meeting a business need through successful project delivery.

Disclaimer: This story has both a hero and a heroine. The gender references are simply used to align with the theme and tell a story. There is no intention or claim, implicit or explicit, that the roles are filled by a specific gender. If it makes you happy, swap them around. Heck, use Martian and Earthling if you like. No…this paper will not infer which is which!


This paper will read like a both a horror story and a love story, with a theme just as intricate as any complex relationship. The good news is that the path to escape the grasp of the monster, navigate the trials and tribulations of a “marriage of professions,” and arrive at a happy ending is easy to define. Of course, it is up to each reader to follow the path!

The setting: Any office that leverages technology for their work.

The Monster (or Legacy System)

The monster has been with us for over a decade now. He started out small, tame, and even wanted. Everyone loved the small beast because of how much he helped with work around the office. Over time, the monster started to grow. By devouring small pieces of work as processes changed, by picking up new features to adapt to an evolving business model, and even by adapting to do work he was never intended to do, the creature grew. We do not know when, and we do not know how, but we became so dependent upon the creature that we could not survive without his help. The monster, with almost human-like awareness, started running the office and dictating how things would be done. We would adapt our daily routine to satisfy the creature. We would devise clever manual processes to avoid upsetting the monster. If the monster slept in late, nothing would get done. The people in the office had forgotten how to do things on their own, and new pets were not allowed on the monster’s turf. The once friendly, helpful pet had become a monstrous burden. To make matters worse, the original caretaker had long since left town and no one was willing to take care of the monster. The staff tried to find someone to help tame the beast; however, the small, incremental changes had created such a unique animal that no one understood how to care for him. As the monster aged without appropriate attention, his ability to handle the work load started to atrophy. The monster was dying. As if the beast’s pending demise was not a big enough risk to the company, the situation was exacerbated by the fact that no one was willing to let go of the monster’s grasp on our office. There were staff members that would rather live with the monster they knew than risk finding a new pet. Change is hard!

A Clear Need (the Genesis of a Project)

The need was obvious. We needed to replace the monster with a pet that met our growing needs. We knew just what to do. We needed a new pet! But this one would be better. He would accomplish more work, he would allow us to be more efficient, and he would even take on some of the manual processes we created because of our fear of the monster. The staff got together and started to describe all of the traits and abilities of the new pet. The challenge is that every time they tried, they would design a new pet that resembled the old monster. Could it be that they did not really want to change? Could it be that they did not know how to change? Could it be a combination of both? Replacing the monster would be a monumental, complex task. The project had begun.

Enter the heroine…

The Heroine (or Project Manager)

The project manager (PM) was a seasoned practitioner and had seen this scenario before. She knew that the biggest challenge would be identifying requirements, priorities and managing the staff's expectations. A quick Internet search will return dozens of reports, studies, and white papers written over the last couple of decades on why projects fail. While each report contains slightly different results, the one common denominator in every study continues to be poor or incomplete requirements. Why are we not learning from our own lessons? We must accept that ultimate success is not measured by meeting timelines or budgetary goals. These short-term wins are quickly overshadowed if the product or service fails to meet stakeholder expectations. True success is measured by how well the project outcome conforms to the genesis of the project; the business need.

Enter the hero…

The Hero (or Business Analyst)

The seasoned business analyst (BA) understood the importance of bridging the gap between the business needs and the solution that would be delivered as a result of the project. He knew that his job was not to recreate the monster by letting the business define the solution. Instead, his role is to elicit, analyze, communicate, validate, and ultimately manage requirements in such a way to meet the stakeholders’ business need. Our hero had seen this scenario before too. He knew from experience that a project team can very effectively and efficiently produce a system that does not meet the users’ needs, which defines a well-managed failure.

Exit horror story, enter love story…

The PM & the BA

What makes a good marriage? Most would agree that marital harmony stems from a mutual understanding and mutual respect for each partner's talents and role. The same is true in a project environment; to meet the business need, we must find harmony between project management and business analysis. In a great partnership, one associate is not subordinate to the other. Instead, we must submit ourselves to the skills brought to the table by each half.

A strong partnership between project management and business analysis is exactly what is needed to address the root cause of many project failures. Project management and business analysis skill sets are largely complimentary. According to Carkenord (2006),

The best way to guarantee success of any type of project is to have a strong, experienced Project Manager and a strong, experienced Business Analyst. These two individuals, working together from the beginning of the project, set the stage for success by accurately planning and clearly defining the expected outcomes. (¶1)

Could this be the answer to the Chaos Report findings from 1994? The Standish Group (1994) identified incomplete requirements, changing requirements, and unclear objectives as three of the top 10 factors contributing to challenged projects. If effectively leveraging the business analysis body of knowledge can reduce the top 10 factors contributing to project failure by 30 percent, then would not the savvy project manager take heed?

If the wedlock analogy is not working for you, let us accept the following advice from the sports industry. According to Ross (2002), in his article about what makes a good partnership in a sports duo, each partner must understand the other, one partner must not be overly dominate, the team must train together, and the team must have mutual trust in each other's abilities.

How a PM and a BA have Complementary Roles

What exactly does “complementary” mean? Here are a couple variations of the definition as provided by Merriam-Webster (Complementary, n.d.) dictionary:

  1. To fill out or complete
  2. Mutually supplying each other's lack
  3. Forming a satisfactory or balanced whole

In a marriage, both partners benefit from a relationship focused on similar goals. This does not imply that both partners perform the exact same functions. Instead, they form a partnership focused on the same long-term goals and leverage each partner's ability to reach those goals. They form a balanced whole. Likewise, the project manager and the business analyst have shared goals. Both want to see the genesis of the project, or the business problem, resolved. Both want to ensure that stakeholders’ expectations are proactively managed to ensure the project's product provides the anticipated results. Consider the following quotes from the business analysis and project management bodies of knowledge as related to managing stakeholder expectations and managing requirements:

Managing Stakeholder Expectations

As outlined in the Guide to the Business Analysis Body of Knowledge (BABOK) (International Institute for Business Analysts [IIBA], 2009), “The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires” (p. 3) and ensuring “requirements are visible to and understood by all stakeholders” (p. 5).

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition (Project Management Institute [PMI], 2008) states, “An important part of a project manager's responsibility is to manage stakeholder expectations. This can be difficult because stakeholders often have very different or conflicting objectives. Part of the project manager's responsibility is to balance these interests…” (p. 24).

By understanding the PM and BA responsibilities as related to stakeholder expectations, it is easy to see how the roles jointly support project success. The BA is focused on eliciting, or drawing out, information about stakeholder needs. The BA also strives to differentiate between needs and wants and works to ensure that all of the stakeholders understand the requirements and that expectations are aligned. In other words, the business analysis activity perfectly supports the PM's responsibility for managing stakeholder expectations as related to solution delivery. By referring back to the quotes mentioned previously, one could infer that the business analysis activity actually helps to overcome the difficulties referenced in the PMBOK® Guide—Fourth Edition quote. How cool is that!?

Managing Requirements

The project initiation processes include “developing clear descriptions of the project objectives, including the reasons why a specific project is the best alternative to satisfy requirements” (PMI, 2008, p. 45). In fact, the PMBOK® Guide—Fourth Edition added Collect Requirements as a critical activity performed during Scope Management with the purpose of “defining and documenting stakeholders’ needs to meet the project objectives” (p. 103).

Let us compare the PM's role in managing requirements to the business analysis body of knowledge…

To a BA, planning requirements management includes “defining the process that will be used to approve requirements and managing changes to the solution or requirements scope” (IIBA, 2009, p. 42). A fully developed Requirements Management Plan includes “the approach to be taken to structure traceability, definitions of requirements attributes, the requirements prioritization process, and the requirements change process” (IIBA, 2009, p. 49).

So, the BA works to analyze, verify, and validate the requirements to ensure stakeholders’ needs are accurately documented and then manages those documented requirements throughout solution delivery. Then what is the PM's role? Great question! The PM manages the activities required to deliver the solution based on the agreed upon business objectives.

Does this mean that there can be an intersection between activities such as developing a business case, identifying user expectations and requirements, and the ongoing management of requirements throughout the project life cycle? Absolutely! And these are only a few examples. Bottom line, there is overlap between a project manager and business analyst's roles and responsibilities. These similarities can be both the source of benefit and of conflict.

Potential Sources of Conflict Between These Roles

Prepare yourself for a pop quiz…

Why do marriages fail? If we can expand that question to include partnerships and teams, how does your response change? What are the most common reasons of failure?

Surprisingly, the list of causes is relatively short. While research will identify a plethora of studies, all with slightly different results, there is a recurring theme that cannot be ignored. As outlined by Diehl (2010), these are three of the top reasons that marriages fail:

  1. Self-centeredness (ego)
  2. Unresolved conflict
  3. Ignorance of the fundamental distinctions between each other

The third reason, or a lack of understanding of the fundamental distinctions between the project management and business analysis roles, can lead to a type of turf war as the functions compete for control and/or recognition for their roles, responsibilities, and effort. To compound the problem, this lack of understanding tends to cause, or aggravate, the other two reasons for failed partnerships: (1) a self-centered focus leading to decisions to benefit one's self at the expense of the other, and (2) conflict that remains a barrier to effective collaboration.

Strategies for Resolving Identified Sources of Conflict

This intersection of responsibilities is not a collision, but a joining of purposes. To realize the full benefit of the joining, we must proactively identify and resolve sources of conflict. The first step in identifying potential sources of conflict is to fully understand each function's roles and responsibilities within the context of the specific industry, organization, and organizational structure. Like a project management methodology, there is no one-size-fits-all set of expectations that will perfectly match every possible scenario. As stated by Stewart (n.d.),

A critical question to ask of yourself is what are your responsibilities and what do you bring to the relationship. The clearer and the more honest you are about the context of your association with potential partners, the easier it gets to be able to navigate the muddy waters of the relationship and potentially achieve things that you want to do together. (¶2)

Accordingly, the strategy for resolving the potential conflict created by the union of project management and business analysis is to develop a full understanding of each role's contribution to project success. We must communicate, document, and educate. Specifically, we must do the following:

  1. Learn about, and appreciate, each other's skills.
  2. Document project-related roles and responsibilities for each profession as necessitated by the organizational structure, culture, and other influencing factors.
  3. Ensure all stakeholders understand how each profession's skills contribute to meeting business objectives and project goals.

Leveraging the Combined Skill Sets

As John Reiling (2008) accurately describes,

The Project Management and Business Analysis functions do overlap, but are distinctly different. The PM is concerned with the overall project and managing product delivery while balancing project constraints. The BA is focused on defining the product and ensuring the solution meets intended needs. (¶10)

This paper purposefully does not address in any great detail if a project manager should perform business analysis activities, or vice versa; however, one would be naïve to assume a project manager should not fulfill (or be prepared to perform) business analysis responsibilities if necessary. How many of you are blessed with a dedicated, trained, business savvy BA for each and every project assigned? If you do not have a BA, does that mean the accepted BA-type responsibilities are not completed? Absolutely not! All the more reason to understand not only the value of business analysis, but also the skills, tools and techniques used for effective business analysis. Keep in mind this paper is intended for a PMI® Global Congress audience. If written specifically for the International Institute for Business Analysis conference, business analysts would be warned that there will be times when they are expected to perform tasks traditionally considered to be a project manager's responsibility. This is not blasphemy; this is reality. Let us revisit the marriage analogy. If the dishes are never washed, what happens? If the garbage is never taken out, who suffers? Is there any requirement for either of these tasks to be performed by a specific partner? The reality is that drawing a line in the sand and saying either “that is not my job” or “you better stay away from my sink or garbage can” does more to damage the partnership than anything else. Men, be prepared to wash dishes. Ladies, there may be times when you need to take out the garbage. Metaphorically speaking…

Shared, Complementary, and Diverse Skills

A PM and BA both need well-developed interpersonal skills. Because working directly with stakeholders is a central requirement for both roles, each must have honed communication skills coupled with an understanding of how to interact with stakeholders at different levels of the organization that may have competing priorities and needs. This also means that both roles must understand the underpinnings of effective negotiation, problem solving, and critical thinking as they lead a diverse group of stakeholders to agreement on the requirements (solution scope), scope of the project (project scope), and chosen solution (product scope).

  1. Product scope: “The features and functions that characterize a product, service, or result,” which is “measured against the product requirements” (PMI, 2008, pp. 103, 105).
    • •    Project scope: “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions” (PMI, 2008, p. 103).

It is important to note that the BABOK includes the exact same definition for both project and product scope.

    • •   Solution scope: “The set of capabilities a solution must deliver in order to meet the business need” (IIBA, 2009, p. 232).

With the definitions outlined, it becomes easier to see that requirements scope is more closely aligned with product and solution scope than project scope. By sharing these responsibilities and focusing on the same goal of meeting stakeholder expectations, the PM and BA form a balanced whole.

Some of the most substantive gains come from leveraging the differences in a PM and BA's skill sets. Carkenord (2006) provides the following comparison of the skill set differences between a project manager and business analyst:

  1. The PM focuses on the overall “big picture” of the project, while the BA pays attention to the solution details.
    • •   The PM leads the project team, while the BA interfaces with the business process owners.
    • •   The PM manages delivery according to schedule and budget, while the BA maintains sight of the product as related to the business need.
    • •   The PM manages project scope, while the BA manages requirements changes (of course, these are not mutually exclusive).
    • •   The PM creates and manages the work breakdown structure (WBS), while the BA may be assigned to requirements-related tasks in the WBS.

We have all heard the old axiom that “The whole is greater than the sum of the parts.” This holds true for the marriage of skills required for effective project management and business analysis. Can the individual parts exist in isolation? Of course! Can a project manager meet stakeholder expectations without a business analyst functioning as a stakeholder liaison and focusing on the requirements and the solution scope? Could happen. Can a business analyst successfully lead the effort required to deliver a product without the help of a dedicated project manager? Yes, this could happen too. Here is the real question: Do we enhance our probability of success by combining skills and allowing each role to contribute based on their skill set similarities and differences? This is likely to happen! Do you want your professional credibility resting on “could happen” or “likely to happen?” Your call…

A Case Study in Practical Application (or How the Monster Was Slain and Replaced)

It is time that the once tame pet that evolved into a controlling, unwieldy monster go the way of the dinosaur. Like most extinctions, something else must fill the role to maintain the balance of nature. People will often choose to maintain the status quo, no matter how inefficient, than risk changing to something new. This is true even when they know the change is for the better or reduces risks to the business. In other words, before anyone will be willing to let the monster go, the hero and heroine must identify a viable alternative. Our dynamic duo's overarching tasks are to managing their stakeholder's expectations and provide the level of comfort necessary to accept the change.

These are the biggest challenges:

  1. Complete dependence upon an antiquated system
    • •   Complete lack of process documentation
    • •   Diverse set of stakeholders with competing priorities
    • •   Lack of understanding of the differences between needs and wants
    • •   History of failed attempts to replace the legacy system

From Need Identification to Scope

Note: This paper is not implying this is a waterfall process that must be completed in the order presented or by the roles identified; however, an understanding of the intersection and interdependencies of the following tasks is critical to ensuring project success.

The BA, working with the business process owners, develops a business case for replacing the legacy system. Who better to understand the high-level costs and benefits of change than those closest to the problem? Preparing a business case based on business need is ingrained in the Enterprise Analysis functions performed by a BA (IIBA, 2009, p. 7).

A business case is also one of the primary inputs to developing the project charter. Working together, the PM and BA can take the project purpose and justification outlined in the business case and produce the project charter; the initial project document used to ensure the project work will satisfy the stakeholder's needs and expectations (PMI, 2008, p. 73). The project charter must contain quantifiable business objectives that tie directly back to, and satisfy, the business need identified in the business case.

The approved project charter then sets the foundation for applying organizational resources to the work required to deliver the product (IIBA, 2009, p. 230; PMI, 2008, p. 73). This work includes the continued activities for requirements collection (PMI, 2008, p. 104) or requirements elicitation, analysis, validation, and management (IIBA, 2009, p. 7).

Requirements collection and management leads to solution (product) assessment and validation (IIBA, 2009, p. 121). Requirements documentation is also one of the primary inputs to both the project scope statement and creating the WBS (PMI, 2008, pp. 113, 116). The completed WBS then captures the full scope of the project, or the effort required to deliver the product in accordance with the documented requirements.

Requirements Traceability

Who owns the requirements traceability matrix?

According to the PMBOK® Guide—Fourth Edition (PMI, 2008), the Requirements Traceability Matrix is an output of the Collect Requirements process and “is the process of defining and documenting stakeholders’ needs to meet the project objectives” (p. 105). Strangely enough, the term “business analysis” does not appear in the PMBOK® Guide—Fourth Edition, even with the addition of the Collect Requirements process as a part of scope management. The role “business analyst” only appears once as related to developing the human resource plan and only as a sample project role. This would imply, although not explicitly stated, that the PM owns requirements traceability. Not so fast! Read on…

The BABOK defines Requirements Traceability as “the ability to identify and document the linkage of each requirement, including its derivation, its allocation, and its relationship to other requirements.” The matrix then demonstrates traceability between requirements and the associated project work components (IIBA, 2009, p. 231). Managing requirements traceability is a major process within the business analysis body of knowledge and is purposed to “create and maintain relationships between business objectives, requirements…, and solution components” (IIBA, 2009, p. 67).

The author suggests that the PM owns management of requirements traceability effort as a portion of the project work, with the BA assigned to the requirements-related WBS tasks and the ultimate owner of requirements traceability. This is simple skill set alignment, or effective allocation of resources. Can you drive a nail with a pair of pliers? Yes, but a hammer is probably a better choice.

Requirements Management

According to the PMBOK® Guide—Fourth Edition (PMI, 2008), requirements management is limited to the planning processes and associated documentation for “how requirements will be analyzed, documented, and managed throughout the project” (p. 110). The who, although not plainly stated, is the BA.

Measuring Project Success

How is project success defined? You can deliver on time and within budget and still deliver something that does not meet the business need(s). You can deliver exactly according to documented scope and still deliver something that does not meet the business need(s). Bottom line, project success is ultimately defined by how well the outcome of the project met the stakeholders’ business need. While project scope includes the product description, project deliverables, and defines the product user acceptance criteria (PMI, 2008, p. 122), this does not fully capture if the project is successful. So why do we continue to use on time, on scope, and within budget as measurements of success? These are only measurements of success from a project manager's perspective. Definitive project success is determined by providing business results through meeting business objectives or solving problems. In other words, neither the project manager nor the business analyst gets to declare a project a success. The customer, client, and/or end user have the final say on if the product met the business need. This means that understanding and managing stakeholder expectations is arguably the most important responsibility for both the PM and BA.


The Standish Group (1994) published research approximately 17 years before this paper that identified the lack of stakeholder involvement, coupled with incomplete or mismanaged requirements, it comprised almost half of the factors causing challenged projects. The causes were a combination of a lack of user input, incomplete requirements, changing requirements, unrealistic expectations, and unclear objectives. If you agree with the assertion that project success is determined by the customer, then it follows that success is neither determined by any specific project document nor defined at any predetermined point in time. Instead, project success is a perception that must be proactively defined and managed throughout the project and solution implementation. The PM and BA are perfectly coupled for the task. A marriage of professions designed to slay the monster, overcome the most common barriers to project success and deliver real business results. Who would not love a story with that type of ending?


Carkenord. B. (2006). Why does a project need a project manager and a business analyst. Retrieved from

Diehl, S. (2010). Why Marriages Fail. Retrieved from

International Institute for Business Analysis. (2009). A guide to the business analysis body of knowledge (BABOK Guide) (Version 2.0). Toronto, Ontario, Canada: International Institute for Business Analysis.

Complementary. (n.d.). In Merriam-Webster's online dictionary (11th ed.). Retrieved from

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide) (4th ed.). Newtown Square, PA: Project Management Institute.

Reiling, J. (2008). Project management intersects with business analysis. Retrieved from

Ross. M. (2002). What makes a good partnership? Retrieved from

Stewart, H. (n.d.). Effective business partnerships. Retrieved from

The Standish Group. (1994). The Chaos report. Retrieved from

© 2011, Chuck Millhollan
Originally published as a part of 2011 PMI Global Congress Proceedings – Dallas/Fort Worth, TX



Related Content

  • PM Network

    Agile Assurance member content open

    By Parsi, Novid Some project teams believe agile means skimping on requirements management. They're dead wrong. When they disregard this crucial component, they put project success on the line: For 35 percent of…

  • Greatness, a Place beyond Stakeholders' Expectations member content open

    By Deguire, Manon Managing stakeholder engagement calls upon something quite different from process groups and domains of knowledge, it calls upon the ability to create emotional responses such as enthusiasm, trust,…

  • PM Network

    Allied forces member content open

    By Merrick, Amy Seventy percent of organizations report that collaboration between project managers and business analysts is essential for project success, but only 46 percent believe the two groups collaborate…

  • Uncover gaps in your requirements using requirements risk management techniques member content open

    By Lee, Cheryl | Schibi, Ori According to a 2014 Project Management Institute Pulse of the Profession® report, inaccurate requirements gathering is the second most common reason for project failure, second only to changing…

  • Collaborating with stakeholders member content open

    By Haney, Victoria B. According to a variety of studies, 60 percent of software defects are linked directly to incorrect or incomplete requirements, with most project teams spending less than 8 percent of their time on…