On January 22, 1986, NASA’s space flight 51-L, space shuttle Challenger exploded seventy three seconds into the mission killing the crew of seven (Rogers, 1986). Subsequently, the Space Shuttle program was suspended, and a special commission was lunched to investigate the cause of the Challenger accident by President Regan (Greene, 2006). Findings in the report will later show that there were serious flaws in the decision-making process leading to the launch of flight 51-L (Rogers, 1986). Although the accident was caused by mechanical failures, the report showed that mangers at Marshall, a government contractor, did not communicate potentially serious problems with NASA but attempted to resolve them internally (Rogers, 1986). Another contractor, Thiokol Management recommended the launch of 51-L, at the urging of Marshall and contrary to the views of its engineers, in order to accommodate a major customer. Marshall, in an attempt to facilitate the demand for an accelerated space shuttle program, failed to act as part of a system working towards a successful flight by failing to properly communicate with other parts of the system (Rogers, 1986). The Challenger explosion took an emotional toll on the nation and the world, as millions of people watched live as the vehicle disintegrated. In addition to the emotional toll, the financial cost of the accident was in the billions of dollars (Greene, 2006). This is an example of ineffective communication between internal customers (colleagues, or people employed by the same organization), and external customers (contractors, or people employed by a different organization).
Good communication is critical in creating strong business relationships with colleagues and clients (Employee, 2010). When most people are unable to understand the message, they tend to fill in with their own interpretation of their understanding of the issue. This is where the majority of communication errors occur. Even in today's society of information overload, employees often lack the information they need to perform their jobs. They may have the data required from external sources; however, it is the information their supervisors and co-workers have but have not properly shared that remains the cause of major issues (Employee, 2010).
Regardless of what system conceptual model to which you subscribe, good communication is an important element that often determines the success of a project (TechTarget, 1999). This research paper will decompose the various issues associated with communication, or lack thereof, in system development. This paper will be an overview of the various communication styles that exist. Understanding these communication styles will allow system designers to tailor their message for maximum impact. In addition, we will discuss ways to be an effective listener when conducting requirement analysis or interviews with clients and communicating requirements with colleagues. As a system designer, in order to get the right answer, designers need to ask the right question. In many cases, the client is aware of a problem but is unable to describe it in a way that allows system designers truly understand their needs. System designers need to know how to structure an interview to extract the necessary information needed for system development. Adhering to the information and suggestions in this research paper will improve communication in all stages of the system development life cycle and lead to many benefits, including a reduction in development time and cost, as well as an increase in the quality of the systems designed (Danglish, 1998).
To communicate effectively, we must understand the various communication styles. Our communication styles directly affect our relationship with our internal and external customers. Everyone has a communication style. They are four styles that managers, employees, and customers use when communicating: the closed, blind, hidden, and open styles (Hamilton, 2008). Most people tend to have two dominant communication styles and may change communication styles for different situations. For example, an employee will communicate differently as a manager than if he or she had no managerial responsibilites. The following sections will analyze effective ways to communicate with people who communicate differently using the various communication styles.
Most clients or system designers described as closed often have these general characteristics: they are usually productive, hard workers who feel more comfortable working with programs rather than people (Hamilton, 2008). For example, an employee with this style of communication will be more productive at writing programs with little interaction with people, but will be less effective when assigned to a role that involves interaction with clients or colleagues.
Another characteristic of the closed style is their tendency to seek little feedback and disclose little information to others. In some cases, people with this personality type are uncomfortable around others and would prefer to work alone. This can be apparent in low-profile managers, or employees who believe the only way to get through life is by communicating little with others, like customers who may prefer to use the self-checkout lanes at a grocery store instead of interacting with sales clerks. (Hamilton, 2008).
When working with people with this communication style, it is important to reassure they are in a safe environment. This can be accomplished, for instance, in the case of dealing with a client by letting them know that they are free to ask any question and that there are no stupid questions. Encouraging other colleagues and clients to ask basic questions may start the discussion and to encourage the closed communicator to participate (Hamilton, 2008).
Another way to working with clients or colleagues with this communication style is by discussing with them in a one-on-one environment (Hamilton, 2008). Because closed communicators work well by themselves and do not like dealing with large groups of people, one-on-one communication can be very productive. Managers can accomplish this by meeting with clients during requirement gathering, before meetings begin, or by setting up one-on-one meetings with clients.
In most cases, blind communicators are subject-matter experts and can accomplish major tasks with little or no input from others. They thrive in situations in which they can demonstrate their expertise and experience. Blind communicators do not avoid others, and tend to overuse disclosure, telling others their opinions and what others are doing wrong, even when their advice may not be wanted (Hamilton, 2008). It may be very difficult for blind managers to delegate responsibility.
Blind communicators often believe they are "right" and their ideas are usually "better." They are normally experienced and very knowledgeable in system development. However, when colleagues are not allowed to give feedback, try things their way, or make mistakes, productivity declines. Therefore, even though blind managers are good trainers, they do not allow their employees the freedom to lead ther own development projects (Hamilton, 2008).
It is essential to identify this communication style in colleagues or clients. If a system analyst is trying to gather requirements from clients, or the client is a blind communicator, using communication techniques that negate the undesirable characteristics is important.
A common technique used to work with blind communicators is piggy-backing on their ideas. Because people with this communication style are mostly subject matter experts, building on their strengths and ideas can be very beneficial while troubleshooting program bugs and problem solving (LAROCHE, 2006).
People with hidden tendencies prefer social environments and want to be friendly with everyone. Hidden communicators are interested in people, are good listeners, and are generally well-liked. It’s very important to them that everyone gets along and that conflicts are avoided. They are called “hidden” because they often hide their feelings and knowledge from others (Hamilton, 2008). In some cases, they are motivated by mistrust of people, and feel more comfortable when they know what people are doing and require lots of feedback. Hidden people often appear to be interested because they ask questions and stimulate others to share, thereby disguising their lack of disclosure (Hamilton, 2008).
To communicate effectively with clients or customers with this communication style, you must look for non-verbal signs because hidden communicators do not easily disclose information. Demonstrating the importance of teamwork as a means of success is a way to utilize the talent of the hidden communicator (LAROCHE, 2006).
Hidden communicators are ideal for requirement gathering and general communication with clients because of superb interpersonal skills. Their lack of disclosure will ensure that they do not taint the ideas of the client, and their genuine interest in people will allow them to gather a vast amount of useful information from the clients (LAROCHE, 2006).
Open communicators tend to use both disclosure and feedback and are equally interested in people’s needs and productivity (Hamilton, 2008). In some cases, open communicators may disclose too much information which may make people around them uncomfortable. There are generally sensitive to the needs of others and realize that conflict can be productive (LAROCHE, 2006).
Open communicators are best at negotiating and coming up with solutions that satisfy the needs of all parties. This makes them perfect for working with clients, especially in conflict resolution. These empowered employees usually develop quality relationships and increase productivity. Generally, "employees in open, supportive climates are satisfied employees” (Conrad, 2002).
All communication styles have their advantages and disadvantages. If a communication style of an employee or client is identified, a manager can assign this employee to a role that will ensure the success of this employee and satisfaction of the client. This process is essential in requirements gathering and in all general communication with the clients. Having the employee with the most appropriate communication style for the situation will ensure the clients' needs are met.
Effective listening is important in all communication with clients and colleagues. Opportunities and problems are often discovered and solved through listening. One reason effective listening is important in system development is because listening accounts for 80 percent of the time we spend when communicating with clients (Powell, 1983). Studies have shown that 60 percent of errors in system design are caused due to poor listening (Cooper, 1997).
Since everyone does not have the honed listening skills of the open and hidden communicators, techniques to improve listening skills should be used to correct this problem. Here are some ways a system designer can improve his or her listening skills:
To improve your listening skills, you must understand the basic stages of the listening process. The five stages of the listening process are listed below:
Sensing Stage - In this stage, listeners determine the most important information from the multitude of data received (Hamilton, 2008). This stage is the foundation of effective listening. It is impossible to absorb all the information we receive from our clients during requirements gathering. Thus, particular attention is needed in this stage to ensure that the client is fully understood by the system designer. For communication to be truly effective, the system designer must be genuinely concerned about the message that is being communicated (Comer, 1999).
Interpreting Stage - In the interpreting stage, listeners assign meaning to the messages that they have seen, heard, and felt in the sensing stage (Hamilton, 2008). Information is often lost in translation; it is important that the designer often checks for understanding to ensure he or she has understood the clients desires accurately. Some of the errors that occur in this stage occur because the person receiving the information assumes they understand and does not check if the information received from the sender is accurate.
Evaluating Stage – This is the stage where the listener thinks about the message, add inferences, evaluates, and judges the speaker and the message (Goss, 1982). Listeners’ evaluations are often affected by their attitude toward the speaker (Hamilton, 2008). In gathering information, a system analyst needs to make sure he or she is not distracted by other non-verbal communcation that can often detract from the quality of the information received.
Responding Stage - After sensing, interpreting, and evaluating is complete, designers must communicate their feedback to the clients (Hamilton, 2008). This stage allows the client to evaluate the messages they sent and whether the designer correctly understood their desires. This is the stage where errors from the interpreting stage are identified and corrected.
Memory Stage – This is the final stage where processed information is stored and can be transmitted or shared with other people. People generally tend to remember only 10 to 25 percent of a presentation they have heard the next day, week, or month (Wolff, 1983). This is one reason why we need to thoughtfully organize, effectively deliver, repeat, and present clearly to facilitate the retention of the information presented (Hamilton, 2008). When gathering information from clients, keeping proper notes with a pen and paper or using a recording device may aid proper commitment to memory.
In summary, it takes significant effort to become and effective listener. Awareness of the various phases in the listening process will allow us identify areas where communication tends to break down. Effective listening is crucial to all stages in system development, which is where communication between two or more parties occurs. As indicated in the introduction of this research paper, an effective solution for the wrong problem is worthless. System designers should focus on what is most important: translating and transmitting information in an organized way.
This section is going to cover ways system analysts should organize questions during the requirement gathering phase when using any system methodology. In the beginning of a project, an analyst will spend a large amount of time interviewing people about how they perform the tasks associated with their work and interviewing other stakeholders to understand the structure of the organization (Hoffer, 2006). If questions are structured in the proper way, the interviewer can maximize the quality of information received from the interviewee. A properly structured interview will also allow the interviewer to resolve conflicting information, as well as uncover the root causes of problems of which the owners of a system maybe unaware. Below are methods to effectively structure interview questions:
Open-Ended Questions – These questions are broad in that they allow the interviewee maximum freedom in deciding how much and what type of information to share (Hamilton, 2008). The person being interviewed is encouraged to talk about whatever interests they have within the general scope of the questions (Hoffer, 2006). Examples of open-ended questions include:
“In your own words, what would you stay are the greatest drawbacks to the information system you currently have?”
“Tell me more about your existing information system.”
“What are the features you rely on the most in your current information system?”
Based on the answer the answer received, the system desinger can then determine if a follow-up question is needed.
Open-ended questions are effective because interviewees find them easy to answer (Hamilton, 2008). A major drawback of open-question is that the answers may be time consuming or of little relevance to the issues the interviewer is attempting to explore.
Closed Questions – Another way to frame interview questions is using of closed questions. Closed questions are located on the other end of our question control continuum shown in the chart above. Compared to open-ended questions that give the interviewee maximum control in their answers to a question, closed questions limit this control and allow the interviewer to focus on a specific issue (Hamilton, 2008). Here are some examples of closed questions:
“What system interface do you prefer to work with? SAP, ORACEL or UNIX?”
“What type of database management system would you wish you had? MySQL, ORACEL, or IBM?”
Including an “other” option to the list of answers allows the interviewee to answer a question as they chose, and reduce the constraint of the closed question (Hoffer, 2006). A disadvantage of closed question is that it does not allow for a detailed explanation.
Hypothetical Open Questions – This is the most flexible way to structure a question, and allows the interviewee answer the question in whatever way they prefer. It is important to note that hypothetical type of question have the same type of advantages and disadvantage as open-ended questions (Hamilton, 2008).
There is no one way to structure interview question. Each type of interview question has certain advantages and disadvantages. The best way to overcome these drawbacks is to use a combination of question types.
Questions used in requirement gathering can be organized in either the funnel sequence or the inverted funnel sequence.
Funnel Sequence – Questions following this sequence move from the general (open-ended or hypothetical question) to the specific (closed) (Hamilton, 2008). The funnel sequence is a very popular method used in structuring questions. Examples of the funnel sequence include:
Inverted Funnel Sequence – Questions following the inverted funnel sequence move from specific to general (Hamilton, 2008). Examples include:
The answers from questions like this will allow you judge if your client is concerned about spending money or would prefer the freedom to fully customize applications to suit their needs.
Hourglass Sequence - This method is mostly used in clarifying information received through the funnel sequence method. When an interview reaches the closed stage of questioning, and if they are not sure or confused by the answer they received in this stage, an open-ended question can be used to clarify or to ask more questions to clarify the previous answer (Hamilton, 2008).
Diamond Sequence – The diamond sequence is used when the answer to your final (open-ended) question in an inverted funnel sequence is unexpected (Stein, 2004). To clarify the answer, you will want to reopen the questioning, starting with a general question and then moving to more specific queries until the interview ends with a closed question (Hamilton, 2008).
Before customer requirements can be analyzed, modeled, or specified they must be gathered through communication (Pressman, 2005). Proper communication is necessary in all interactions between colleagues, especially for any given project to be successful. In the past, departments and teams worked independently and only communicated the final results of their piece of the project with other teams and suppliers only after their task was completed (Martinich, 1997). This style of communication leads to poorly developed products, which often does not meet the requirements of the clients. The cost of product development is very costly if suppliers are not consulted on alternative solutions (Martinich, 1997).
Good communication is the difference between a properly designed system and a poorly designed system. A poorly designed system will lead to a loss of clients, loss of money, conflict among colleagues, and client dissatisfaction. In extreme cases poor communication can result in the loss of lives, as shown in the accident of the Challenger space shuttle(Atwood, 2006). Understanding the communication styles of system developers allows managers to assign roles in system development so that colleagues increase the chance of success. Listening is one of the most challenging skills necessary in effective system design (Phariss, 2006). Proper listening plays a major role in ensuring system developments' success. Knowing how to ask the right types of questions and how to structure interview questions improves the quality of information available to system designers.
1. Atwood, J. (2006, November 20). Coding Horror: Programming and human factor. Retrieved November 11, 2010, from Coding horror: http://www.codinghorror.com/blog/2006/10/the-iron-stool.html
2. Comer, L. B. (1999). Active empathetic listening and selling success: A conceptual framework. Journal of Personal Selling and Sales Management, 15-29.
3. Computerperformance. (2007, June 15). Computerperformance. Retrieved November 20, 2010, from SharePoint: http://www.computerperformance.co.uk/Sharepoint/SharePoint.htm
4. Conrad, C. &. (2002). Strategic organizational communication: Into the twenty-first century. Ft. Worth: Harcourt Brace.
5. Cooper, L. O. (1997). Listening competency in the workplace: A model for training. Business Communication Quarterly, 75-84.
6. Danglish, B. (1998, August 10). LMCS GOES INTO ORBI. Retrieved November 11, 2010, from LexisNexis: http://www.lexisnexis.com.ezproxy.umsl.edu/hottopics/lnacademic/
7. Employee, A. (2010, March 21). anonymousemployee.com. Retrieved November 1, 2010, from AE: http://www.anonymousemployee.com/csssite/sidelinks/poor_communication.php
8. Goss, B. (1982). Listening as information processing. Communcation Quarterly, 30, 306.
9. Greene, N. (2006, January 28). Space and Astronomy. Retrieved November 2, 2010, from About: http://space.about.com/cs/challenger/a/challenger_2.htm
10. Hamilton, C. (2008). Communicating for Results. Belmont: Thomson Higher Education.
11. Hoffer, G. V. (2006). Mordern System Analysis And Design. Uper Saddle River: Pearson Prentice Hall.
12. Hunter, B. (2002, June 11). The Subtle Benefits of Face-To-Face Communication. Retrieved November 11, 2010, from stanford: http://www.stanford.edu/class/symbsys205/facetoface.html
13. LAROCHE, N. R. (2006, November 20). A Primer to Communicating as a Systems Analyst in Today’s World.
Retrieved November 11, 2010, from A Primer to Communicating as a
Systems Analyst in Today’s World:
http://www.nathanielandstephanie.com/is6840/index.htm
14. Martinich, J. S. (1997). Production And Operation Management. New York: John Wiley & Sons, Inc.
15. Phariss, R. (2006, November 29). Requirements Definition in IT Systems Development.
Retrieved November 11, 2010, from Requirements Definition in IT
Systems Development:
http://www.umsl.edu/~sauterv/analysis/f06Papers/Phariss/
16. Powell, J. T. (1983). Listen attentively to solve employee problems. Personal Journal, 62, 580-582.
17. Pressman, R. S. (2005). Software Engineering: A Practitioner's Approach. New York: Mc Graw Hill.
18. Rogers, W. P. (1986, June 6). Report of the Presidential Commission on the Space Shuttle Challenger Accident. Report of the Presidential Commision, 82-118.
19. Stein, M. L. (2004, January 21). Information Interview. Retrieved November 11, 2010, from roguecom: http://www.roguecom.com/interview/module5.html
20. TechTarget. (1999, March 23). Software Development Lifecycle.
Retrieved November 9, 2010, from searchsoftwarequality:
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755068,00.html
21. The McGraw-Hill Companies, Inc. (2004). Phases of Value Methodology. Manufacturing Engineer, 17-18.
22. Valkovski, B. J. (2010, March 1). Video Conferencing.
Retrieved November 12, 2010, from Ezine:
http://ezinearticles.com/?An-Introduction-to-Video-Conferencing:-Basics-and-Benefits&id=121411
23. Wolff, F. I. (1983). Perceptive listening. New York: Holt, Rinehart & Winston.