Skip to main content

BA & QA

During a business analysis transformation project at a large organization, I had a quality assurance management executive ask me what the BOK says about QA.  Surprisingly little, and in my opinion, rightly so.  The quality movement succeeded in Japan, and mostly failed in the U.S., because in the U.S. QA was given out as if it was a separate job.

BA IS QUALITY, and I quote Edward Deming and his followers to make the point.
http://en.thinkexist.com/quotation/if_you_can-t_describe_what_you_are_doing_as_a/12330.html 

“You can’t inspect quality into a product – the quality is already there.”  In other words, you must examine how you do things, not what you have done.

“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”  Indeed, they don’t.

“It is not enough to do your best; you must know what to do, and then do your best.”  If only – so many projects work so hard so everyone can feel good about their contribution, as if every contribution was the “best”.

“We should work on our process, not the outcome of our processes.”  Can you spell BPR?

“Quality is everyone’s responsibility.”  Goodbye, ineffective QA Managers?

“If you do not know how to ask the right question, you discover nothing.”  This is why elicitation of requirements is such a key “art” for BAs – how do you explain what else to ask?  Experience!

“Does experience help? NO! Not if we are doing the wrong things.”  BA is committed to doing the right thing – no wonder it struggles for status in the U.S.

“It is not necessary to change. Survival is not mandatory.”  As demonstrated by the last two large IRS IT projects (look ’em up!).

And my contribution:  “If there is no significant change in the business, there is no significant requirement to analyze.”

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!

© 2009 Marcos Ferrer

The Realities of Surveys in Requirements Gathering

Requirements gathering techniques include the easy to send, but sometimes hard to develop, survey method to obtain data from a wide variety of people located anywhere. Surveys, however, are notorious for many faults such as ambiguity and a lack of response.

But surveys can produce a large volume of information for the gathering parties to peruse and collate, so developing good surveys is important for both the respondents who have to understand the questions and for the collators to get useful data.

Statistics Prove “IT”

It has been said you can prove anything with statistics if you ask the right question. Obviously, you need to ask the right questions to get the right data. Right?

Reality can be different. The interpretation of an ambiguous question, an open-ended question, a leading question, or a question made up of words most people do not understand, can be very detrimental to getting the answers you need.

For instance, if the requirements were related to virtualization of your datacenter equipment, you should avoid being too general or assume too much knowledge on the part of the respondent.

Ambiguous Question examples:

How does it help?
Who can use this?

Open Ended Question examples:

Why do you need this feature?
What services would help you?

Leading Question examples:

If this service were to fail, who would be affected?
Without web based access to this device, what can be done?
Who amongst your group has the necessary required certifications?

The “Right” Questions

So what is the right question to ask? You do not want to insult your respondent nor do you want to assume they understand the situation or concepts entirely.

How can you ask the right question? Ask an eight year old. Or rather, pretend the audience is eight years old. Assume they do NOT have a vast knowledge of the topic, a slanted knowledge of the world, or possibly a jaded view of the system. Use simple language that is less likely to be interpreted differently.

Provide respondents with some background information or assumptions at the beginning of the survey, or point them to relevant documents or websites they can use to clarify the concepts and issues.

Avoiding Acronyms and Industry Jargon

Often times, in the technical world, we have developed our own jargon or acronyms for the myriad technologies, services, applications, and such that we developed and/or have to deal with every day. For instance, SMB is one acronym that has vastly different meanings depending on your perspective. A recent book had this acronym within the title, and it was very confusing for the network specialist who later found out the book was meant for a general business type audience. What does it mean to you? In the book context, it was Small- to-Medium Business, to the technician, Server Message Block. To my kids on their instant messaging service, it meant So Much Better.

The standard axiom of KISS (or, Keep It Simple, Stupid), applies for questions – keep them short and simple but clearly to the point. In some cases, a preliminary paragraph stating the base assumptions will help to clarify the premise for the questions.

In Requirements Gathering

A common method of gathering requirements from many stakeholders, when interviewing or workshops are not prudent, is to send a general topic survey of questions in the early phase of discovery. These general questions should lead toward more specific questions as the discovery phase progresses. This is when specific questions become more critical. The questions must be very topical or delivery-oriented, maybe even very technical in nature, and yet they must ensure the respondent clearly understands both the premise and concepts.

For instance, a general trend today is toward using virtualization. Most people have no idea what this really means or even implies. To make your survey results more coherent, you may need to include references to websites, local or external, that explain the concepts. Have multiple people within your organization peruse these materials to assess their usefulness, and employ a wide cross-section of people to gauge if the content is technical in nature. You should not rely exclusively on technicians for feedback.

Survey Says …

The right questions on a survey may not always be enough. In some cases, the options to respond and/or the choice of responses can affect your survey results.

Fixed answers, such as in multiple choice, should give the reader plenty of leeway for their decision. Be as wordy as necessary for each choice, without too many overlapping or confusing variations of the same request.

Assumptions

Surveys have to assume some level of knowledge for the respondent, but that is not always achievable when dealing within different technical or managerial staffing levels.

For instance, the following question assumes a great deal of knowledge on the part of the respondent:

Q. How would your department benefit from using virtualization?

This is a rather open-ended question requiring the respondent to be very familiar with the topic and critical about the lack of virtualization use for a long time. To improve this question, provide some options that will make sense rather than have the respondent come up with all the answers:

Q. In an effort to reduce our data-center footprint, the company has been looking into the possibility of moving toward the use of specialized hardware that maintains the separate host services on a centralized, redundant virtual computing platform. Each current host that meets all the criteria (see website //xxx/criteria for details) for being virtualized will be transitioned to the virtual environment. How would your department benefit from using virtualization?

Redundancy [ ] Backups [ ] Ease of recovery [ ] Availability [ ]
Reduce licensing requirements [ ] Reduce number of physical boxes [ ]
Reduce management overhead [ ] Reduce resources [ ]
Expand service levels [ ] Ease of testing [ ] Ease of deployment [ ]

This may be too limiting, instead provide a range of responses

Q. [same intro] How would your department benefit from using virtualization?
(Scaled response with 1 being the least important and 5 being the most important)

This might be followed-up later with questions that specifically define some of the key attributes for switching to a virtualized platform or not.

Q. Select all that apply to your server:

Server provides: [ ] file [ ] print [ ] dns [ ] AD [ ] other _____
Comments: _________

Service must be: [ ] kept separate [ ] own IP [ ] behind firewall
Comments: _________

Setup requires: [ ] Win2K [ ] Win2K3 [ ] Win2K8 [ ] XP [ ] Linux
Comments: _________

Survey Choice Option Default Settings

Surveys often provide a scale for their responses. Some include as few as three options, while others may have 10 or more within the range. There is no best answer, although five to eight choices are probably more than adequate for most ranges.

Imagine a now defunct restaurant asked you to fill out their web-based survey as you left the restaurant. They failed, however, to put an easy-to-find link to the survey on their website. After searching the entire main page, and a few subsequent pages, a small, bottom menu link was eventually found. Within the survey web page, there was a simple explanation of their scale being from 1 to 5, for the 10 questions presented. Each question ended with the same simple drop down list. The default drop down value was preset to 1 for all 10 questions. This may have been planned or not, but it might produce a lot of low results.

Common survey choice ranges include:

“Excellent, Good, Fair, Poor, N/A”

“Strongly Agree, Agree, neutral, Disagree, Strongly Disagree”

“1=Very Bad to 5=Excellent”

“1 is worst, and 10 is best”

Clearly, each of these ranges requires questions that would elicit such a response from the expected target audience. However, do not expect that you will get the top-level choice. How often are you told you are doing an “excellent” job as apposed to a “good” job? Probably not very often. So why would you expect the general public to give a 5 or 10, an Excellent or Best response? Why would you then assume anything else is unfavorable if you have not clearly defined to the respondent what each choice represents?

Do Ranges Reflect Expectations?

The option “Good” could mean many things to many people such as: good, good enough, acceptable, expected norm, at least as good as you expect, etc. This is especially true when the “Excellent” response is the only one good enough. If anything other than “Excellent” is not good enough, ensure the respondent knows that they have to explain why they did not select “Excellent.”

In many hotels, you are given a document requesting that you call the local manager if there is anything that is not to your liking at any time. They want to provide you with a “10 out of 10” experience every visit. They conveniently provide a survey form for when you leave. What do you think happens if you do not fill out the survey for your stay? Perhaps an automatic “10” for that visit?

In some local grocery and department stores, they now have “Outstanding Service” forms you can fill out to honor anyone who has gone out of their way to provide exemplary service for you. No mention of where to enter complaints.

Can you remember your last few visits to a restaurant and a large department store? What was your experience? What was your expectation? What would you expect to be asked? Which range would you expect for the answers?

Surveys Everywhere

Surveys are now ubiquitous throughout the world and we have developed a love-hate relationship. We love to send them but hate to respond to them. We, and this is a collective “we,” tend to ignore most surveys unless there is something in it for us. There are companies on the Internet that offer rewards for filling out surveys from their clients.

Many years ago, a former boss had a great philosophy about surveys done by large groups of customers. He would sort them according to rank, from best to worst, and then ignore the first and last to get the average. He assumed that there was always one in the crowd who had a weird idea of what “good” meant, and he balanced this against those who just quickly gave a general “good” or “excellent.”

There are lots of ways to interpret survey results – many of them bad!

The professional sports teams have all sorts of methods, or “improvements,” to make their stats look good. There are rules for how stats are accepted and interpreted. They usually keep a running total, not just the single events. Keep this in mind when you are working on your results. Taken in small groupings, there can be wide swings in averages. Taken in gross, these averages of averages are more consistent.

In Summary

The usefulness of a survey is in the responses that are received. Be as helpful as possible to the respondents by ensuring they have sufficient information and knowledge to complete the survey. Strive to provide a reasonable and clearly stated range if used. Restrict the space for open-ended questions and keep the questions as simple and succinct as possible, so that anyone can understand each question. Adding an incentive for respondents to complete the survey quickly may also speed up the process. Surveys can take a long time to prepare, collect, and collate but with careful planning, a well-executed survey can simplify the process of gathering requirements.


David Egan is a Course Director and developer of content for more than 20 Global Knowledge courses. David has more than 20 years of teaching experience including more than five years of teaching ‘on-line’ virtual classes over the Internet using Centra, Interwise and iLinc virtual classroom services. David has also written technical books and delivered adult learning seminars on UNIX, Linux, Microsoft Operating Systems and Services, as well as Business Process Analysis and Project Management since 2005. David and his family live in a suburb of Vancouver, B.C. This article was originally published in Global Knowledge’s Management in Motion e-newsletter, Business Brief. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training.

Copyright © Global Knowledge Training LLC. All rights reserved.

The Teamwork Model

People fall into the following three levels of teamwork:

Level 1: Individuals. Individual performers on solo projects.  Within a limited scope individuals can deliver exceptional results.

Level 2: Groups. A group includes the participants and a leader.  The team’s final product is a joint contribution and reflects the strength of the group as a whole.  Teams at this level take time and require a stable environment to build working relationships amongst the participants.

Level 3: A Collection of Individuals. This level of teamwork exemplifies the positive attributes of individuals and groups.  A Collection of Individuals is able to tackle the most ambitious and difficult projects.  Each member is a master craftsman.  At this level of teamwork the product reflects the strengths of individual participants and the group as a whole.  Level 3 teams typically do not require a stable environment and may, in fact, thrive under changing circumstances.

The business world demands that Collections of Individuals be formed on an ad hoc basis.  In many cases it is neither cost effective nor an efficient use of resources to commit a group of people to the same set of tasks for any length of time. While it may be unrealistic to expect a level of true mastery from everyone it should be the goal we all strive to achieve.

Requirements Definition for Distributed Teams

Last month, we talked about Requirements Definition for Outsourced teams. In this article, we are going to explore a new dimension to requirements definition challenges that looks at the reality of today’s distribution of departments, personnel, and company locations. While there have been many drivers behind today’s distributed workforce, much of it has been driven by the record number of mergers and acquisitions in the past five years. IT teams are finding it “normal” to engage with peers and internal customers located in different buildings or even in different time zones. Gathering and defining requirements can be quite a challenge in this environment.

Automating and Empowering Critical Business Processes

Today’s business application software is relied on to automate and empower critical business processes. There is not an organization in the developed world that can process a sales order, hire an employee, or close their book at the end of a fiscal year without the help of business software. Software is not an accessory to the business, it is the business.

In today’s software development landscape, project teams are consistently being stretched to deliver against increasing business challenges to enable an organization to sharpen their competitive advantage. In a global market place, this continual pressure on IT is not just stretching team capacity; it is actually stretching the organizational structure as well. In fact, in 2009, over 70% of business and IT teams are geographically distributed and globalization is the business driver for the majority of new projects [1].

With geographical distribution becoming the standard operating procedure, collaboration between business and IT teams around project requirements has become a new focal point to control project team efficiency and effectiveness. Organizations must improve the fidelity and precision of their software requirements to ensure that IT delivers the right solutions that the business needs. Communication of project requirements must evolve to eliminate the cultural, geographic, and time-zone barriers that now exist between these separated colleagues.

This article explores how software projects are improving the collaboration between distributed IT and business teams by focusing on requirements communication. We will explore how visual requirements simulation plays a critical role to ensure understanding and to eliminate barriers to productivity that naturally exists within distributed, global teams.

Requirements Analysis: Becoming More Complex

Requirements are the blueprint to the functionality, interoperability, and integration of business software. As more organizations drive to streamline, consolidate, and modernize existing applications, the complexity of requirements is increasing. Analysis of requirements has become a job within itself, with an emerging dedicated stakeholder that services the development and communication of project requirements to business and IT stakeholders. This stakeholder is commonly referred to as the business analyst or business systems analyst.

As the world continues to get smaller and businesses expand to reach new markets and lower-cost suppliers, globalization has become a major driver of IT projects. In 2009, the majority of IT projects are designed to assist businesses scale to meet the needs of globalization. According to a recent CIO survey by Smart Enterprise on Globalization and IT, over 50% of IT teams are being asked to build systems for non-US supply chains, 40% are being asked to deliver software applications that leverage third party technology service providers and 60% of new projects are serving customers in a different country.

On top of the increasing complexity of IT projects driven by globalization, team distribution has become a critical operational challenge. According to a recent report from the IEEE, “key risk factors associated with IT development projects are magnified or multiplied when dealing with distributed project teams.” Distributed teams are largely in place due to business impacts from globalization. Typical drivers include the increase in mergers and acquisitions, the need for new talent pools, the leveraging of lower-cost resources, outsourcing, and overall business geographic demand. According to the IT Strategy Center, the most significant impacts of distributed teams are directly related to communication of business context, the implementation of language barriers, time zone separation, the lack of physical exchange, and the reliance

on batch oriented communication.

CIOs can adopt new requirements definition practices and techniques to appropriately eliminate the risk associated with distribution. These practices include shifting away from the heavy use of natural language expression and moving toward the use of multi-aspect requirements definition with visual simulation and validation. Multi-aspect requirements definition enables organizations to standardize on rich requirements that eliminate ambiguity and imprecision that often exists in the geographic separation of teams.

Levels of Geographic Distribution

My company’s customers range across four distinct levels of team distribution. Each level creates a unique set of challenges for defining and communicating project requirements. Figure one illustrates these four levels of distribution.

At level one, business and IT teams are co-located within the same building and location. Just ten years ago, this was more common than any other level, but in 2009 this represents less than 30% of Fortune 500 IT teams. At level two, business and IT teams are distributed at a department level. IT is usually centralized and acts as a service arm to the business. At level three, business teams themselves, or IT teams themselves, are geographically separated, which increases the complexity and challenges of inter-department collaboration. Finally at level four, globalization has created the ultimate geographic challenge, with team separation and distribution pervasive across the globe. With globalization and the rise of outsourcing, this has become all too common.


Figure One: Four Levels of Team Distribution

As organizations evolve to embrace more distribution, the challenges to understand the context of application requirements increase significantly. These challenges include intra-teams functional capabilities, task understanding, gaining organizational consensus, and the cultural challenges to understanding. In Figure Two, we overlay how these challenges (and risks associated with them) increase significantly as teams become more distributed.


Figure Two: Challenges to Alignments of Distributed Teams

Challenges of Requirements Communication with Distributed Teams

As we discussed in the previous section, geographic distribution injects new challenges to IT productivity and alignment. Requirements communication fits squarely into the center of the challenges of distributed teams. Traditional methods of communicating requirements, which include enumerated lists of features, functional and non-functional requirements, business process diagrams, data-rules, etc., generally are documented in large word-processing or spreadsheet documents. When applied to distributed teams, this method of communicating requirements creates significant waste and opportunities for failure, as the barrier to understanding can become too great to overcome. Incorrect interpretation and the lack of requirements validation can create artificial (or false) goals which consume valuable team resources. Due to the nature of software development, these false goals usually manifest themselves into incorrectly implemented code, resulting in costly waste and rework.

Outsource providers often treat such rework as change, resulting in costly charge-backs to the business.

Multi-aspect Requirements Definition for Distributed Teams

To significantly reduce the probability of ineffective requirements communication through natural language documentation, IT organizations are transitioning to more precise vehicles to communicate requirements. One of these vehicles is the adoption of the multi-aspect definition approach to communicate requirements in a highly visual way. Multi-aspect definition provides detailed context capture through highly precise data structures. These definition elements used in these holistic representations include use-cases for role (or actor) based flows, user-interface screen mockups, data lists, and the linkage of decision-points to business process definitions. These structures augment enumerated lists of functional and nonfunctional requirements.

The benefits of this approach include the use of simulation to ensure requirements understanding. Simulation is a communication mechanism that walks requirements stakeholders through process, data, and UI flows in linear order to represent how the system should function. Stakeholders have the ability to witness the functionality in rich detail, consuming the information in a structured way that eliminates miscommunication entirely.

Multi-aspect definition and simulation also provide context for validation. Validation is the process in which stakeholders review each and every requirement in the appropriate sequence, make appropriate comments, and then sign-off to ensure the requirements are accurate, clear, understood, and are feasible to be implemented. Requirements validation can be considered one of the most cost-effective quality control cycles to ensure team understanding. Since requirements are the “blueprint” of the system, distributed stakeholders can make use of multi-aspect definition and simulation during implementation to gain understanding of the goals of the project. Simulation eliminates ambiguity by providing visual representation of goals which, in turn, eliminates interpretation.

Rich requirements documentation often is a specified deliverable for most IT projects for various reasons that include regulatory compliance (Sarbanes Oxley, HIPAA, etc.), internal procedural specifications, and other internal review cycles. Multi-aspect definition can serve as the basis of this documentation and next generation requirements workbench solutions (such as Blueprint Requirements Center) can transform models into rich, custom Microsoft Word documentation. Since these documents are auto-generated, the amount of effort required to build and maintain these documents is minimized.

The Solution: A Case Study

PAREXEL is a world-leader in biopharmaceutical research. Some of the world’s largest drug, biotech, and medical device firms make use of their clinical research, consulting and medical communications services. PAREXEL was in the early stages of a major $1.2M upgrade to their revenue forecasting system. This project involved project staff distributed across many countries. They were already using HP Quality Center for requirements management test planning and management. At this early stage in the project they were already noticing issues with the requirements they had defined. General observations were that the requirements were too ‘wordy’ and abstract. Clarity had been lost in the translation of original business need into system functional requirements, and there were numerous instances of misunderstanding and misinterpretation of the requirements which, to that point, had been expressed using flat-file documents. During this early phase they took the opportunity to evaluate tools that might help with these requirements issues. Blueprint was one of the products considered and was ultimately chosen partly due to its capabilities to support distributed requirements definition teams.

The development results of the very first module defined using Blueprint Requirements Center was enough to extend its use to all enhancements of PAREXEL’s financial applications. The first module defined using Blueprint Requirements Center saved three months of rework effort.

The full extent of Requirements Center’s feature set is now leveraged to span the complete requirements lifecycle including requirements lists, use case models, user interface mockups, simulations, and the generation of assets automatically, such as tests and documents.

PAREXEL has established a corporate Blueprint forum and knowledge base and is currently in the process of expanding use of Blueprint Requirements Center to other departments throughout the organization.


Matthew Morgan is a 15 year marketing and product professional with a rich legacy of successfully driving multi-million dollar marketing, product, and geographic business expansion efforts. He currently holds the executive position of SVP, Chief Marketing Officer for Blueprint, the global leader in Requirements Lifecycle Acceleration solutions. In this role, he is responsible for strategic marketing, partner relationships, and product management. His past tenure includes almost a decade at Mercury Interactive (which was acquired for $4.5B by HP Software), where he was the Director of Product Marketing for a $740 Million product category including Mercury’s Quality Management and Performance Management products. He holds a Bachelor of Science degree in Computer Science from the University of South Alabama. He holds a Bachelor of Science degree in Computer Science from the University of South Alabama.

Men and Women and Workplace Communication

We know that men have a different workplace communication style than women – but does “different” mean better?

Well, yes…..and no!

There are obvious strengths and weaknesses in the communication styles of both genders. Based on a recent research project, in which I collected responses from 387 employees and managers in the United States, Canada and Europe, I found that both sexes identified the same set of strengths and weaknesses in themselves and each other.

On that, at least, we all agree.

This study reinforces other research I conducted for my book, The Nonverbal Advantage: Secrets and Science of Body Language at Work. As you look at the findings below, notice how much of what people call “communication style” is determined not by the words someone is speaking, but what their body is saying.

Top three communication strengths for females:
1. Ability to read body language and pick up nonverbal cues.
2. Good listening skills.
3. Effective display of empathy.

Top three communication weaknesses for females:
1. Overly emotional.
2. Meandering – won’t get to the point.
3. Not authoritative.

Top three communication strengths for males:
1. Physical presence.
2. Direct and to-the-point interactions.
3. Body language signals of power.

Top three communication weaknesses for males:
1. Overly blunt and direct.
2. Insensitive to audience reactions.
3. Too confident in own opinion.

To best understand these findings, however, it’s important to consider them in the context of workplace applications and implications:

For example, there is no “best” communication style for all workplace interactions. Women have the edge in collaborative environments (where listening skills, inclusive body language, and empathy are more highly valued), and men are seen to “take charge” more readily (and viewed as more effective in environments where decisiveness is critical).

In all cases, a strength turns into a weakness when overdone. (A female’s collaborative style can come across as indecisive and a male’s directness can be taken as callousness or disregard for other opinions.)

To a woman, good listening skills include making eye contact and reacting visually to the speaker. To a man, listening can take place with a minimum of eye contact and almost no nonverbal feedback. (Women often cite a lack of eye contact as evidence that their male boss “doesn’t value my input.”)

Men are more comfortable when approached from the side. Women prefer approaches from the front. Likewise, two men speaking will angle their bodies slightly, while two women will stand in a more “squared up” position – a stance that most men perceive as confrontational.

When a man nods, it means he agrees. When a woman nods, it means she is listening.

Female superiority in reading nonverbal signals during business meetings allows women to accurately assess coalitions and alliances just by tracking who is making eye contact with whom at certain critical points.

Men are judged to be better at monologue – women at dialogue.

A man’s ability to hold his emotions in check and to “keep a poker face” is viewed as an advantage in business situations. A woman’s tendency to show her feelings more outwardly in gestures and facial expressions is perceived as a weakness.

When a woman can’t read the person she’s talking to, it makes her anxious. Men’s ability to mask their facial expressions causes uneasiness in women, who often perceive this as negative feedback.

Men are larger, taller and, because we typically equate mass with power, they gain an instant sense of “presence.” Females can compensate by standing straight, broadening their stance, and even putting their hands on their hips in order to take up more physical space.

Women sound more emotional because they use approximately five tones when speaking – and their voices rise under stress. Not only do men have a deeper vocal range, they only use approximately three tones.

Male body language is more likely to emphasize stature, composure, and confidence. Men also send signals of indifference, disagreement or smugness far more often than women do.

As women make decisions, they tend to process and think of options out loud. Men process internally until they come up with a solution. This can lead to problems if a male thinks that the female’s verbal brainstorming means that she’s looking for approval rather than just thinking aloud.

Men’s discomfort dealing with emotion leads them to believe that there needs to be a solution, rather than understanding that sometimes people just need tbe heard.

Because they access the full message (words and body language), women are better at watching and listening for reactions. This allows them to ensure that they are being understood, and adjust accordingly.

In negotiations, men talk more than women and interrupt more frequently. One perspective on the value of speaking up comes from former Secretary of State Madeleine Albright, who – when asked what advice she had for up-and-coming professional women – replied, “learn to interrupt.”

Men make direct accusations (You didn’t do it!) while women use an indirect method (Why didn’t you do it?)

Women are viewed as less professional when they resort to girlish behaviours (twirling hair, playing with jewellery, etc.) or flirtatious body language (tossing hair back, crossing and uncrossing legs, etc.).

Men who don’t know each other well tend to keep a greater distance between them than women who have just met. This difference in interpersonal distance as determined by gender is even true in Web 2.0’s online communities (like Second Life) where many of the unconscious “rules” that govern personal space in the physical world can be found in the virtual world.

Women are viewed as lacking authority when they try to avoid confrontation and conflict, when they are unnecessarily apologetic, when they are too focused on pleasing others, when they smile excessively or inappropriately, and when they discount their own ideas and achievements.

So Venus or Mars – whichever you are – the trick is to know when your communication style is an aid to success. And when it becomes a deterrent. Comparing your strengths and weaknesses to these generalized gender differences is one place to start. And enlarging your repertoire of communication skills, so you can employ strategies that are most effective under various circumstances, definitely gives you an advantage.


Carol Kinsey Goman, Ph.D., is an author and keynote speaker who addresses association, government, and business audiences around the world. Carol is the author of 10 business books. Her latest is The Nonverbal Advantage – Secrets and Science of Body Language at Work. She is an HR columnist with Troy Media Corporation