go away please!
One of the most difficult phases of the project is gathering business requirements from stakeholders. Under the best circumstances requirements are often vague, because it is difficult for customers to articulate their needs before they see the end product. In addition, some customers have personal agendas, which make identifying the true needs difficult. When the business customers and project team have a relationship built on trust, they can more quickly work together to produce a product of value to the organization.
Go away, please!
What happens, though, when that trust factor is missing? Sometimes the clients' resentment manifests itself openly. If you've ever heard the following in response to setting up requirements meetings, you have probably encountered open resistance:
- “We've always done it this way”
- “If it ain't broke, don't fix it”
- “The tool or technique that I'm using now works just fine, thank you”
- “I'm busy right now. Go away please!”
All of these responses imply not only that things are working well as is, but that the change is less than welcome. Because the change is not apt to be readily accepted, resistance to it can contribute to an undesirable project outcome. The underlying cause of resistance will be discussed later in the paper.
Resistance is not always evident to the project manager and/or business analyst. It can be couched in friendly terms. If you've encountered the following, you may have run into what we call the “Missing Trust Factor.”
- “Did I tell you that last week? I'm terribly sorry but that was wrong.”
- “Boy, I sure don't remember telling you that.”
- “Oh, I'm so sorry, but I forgot to tell you…”
- “There is no way I ever said that,” when trust is really absent
Overt resistance is easier to handle than behavior that appears to be cooperative, but which prevents the project from moving forward. This paper will focus on resistance to business requirements elicitation and discuss how building relationships and trust can help overcome it.
What are business requirements?
To understand why it is difficult to get business requirements, particularly when stakeholder relationships are weak or absent, it is necessary to define the term. A business requirement is a description of the features and functions of a product (something you will deliver) that satisfies a want or need enabling people to do, know, operate, or have something new or in a new way. This description usually is in the form of text, but could be documented in a graphical model. The features of the product describe characteristics and functions describe what the product needs to do.
The new brochure will include:
Company name and tag line
Company branding and identity
New program Related products Benefits
Introduce company to new customers
Provide credibility to new customers
Provide a consistent message and image
Provide speaking points during customer visits and presentations
The new order system will include:
Reports rolled up by:
Customer, product ordered, date
Product, price, cost
The system shall:
Adjust suggested retail for profitable customers
Apply discounts by dollar amount or percent off
Allow for specific sale price to be entered
Requirements solve business problems
Before the formal requirements gathering 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 vision and strategic direction. They need to link to business goals and objectives. When requirements do not have this linkage, which we call upwards traceability, there is a high likelihood that customers will request features and functions that are not only out-of-scope, but may also promote their own personal agendas.
In addition to meeting business objectives, requirements usually work together to solve business problems. One of the most common complaints from business analysts and project managers who gather requirements is that their customers often bring them solutions. The underlying need for the solution, however, is neglected, often resulting in a product or service that goes unused. Some questions to ask to uncover this business problem are:
- What is the problem and the resulting business pain?
- What is currently limiting you?
- What were some things that made you realize the status quo wasn't good enough?
- What opportunity arose?
- What compliance or regulatory requirement is this project addressing?
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. When sponsors and business experts realize that the project manager is going to help them reduce the pain in their current environment, acceptance can begin. Focusing on the business need and vision also demonstrates business acumen, which in turn builds respect, and leads to trust.
Once the business problem, project objectives, and deliverables are documented, we can begin to gather our highlevel requirements.
Trust and how requirements are gathered
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 encourages key stakeholders to articulate their requirements in a formal meeting session. This approach has many advantages, including using the synergy of the group to help build relationships and trust.
On the other hand, the dynamics of the attendees can have a significant effect on the facilitator's ability to elicit requirements, as well as the group's ability to provide the information sought. The following are just a few behaviors that can contribute to an unsafe environment, thus impairing the group's effectiveness in articulating their requirements:
- Dominant participants, particularly when they have more positional power than others in the group
- Lack of respect on the part of participants towards other participants and/or the facilitator
- Unclear roles and responsibilities related to the session. The most common issue is having the facilitator, such as the project manager, also be responsible for the outcome of the meeting, This important topic of separating the meeting results from the meeting process is widely misunderstood. Unclear ground (meeting) rules, which guide the group's behavior. Unless each participant actively agrees to each ground rule, there is the risk that a variety of dysfunctional behaviors will prevent the group from reaching its desired outcome and in the process create an unsafe environment.
Another common technique is the “one-on-one.” 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-ones 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 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 are not 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
There are many barriers to effective elicitation, including (just a few):
- Distance of stakeholders. Ideally all key stakeholders would be collocated, that is, officed on the same floor or in the same building. The further removed the business experts and sponsors are from the analyst and project manager, the more difficult requirements elicitation will be. Each of the most commonly used technologies for elicitation, teleconferencing, video conferencing, and net meetings presents significant challenges, which can be overcome, but which make the process cumbersome.
- Inadequate discovery time. Whether we want to acknowledge it or not, it takes time for business experts to discover their requirements, particularly the details of those requirements. For example, 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.
- Having a project and product requirements that don't fit into the organization's goals and objectives. When this happens, stakeholder availability tends to evaporate. Poor or late attendance at meetings, coming to meetings unprepared, and unanswered voice and emails are all symptoms.
- Not understanding 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.
- Reluctant or even hostile participants. If a project is meant to automate, streamline, or downsize an operation, people often fear losing their jobs. Trust is difficult to establish and complete requirements are hard to gather when providing the details may cost someone their job.
The most difficult barrier--distrust
Perhaps the most difficult barrier to overcome is stakeholder distrust of the people, project, or end product. There are many reasons why key stakeholders may not want the end product, and they may try any number of "sabotage " techniques. Analysts and project managers need to understand the fundamental association between the ability to gather requirements and the relationship with the stakeholders who have the requirements.
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 incomplete, inaccurate, or difficult to learn;
- Fear of loss of value or stature in the organization. A new process may be less cumbersome than the old. A new system may be faster and may provide more information. And, a new product may be enormously valuable for the company. Despite all this, an individual's business process will change, and the affected employee will have that uncomfortable lack of familiarity. Stakeholders are usually reluctant to relinquish their knowledge and expertise in an organization, and distrustful of those they perceive as taking it from them (project managers and business analysts).
Without an established relationship and trust, it will be very difficult for analysts and project managers to elicit the necessary requirements.
What happens when the trust has not been established? The risk of having a less than positive outcome greatly increases. Some possible impacts include:
- Unhappy sponsors. Sponsors do not usually like having their client representatives or project managers make a habit of asking for additional time and/or funds. They also are not fond of hearing their staff complain about unsatisfactory products. When requirements are not clear from the beginning of the project, both tend to occur. An effective partnership between sponsor and project manager is the best way to address these possibilities. And the most important component of an effective partnership is trust.
- Added scope. Business clients and sponsors will figure out a way to get the features and functions they want and expect, even when they have never articulated them. Sometimes this additional work is authorized, but more often business clients put pressure on project managers to add to the scope, blaming them for missed or incorrect requirements.
- Schedule delays. It will almost always take longer to gather requirements when relationships have not been established. Each time that requirements are given to sponsors and business clients to review, more time is needed for turnaround and approval. There will most likely be more time required for revisions, as well.
- Team issues. It is easy to fall into “blame mode” when new requirements surface late in the project. Imagine this conversation:
Project manager: “This widget was not part of the approved project scope.”
Business client: “Yes it was. Right here where it says provide all necessary widgets.”
Project manager: “But you never specified this particular widget. You said all necessary widgets. This seems more like a want than a need.”
Business client: “Well, I need to have it because I'll have to create workarounds without it.
What is trust
Trust can be thought of as “acceptable uncertainty.” (Trust Enabling Strategies, 2005) and has been said to be “the big issue of the 21st century,” (O'Hara, 2004
A recent survey found that finds 69 percent of Americans say “I just don't know whom to trust anymore.” (Golin/Harris, 2002). Yet trust is the foundation of effective partnerships and collaboration. Building trust requires acting consistently and with integrity over time.
According to the Golin/Harris Trust Survey (2002), the top things organizations can do to build trust are:
- Be open and honest;
- Communicate more openly, honestly, and straightforwardly.
In addition, for parties to trust each other, each must:
- Communicate bad news as needed;
- Act with integrity and honesty;
- Acknowledge mistakes;
- Give credit where credit is due;
- Value each other's input;
- Make and meet commitments;
- Be competent within the domain of expertise.
Trust usually takes time to develop. 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 judgments. Analysts and project managers don't always have or take time to let relationships develop, so here are some things that can be done to build trust quickly:
- Discuss the project objectives openly. For example, if reducing headcount 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 an open conversation can lead to one about the advantages to the employee of actively participating to help the organization meet its goals.
- Communicate bad news. If the project is behind schedule or needs more resources or if lack of stakeholder participation is slowing the project, 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 correlation between laughter and trust. Having fun in meetings and laughing appropriately (not hurtfully) builds a sense of team and a desire to work together towards a positive project outcome.
- Define clear roles and responsibilities. When not defined, not only do tasks overlap, but 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 the resulting project delays.
- Deliver on what is promised. As the saying goes, “talk is cheap,” but trust is built on delivering what was promised and agreed on. Since trust is about expectations, find some “quick hits” you can deliver on quickly. It will help build trust for the outcomes that take longer to deliver on.
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 things that are guaranteed to break the trust are:
- Disclosing confidential information. While we do want to encourage open communications, we cannot disclose information given to us and accepted in confidence. It is acceptable to tell the inquirer that the information is confidential. It is also acceptable to set up initial communications guidelines, such as if the information is confidential, you will say so.
- Creating a competitive environment. Competition by its very nature produces winners and losers. While some stakeholders can be positively charged by competition, for others it can be viewed negatively, with resentment and even anger, leading to a weaker relationship.
- Communicating within a hierarchy, rather than having team-based communications. 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 “trustee.” In turn the person being micromanaged will also develop a mistrust of the micromanager.
- Not making decisions. Being indecisive can be destructive to the 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.
In conclusion, 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 lead to lower morale. Although building relationships takes time and effort, it can actually shorten project time and result in improved project performance. Finally, a good relationship between project manager and sponsor, built on trust, goes a long way to resolve the inevitable project issues that surface and help ensure positive project results.
Golan/Harris Trust Survey (February, 2002). retrieved 14/03/05 from http:/www.golanharris.com
O'Hara, K. (2004) Trust from Socrates to Spin Icon Books Ltd, retrieved on 06/07/05 from http://www.trustenablement.com
Trust Enabling Strategies, retrieved on 06/07/05, from www. http://www.trustenablement.com
© 2005, Elizabeth Larson and Richard Larson
Originally published as a part of 2005 PMI Global Congress Proceedings - Toronto, Canada