Skip to main content

Author: Elizabeth Larson

Elizabeth Larson, has been the CEO for Watermark Learning as well as a consultant and advisor for Educate 360. She has over 35 years of experience in project management and business analysis. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as the several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, and spending time with her 6 grandsons and 1 granddaughter.

Can a Person Function as both BA and PM on the Same Project?

Written by Elizabeth Larson on . Posted in Articles.

One of the most frequently asked questions I still get from my clients is whether or not one person can be both a PM and a BA on the same project. The answer, of course, is yes, they can. A related question, though, is whether or not they should. I think there are really two different answers to two different questions.

If the question is could the BA and PM play the same role on the same project, my answer is that I can think of many situations where a single person could perform both functions. For example, if the organization does not recognize the importance of either role, if it doesn’t have enough resources for both roles, if a project is known to be “small,” when the team has worked together and is a high-performance team, one person could play multiple roles. Functioning in both roles on one project can work, especially when it is clear to everyone which “hat” is being worn at any given moment.

On the other hand, we might ask under what circumstances would it make sense for the BA and PM to play the same role. For me this is a harder question to answer. Here are some considerations:

  1. Generally speaking, there is an inherent difference of objectives between the two roles. The PM’s role is to meet the project objective (PMBOK® Guide Fourth Edition Section 1.6). The BA’s role is to help organizations to reach their goals (BABOK® Guide 2.0 Section 1.2). This is a subtle but important difference. Organizations usually complete projects to help them meet their goals. Project objectives are more specific than organizational goals. Put another way, the project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.
  2. Another difference is one of focus. The PM typically focuses on the project-creating baselines and managing project constraints, communications about the project, resolving issues about the project, getting the resources working on activities and tasks. The BA typically focuses on the end product. However, those lines are not always clear- cut. According to the BABOK® Guide 2.0, BAs do need to focus on the project when they plan and monitor the business analysis work, which is part of the project. That is, planning how the business analysis work will be completed, how formal the work will be, what documents, if any, will be produced, what approach will be taken, how the work will be tracked and reported etc. is project work. The focus is on the project, not the end result.

    However, doing project work as part of business analysis does not mean that the roles of PM and BA overlap. The project manager gets input from a variety of people on the team including the BA and uses that information to manage the project.

Although the PM may do some work related to the product and the BA may do work related to the project, there is still a need, I think, for both roles on most projects. It seems to me that:

  1. It takes time to do both jobs well. Certainly on “large” projects, it is a full-time job to manage the project and to manage the end product requirements. Trying to do both will usually mean increasing the risk and compromising the quality of both the project and the end product.

    One of our clients recently completed a study on separating the two roles, which had previously been combined. This assessment was undertaken in part because during different phases of the project, the PM role was neglected, and during other phases the BA role was. They concluded that on most projects both roles were needed and recommended the separation.

  2. Because there is a different focus and different objectives, there is often a pull in opposite directions, especially when both roles report to different organizational functions. Project managers want to deliver the end product on time and within budget. Business analysts want to ensure that customers can actually use the end product once it has been implemented.

    I can almost hear an internal conversation the combined PM/BA might have: the PM voice, sitting on one shoulder, says “But this has to be complete by Jan. 15th so we need to take these shortcuts.” The BA voice, sitting on the other shoulder, says “But we need to take time to do this right. If we put this into production now, it will cause defects, rework, workarounds…” The PM voice replies “if we don’t meet the date, we’ll destroy all their trust in us.” The BA voice says, “If we don’t get this right, we’ll destroy all their trust in us.” When we wear multiple hats, which voice do we listen to?

Personally, I have found it helpful to have both roles on projects, even when the project is “small.” So although it may not be necessary to have both a PM role and a BA role on every project, it sure makes sense on most.

Don’t forget to leave your comments below.

Elizabeth Larson, PMP, CBAP,CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected].

Gather Trust then Requirements

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on Gather Trust then Requirements

Co-authored by Richard Larson

One of the most difficult phases in project management is gathering business requirements from stakeholders. Requirements are often vague because it is difficult for customers to articulate their needs before they see the end product. When business customers and the project team have a relationship built on trust, they can work together more quickly to produce a product of value to the organization.

This article explores various ways to build trust in order to gather business requirements more quickly and accurately.

Solving Business Problems with Requirements

Before the requirements can be gathered, either formally or informally, it is important to discuss the business context of the project with the sponsor. Requirements need to be aligned with the organization’s overall vision and strategic direction. They must link to business goals and objectives. Keeping the vision in mind helps focus the team and helps reduce decisions based on personal agendas.

Initial meetings with the sponsor to discuss the business and project vision, as well as the business problem(s) can be a helpful way to establish rapport and begin to build trust. Focusing on the business need and vision demonstrates business acumen, which in turn builds respect, and leads to trust.

Elicitation Techniques that Can Help Build Trust

 

There are a variety of techniques that are typically used in requirements elicitation. Below are two:

 

Facilitated Requirements Workshops.

One of the most common is the facilitated requirements workshop, in which a facilitator enables key business stakeholders with differing needs and expectations to articulate their requirements. Part of this process encourages conflict by purposefully getting different opinions and perceptions out on the table before bringing the group to consensus. When a trained facilitator creates a safe environment, participants can provide their input without fear of rejection. When they start to feel that their input is valuable and valued, they can build relationships and trust with each other. The safer participants feel, the more likely we are to get complete requirements.

One-on-Ones.

Another common elicitation technique is the one-on-one interview. This technique is a way for business analysts and project managers to meet individually with stakeholders. Through these individual meetings trust can be built in several ways:

Assess Commitment. Some stakeholders do not like to make decisions or agree to decisions in meetings. One-on-one meetings provide a safer venue to discuss real needs behind the stated-and unstated-needs.

Address individual Concerns. Some individuals are more inclined to reveal their true concerns about the project and the other project stakeholders in one-on-ones rather than in large groups. When elicitation is limited to facilitated workshops, these concerns can go largely unaddressed.

 

Address Negative Behavior. Sometimes stakeholders either dominate meetings or demonstrate various types of disruptive behavior that negatively impact the group. By meeting individually, analysts and project managers can focus on the behavior and, together with the individual, determine ways to reduce its impact.

Each individual meeting is a chance to establish rapport and ultimately build relationships and trust.

Barriers to Elicitation

 

Distance of Stakeholders. In the ideal world all key stakeholders would be based in the same room or section on the same floor in the same building. The further removed the business experts and sponsors are from the business analyst and project manager, the more effort it requires to build and maintain good relationships, and the more difficult it is to collect requirements. Teleconferencing, video conferencing, and net meetings can be used for elicitation, but each presents significant challenges that make the process cumbersome. Scott Ambler, in his Agile Adoption Survey, found that dispersed agile teams while still highly successful, were less so than co-located teams.1 If we can be co-located with a full-time key business subject matter expert (SME), we can build trust far more easily.

 

Cumbersome Process for Collecting Requirements. Those of us who have built a house know that our requirements change. In the beginning we have a vision of the kind of house we want to build, but rarely can we articulate all our detailed requirements at the first meeting with the architect and builder. This is true for all business requirements, regardless of the project size. Complexities arise when different stakeholders have different requirements that must be reconciled and finalized. If we expect to collect all our requirements before designing and building our end product, we will probably not be successful. However, if we expect that the business will change and that requirements will change, and if we collect our requirements iteratively, we have a greater chance of meeting expectations, thus building solid relationships with the business stakeholders.

Project Misalignment with Corporate Objectives and Goals. When this happens, executive support and stakeholder availability tend to evaporate. Poor or late attendance at meetings, coming to meetings unprepared, and unanswered voicemails and emails are all symptoms.

Lack of Understanding of the Political Landscape. Business analysts and project managers who begin projects without having a clear picture of the political landscape will struggle, and the project is likely to take longer than expected. We may think that SMEs are providing their requirements, but the “Oh, by-the-ways,” or “Did I tell you that-that’s not right,” or “what I really meant was…” creep into the discussions.

Distrust. The most common reason for stakeholder caution and concern is distrust, caused by one or more of the following:

  • Fear that the end product, such as a new system, will dramatically change or eliminate their jobs
  • Fear that the end product will impede or slow their workflow in the name of trying to improve it
  • Fear that familiar software (ex. existing system or Excel spreadsheets) will be replaced by a system or process that is incomplete, inaccurate, or difficult to learn

Without an established relationship and trust, it will be very difficult for business analysts and project managers to elicit the necessary requirements.

Building Trust

Trust usually takes time to develop. The further away people are from each other, the harder it is. We may initially trust or not trust those involved on our projects, based on past experience, personal filters, culture (organizational, geographical, and otherwise), and a wide variety of factors that can influence our judgment. Business analysts and project managers don’t always have time to let relationships develop, so here are some things that can be done to build trust quickly:

Communicate Bad News. When the project is behind schedule, when it needs more resources or when lack of stakeholder participation is slowing the project, it is important for project managers and business analysts to address these issues with the sponsor and other appropriate team members.

 

Encourage Laughter. There is a strong relationship between laughter and trust. Having fun in meetings and laughing appropriately (not hurtfully) even under pressure builds a sense of team solidarity and a desire to work together towards the desired project outcome.

 

Define Clear Roles and Responsibilities. When not defined, not only do tasks overlap, but they more commonly fall through the cracks, which invariably leads to finger-pointing, blame, and lowered morale. Clear definition helps prevent territorial squabbling and decreases the chance of misunderstanding and subsequent project delays.

Be Competent and Credible. We lose trust quickly if we shoot from the proverbial hip, if we continually provide incorrect information, if we don’t communicate effectively, or if we set our own self-interest above the organization’s and the team’s.

Be Courageous. As project professionals, project managers and business analysts need to be trusted advisors. We need to point out risks, even when the organization typically shoots the messenger. We need to make recommendations. We need to ensure that the business takes ownership. These are not easy to do, but they are necessary to building trust.

Maintaining Trust over Time

Once trust is established, it can lead the team members through project difficulties. However, once broken, it cannot easily be regained. Some common trust breakers include:

Disclosing Confidential Information. While we do want to encourage open communications, we cannot disclose confidential information given to us. It is acceptable to tell the inquirer that the information is confidential. It is also acceptable to set up initial communications guidelines.

Creating a Competitive Environment. Competition by its very nature produces winners and losers. While some stakeholders can be positively charged by competition, others may view competition with resentment and even anger, leading to a weaker relationship. Collaboration has proven a key to many successful projects.

Communicating within a Hierarchy. When we keep the entire team informed, we reduce the likelihood of gossip, speculation, and low morale.

Micromanaging. Hovering in its various forms can give the impression that the micromanager does not trust the person being micromanaged. In turn the person being micromanaged will also develop a mistrust of the micromanager.

Failure to Make Decisions. Being indecisive can be destructive for a team looking for leadership. Being decisive does not mean making all the decisions or being authoritarian. It does mean taking appropriate action to resolve real issues, remove project barriers, and move the project forward.

Gathering Requirements = Relationship Building

Requirements elicitation requires building relationships and trust among the project stakeholders. When trust is absent, the requirements elicitation process will take longer, be incomplete, and will generally become an unpleasant experience for all concerned. Although building relationships takes time and effort, it can actually shorten project time and result in improved project performance.

1 http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/536/Agile-Business-Analysis-Interview-with-Scott-Ambler.aspx

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP and Richard Larson, PMP, CBAP are Co-Principals of Watermark Learning, a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. With academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. They can be contacted at 800-646-9362 or at www.watermarklearning.com.

Slaying the Dragon: Oldies but Goodies in an Agile World

Written by Elizabeth Larson on . Posted in Articles.

Attending the PMI Global Congress a couple of weeks ago reminded me that good ideas have staying power. There were several presentations on managing agile projects. As I listened, I was reminded of some of my past projects. Here are a few principles that have always worked for me and that can apply to agile projects.

Divide and Conquer

When I was first promoted to project manager, I was given a large new project to tackle. One of my colleagues told me that he was glad I was assigned the project. He said that he dreaded hearing of a new initiative, because he imagined a large dragon with its head peeking around the cubicle wall. I loved being a dragon slayer. I took that fire-breathing beast and cut it into several pieces, which we prioritized and completed more or less successfully. The “less” had more to do with not getting input from enough business subject matter experts, but the principle of breaking a large project into smaller chunks worked wonderfully.

The Project Management “what” vs. “how”

Deliverables have always counted more on my projects than activities and tasks. Deliverables focus on what needs to be done. Tasks provide actions – how each deliverable will be produced. In his Global Congress presentation, Why Agile Focuses on the Work-Breakdown-Structure and Frequent Communications, Clement J Goebel described the application of the Work Breakdown Structure (WBS) to the agile environment. I continue to believe that the deliverable WBS is one of the most useful concepts in the PMBOK, and I was delighted to hear how it applies to agile projects. As a project manager, I was the only one I knew who never used a Gantt chart. Sure I had activity lists, but each task was tied to a deliverable. A feature if you will.

Whose Project is it, anyhow?

I learned early in my project management career that trying to control scope was a losing battle – one I fought courageously, but never won. I learned that requirements, the basis of the project scope, needed to be prioritized by the business, not by me. On some agile projects features are prioritized by the role of the product owner, or business representative, not the acting project manager.

The Three “I’s.”

In the mid-90s I worked on a large project, one of the organization’s early “RAD” projects. RAD stood for Rapid Application Design/Development. We were trained by a consultant, who taught us the principle of the Three-I’s” – Iteration, Increment, and Involvement. We learned to do iterations, focusing on prototyping as a way to drive out requirements, although in all honesty, our iterations were more of a hybrid approach than is used today.  The increments were time boxes. Again, our time boxes were longer and looser than those today, but they certainly helped.

Perhaps the most important of the “I’s” was Involvement. We were fortunate, indeed, to have a full-time business expert move from her office in the merchandising department, where she was one of hundreds of buyers, to our IS area where our team was co-located. Her presence was invaluable to the project. Today we would probably call her the product owner, but we called her a BUC– Business User Coordinator.  She facilitated the requirements workshops, prototyping sessions, and user acceptance testing. As code was developed, she brought other client representatives into our area to show them prototypes and ensure they were on board with the new system. She participated in sponsor meetings, particularly when there was conflict between SMEs.

Our BUC worked in true partnership with the business analyst who ensured that the requirements were clear, that dependencies were taken into account, and that the design, code, and testing addressed the approved requirements. She also helped ensure that the interfacing systems and programs were completed, since there were many hundreds of programs that needed to be changed to accommodate the new system. There was virtually no conflict between these two roles. The term “collaborate” was not in our vernacular, but that’s exactly what they did.

Although the project was considered highly successful, one of the main missing ingredients had to do with me, the project manager. In retrospect, I should have spent more of my time removing obstacles (of which there were massive numbers) and let the team figure out how to get the project done. I should have worked for the team, instead of viewing the team as working for me.

Final thought. It seems to me that agile was built on some pretty solid principles, but these have been taken to a whole new level, vastly improving the software development process.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected].

Cultural Intelligence – Do You Have It?

Written by Elizabeth Larson on . Posted in Articles. 2 Comments on Cultural Intelligence – Do You Have It?

There are lots of different types of intelligence. Components can include such things as understanding, learning, use of language, creativity, emotional, and many others. This decade’s intelligence emphasis is cultural. Understanding different cultures is something I’ve always been interested in, but I’m not sure I always exhibited an abundance of cultural intelligence.

Years ago I lived in a South American country, far from my American home. When I first arrived, neighbors brought me welcoming treats ranging from a single mango to elaborate desserts in fancy dishes. After removing the treat, I would wash the plate and return it. Finally someone told me that it was rude to return an empty plate. The custom was to place a return treat on the clean plate. Completely unaware of this custom, I had unintentionally offended my kindly neighbors.

PMs and BAs usually understand that working with team members from different cultures presents unique challenges. Many of us completely oblivious to a particular custom, find that we have inadvertently offended someone on the team. I once managed a project that included several foreign team members working on the software development phase of a large project. I remember reacting with surprise when a team member told me that in her country she kissed her father-in-law’s feet whenever she greeted him. She explained that in her culture this was a sign of respect. This action, which seemed so different from anything I had ever experienced, was the norm for her.

On the same project, another developer rarely completed his assigned tasks on time. When I met with him in a conference room and asked about the missed deadlines, he refused to offer an explanation. During the meeting he appeared uncomfortable, but remained silent. I had mistakenly thought that team members would complete their assigned tasks. It never occurred to me that in some cultures work is completed based on relationships, not simply because the tasks appear on a Gantt chart. I later learned that the conference room meeting had been highly threatening to him, and that he was uncomfortable reporting to a woman.

Culture clashes can occur not just between people of different countries. As a manager I frequently noted what I called the “second company syndrome.” Candidates’ resumes often showed long tenure at the first company worked and a far shorter one at the second. When asked, candidates often said that they couldn’t get used to their new organizations. I heard things like the new organization had “too much process,” or “things were so chaotic,” or “they’re so unfriendly. No one goes out to lunch together,” or “everyone expects me to go out to lunch with them when I really want to eat at my desk and get some work done.”

There are even cultural clashes between business units within the same organization. I’ve worked in organizations where “users” clashed with IT and vice versa. In one organization I heard statements like “I’m surprised the elevator doesn’t automatically stop on the IT floor because of all the polyester worn there.” Or “those dumb users-they don’t know how to define their requirements.” I think it’s important to recognize that there are no “rights” or “wrongs.” Although we tend to view “our way as the right way,” we need to keep in mind that our ethnocentric perspectives can not only cause bad feelings, but can also hinder our ability to get the necessary work accomplished.

So what is ethnocentrism? It’s the “my way is the right way” attitude. It’s applying negative judgment to the way others live, work, and worship. We can recognize ethnocentrism when we hear phrases like, “How weird!” or “How can these people live like that! ” It’s feeling that one’s norms are superior to others.” “At my old company we used to write use cases” implies that writing use cases is the best way to discover and document requirements.” Or, “our systems were implemented almost without defects at my old company.” Or, “on my previous team we used to bring treats on Fridays. I don’t know what’s wrong with this new team-they never seem to want to have any fun.”

Related to ethnocentrism is culture shock, which is what happens to most of us when we live abroad for an extended period of time. The cultural differences become so overwhelming that we can become disoriented and distressed. We can’t wait to return home to what we view as “normal.” I believe that another team member experienced culture shock when she expressed surprise to learn that it is not uncommon for American parents to hug their children. She noted that Americans seemed so cold to her that she couldn’t image them expressing affection to one another.

I find it helpful to remember that new team members (from other countries, regions, organizations, or teams) may experience culture shock to a greater or lesser degree. They may miss their families, the camaraderie of previous teams, the HR policies of a previous company, or the weather, scenery, and customs of their home country. I have had team members experience culture shock on my team, but I didn’t always recognize it. I sometimes made the mistake of taking their distress personally. My tendency was to withdraw, when exactly the opposite was needed. However, I learned that rarely can we go wrong when we go out of our way to build relationships, listen, and offer support when working with team members from other cultures.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

Tips and Tricks for Facilitating Conflict Resolution

Written by Elizabeth Larson on . Posted in Articles.

We all know that conflict is a difference of opinion and therefore neutral-neither good nor bad. Right? But try telling that to a project manager or business analyst embroiled in conflict. Conflict can threaten to destroy the team and sabotage efforts to elicit requirements. But it doesn’t have to. Having a strong, neutral facilitator and a process for conflict resolution can reduce tensions and bring about a positive outcome.

Early in my career I was a liaison representing the interests of a large branch of a national bank. I was on a committee that met monthly to prioritize requirements. Each month I met with my branch management to determine their needs. Each month I and liaisons from the other branches would argue about which new systems and enhancements should be given priority. There was no formal facilitator. Conflict was rampant and remained unresolved. I don’t remember much being accomplished in these meetings. Each branch came in with its personal agenda and each of us went away unsatisfied with the results. Time after time I was in the unenviable position of having to tell my management that they weren’t going to get what they wanted. Again!

In retrospect one of the things I should have done was to spend time understanding the problem management was trying to solve. That way I could have presented a coherent set of recommendations at the monthly meetings.

Another thing I should have done was to meet individually with key representatives before each monthly meeting to discuss our concerns, find common ground, and build relationships. Instead of returning empty-handed each month, I should have returned with a recommendation that helped not just our bank, but the entire network of branches across the country. Everyone would have benefited.

Finally and maybe most importantly, the meetings would have run more smoothly if we had had a facilitator to tell us where we were going and keep us on track.

Many years later I learned that when conflict is preventing important tasks from completing, having a facilitator and a facilitation process is essential. Such a process might include:

  • Find a neutral facilitator. When emotions run high, it is important to find someone without a vested interest in the outcome. Some BAs and PMs take turns facilitating meetings for each other. Some organizations or PMOs provided facilitation services. What’s important is having a designated, neutral facilitator role.
  • The facilitator should set ground rules. One ground rule that can be used for conflict situations is that the participants will disagree with ideas and not people. This helps prevent the discussion from turning personal. If the discussion becomes emotional, the facilitator needs to bring the focus back to the issues at hand. If this is not possible right then, the meeting should adjourn.
  • Take time to understand the problem. Conflict arises for a variety of reasons. People have personal agendas, they think their way is the right way, they want to be recognized as experts, etc. We need to understand the real needs behind the stated needs, the issues behind the positions.
  • It is important for those in conflict to resolve it themselves. Once all participants understand the problem, we need to hold a brainstorming session to generate ideas to solve the problem. This can be done individually or in a group. Sometimes it is useful to have the participants write ideas on yellow stickies. It is important at this point to concentrate on generating ideas to solve the problem, not to evaluate the ideas presented.
  • Prioritize the solutions that have been generated by comparing approximate costs and benefits. You may need follow-up action items to quantify both the costs and benefits of the solutions.
  • Another facilitated session may be needed to develop a recommendation, or the recommendation can be assigned to one of several of the participants.
  • Present the recommendation to a pre-determined decision-maker, such as a project sponsor. It’s important to have a designated tie-breaker to ensure the conflict is resolved.

These steps will not prevent conflict, which is a natural part of a project. But they will help keep the project on track and prevent ruined relationships.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]