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.

Projects without Borders; Gathering Requirements on a Multi-Cultural Project

Written by Elizabeth Larson on . Posted in Articles.

Co-authored by Richard Larson

One of the most difficult tasks project managers and business analysts face is obtaining customer requirements. Even when business customers and the business analyst work in the same building, misunderstandings are bound to arise. And as more and more businesses expand beyond their borders, different terminology and ways of doing things the risk of things going awry gets even greater. It’s a challenge to ask the right questions, get the right people involved, and document unambiguous requirements, regardless of the backgrounds of those participating. When the project includes multi-cultural stakeholders, particularly if they comprise a virtual team working in geographically dispersed areas, often thousands of miles, time zones and oceans apart, the job becomes much harder.

Some of the challenges facing project managers and business analysts are not unique to multi-cultural projects. However, personal agendas, conflicts about roles and priorities, and availability worsen the situation. In addition, recent studies have shown that almost half of the typical project budget is spent reworking requirements defects. While there are many underlying reasons for this rework, dealing with a group of multi-cultural business customers and/or project team members can create significant hurdles.

The Challenges

Physical Distance of Stakeholders

Although many of the challenges exist even when the team and business customers are located on the same floor in the same building, the difficulties in dealing with them increase with physical distance. Time zones make meetings hard to schedule. Business analysts on today’s global projects have learned that the standard eight-hour work day doesn’t exist. If we are truly customer-focused and interested in building relationships to capture requirements, we schedule meetings at a time convenient to our customers, not to us.

Few meetings on global projects are face-to-face, making the assessment of non-verbal communication nearly impossible. Since most business analysts pay a great deal of attention to non-verbals as part of the elicitation process, not being able to see them diminishes the communication and therefore the ability to capture requirements. Finally, although there are alternatives to face-to-face meetings, neither video conferencing nor “net” meetings is ideal. Video conferences usually lack some spontaneity and the audio lag can be distracting. Facilitating large groups over a video conference is quite challenging, since multiple conversations, dominance of one group or individual, and other facilitation difficulties abound. With both video-conferencing and net meetings, there are often equipment issues which hinder the requirements elicitation.

Roles and Responsibilities

Unclear roles and responsibilities can be the bane of project mangers and business analysts everywhere. When they are unclear, tasks invariably fall through the cracks and finger-pointing ensues. Unfortunately when stakeholders are removed from each other, it takes longer to find omissions and the resulting errors are harder to correct. Trouble usually occurs if a business analyst expects the business client to define the requirements, but the business client thinks they have already provided the solution and the rest is up to the business analyst. With differing cultural attitudes towards conflict, it can take even longer to perceive that there is a difference of opinion, let alone resolve it.

Language

Language barriers across cultures are numerous. The difficulties caused by differences in languages and even pronunciation among the stakeholders is well-known. In addition, most people have different levels of understanding and expressing both written and oral languages that are not in their tongue. For example, some people can understand another language when spoken, but have difficulty writing it. Others can understand better than they speak and write better than they understand. In order to elicit the requirements, project managers and business analysts need to work with business customers whose language differs from theirs to assess the comfort with both written and oral communications.

Finally, we need to consider the use of TLAs (three-letter acronyms), humor, euphemisms (powder room, passed away, downsizing), and sports analogies (ballpark estimate, coming out of left field, long shot) that can cause confusion and misunderstanding.

The Cultural Landscape

Another barrier is assuming that all team members, whether or not they are collocated, approach the project with the same cultural perspective. For example, I was managing a project that included a male team member who appeared uncomfortable taking direction from a woman. The more I discussed the importance of meeting deadlines, communicating status, and teamwork, the more uncommunicative and uncooperative he became. Finally I realized that the real problem was that I had done nothing to build trust and a strong relationship with him. His cultural work ethic dictated the importance of relationships. Therefore, he completed tasks because of the relationship, not because tasks appeared on a work breakdown structure.

Tips and Techniques for Making it Work

As organizations take on more global projects or projects that include a diverse set of business customers, they need to establish a corporate mindset of acceptance, inclusion, and learning that crosses borders. In addition, the project team needs to understand its inter-dependency in order to have project success. Synergy between the business customers and the project manager or business analyst is required to ensure that the end product is successful. Therefore, each party, the project manager, business analyst, sponsor, and all the business customers have an obligation and a stake in making this cultural diversity work. Without the project manager, the organization will spend more time and money on failed projects. Without the business analyst, the end product will not be usable. Without strong sponsorship and actively engaged business clients, the true requirements will not be discovered, and the end product will not be viable.

Although each party has its responsibility for making the project and end product successful, there are some things that the project manager and business analyst can do that help bridge the cultural gap.

Build Relationships and Trust

Building relationships and trust is important on all projects. There are a myriad of ways business customers can sabotage a project if they are afraid that the end result will jeopardize or dramatically change their jobs, or when the local requirements are not taken into account. With good relationships, issues surface more easily and can be resolved quicker.

The different requirements elicitation venues promote team-building to a greater or lesser degree.

  • For example, the use of surveys does little to promote mutual understanding.
  • Facilitated sessions (which may have to be net meetings on global projects) can help build teamwork, but it could take weeks or months for a virtual team to solidify.
  • One-on-ones serve to build relationships and help navigate the political and cultural landscape. By meeting individually, the project manager or business analyst can assess commitment to the project, discuss individual concerns, gather requirements from those who may not speak up in meetings, and gather requirements related to local needs of the global business experts. One-on-ones can also more easily promote understanding of team members from various cultural backgrounds, because language differences are the least problematic and personal stories and experiences can be more easily shared.

Define Roles and Responsibilities Using a Matrix

One technique that can aid in avoiding the pitfalls of unclear roles and responsibilities is to document them using some form of matrix, such as the Responsibility Assignment Matrix or the RACI chart. These tools use minimal text, so they are easier to understand than textual descriptions. In addition, in order to complete them, valuable discussion needs to occur. By facilitating this discussion, the project manager can help ensure that the fine distinctions between such things as a role and responsibility can be cleared up earlier rather than later in the project.

Example RACI Chart

(Responsibility for doing the work, Accountability for decisions, Consult with on the work, Inform that the work has completed)

Task/Phase

R

A

C

I
Project Plan Martha Mary PMO Team
Requirements List Martha Client Requirements Consultant Team
Client’s Staff
Modeling (Process, Use Case, and Data) Ying, Susan, David Mary DBA Team
User Interface Requirements/Prototyping Martha, David Mary Usability Lab Team
Programming Sunil, Shashi Mary All BAs Team
User Acceptance Testing Martha Client Sunil, Shashi  

Model the Requirements

One of the best ways to elicit requirements is to use various models to represent the requirements. Models, such as process models, usage models, and prototypes can provide a structure that encourages asking questions to find hidden requirements and more quickly document a complete set of requirements. Models have a number of advantages in general, and for cross-cultural projects in particular:

  • Models have the advantage of needing few words, so the language issues can be more easily overcome. They also have the advantage of promoting a two-way translation of requirements, from business customer to the model and back to the business customer, again with a great deal of structure and a minimum use of words. Models should be created so that they are clear and for the most part understood and used by the business clients.
  • Models are the most effective way to avoid having different members of the group have different mental pictures of the requirements. They are, for the most part, culturally independent. They can be created using several of the requirements venues including facilitated sessions, one-on-ones, and observation.
  • Models can help traverse the cultural landscape because they produce unambiguous requirements. That is, there is little room for misinterpreting them. Regardless of the birth countries of the business customers, business analyst, and team, cultural interpretations of the requirements are minimized by using pictures instead of text.
  • Finally models can be used whether or not the business customers are local or dispersed. Technology now permits models to be easily shared in-person, by email, with video-conferencing, and with net meetings. Because models can be viewed by all, there is less chance for miscommunication of requirements.

Summary

A large, multi-national U.S.-based pharmaceutical client of ours regularly experiences the challenge of cross-cultural requirements gathering. The following are some anecdotes to summarize a few of the key points in this article.

  • A conference call with a Tokyo client took twice as long to review a process flow as with domestic clients. The analyst kept asking “is there anything else” because of not wanting to omit something important. (Conclusion: plan for extra time when working cross-culturally.)
  • A similar group of Japanese clients insist on spending time at the beginning of a project getting to know their IT counterparts. They frequently and repeatedly ask that the IT staff come over to Japan to meet and visit with them. When the groups do meet in person, each meeting ends with a glass of sake to celebrate. (Conclusion: relationships are more important than the work in some cultures than others, even to the extent of delaying work. Projects will be stalled until relationships are established, and trust may be even more difficult to establish.)
  • A cross-cultural team of American, French, and British clients spent two hours talking about an industry term that the three groups swore had three different meanings. They later discovered the terms were really the same and then had to agree on which one to adopt. (Conclusion: language differences will be a challenge, so take the time to define key terms and record them in a glossary during projects.).
  • A project manager made an onsite visit to a client from Latin America on a project. The project manager had written in an email that he had found a restaurant to go to, but you had to BYOB. The client was confused and asked when they got together: “who is ‘bee-yob’?” (Conclusion: be careful with and define all acronyms!)

In sum, gathering requirements on a multi-cultural project has numerous challenges. To avoid or lessen the affects of these pitfalls, project managers and business analysts should spend time developing relationships, clarify roles and responsibilities in a chart format to ensure understanding by all, use terms and language carefully, and model the requirements to help ask questions. The ultimate goal is to uncover requirements in a way that is easier for all stakeholders, regardless of their language and culture.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. Over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Attendees immediately learn the retainable real-world skills necessary to produce enduring results. Between them they have presented workshops, seminars, and training classes on three different continents to over 15,000 attendees. Their speaking history includes repeat appearances at Project Management Institute (PMI®) North American, European, and Asia-Pacific Congresses, and at Business Analyst World conferences around North America. 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 of the section on collecting requirements in the upcoming 4th edition of the Project Management Body of Knowledge (PMBOK®).

A Requirement by Any Other Name

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on A Requirement by Any Other Name

The response I received to a recent article on the importance of trust in gathering requirements prompted me to ask myself exactly what was a business requirement. Because there were no comments on the trust aspect and a variety of views on the definition of a business requirement, I had to ask myself this question: If the definition of a business requirement varies from person to person, is it still the same thing? To paraphrase, is it true that a requirement is a requirement is a requirement? After all, a requirement by any other name…

So what is a requirement? Many years ago I worked for a national retailer in an IT group which developed two specifications for developing software. The first was a business requirements document (BRD), which we called a “bird.” The second was a technical requirements document (TRD), which we didn’t bother to pronounce. We never agonized over which requirements belonged in each category. We put those that came from the business in the BRD. Generally speaking these dealt with the capabilities of the software, such as the way people would use the system and the data that needed to be entered or displayed. Those relating to how we were going to implement the software were documented in the TRD.

But as with many things in life, the more I have learned, the less I know. Not only has the distinction between business and technical requirements become blurred, but even the definition of a business requirement has evolved.

We used to say that business requirements described the “what” and technical requirements described the “how.” But the lines between these two are not clearly drawn. For example, is a business process a “what” or a “how?” Next we divided requirements into functional and non-functional and disagreed about whether or not non-functional requirements were considered technical.

Definition of a Business Requirement.

A requirement seems easy enough to define, since the IEE’s definition has been pretty well-accepted: -“a condition or capability needed by a stakeholder to solve a problem or achieve an objective.” One difficulty with this definition, however, is that requirements no longer apply to software only and business analysts work on a variety of efforts. Business analysis applies to the completion of feasibility studies, new business processes, recommendations on staffing, to name just a few. We are left to ponder whether completing business analysis work always results in requirements as defined above.

Another difficulty is that while there is general agreement that requirements can be classified and that one of the classifications is “business requirement,” there is no agreement on what those classifications should be. It would be wonderful to refer to a body of knowledge to help us out. Indeed, one of the truly great things about having a body of knowledge is that we practitioners can use language that is generally accepted and understood by all. We no longer have to waste time discussing the definition of a requirement, of business analysis, of a business requirement. Or do we?

The BABOK® Guide 2.0 describes its classification scheme to include business requirements (goals and objectives) stakeholder requirements (those coming from the business domain perspective), solution requirements (functional and non-functional) and those temporary requirements that help the organization transition from the current to the future state.

The PMBOK® Guide – 4th Edition, on the other hand, classifies requirements as project and product (so far so good). But project requirements are classified as “business, project management, delivery, etc.” Product requirements are “technical requirements, security requirements, performance requirements, etc.” There are many ways to interpret these categories. Perhaps technical requirements equate to functional requirements, perhaps not. Perhaps delivery requirements refer to the target date, perhaps not. The point is that if we are going to rely on bodies of knowledge to help us speak a common language, it would be wonderful if they were aligned.

So what is a business requirement, anyhow? Being the old dog that I am, I still like thinking of business requirements as the umbrella term for those requirements approved by the business domain, regardless of the level of detail. However, I do believe I can learn a new trick or two, and can certainly see the rationale for defining the business requirements as the highest level goals and objectives. (BABOK® Guide). And if anyone knows what a delivery requirement is, I’d sure appreciate your letting me know.

Don’t forget to post 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].

Gathering Requirements; Go Away Please!

Written by Elizabeth Larson on . Posted in Articles.

Co-author Richard Larson

One of the most difficult phases of a 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 article focuses on resistance to business requirements elicitation and discusses 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.

Marketing Example:
The new brochure will include:

Features
Company name and tag line
Company branding and identity
New program
Related products
Benefits
Customer testimonials

Functions
Introduce company to new customers
Provide credibility to new customers
Provide a consistent message and image
Provide speaking points during customer visits and presentations

System Example:
The new order system will include:

Features
Reports rolled up by:
Customer, product ordered, date
Product, price, cost
Discounts
Special promotions

Functions
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 high-level requirements.

Trust and How Requirements are Gathered

Facilitated Sessions

 

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. Not clearly separating these two important responsibilities often creates an uncomfortable environment, which can stifle requirements elicitation and often skews the results.
  • 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.

One-on-Ones

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 sponsor 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 any politics involved 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 (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.

Risky Business

What happens to the when 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 .

  • 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,” and has been said to be “the big issue of the 21st century,”). A recent survey (Golan/Harris Trust Survey, February, 2002). found that 69 percent of Americans say “I just don’t know whom to trust anymore.” 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, 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.

Summary

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.

References:
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

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals of Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our 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. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

Estimating the Business Analysis Phase of a Project. Is it Even Possible?

Written by Elizabeth Larson on . Posted in Articles.

Years ago I worked on a large effort to reengineer a distribution center for a major retailer. We provided an estimate for both the business analysis work and for the entire project, which would involve the organization’s first use of Electronic Data Interchange (EDI), new business processes, many software changes, and the purchase of new barcode scanners. The business analysis effort took far longer than we anticipated, and at the end of it we refined our estimate for the total project. When we reported the new estimate to the president of the company, he literally pounded his fist on the table and asked, “How did we get to this point? Why didn’t we know sooner? You’ve already spent all this time on the project and what do we have to show for it? Nothing! Absolutely nothing!”

I have always thought of business analysis as the most ambiguous and the most fun of the project phases (by phase I mean phase, increment, or iteration). However, for many years it was my least favorite phase to estimate. I felt like I was guessing, simply pulling numbers out of the air. No wonder we were so far off.

Estimating the business analysis phase(s) is not easy. It is not hard, but it takes a willingness to think about exactly what work will be produced, and many business analysts do not have the patience. So for those of you who do not have the “stomach” to spend the required time to estimate business analysis, here are some tips.

  1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small.
  2. As we progressively elaborate our requirements, we can progressively elaborate our estimates. We go from Rough Order of Magnitude (ROM) to budgetary (deliverables identified) to definitive (requirements defined to a low level of detail).
  3. It is helpful to use a variety of estimating techniques. When we’re first asked how long business analysis will take, we really cannot be precise. We use analogous estimating, or experience with a previous project. If we have good history, we might be able to use parametric estimates. For example, if we know that it takes two hours to model a business process and we have five processes to model, it will take ten hours to model business processes. Providing detail on each of these techniques is beyond the scope of this blog, however.
  4. I have found it helpful to brainstorm with the people who are actually going to do the work. They usually have a more realistic idea of what needs to be done and how long it will take. I also like yellow sticky notes, since they can be easily added, taken away, and moved.
  5. But here’s the real key to estimating business analysis. Identify all the deliverables (work products, artifacts) you will produce during the business analysis effort. It is essential to first identify the approach you’re going to take, whether plan-or change-driven (Waterfall/Agile). It is also helpful to use the BABOK knowledge areas to identify which work products will be completed. During the course of an Elicitation event, for example, we might send out an agenda (one work product), update our traceability matrix (another deliverable), create an “as-is” process model (another deliverable), and update our list of issues (yet another deliverable). Next we think of the tasks needed to complete each work product, and finally how many hours the task will take.

Of course the real, real key is having the courage to communicate bad news. Which brings me back to the president pounding his fist. What I should have done was reported the plan vs. actual of the business analysis effort regularly, rather than surprising him after months of work.

What a lesson learned!

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]

Avoiding Conflict between the PM and BA. Part 2.

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on Avoiding Conflict between the PM and BA. Part 2.

Planning Business Analysis Work

When I first read the BABOK® Guide, my initial reaction was, “What are they thinking?!” With my PM hat perched squarely on my head, my reaction was “but… but this is PM work!” In my mind I imagined all kinds of conflict occurring as the BA took on more and more of the PM role. After all, as a PM I had done such traditional project management tasks as creating work breakdown structures, activity lists, estimating,  scheduling, and now a body of knowledge was saying that the BA was supposed to do this work? I could see heads butting already.

When I joined the BABOK committee about a year later and raised these concerns, I was asked an insightful question: “Elizabeth,” one of the committee members asked, “as a PM did you come up with all the deliverables, tasks, and estimates for everyone on the project?” Ah, BAs sure do ask good questions! I remembered that as a PM I had gone to many team members, in particular technical SMEs, the developers, our full-time business SME on the project, and others to get their deliverables, tasks, estimates, and availability. But it had never occurred to me to involve the BA. With that one question the light bulb came on. The image of locked horns disappeared. In its place I saw a PM (me) with the weight of too much project planning on her shoulders suddenly stand up straight and unencumbered. How much easier my life as a PM would have been if for the business analysis work, I had taken the information from the BA and rolled it into the overall project. What a relief it would have been to get the business analysis input from the person who knew the most about business analysis!

With the light bulb came a few related insights:

  1. Planning doesn’t mean doing all the work yourself, so PMs don’t have to complete all the planning processes listed in the PMBOK® Guide themselves. PMs need to ensure that all the work appropriate to the project is done, but that does not mean that the work in Section 5.1, Collect Requirements, for example, must be completed by the PM.
  2. BAs are closer to the business analysis effort, so input from BAs is apt to be more complete and correct. When competent BAs are on the project, PMs do not need to micromanage business analysis. There’s enough for PMs to do, so getting out of the way during business analysis will likely reduce the PM’s stress. PMs, so focused on delivering on time and within budget, need to realize that PMs and BAs working collaboratively get more done, so the project has a better chance of completing sooner.
  3. On large projects, both the PM and BA have full-time work doing project management and business analysis respectively. If either is saddled with doing the work of the other, both will be overburdened, increasing everyone’s pressure and stress levels. Under such circumstances, resolving the inevitable territorial conflict will be that much more difficult and take that much more time, delaying the project even further.

So my advice, PMs, is to let the BAs do business analysis work, which includes business analysis planning. My advice, BAs, if confronted with a PM who wants to plan for the entire project, is to keep asking those insightful questions!

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]