Skip to main content

Author: Elizabeth Larson

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is a consultant and advisor for Watermark Learning/Project Management Academy, and has over 35 years of experience in project management and business analysis. Elizabeth’s speaking history includes keynotes and presentations for national and international conferences on five continents. 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 several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 6 grandsons and 1 granddaughter.

Slaying the Dragon: Oldies but Goodies in an Agile World

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

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

Tips and Tricks for Facilitating Conflict Resolution

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

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

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

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