How to Build Trust for Better Business-Requirements Gathering

- Elizabeth Larson, PMP, and Richard Larson, PMP, Computerworld

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. But how do you go about building trust?
Before the formal requirements-gathering process begins, it is important to discuss the business context of the project with the sponsor. Requirements need to be gathered and managed in relation to the organization's overall vision and strategic direction. They must link to business goals and objectives. When requirements lack this linkage, which we call upwards traceability, there is a high likelihood that customers will request features and functions that not only are out of scope, but also promote their own agendas.
In addition to meeting business objectives, requirements should also solve business problems. One of the most common complaints from business analysts and project managers who gather requirements is that their customers bring them solutions and neglect the underlying problem. Often, the result is a solution that goes unused. Here are some questions to ask to uncover this business problem:
What is the business pain?
What is currently limiting you?
How do you describe your need or problem?
How did you first realize status quo wasn't good enough?
What opportunity arose?
What are you trying to solve?
Initial meetings with the sponsor to discuss the business and project vision, as well as the business problems, 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.

Techniques for Building Trust

There are a variety of techniques that are typically used in requirements elicitation. One of the most common is the facilitated session, in which a facilitator enables key stakeholders to articulate their requirements in a formal meeting. This approach has many advantages, including using the synergy of the group to build relationships and trust. Another common 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 don't 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 people are more inclined to reveal their true concerns about the project and the other project stakeholders in one-on-one interviews, rather than in large groups. When elicitation is limited to facilitated sessions, these concerns go largely unaddressed.

Address negative behavior
Sometimes stakeholders either dominate meetings or demonstrate various types of 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.

Recognize individual achievement
There are individuals who aren't comfortable with public recognition. With these stakeholders, individual accomplishments are better recognized in private. Each of these individual meetings is a chance to establish rapport and ultimately build relationships and trust.

Barriers to Elicitation

Distance of stakeholders
Ideally, all key stakeholders should be based on the same floor or in the same building. The farther the business experts and sponsors are physically removed from the analyst and project manager, the more difficult requirements elicitation becomes. Teleconferencing, videoconferencing and Net meetings are often used for elicitation, but each presents significant challenges that make the process cumbersome.

Inadequate time to determine requirements
It takes time for business experts to determine their requirements and, specifically, the details of those requirements. By analogy, homeowners can discuss certain aspects of the house they want to build, but rarely can they articulate all their 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.

Project misalignment with corporate objectives and goals
When this happens, executive support and stakeholder availability tend to evaporate. Arriving at meetings late, attending them irregularly, coming unprepared and not answering voice mails and e-mails are all symptoms.

Lack of understanding of the political landscape
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.

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 (such as the existing system or Excel spreadsheets) will be replaced by something incomplete, inaccurate or difficult to learn.
Without an established relationship and trust, it will be very difficult for analysts and project managers to elicit the necessary requirements.

Building Trust

Trust usually takes time to develop. Our trust of those involved in our projects may be based on past experience, personal filters, culture (organizational, geographical and otherwise) and a wide variety of factors that can influence our judgment. 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:

Discuss the project objectives openly
If reducing head count is a business objective and the project in question may contribute to meeting that objective, the project manager or analyst needs to communicate the possibility to the stakeholders if asked. Trust will not be built by avoiding the conversation or asking the stakeholders to discuss it with their bosses. Such a conversation can lead to one about the advantages to the employees of actively participating to help the organization meet its goals.

Communicate bad news
If the project is behind schedule, needs more resources or is suffering from a lack of stakeholder participation, it is important for project managers and 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 toward the intended 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 misunderstandings and subsequent project delays.

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 the following:

Disclosing confidential information
While it's important to encourage open communication, confidential information can't be disclosed. It is acceptable to tell the inquirer that the information is confidential. It is also acceptable to set up initial communication 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.

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

Micromanaging
Hovering over subordinates can give the impression that the manager doesn't trust them, and they in turn will develop a mistrust of the micromanager.

Failure to make decisions
Being indecisive can be destructive for a team looking for leadership. Being decisive doesn't 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.

Elicitation = 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.

Elizabeth Larson, PMP, and Richard Larson, PMP, are principals of Watermark Learning, a Minneapolis-based project management and business requirements analysis training company.