Skip to main content

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.


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.


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

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.