The role of the BA in managing stakeholder expectations

Abstract

This paper offers new ways of managing and dealing with projects, with more focus on communications, understanding stakeholders’ needs, and managing their expectations, as well as on learning about organizational politics and culture and performing value-add activities. It introduces a practical approach for the business analyst's (BA's) role in managing those things that matter most for project success—communications, stakeholder expectations, risk, change, and quality—done in conjunction with the project manager (PM) so that the scope, schedule, and cost, as well as the project's intended benefits for the organization, end up on target.

Introduction

The introduction of the Project Management Institute's (PMI's) latest certificate offers a great promise for a new look at the relationship between the project manager and the business analyst—to maximize the contribution of each of the roles for project success. With that said, there are many challenges with the seam line between the two roles that often make the relationship less than ideal, if not challenging. Perhaps one of the most important areas toward which the BA can contribute is the management of stakeholder expectations—an area that on its own poses challenges to the PM. One of the main messages this paper tries to promote is to allow the BA to focus on the less technical aspects of the role and more on the people side—in line with the ongoing shift in the PM's focus toward right-brain activities.

Increasing the BA's contribution in managing stakeholder expectations will add significant value for the project and for the organization. As the business analyst often brings into the project substantial context about the product and the organization, this knowledge can be utilized and leveraged to benefit the project in a variety of areas, including those that will be discussed in the body of this paper.

The BA and Managing Stakeholder Expectations

Continuity from the Pre-Project Activities

It is common to see PMs being “installed” to lead and manage projects upon, or even after, the project initiation. This introduces a variety of challenges about the PM's familiarity with the subject matter, the technical knowledge of the PM, and the continuity in relation to pre-project due diligence and other activities. While it is arguably fairly easy to bring the PM to be technically (product-wise) up to speed, the deficiencies in relation to the context and the project objectives pose increasing challenges as the project moves forward.

It is common that BAs participate in, or even lead, business case exercises, feasibility analyses, and other activities that take place prior to the start of the project. These activities often offer context and significant information as to why the project is taking place and about some of the stakeholders involved, as well as provide a series of clues to identify project success criteria. For a new PM, most of this information may not be known, and the BA can provide the PM with it, giving the PM a head start and a large chunk of the project charter's content.

Complexity and Readiness

The knowledge that the BA already has about the project makes the BA an excellent candidate to lead or perform early activities in the project: project complexity assessment and project readiness assessment. These should not be formal or extensive exercises but rather effective ones.

The complexity assessment

This assessment can serve as a pre-risk assessment, where the BA will try to capture potential areas of complexity in and around the project. The BA works with a checklist of potential areas that may introduce complexity and check their status. The following areas should cover most sources of complexity and should be considered based on the organizational capabilities and circumstances:

1. The size of the project—This measure checks whether the project (in terms of budget, scope, functional areas, or organizational areas covered) is larger than other projects the organization has undertaken before.
2. Duration—The longer the project, the more chances it has to interfere with other initiatives and conflict with other organizational priorities. Longer projects are not necessarily more complex, but the duration should definitely be considered.
3. The environment—This requires review of the context in which the project is being taken (market, competition, economic and geopolitical conditions).
4. Technology—New or old, any unusual type of technology may make things more complicated to implement or integrate. While many projects deal with both new technologies and legacy systems, this measure tries to provide a read on whether it may pose specific difficulties throughout the project.
5. Multiple objectives and organizational priorities—This measure checks whether there is a clear understanding of the project's priority in relation to other organizational initiatives and whether the project has multiple objectives. A large number of organizational priorities and/or multiple project objectives might pose challenges in delivering on those objectives.
6. The change—This is an attempt to check how the organization will be able to handle the change the project introduces (in terms of people, culture, processes, tools, and other variables). Even simple projects that are easy to implement may face challenges in getting the change they introduce to last.
   

   Exhibit 1: The Change—Important as Both a Readiness and a Complexity Indicator

7. Responsibility without authority—This is a very common challenge PMs face in many organizations. This measure tries to provide a read on whether the PM has the appropriate type of authority for the task at hand.
8. Stakeholders—Whether there are a large number of stakeholders, diversity in their opinions, or an unusually high number of highly influential stakeholders, it would be helpful to know about this issue in advance and prepare for it.

Project readiness assessment

The readiness assessment is introduced to provide the organization with the knowledge of whether the organization is prepared to take on the initiative and move ahead with the project. Previously performed business case and feasibility analyses may not be sufficient for this purpose, since they refer to the need and the intent the organization has more than to the capabilities and capacity of the organization in regard to the initiative. The readiness assessment does not deal with the intent, and there is no question as to whether the project is the right thing to do or not.

People regularly perform readiness assessments, albeit not formal. For example, before we leave home in the morning, we get ready, pick an outfit, and allocate time for the commute based on where we go, the nature of the engagement, and when we need to be there. Similarly, organizations need to be able to perform a readiness assessment before they take on projects, learning where the stakes are higher and where there is a need for more structure and formality. The following are the areas to be considered as part of a readiness assessment:

1. Alignment—There is a need to verify that the project objectives align with the organizational objectives and strategy and that the project represents clear value for the organization.
2. The change—Is the organization ready for the change the project is going to introduce? This is one of the areas that need to be assessed from the points of view of both complexity and readiness.
3. Organizational priorities and culture—Check if the organization has a genuine intent to provide the project with sufficient priority in resource allocation, budgets, approvals, and dependencies.
4. Leadership—This can be achieved both from the appointment of a PM with the appropriate level of seniority, leadership skills, charisma, subject matter knowledge, and authority as well as from senior management with the ability and desire to provide sufficient support for the project.
5. Track record—This measure tries to check the track record of the organization, its senior management, and the PM in terms of delivering success and in regard to their approach toward supporting areas for the project, including, but not limited to, planning and estimating.
6. Success, objectives, and quality—This area partially overlaps with the track record, but it also checks whether the project objectives are properly defined and communicated, whether clear success criteria have been defined, and what the sponsor's and PM's views are toward the importance of quality, standards, and the cost of quality. An effective way to define success is to consider the competing demands as if they are parts of a balloon—when pressing on one of the competing demands, there has to be a combined trade-off of equal size to any one or more of the others.
   

   Exhibit 2: Defining Project Success—the Competing Demands

7. Resources and the team—From the allocation of a PM to the resource allocation, check whether sufficient capacity, availability, skills, and experience are in place for the project. A situation where there is no team in place and a promise to hire the resources for the project can generally serve as a red flag as to the organizational readiness. This area also looks at the organizational approach to resource allocation and, along with the track record, it provides an indication regarding the level of commitment there is for resources and deliverables.
8. Risk—This area measures both the risk level the project is facing (with complexity assessment as an input for this) as well as the risk tolerance level of the organization and of the stakeholders toward risk events the project may be facing.

Once again, the results of the assessment cannot be compared to other organizations’, and they will be specific to the context and situation of the performing organization.

Even if any one of these assessments’ results points at a complex project or at the fact that the organization is not ready for it, this does not mean that the project should be called off. Under extreme circumstances that might be the case, but otherwise these assessments should serve as warning signs and triggers for the organization to take action to alleviate some of the complexity and/or to take measures to prepare for the endeavour.

Stakeholders’ Objectives and Success Criteria

With strong involvement in the requirements process and familiarity with the product and with the context of the project (e.g., through the business case or feasibility analysis), the BA can jumpstart the process of defining, articulating, and communicating the project success criteria. Project success criteria are not about stating that the project must deliver on time, and on budget, and to full specifications, but rather they are an attempt to define what type of trade-off among the competing demands the stakeholders are willing to accept.

One could argue that defining the success criteria is one of the core roles of the project manager; however there is no reason why BAs should not participate and even lead this task—drawing on the experience and knowledge they already have. In fact, the entire stakeholder analysis should be performed jointly between the BA and the PM. While some BAs may say that this is an attempt by PMs to “download” some of their work onto the BA's already full plate, in fact this is simply a more efficient and effective utilization toward the success of the project of the knowledge that the BA has already obtained.

With the newly appointed PM attempting to look for information about stakeholders in what might be an unfamiliar environment and almost arbitrarily defining project success, the BA can provide very valuable information; with that he or she can make the initiation and early planning activities of the project easier to perform and more effective.

In regard to the stakeholder analysis, there is no argument that it serves the PM and measures the PM's ability to deal with stakeholders; however, we should view the PM and the BA as one entity—from information sharing among them, through consistency in handling situations, to sharing the task of managing stakeholder expectations in such way that will benefit both the PM, the BA, and the project as a whole.

Having the BA taking a lead role in defining success and analyzing stakeholders will allow another set of eyes to participate in project decision-making processes and will virtually allow “duplication” of the PM by having a “deputy PM” helping out in the project. There is a growing need to streamline the relationship between the PM and the BA, and these activities both contribute to the streamlining process as well as help the project deliver on its objectives.

Communications Planning and Ground Rules

One of the most important areas to address in a project is communications planning. With PMs spending the majority of their time communicating (in various settings and forms) and BAs also spending significant amounts of time doing so, there has to be a better handle on communications by both roles. As most PMs provide a very basic communications plan that revolves around a table—stating who gets what and when—there is a need to plan for and address other aspects of communications, which, for the most part fall under the heading of ground rules. PMs and BAs need to work together to ensure there is one set of ground rules for communications in the project, to be applied to all communications—from requirements, to expectations, reports, risk, and change. Setting up the ground rules (or a team contract) will provide all project team members, as well as other stakeholders, a set of expectations for handling communications and the code of conduct for interacting with each other. Team contracts have been proven to be very helpful in streamlining communications, achieving consistency, and reducing friction and negative conflict in project environments.

For every organization there is a need for specific guidelines, based on the organizational culture, the project environment, the project velocity, and the personalities involved. Those team contracts provide standards and guides under three main headings:

1. General communications—Typically providing reference to use of currencies, time zones, appropriate use of communication channels, and quantification of requests (as opposed to the use of adjectives; e.g. please send me the report by Friday at 2:00pm EST, vs. please send me the report ASAP).
2. Email communications—To achieve consistency in the use of email, set expectations for response times and email structure, as well as guidance regarding email administration and an overall a reduction in the use of email.
3. Meeting—Set up expectations for meeting organizers and participants, as well as for meeting times, agendas, use of electronics, teleconferences, and general conduct.

Although most project communications will ultimately be owned by the PM, when these ground rules need to be established early in the project, the BA is often more familiar with the organizational structure and with the stakeholders than the PM is, and so the BA can provide context, value, and specific knowledge that will contribute to the creation of a plan which is appropriate for the situation at hand. Moreover, as BAs are typically involved extensively in informal communications, they need to be involved in the design of these ground rules, so there is better control around informal communications, as well as clear distinctions between formal and informal communications—two issues that often plague projects.

Additional Touch Point Areas

There are several areas that inherently introduce challenges in the division of work between the PM and the BA, and hence they require special attention to ensure that the “touch points” between the PM and the BA are structured and clear, with no unserved gaps, as well as to minimize the duplication of effort between the BA and the PM.

Beyond the context, stakeholder analysis, communications planning, and success criteria that were discussed above, the PM and the BA should define clear lines of responsibility and boundaries for the areas listed below:

1. Assumptions—Both the PM and the BA need to log the assumptions they make about planning, estimates, promises, resources, and deliverables. However, managing two separate lists may create a duplication of effort and lead to inconsistencies in the handling of the assumptions. Consolidating these lists into one, managed by the BA but with full involvement and collaboration by the PM, will ensure a comprehensive list of assumptions that covers all applicable areas.
   

   Exhibit 3: Assumptions—Important to Track and Manage; Require Input from Both the BA and the PM

2. Risk—Since assumptions may turn into risks, the documentation and administration of this area should also be led by the BA. With the BA and the PM jointly working on managing risks, a healthy and desired balance between project consideration and product consideration can be achieved, allowing a proactive approach that will help intercept many risks before they happen, and almost eliminating duplications and inconsistencies.
3. Dependencies—Once again, with the BA administering this area, the PM will be able to lead “with the lights on” and make more informed decisions that are based on facts rather than assumptions. Consolidating the effort of managing dependencies will allow for consideration of all types of dependencies, led by resource, risk, product, technical, and cross-project dependencies—to be factored into the estimates and the decision-making process.
4. Communications—Both the PM and the BA are perceived to be champions of communications in their respective areas. Unfortunately the touch points between these areas are not only mismanaged, but they are not always clear. As the BA typically leads the communications regarding requirements, it is expected the PM will lead all other communications. In reality, there are some gray areas that may be left unserved. Managing the entire project's communications in one consistent way will make the communication more consistent and will allow coverage of all areas under consideration.
5. Requirements, scope, and change management—The separation of the requirements from the project scope through the division of the BA and the PM roles, creates a chasm that often leads to misunderstandings and misinformed decisions about scope items that damage the product or the overall project objectives. As long as the requirements and the project scope are handled by different people, there will be inconsistencies, gaps, and mismanaged expectations. This brings us back to the need to treat the PM and the BA as one entity and have the BA participate in and lead some of the “traditional” PM roles. Any handover between the requirements process and the scope management involves risk for gaps, problems, and issues. If BAs continue their leading role throughout the definition and management of the scope, including leading the change control process—all while maintaining full transparency and collaboration with the PM—it will improve the chance for scope- and change-related decisions that are aligned with the actual project objectives and that are handled consistently and responsibly.
6. Resource allocation—Since the PM often has only limited knowledge of the product, it may be hard for the PM to define resource needs clearly. Having the BA participating in the resource planning and estimating process will add another layer of knowledge and context that will lead to a more informed and realistic set of requests for resources. In the event that resources are not available, it will also provide a timely plan for recourse and for impact assessment.
7. Reporting—Collecting information for reporting and interpreting the reports will be more effective if shared, since it will provide context for both technical, as well as project considerations, integrated together rather than in a silo.
8. Recovery efforts—When projects reach the point which they can no longer deliver their original objectives, there is a need to change gears and to enter a recovery phase. For all the reasons documented here, the recovery effort should include the “one entity” type of collaboration to ensure that the project team can capitalize on this one-time-second-chance opportunity.
9. Documentation and joint artifacts—BAs’ involvement with technical considerations and the product aspects of the project requires them to produce significant amounts of reports, documentation, and other artifacts. Since these items are part of the project, they need to “fit” the project needs, and establishing a set of expectations around these artifacts early on will save the need for unnecessary changes and misunderstandings later. With the BA leading the way in designing these items and working together with the PM to ensure that their format and structure maximize the value produced for the project, the process will allow for both the PM and the BA, as well as for other team members and stakeholders to focus on the content and the meaning of these documents, as opposed to creating confusion around their structure.

It is not the notion behind the “one entity” to transfer responsibility from the PM to the BA or to overload the BA; it is about getting the two roles involved together in most aspects of the project and having them freely share knowledge and responsibilities. Naturally the BA will still be the lead on the requirements and product aspects, while the PM will still be ultimately accountable and the main point of contact for external stakeholders. With that said, two sets of eyes, two types of knowledge, and two points of view will achieve economies of scale and make both roles easier to perform and more successful.

During Project Planning and Execution

As BAs are constantly “in the trenches,” they have the ability to be the first ones to “test” early project p lans (regarding stakeholders, communications, complexity, readiness) and findings and in turn make recommendations to adjust them based on the dynamic in the project. Moreover, BAs’ exposure to subsequent planning and other pr oject work gives them the ability to add value by adjusting previously discovered risks and expectations around objectives and success, along with performing their “natural” role—re-prioritizing requirements in the context of the project objectives more effectively.

Maintaining BA involvement in these areas, along with ongoing, open communications with the PM will ensure that the BA's and the PM's actions both consider each others’ impact and that none of them is performed in a silo. The “one entity” notion will also dramatically improve the PM's and the BA's ability to articulate trade-offs, costs, and impacts of choices and options, under full consideration of all project aspects.

Project Health

Relatively few PMs utilize a set of quality assurance (QA) measures that can provide a read on project health. These are a series of interim measurements about the project performance to identify proactively the interim performance, trends, and direction certain aspects of the project are heading toward. Project health measures do not deal with major deliverables but rather with performance related to the project.

Areas of project health include half a dozen, where each can produce several measurements. The goal is to “adopt” up to a handful of measurements from a representative mix of these headings, which are meaningful for the project and for the organization:

• Results and deliverables—Identify a set of interim deliverables and items produced that can provide indications regarding various aspects of the project.
• Scope and requirements—Track the number of changes per requirement and the number of defects produced per requirement (or per change) to provide an indication regarding the scope stability.
• Issues and risks—Measure the number of issues, risks, and assumptions at given milestones throughout the project and compare them to previous, similar projects to check for associated trends.
• Human factors such as conflict and team dynamic—While this is a tough measure to quantify, both the PM and the BA can provide inputs from their specific points of view regarding team cohesiveness and dynamic.
• Estimating and scheduling—Assess the quality of estimates and their accuracy and completeness.
• Customer satisfaction—Establish measures to track customer satisfaction, using escalations, urgent calls, ongoing reporting, and issues raised.

In order to develop a project health system, there must be full collaboration between the BA (who is best suited to produce the information gathering mechanism and metrics), and the PM (who needs to establish the measurements and thresholds). Together, the PM and the BA will establish a mix of project health readings and their meaning. Another contribution of the BA will be the tracking of the readings over time, in order to provide context and meaning that add value to the project, as a one-time read may provide measurements that are out of context.

Project health measures do not point at the project product or results but rather at performance issues that, if not addressed, may indicate that areas of the project are not heading in the right direction. It is a sort of a safety net that can point at issues and problems before they directly affect project deliverables and results.

Cost of Quality

In an effort to curb costs and reduce areas of waste, there is a growing trend that attempts to measure the cost of quality better. It is still a surprisingly underserved area; however, an increasing number of companies try to track all the costs associated with achieving quality—including the “hidden” costs of quality—indirect costs that are incurred as a result of quality issues.

While this entire paper insinuates that in order to deliver quality, there has to be a better collaboration between PMs and BAs, such collaboration is absolutely critical for project quality management. From planning quality, through performing QA, and leading to controlling quality, the PM simply does not have enough product knowledge to define metrics, measurements, and thresholds, and the BA alone cannot lead the solution assessment or any verification or validation process without the context and the success criteria as articulated by the PM.

Working jointly, the PM and the BA need to form a partnership that allows them to deliver a quality product, through an integrated ability to define targets, identify standards and metrics to measure, and set up and manage measurements, thresholds, and expectations. All these must be closely aligned with both the project and with the organizational objectives, taking into account threats, opportunities, resource allocation, budget, and timelines.

Change Control

Change control is an area that, on one hand, already involves the BA and, on the other hand, serves as an ongoing challenge. A lot has been said about our need to improve change requests, estimates, and impact assessments; however, even more can be done. In most organizations change control serves as an ongoing example of lack of integration and a source of unrealistic estimates and risks. The problem is usually not because of lack of formal process or an ineffective one but rather due to multiple resources participating in the process and lacking coordination and guidance. Most change requests are assessed in silos—not taking into considerations various areas in the organization, other aspects of the project, or even other change requests. The result is negative impact on the competing demands, morale, and ultimately quality.

One of the reasons for the above-mentioned problems with change control is that the process is often not led end-to-end by a BA, and even if a BA is involved, the impact assessment and estimates are often mostly either product-driven or project-driven—but not taking all aspects of both into account. Co-owning (PM-BA) the process and ensuring end-to-end coverage from the requirements to all auxiliary areas of potential impact is the only way to ensure change control is better managed.

The intent of the term “co-owning,” is not to say that all activities have to be performed by both the PM and the BA, but rather that the actions of one of these individuals are equivalent to having both the PM and the BA directly involved. “Co-owning” is part of the PM and the BA acting as “one entity” —fully coordinated, in collaboration, integrated, and with full disclosure, clear communications, and streamlined handoffs.

Lessons Learned

One of the final project activities and the last one to be discussed here is the area of lessons learned. Although the term is widely used and its importance is clear, it is safe to say that one of the places in an organization that can store the most confidential information is the lessons learned folder on Sharepoint, since no one ever looks there.

Listed below are the steps for the most effective way to collect and apply lessons in projects:

1. Collect feedback on an ongoing basis throughout the project;
2. Perform a lessons learned exercise before the end of the project, presenting relevant feedback collected throughout;
3. Identify a handful of items for immediate implementation;
4. Produce a report for senior management discussing short-term and long-term recommendations.

Performing the process as described above would limit the number of lessons to be implemented, increase the chance the identified areas will be implemented, ensure buy-in and meaningful discussions, and reduce the future need to sift through old lessons learned reports. To facilitate an effective process, there is a need for both the PM and the BA to be involved in it, along with a need for integration of the recommendations—so both project, process, people, and product considerations are addressed.

Moreover, the ongoing collection of feedback throughout the project will allow for the PM and the BA to devise action plans in real time for issues that are identified—introducing potential solutions throughout the project, rather than waiting for the project to end.

Working Together

Although all activities discussed here are often part of the role of either the PM or the BA, sharing them between the two roles does not mean an increased work volume for either of the roles. To the contrary, it can free up some time for both individuals and leverage both types of skillsets and knowledge brought to the table to become more effective in managing stakeholder expectations and delivering project success.

How to Do It

One of the main challenges the ideas in this paper introduces is how to achieve the desired level of collaboration between the PM and the BA. It is clear that the need is there and that the realization of the value is clear. The following list provides additional context in this matter:

1. It starts with senior management getting BAs involved in pre-project due diligence activities, such as business case and feasibility analysis.
2. It is about ensuring that the appropriate PM is selected for the project. This is the responsibility of the sponsor and other senior managers in the organization—to appoint a PM with sufficient level of seniority, capacity, experience, and subject matter knowledge. Keep in mind that the PM will most likely not have a say on who the BA will be, since the BA is a “given” that comes with the project.
3. There needs to be continuity. Make sure that the same BA taking part in the due diligence activities is appointed to the project. Further, the BA should bring in all relevant information to the project.
4. Upon appointment of the PM, it is important to have the PM and the BA sit together and start by conducting a mini stakeholder analysis about each other, including “interviewing” each other and learning about one another's personalities, skills, and experience. Full disclosure is key to building a lasting and productive relationship.
5. Based on the findings from the stakeholder analysis, the project needs, and the experience the PM and the BA bring to the table, each party needs to put together a checklist of expectations and needs as a conversation starter for the planning of the partnership.
6. The BA will then present the information he or she brings in from the “pre-project due diligence” stage to bring the PM up to speed and to start the assessment stage of the PM-BA partnership.
7. Continue the conversation by discussing the division of their roles. Who does what, where each role ends and the other begins, and specific areas of responsibility.
8. Build a rapport and establish trust between the PM and the BA. This may require some mentoring and/or support from the sponsor.
9. Lay out the full list of items of both the PM and the BA to perform and determine the split, division, touch points, and boundaries of the work. Create a list of items, handoffs, and mechanisms for discussion and issue resolution.
10. Determine who takes the lead on which items and establish what the second person does for each area.
11. Establish a set of tangible expectations and ground rules between the PM and the BA to ensure that information flows, that decisions are informed and that even of only one of them (the BA or the PM) takes part in an activity, the mandate, and decision-making process are clear and valid.
12. As part of the communications lines between the two roles, establish a clear set of roles and responsibilities for delegation, escalation, communications channels and styles, document updates, and information sharing.
13. Inform team members and other stakeholders of the responsibilities of each of the roles.
14. Meet regularly (at least every day) to share information, update reports, strategize, and review the extent of the collaboration.
15. Adjust the relationship and responsibilities as required.
16. Identify team members to support both roles (of the PM and the BA), and empower them based on their roles and subject matter expertise. This will benefit both roles by reducing a significant part of the technical aspects of their roles, to free up their time for the tasks outlined in this document. For example, for the PM provide a strong project control officer (PCO) support and for the BA, empower team members such as business systems analysts (BSAs) and more junior BAs.
17. Document the process and successes, failures, and challenges, ideas, and issues on an ongoing basis to establish a set of best practices for future projects.
18. Conduct a meaningful lessons learned after major milestones and at the end of the project to ensure continuous improvement and working relationships moving forward in future projects.

Conclusion

Senior management, as well as both PMs and BAs have the awareness of the importance in improving the collaboration between the roles—specifically in having the BA making a more substantial contribution to the effort of managing the stakeholder expectations. This area opens the door—thought—to a major overhaul in the PM-BA relations and to a more constructive and collaborative relationship between these two key roles.

Like so many other aspects of project management, the challenges are not with the knowledge or the awareness but rather with the implementation. Only when there is a conscious effort and a meaningful change in the mandate of both roles and in the way both the PM and the BA do their work will the great potential of this area materialize into making projects more successful partially by enhancing the contribution of the BA to managing stakeholder expectations and delivering success.