Business analysis/project management friction, and how to overcome it

Penny Pullan, PhD, PMP

Director, Making Projects Work Ltd.

This paper explores the relationship between project managers and business analysts, the friction that can arise between the two, and how to overcome it.

While there is some overlap between business analysis and project management, these are two areas with different perspectives on projects that can cause friction. We explore what is meant by project management and by business analysis, and look at the particular skills and perspectives of each discipline. There are also wide areas of overlap between the two, which we lay out. We look at changes in the role of the business analyst over the years, and how this has shifted the relationship with project managers.

We share the results of asking nearly 400 project managers and business analysts about the relationship between the two roles. This work began with the responses of over 200 participants during an interactive webinar in July 2014 (Pullan). These answers were refined during an online survey carried out in January–February 2015. The survey had 186 participants from countries including the UK, the United States, Canada, Australia, New Zealand, South Africa, India, Ireland, and sixteen others.

The results of the research show that there are issues caused by the project manager, business analyst, and the organisation that can be overcome by good communication, trust, respect, rapport, mutual understanding, and a shared language. Organisations can help by including business analysis from the start of each project, ensuring clear roles and responsibilities for both roles, supporting their project teams with a clear vision of the end goal, and providing good governance.

What Is Project Management and Business Analysis?

Project management is defined as, “the application of knowledge, skills, tools and techniques to project activities to meet the project requirements” (PMI, 2013).

Here is a definition of business analysis taken from the recently published practice guide (PMI, 2015):

“Business analysiscls, tools and techniques to:

  • Determine problems and identify business needs;
  • Identify and recommend viable solutions to meet those needs;
  • Elicit, document and manage stakeholder requirements in order to meet the business and project objectives;
  • Facilitate the successful implementation of the project, service or end result of the project or program.

In short, business analysis is the set of activities performed to identify business needs and recommend relevant solutions; and to elicit, document and manage requirements.”

How Do Project Management and Business Analysis Overlap?

These are two distinct roles, but they share a large area of overlap. See Exhibit 1, which shows the different but overlapping perspectives.

img

Exhibit 1: The project manager and business analyst have different but overlapping perspectives, adapted from Robertson (2013).

The focus of the project manager is the scope of the project, which is the effort that needs to be completed to deliver the end product service or result. They are likely to liaise with the sponsor and manage the budget, project team, and risks involved.

The focus of the business analyst is the scope of the solution, which is what will be included in the final product delivered by the project. The business analyst will work closely with the business owners and other business stakeholders to uncover the scope, using a very facilitative style to work with very diverse types of people.

In the centre, the area of overlap between the business analyst and the project manager, falls a shared overall understanding of what the project is trying to achieve and how. While planning the project overall lies with the project manager, he should build his project plan on the basis of requirements from the business analyst. The business analyst should plan her own requirements work, negotiating with the project manager, rather than work with whatever time slot the project manager allocates to this task, which is often limited (Ouellette, Larson, Beatty, Paton, & Larson, 2014).

Tensions in the Relationship

Business analysts often complain of friction in the project manager/business analyst relationship, which has knock-on effects on the project team as a whole and impacts project success. We show some typical arguments between business analysts and project managers in projects at the retail company Waitrose in the UK in Exhibit 2:

img

Exhibit 2: Typical arguments of project managers and business analysts (Grace, 2012).

The author began to explore this area by considering the changes and challenges that cause tension and their resolution. She ran a webinar with ESI (Pullan, 2014) and followed this up in 2015 with a survey of practising project managers and business analysts.

In this section, we will introduce each area of tension and set out the results of a survey of practicing business analysts and project managers, looking at the practical issues that they face working with their colleagues. The survey contains responses from 186 people. The overall results are shown in Exhibit 3.

img

Exhibit 3: How survey participants rated the business analyst–project manager relationship.

Here are the details:

  • 30% indicate that they had a very good working relationship, where they work productively together, building on one another's strengths;
  • 57% indicate that theirs was OK and could be better, but on the whole they get the job done;
  • 9% describe the relationship as poor, with real problems in the relationship that affect the work done;
  • 2% suggest that the relationship was awful and that they don't work together effectively.
  • 2% did not know.

Of those that took part in the survey, there were 124 business analysts (of these, 24 marked themselves as having the role of project manager as well) and 26 business analysis managers. There were 60 project, program, or portfolio managers.

Looking into the results across different roles, 96% of the project managers rated the relationship as very good or OK, but this fell to 83% of the business analysts. Perhaps this is why many more business analysts responded to the survey?

The more senior respondents, namely those who had ticked the role of programme manager, portfolio manager, or business analysis manager, showed fewer marking the relationship as very good, and 17% rating it as poor or awful.

The results indicate that, while project managers on the whole are happy with the relationship, it is the business analysts and more senior managers who are more likely to notice problems and tension.

1. The Changing Role of Business Analysts:

Business analysis has grown rapidly over the last decade, driven by the rise in complexity of projects, outsourcing, and even the global downturn. Projects are more likely to have multiple stakeholders, ambiguity around project features, resources and phases and/or even unknown project features, resources, and phases, all of which make requirements elicitation more difficult. Poor requirements and/or missing requirements are leading causes of project failure (Ouellette et al., 2014). Outsourcing in the early years of this century forced many companies to improve their internal requirement elicitation and documentation to ensure that their outsourcing partners could work to provide working solutions. The downturn meant that less money was available to spend on projects, so known causes of failure, such as poor requirements definitions and elicitation, came into focus.

The relationship of many project managers with their business analysis colleagues has changed too. Years ago, the business analyst was typically a junior member of the project team, probably reporting into the project manager and seeing the project manager role as a future career step. Nowadays, business analysts can stay out of project management throughout their careers, even as they rise to strategic positions in their organisations. Business analysts are leaders in their own right, working alongside the project manager. The relationship between the two roles has had to change. Both have a leadership role to play on the project, and this can be difficult for both sides, especially for those project managers who were used to the old ways and haven't yet adapted.

When the author contacted project managers and asked them to comment on their project manager/business analyst relationship, many responded that “they didn't work with business analysts,” and some had not heard of business analysis as a project role!

The author shared the survey widely in social media in both project management and business analysis groups. Interestingly, business analyst responses outnumbered project manager responses by more than two to one. This might indicate that business analysts found the topic more engaging. Interestingly, almost half of those who identified as project managers also identified as business analysts, indicating that one person often covers both roles.

2. Tensions Due to the Project Manager Role

Here are the main causes of tension due to the project manager role, listed in order, with the percentage of survey participants agreeing with the statement given in brackets at the end:

  • The project manager is under pressure to get things done. (68%)
  • The project manager uses the business analyst for a range of tasks, not just business analysis. (47%)
  • The project manager doesn't wait for requirements before planning the projects. (43%)
  • The project manager doesn't understand the business analyst role. (42%)
  • The project manager doesn't invite the business analyst to share in leadership. (42%)
  • The project manager has a short-term focus. (36%)
  • The project manager doesn't understand the business analysis perspective. (36%)
  • The project manager doesn't wait for requirements before starting to develop the solution. (34%)

To bring these statements to life, here are some typical quotes and personal stories from individuals who responded that relate to some of these tensions, which have been left anonymous and with the grammar and spelling adjusted for clarity in some cases:

In my organization, project managers are mere administrators with little insight about the intricacies of what is required. I have spent literally hours trying to explain to my project manager the why of something for him to respond: “But this will be done by tomorrow, right?” Thus I do not bother now. I use passive-aggressive techniques and yoga to counteract the frustration.

My current project managers mostly do not understand the problem domain or the ways that business analysts and technical specialists have to work. They overlook dependencies and make up their own estimates. They do not manage the project but try to manage their own managers and their clients. They do not make clear what they want or expect everyone to do. They do not even produce meaningful project plans.

Project management is more interested in the timelines, not the nitty-gritty. Sometimes the project manager doesn't understand the issues arising and the estimates go wrong. There are instances when the original analysis was not detailed enough but creating new stories or detailed requirements later is not accepted by the project manager.

As a business analyst I am focused on the facts, details, and logical approach to ensure solutions are implemented that effectively deliver against the business requirements I have defined. The project manager is focused on “quick wins” and delivery of anything, as long as it is on time.

The project manager is under pressure to get the project finished on time. The business analyst (me!) can see opportunities for delivery of significant organizational efficiencies being missed by an overly ambitious timeline. The project manager has very narrow view, whereas focus of business analyst is probably more enterprise-wide.

The project managers and business analysts have opposite drivers. The business analyst is driven by quality and accuracy. Analysis takes time and needs resources and support. The project manager is driven by time and cost. They are resource-constrained and driven by the schedule.

I have worked in other areas of the company/elsewhere where business analysts are effectively considered to be “second class citizens” to the project manager, hence the roots of the conflict.

Passive project managers, perhaps merely checking off work breakdown structure (WBS) tasks, do not contribute much to keeping the project effectively progressing and, worse yet, may sometimes hinder project progress because they're not consistently involved in shaping up the project definition.

I find a mismatch in expectations to be the most difficult part of the relationship. Project managers can be very rigorous and process-driven, where as a business analyst I like to go where the research takes me and explore things at my own pace, and that doesn't always fit with the need to follow process.

As a business analyst, I think that project managers believe business analysts are beneath them. For example they attend meetings without the business analysts and still expect the work to be finished in a certain period. Some project managers do not understand and appreciate analysis—this is a major issue in my opinion. Sometimes it boils down to personalities.

Discuss roles and responsibilities at the start of a project and agree when covering for each other, rather than just going ahead and doing something out of your remit. It's a bit like the issue with a child asking for something from one parent and not getting it and goes to the other and says, “Dad said I could!” In addition the assumption is that someone else will do it without agreeing it up front!

One of the biggest bugbears is the project manager acting as a manager of business analysts, which can cause the business analyst to feel undermined in the value they actually add to the project.

Project managers are impatient and blinkered individuals, full of drive and focused on delivery almost at all costs. They are screened to be so, so it isn't their fault. A strong counterbalance is needed in their culture and reward structure to ensure they fully utilize business analyst skills to “get it right” as well.

3. Tensions Due to the Business Analyst Role

Here are the main causes of tension due to the business analyst role, listed in order, with the percentage of survey participants agreeing with the statement given in brackets at the end:

  • The business analyst wants to do the right thing, no matter how long it takes. (36%)
  • The business analyst has a long-term focus. (28%)
  • The business analyst doesn't realize the time pressures of the project and act accordingly. (27%)
  • The business analyst doesn't understand the project management perspective. (26%)
  • The business analyst doesn't understand the project manager role. (18%)
  • The business analyst focuses too much on the overall, holistic, strategic view and not enough on getting things done. (15%)
  • The business analyst doesn't share all the information with others. (15%)
  • The business analyst seems to be unaware of project constraints, especially time. (14%)

To bring these statements to life, here are some typical quotes and personal stories from individuals who responded that relate to some of these tensions, which have been left anonymous and with the grammar and spelling adjusted for clarity in some cases. There were fewer comments about business analysts than in the previous section, which is probably due to the smaller number of project managers that took part in the survey.

As a project manager I often had the experience that business analysts stay at an academic level and are not always in touch with the real world.

Business analysts have an agenda, which is not aligned to the project. They get upset when they have to work within given constraints.

Often a misunderstanding of the status of the project manager as the leader and the key person accountable for delivery lies at the heart of problems with business analysts who see themselves as largely autonomous.

4. Tensions Due to Organisational Issues

With the project manager often focused on delivery to time and cost, and with the business analyst looking for the right solution to solve problems and/or pursue an opportunity, there are subtle differences in the perspectives of the two roles. Under pressure to deliver, it's all too easy for project managers and business analysts to end up in conflict as we saw in the previous two sections.

Interestingly, these are not the only issues that cause tension. There are pressures too from the organisation: how things are done, how projects are governed, the project methodology chosen, and the corporate culture also have a lot to answer for. Here are the main causes of tension due to the wider organisation, listed in order, with the percentage of survey participants agreeing with the statement given in brackets at the end:

  • Insufficient time for analysis. (57%)
  • Different priorities. (43%)
  • Accountability and ownership issues. (40%)
  • Insufficient budget for analysis. (38%)
  • Scope issues. (37%)

To bring these statements to life, here are some typical quotes and personal stories from individuals who responded that relate to some of these tensions, as before:

A poor Head of Change (dare I say that?) Internal politics.

Organizational politics plays a part, so, instead of working as a team, each individual is more interested in his or her own success in the role.

There is a lack of clarity in the project objectives and poor project formulation.

Different viewpoints and ways of working. Who is responsible for which deliverables?

Conflicting perceptions of what the other role is meant to be doing or what they are responsible for could create problems with communication and for the overall management of the project.

I believe most organizations don't have clear roles and responsibilities of each role and don't have an appropriate engagement process (i.e.—folks are brought in too late).

Business analysts aren't involved early enough in project set-up. So projects are set up with an incomplete view of stakeholders and requirements, leading to mistakes early on that are hard for business analysts to resolve.

There is little sense of empowerment on the part of the business analysts.

The main problems are a lack of understanding of how we apply the business analyst model in the organization and a perceived hierarchy between the business analyst and project manager roles (whereas we actually operate them as peer services). The different expectations between business analysts and project managers then become the issue.

Changing stakeholders during projects.

This is complicated by the trend toward remote working, so the emphasis on facilitating good remote working processes and supporting technologies. As we get more comfortable with remote working this will develop, but initially provided some interesting challenges.

What Sustains Productive Partnerships Between Project Managers and Business Analysts?

In this section, we explore what is already working in productive partnerships between business analysts and project managers. These results give a foundation of what already works that organisations can build on to overcome project manager/business analyst friction.

1. Ways the Individual Project Managers and Business Analysts Can Help the Relationship

Here are the main things that work, listed in order, with the percentage of survey participants agreeing with the statement given in brackets at the end:

  • Good communication with regular updates. (80%)
  • Trust between the two roles. (76%)
  • Respect of each other's knowledge and skills. (74%)
  • Rapport between the two roles. (69%)
  • Project manager understands the business analysis perspective. (67%)
  • Both speak the other's language sufficiently to communicate well. (67%)
  • Both understand their shared, common interest in project success. (65%)
  • Business analyst understands the project management perspective. (65%)
  • Listening. (60%)
  • Business analyst provides the project manager with a work breakdown structure and time plan for analysis tasks. (51%)
  • Acknowledge obstacles and make them visible. (50%)
  • Project manager and business analyst sit close together and have frequent conversations. (49%)
  • Alignment on objectives, costs, and benefits. (48%)
  • Project manager and business analyst work together on key deliverables. (47%)

To bring these statements to life, here are some typical quotes and personal stories from individuals who responded that relate to these, which have been left anonymous and with the grammar and spelling adjusted for clarity in some cases:

A commitment to working together productively and flexibly, with each being willing to respect the other's expertise but also to spend time explaining his/her own background, beliefs, priorities, methods etc. Design a modus operandi for the specific circumstances. Keep it under review, being prepared to acknowledge when things are not working and try something different. Focusing on what actually needs to be done and not being constrained by unthinking and unhelpful stereotypes of the sort “A PM is xxx,” “A business analyst does yyy.”

Good old-fashioned adult conversation, understanding and agreement on responsibilities and deadline. I've also found that project managers love it when a business analyst gives them a “heads up” on possible risks to the project and then leaves it up to the project manager to manage that (and not whine about the project manager “not taking the advice”.)

Lots of meetings. Lots of talking. Working through project documents together. Explaining to each other what they are doing.

I have built a strong personal relationship with the PM. We have open and frank discussions, with shared expectations of my role. I hope that I am supportive of the PM in her role: identifying risks, issues, mitigations, scope creep, challenges with the customer, timelines, etc.

Frequent, two-way communication. Understanding of each other's concerns and priorities.

Getting together early in a piece of work - getting the relationship off the ground - getting some ‘banter’ going as people with smiles on their faces will work better together - ensuring there is a shared understanding of what is to be done, why and how - 'shared’ is the key word here to ensure both parties buy into the process.

Meet before project is initiated, define roles and responsibilities, become allies.

Clearly defined and agreed ownership of tasks and leadership of different areas.

A very tight relationship and alignment of goals is definitely required between the two roles.

Understanding of each role and setting expectations well ahead of time. Good interpersonal relations also help. The PM having delivered similar projects before goes a very long way.

Clear understanding of roles and responsibilities. Collaborative approach to planning. Environment where it is OK to challenge. Whole team to be conscious of team dynamics such as Forming, Storming, Norming, Performing.

Good communications, clear definitions of roles & responsibilities, consultation, accurate estimates from all parties including business analyst's on their deliverables.

A clear delineation and mutual understanding of project goals, priorities, roles, responsibilities, perspectives, incentives and, most importantly, constraints and risks.

Allocated time for daily debriefing, which could be over morning coffee, before dealing with the rest of the team. Frequent and succinct updates across both roles.

Co-location within earshot. Clear priorities and deliverables. Shared ownership.

Constant interaction. Healthy debate without blame or over-sensitivity. Earned mutual respect. Solidarity as a team in the face of external challenges.

When the PM invites the business analyst to sponsor meetings.

Empathy and a common understanding, appreciations of the differences (and similarities), and the ability to ask hard questions of each other. It's perfectly legitimate for a PM to ask, “Can you explain why the task will take that long, and the risk of shortening it?”. It is equally legitimate for a business analyst to ask, “Can you tell me how that deadline is derived, and the impact of us not hitting it?”. Plus engagement is key. One more thing: Arbitrary deadlines motivate nobody. Get relevant experts to estimate their own work. Challenge by all means, but get the right people to do the estimates.

View each other as equals, both having important roles to play. Understand that the skill set is different. It is important to have a problem statement/scope vision very early on, that sets the scene and the boundaries for future collaboration.

2. Ways That Organisations Help to Support Productive Partnerships

Here are the main things that work, listed in order, with the percentage of survey participants agreeing with the statement given in brackets at the end:

  • Involve the business analyst from the start of the project. (75%)
  • Clear division of responsibilities – who does what. (61%)
  • Clear vision and target from senior stakeholders. (45%)
  • Clear buy-in from stakeholders. (44%)
  • Clear governance. (41%)
  • Clear gates in the project plan, with checks as the project proceeds. (39%)
  • Clear organisational processes and procedures. (38%)

To bring these statements to life, here are some typical quotes and personal stories from individuals who responded that relate to these, as before:

Co-location.

Training, education, and culture. Collect real-life examples of successfully working together to improve outcomes.

Cake helps!

An agreed terms of reference, agreed outcomes, and agreed metrics.

Clear company strategy with clear definition on what the end deliverable is expected to be, i.e. pulling in the same direction. Their work should “complete” and not “compete.”

Publicity of early success by and higher management recognition for groups that are the change-demonstrators.

Clear definition of roles, accountabilities, responsibilities for project manager and business analyst. Contribution toward joint key performance indicators (KPIs). Culturally: promotion of the business analyst role within the organization as valuable—with opportunities for development. Culturally: requiring business analyst and project manager to think in the shoes of the other.

Clear definition of escalation paths to an arbitrator.

Senior leadership direction and pressure/expectation that people will follow.

Clearly define responsibilities of the project manager and business analyst and document them as a standard part of the organization's project manager methodology standards, to be used for each project.

Communication is key. Ensure you are on the same page to start off and have regular updates to do health checks on the project and ensure both are aware of issues/risks and what is in-progress from the project's perspective and the business analyst perspective. Honesty and transparency. Ensure both project manager and business analyst have the same understanding about the project objectives from the start and check-in at appropriate points in the project. Work together to identify and manage risks and issues.

We know the remit of each of our roles, and thus know who's responsible for the various tasks/deliverables. We've changed our project planning process over the last two years—we'd typically start a project with a two-week discovery phase where the business analyst was required to do his or her analysis, but we frequently found that two weeks wasn't enough time. So we've moved on to having research-only projects, a) to allow more time for the business analyst to do his or her work, and b) to verify that there is a real need for the project before we commit a full development team to it. Good communication between the project manager and business analyst is essential too, whether verbal or written.

Top Tips for the Project Manager Who Wants a Productive Partnership with His/Her Business Analyst/s

In this section, we suggest steps that project managers can take to ensure that their relationship with their business analysts is based on mutual trust and understanding. With this key relationship working effectively, the project team will gain a clear understanding of the real problem and what's needed to solve it. There will be a joint communications strategy in place and the project and product scope will be well managed and understood by both. Risk will be a joint effort, with the business analyst seeing risk identification as an important part of his or her role, while the project manager will take overall responsibility for managing risk. The two roles will draw support from one another and, together, work for project success.

Tip #1: See the business analyst as a leader, just as you are a leader.

Don't worry! Your business analysis colleague isn't likely to want to take over your project budget, schedule, and team management. He or she is probably far more interested in exploring what your diverse range of stakeholders really need and what would work best in the context of the organisation.

When we talk about business analysis leadership, we mean that business analysts need to step up to leadership themselves first, then be a real leader alongside you on the project, in a complementary way. They are the person in the project who considers what is best for the organisation and beyond. Here's a view of the different levels of business analysis leadership from the author's book (Pullan and Archer, 2013).

img

Exhibit 4: A leadership model for business analysis from Pullan and Archer (2013).

This research has shown that trust and respect form a great basis for a productive relationship, so start off that way by trusting your business analyst as the fellow leader that he or she can be.

Tip #2: Use a common language, develop a common understanding, and know each other's different perspectives.

Good communications and mutual understanding came out very high in the survey. By developing a common understanding of the project and of each other's roles, with a shared use of language, you can build a strong rapport to serve your project together. Let's look at a couple of examples of this in a bit more detail.

Too often, project managers and business analysts use slightly different terms or, worse still, use the same word in different ways. One example of the latter is the word “scope.” Project managers will think of scope as all the tasks that need to be done to complete the project, defined by the work breakdown structure. This is project scope. Business analysts use the same word, scope, to mean the boundary between what's included and what's excluded from the solution. This is solution scope or product scope. Can you see the difficulties this can cause? So make sure that you understand the business analysts’ perspective and their language and how they use it. Then help them to do the same for you.

As a project manager, consider how useful it would be if your business analyst colleague came to you with all the requirements work planned out in a work breakdown structure, with risks identified, effort assessed, and a potential schedule worked out. Then you could work together to come up with the final version to be incorporated into the overall project plan. The first time you do this, you may well need to help your business analyst, as this requires project management skills, but over time it will strengthen your relationship and you'll come up with better plans.

Tip #3: Work together from the start, building on each other's strengths and developing a good working relationship.

There are many areas where project managers and business analysts can work together powerfully.

Risk management is one such area. The project manager is in charge of managing risk; however, the business analyst is likely to have the facilitation skills and the close relationships with a diverse range of stakeholders, which are useful for identifying risks and facilitating the risk management process. The two roles work together and complement each other.

Another complementary area is communications. By building a communications plan alongside your business analyst colleague, you'll be able to tap into his or her deeper knowledge of individual stakeholders and their needs.

In a partnership like this where tension is possible, it's a really good idea to use a responsibility assignment matrix (RACI matrix) to ensure that you are both completely clear on who is responsible for doing each action, who is accountable, who needs to be consulted, and who needs to be informed.

Tip #4: The organisation matters.

In the survey, the answers remind us that the project manager and business analyst relationship doesn't happen in a vacuum. Your context matters and your organisation can help or hinder how the two roles work together.

As a project manager, if you are appointed before the business analyst, push for and encourage your managers to provide a business analyst from the very start. Do you have a clear vision from your senior stakeholders? If not, how can you facilitate this? Is the governance for your project clear? If not, ask questions and clarify things like escalation paths before they are needed.

If your organisation doesn't have clear roles and responsibilities for the project manager and business analyst, then as a minimum, discuss and agree these with your business analyst right at the start.

Tip #5: Iterate and learn as you go.

As your relationship with your business analyst develops, make sure you take time away from project tasks to be able to reflect on how the project is going. What's going well? Build on it; do more of it. What would make things better for your business analyst colleague? Why not give those things a try? What would make things better for you? Why not discuss this and agree how you'll do things differently in the future. As the quote earlier in this paper from our survey says, “Cake helps!” Spend time together, reflecting, learning, and improving both your relationship and the effectiveness of your work together, toward the ultimate goal of project success.

Conclusion

In our world of increasingly complex projects, diverse stakeholders, and limited resources, the project manager/business analyst relationship is more critical than ever to project success. While this important relationship often shows sign of tension, there are ways that project managers, business analysts, and their organisations can help to foster positive, collaborative relations.

Let's finish with a quote from the survey that sums it all up: “For me, it's not about project success, it's about business success. I'd rather can a bad project than drive it to an ‘on budget, on scope, on time’ delivery of negligible benefit.” Was this written by a business analyst or by a project manager? Does that even matter? Let's work together for projects that make a difference.

References

Beatty, J. (2014). Business analyst vs project manager. Requirements Blog, December 2, 2014. Retrieved from http://requirements.seilevel.com/blog/2014/12/business-analyst-vs-project-manager.html

Grace, C. (2012). Business analysis success within a PRINCE2TM framework:. Business Analysis Europe Conference 2012, September. London, UK.

International Institute for Business Analysis. (2009). A guide to the business analysis body of knowledge® (BABOK® Guide) – Version 2. Toronto: Author.

Ouellette, B., Larson, E., Beatty, J., Paton, L., & Larson, R. (2014). PMI Webinar: The BA & PM working relationship. Retrieved from http://www.pmi.org/Certification/PMI-Professional-in-Business-Analysis-PMI-PBA/Thank-You.aspx?

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.

Project Management Institute. (2015). Business analysis for practitioners: A practice guide. Newtown Square, PA: Author.’

Pullan, P. (2014) Project manager and business analyst: Productive partnership or conflicted couple? How to build effective collaboration between the two key roles in your project. Retrieved from http://www.esi-intl.co.uk/webinars/PM-and-BA/

Pullan, P., & Archer, J. (Eds.). (2013). Business analysis & leadership: Influencing change. London: Kogan Page Limited.

Robertson, S. (2013). Working with the project manager. In P. Pullan & J. Archer (Eds.), Business analysis & leadership: Influencing change (pp. 59–66). London: Kogan Page Limited.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2015, Penny Pullan
Originally published as a part of the 2015 PMI Global Congress Proceedings – London, UK

Advertisement

Advertisement

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.