CHALLENGES RELATED TO PROJECT MANAGEMENT AND BUSINESS ANALYSIS

"We don't grow when things are easy; we grow when we face challenges." — Joyce Meyer

There seems to be a lot of confusion among practitioners and experts alike regarding the division of work and the touch points between the project manager (PM) and the business analyst (BA). While the cause for the confusion ranges from unclear role definition (especially that of the BA) to unclear expectations and lack of understanding on how to effectively utilize the BA in project environments, the bottom line is the same — a mismatch of activities, expectations, ideas, and initiatives — some work well together, others do not, and the rest are in outright conflict with one another.

This chapters sheds light on the challenges in the important, interesting, and at times tense relationship between the PM and the BA — and between the PM-BA duo and the rest of the project team and the organization. The challenges will be addressed in this chapter, and more elaborate resolutions will be presented throughout the book.

DEFINE EFFECTIVE

The word effective often comes to mind when describing a PM or a BA; however, there is a wide range of ways to describe effective. Does effective mean impactful? Or rather fast? How about collaborative? Focused? Assertive? Problem solver? We live in an era where projects needs are not only about the individual skills of the people who lead the projects, or those of the team members, but rather the needs shift toward needs that are more integrative, collaborative in nature, and above all — people's ability to communicate with each other and work together toward success.

An effective PM is an individual with leadership skills and style that are appropriate for the circumstances of the project and the organization — one who can work effectively with a BA; who can share responsibility, delegate (once again, effectively), and integrate all points of view, ideas, and actions together toward one cohesive picture. In turn, an effective BA is not only one who understands the project's product, but can work alongside a PM — sharing relevant information, providing clear impact for actions (or inactions), and making recommendations that factor in the full range of considerations to benefit the project and the organization.

As this book is going to illustrate, there is only one way to bring together a PM and a BA and make them into a strong, effective team — a combination of collaboration, integration, and communication that focuses on the strengths that each individual brings to the table, while overcoming the weaknesses and ultimately, turn these two different people into one entity that is designed to take on the challenges at hand.

ONE ENTITY?

Many practitioners may claim that an attempt to turn the PM-BA team into one entity is not going to be as successful as simply utilizing one person for both roles. While in theory it may be true, and it may be applicable for smaller, less complex projects — larger or medium-sized projects require more from this unified role than the capacity of any one individual can produce. Furthermore, despite the many similarities between project management and business analysis, few individuals possess the skills and traits required for both roles. Experience shows that attempts to consolidate the PM and BA roles into one individual on larger, more complex projects ends up backfiring and costing the organization significantly more than the attempted related benefits. Having the PM-BA duo work seamlessly together as one entity on the larger, more complex initiatives generated very favorable results. For smaller, less complex projects, the PM-BA hybrid role has increased in popularity as more organizations shift towards a more change-driven or agile environment. This introduces the need for resources to be cross trained in both disciplines. However, the need still exists for the hybrid PM-BA to understand the integration points between project management and business analysis in order to deliver a successful project.

CHALLENGES

In any scenario where two people need to work together and perform activities that depend on each other, there will be challenges, differences in opinions, and often friction and conflict. Adding to that the existence of many moving parts, uncertainty, differing philosophies on how to perform the work, political pressures, third-party involvement, changes, and shifting priorities may lead to results that are common in most project environments. The PM and the BA have separate backgrounds and areas of focus, and they often report to different parts of the organization — representing different values and priorities. When attempting to combine their knowledge and experience, the PM and the BA often do not get along — they may perform activities that are not aligned and sometimes override each other.

Before diving into the myriad of challenges that impact the relationship between the PM and the BA and in turn, the combined value these two roles produce for the organization, we need to keep in mind that the role of the BA must not be limited to only Information Technology environments. Utilizing a BA to support both the project and the PM can substantially benefit most projects in a variety of disciplines and industries.

It is easy to find challenging areas when reviewing the roles of the PM and the BA; mainly due to the heavy involvement of both roles in the project work. The following pages covers the most common challenges and sets the groundwork for finding ways to address them and ultimately resolve these challenges.

Splitting the Work

Most PMs and BAs do not take the time to discuss how they can work effectively together or how to divide their workload. With multiple areas of responsibility that overlap, it is important to define who does what and where one role ends and the other begins. Different aspects of areas such as risk management, communication, relationship management, and change management need to be addressed by both roles. With no coordination or clear role definition, confusion is likely to ensue — leading to overlaps, redundancies, confusion, and conflict. Clear definition of both the PM's and the BA's roles and responsibilities will clarify who does what, both for those who hold the roles and for others (the team and other stakeholders). Further, the role definition will help address the touch points between the roles and the handoffs between the PM and the BA and from the PM-BA duo to the rest of the team.

Understanding Each Other's Capacity

As an extension of splitting the work and defining the roles, early discussions of the roles and responsibilities will also allow the PM and the BA to learn about each other's availability, skills, areas of expertise, and capacity. It is common to see PMs and BAs dump work on each other, or escalate issues without first understanding whether the other person is capable of handling these issues. As part of becoming one entity, the PM and the BA need to act in full synchronization and become fully aware of each other's experience, skills, availability, and capacity. Bouncing issues and activities from one to the other turns the PM and the BA into a bottleneck and beyond delaying work and resolution of issues, it creates a perception among team members and stakeholders that the PMBA duo's handling of the project work is insufficient. In turn, it contributes to doubts in their skills, slowdowns, and calls to replace either one, or both the PM and the BA. As part of the PM-BA collaboration, they also need to learn of each other's strengths and weaknesses so they can complement each other and divide the work so they can instinctively hand over issues, problems, and activities to the most suitable individual to deal with the problem.

Aligning Areas of Focus

The BA's focus is typically on the product and the requirements; that is, what we are trying to produce. In simple terms, they are driven by the business objectives — their role is to create a bridge between the business needs and the technical aspects of the work, and they are ultimately associated with advocating for product quality. This is not to imply that the PM does not strive for product quality, but the PM's areas of focus are mainly project related; deliverables and activities that need to take place to produce the product or service for which the project is undertaken.

Since the project performance will be evaluated based on the scope, time, and cost (a.k.a. triple constraints) of the project, the PM and the BA must align their focus areas and activities to ensure that they both work toward achieving the same objectives. A common occurrence on projects is having PMs performing activities to promote their area of focus, often at the expense of the BA's focus, and vice versa. While it is not done intentionally, the unfavorable result is inevitable. For example, when the PMs try to meet the schedule, they may propose removing certain scope items (and hence, requirements), without understanding the full impact on the business objectives, or on other requirements. The same goes for the BAs who often propose a requirements prioritization scheme that does not take resource availability into account, thus leading to a schedule bottleneck.

The aforementioned examples may once again bring up the need to have one person performing both activities; however, the different skills and especially the capacity required for each of the roles usually makes this an unrealistic option. Aligning the areas of focus means a joined process for planning and estimating, ensuring that both the PM and the BA are familiar with their counterpart's considerations, and with the full impact of their actions on their colleague's areas of focus.

Integrating the Requirements

As a significant percentage of defects in projects can be traced back to requirements, there is a strong need to ensure that requirements are not only elicited and managed properly, but also that the entire requirements management process is fully integrated into the project. With requirements being under the responsibility of the BA, and with PMs often not being involved in the process, there is a need to ensure that the requirements are fully integrated into the project. This leads to a discussion involving a full division of the roles and responsibilities between the PM and the BA, as well as identifying specific areas to perform the requirements integration. This includes everything from ensuring business value, traceability, incorporation of requirements into the project scope, managing requirements related risks, and ensuring their handling is transferred from the BA to the PM — to requirements prioritization and one integrated change control process. There is no point in getting the BA to cross-train the PM to better understand the product and the requirements, but there is a need to ensure that the BA informs the PM of relevant information that pertains to the impact of the requirements on the project as a whole. At the same time, it is necessary to ensure that the PM consults with the BA to fully understand the dependencies and the impact of scope, as well as other changes in the project on requirements and on the product.

Estimating Techniques

Despite an improvement in the area of estimating a few years ago, there are still multiple standards and resources that project managers can use to estimate work efforts, durations, costs, and the need for resources. Having more organizations moving toward agile project management gets us closer to achieving more consistency and transparency in estimating, but it is still not enough. The PM is not always sufficiently involved in either the estimating process or in the technical work performed and it may reduce the PM's ability to effectively facilitate the estimating process or to provide valid estimates and controls. Moreover, it is common to see team members mixing hope and other subjective considerations into their estimates — and many of those providing the estimates are not the ones actually performing the work. The BA is typically more intimately involved in the technical work that needs to be performed in the project and as such can serve as a liaison between the PM and the team. This will ensure consistent estimating standards are being followed, that terminology is used in a unified manner (i.e., effort vs. duration, specific completion times), and that controls are applied on work performed to allow real time reporting that is as close to representing the actual status as possible.

Reporting

Meaningful project reporting is a common problem in projects. From the timeliness of the reporting to accuracy, completeness, and relevance — reports often not only fail to represent actual progress and status, but they also lead to flaws in decision-making processes and ultimately to an increase in the number of change requests. When senior management does not feel it has the full information or when the information reported does not properly represent progress, it is more likely that senior management will introduce changes to the projects — changes that should not take place whatsoever. The result is waste — extra work, assessments, plans, and work performed to execute the approved changes, which in turn, introduces new risks to the project. Having the PM and the BA design the reports and the reporting standards upfront and bringing the reporting mechanism for approval will save a lot of the potential subsequent misunderstandings and need for changes.

Divide Areas of Responsibility

An important ingredient of the collaboration between the PM and the BA is to identify the areas of shared responsibility, recognize the full scale of both roles, and divide the responsibility of leading each area. This book covers the areas of responsibility for each of the roles extensively. But, it is not sufficient to only identify these areas — it is also important to coordinate and determine for each area whether it is the PM or the BA who is most suitable, appropriate, and qualified to lead. The decision has to be based on capacity, interests, subject matter expertise, the type of project, and stakeholder needs.

Terminology

Project management and business analysis have been governed, for the most part, by different organizations, and as such, both disciplines have grown separate from each other and further — in different directions. PMs and BAs often do not speak the same language or use terminology in the same context. The recent development of the Professional in Business Analysis certification by the Project Management Institute is instrumental in helping PMs and BAs become better partners — starting with using the same terminology and improving collaboration, rather than misunderstanding each other. The bad news is that it takes more than just a methodology to bring two disciplines together. It is now up to the PM and the BA, along with their managers and the organization, to define boundaries, draw interaction maps, set up rules of engagement, develop common vocabulary, and fertilize the new way of doing things through continuous improvement.

COMMON CONFLICT AREAS

It is a known fact that conflict is not a bad thing — that is, when it is managed properly and when it is the right type of conflict — about the merits, the work, the domain, and the substance rather than about personalities and styles. Unfortunately, a large portion of the friction between PMs and BAs is due to misunderstandings and alignment issues between the two roles, which leads to a lot of waste but fortunately can be easily fixed.

Scope Management

The project scope has the potential to become a significant source of conflict in many project environments. This conflict may be caused by a combination of factors including time pressure, lack of understanding of the difference between project scope and product scope, and issues around change control.

• Time pressure: This is the reality of virtually all projects and it leads to shortcuts in planning, lack of attention to detail, misunderstandings, and prioritization issues. While it is impossible to stop time, add time, or create new time, this book helps deal effectively with time consuming obstacles — and overcoming them will allow PMs and BAs to focus more on value-added activities such as collaboration, planning, and effective communication.

• Project scope and product scope: Project scope defines the activities, time, and resources needed for the project — in order to produce the product, service, or result. It is about the work to get done and the activities that need to be performed in the project. The project scope is articulated through the work breakdown structure and the project activities. Product Scope defines what must be delivered in order to meet the business need, that is, the major features of the solution. It is articulated in the requirements documentation. One of the major challenges any project faces is to integrate the two seamlessly; take the requirements and integrate them into the project scope by understanding what we have to do and then ask the other Ws: when, where, who, how, and how much.