IS6840 Term Paper


A Primer to Communicating as a Systems Analyst in Today’s World


You want what?


       “But half the team is in India, the other half is in Argentina, and I’m stuck in Peoria, Illinois!” That is the reaction from one particular System’s Analyst, myself, after hearing from one of two managers that I reported to working for a major consulting firm. I had just been asked to change some of the requirements, earlier defined by the client, by the end of the day. The problem at the time was that my manager did not understand that while the “end-of-day” in Peoria was two hours away, the day was wrapping up in Argentina and hadn’t even started in India, a matter of fact the work day in India wouldn’t start for hours. This request will require some quick and efficient communication to meet Argentina’s needs and then I’ll have to burn some midnight oil to communicate the changes to my Indian colleagues. How could this have been handled better? How could I, as a Systems Analyst working with teams around the world, better communicate with them? Luckily there are models of communication and tools that can help a Systems Analyst navigate today’s environment of matrix management and distributed teams, the same matrix management and distributed teams that produce complex systems and difficult problems.
       Together we’ll touch on the environment Systems Analysts must navigate: the complex systems, complex problems, complex organizations, and complex teams. We’ll explorer the importance of expectation setting, models to help understand and facilitate communication, and physical tools that can help streamline the complexities. This will be discussed in the perspective of the Systems Analyst-Client relationship and the Systems Analyst-Team relationship. Whether that client is an internal group or person to the company the Systems Analyst works for or whether the Systems Analyst works for a consulting firm with a contractual obligation to the client, the same end goal of a successful system analysis and implementation resulting in customer satisfaction applies. The team aspect could be as a manager of a team or as a team member in a non-management role, in either role the importance of understanding the complexities, models, and tools facing and provided to a Systems Analyst cannot be underestimated. In both the client and team relationships understanding the environment and the communications needs of that environment, as well as the tools available, are imperative to success.


Complex Environments, Complex Organizations, and Complex Teams…oh my!


       The most complex industry in the 1800s could very well have been a grain mill grinding grain to produce flour. Here a few individuals would work in the mill but there probably was not a large degree of specialization and the system certainly wasn’t overly complex. As we jump to the 1900s Henry Ford popularized the assembly line. Suddenly there is a lot more specialization and interdependencies. If the individual at the previous station did not manufacture a part or install his or her piece correctly then every person further down the assembly line could be affected. Here the system was getting more complex and tweaking or changing on part could have a profound impact on the entire process. Now we are in the twenty-first century with distributed systems. Less and less teams are in assembly lines located under one roof. Instead teams are increasingly spreading around the world working with increasingly complex technology with many interdependencies. The complexities have been multiplied many times over as we’ve moved through the last two hundred years. This environment is the first challenge a Systems Analyst must acknowledge.
        The results of the complexities in today’s environment are profound as navigating them is very difficult. It is often easier to default to simpler and perhaps incomplete definitions or superficial problems and explanations. John Humphreys in his article “Developing the Big Picture” hinted at this, “Why do otherwise competent executives so easily gravitate to technical, tactical, and practical problems rather than addressing broader questions with the potential for far greater impact?”(Humphreys). Humphreys went on to say that there are two reasons. The first is that “the practical stuff is much easier” and, second, to come to a conclusion on a simplified issue brings “finality” quickly. (Humphreys). But what is perhaps more disturbing, “is the fact that some organizational decision makers simply have not acquired and/or developed the conceptual skills needed to operate as leader in a world filled with ambiguity” (Humphreys). This parallels the reality that many leaders, and Systems Analysts, prefer to tackle symptoms and not the underlying problems. The fact is that this “ambiguity” and tackling simple issues or symptoms are the result of today’s highly complex environments and while Humphreys' points are directed at today’s leaders it just as easily applies to today’s Systems Analysts.
        Besides today’s complex technology and systems the management structures that Systems Analysts and their client’s operate under are also becoming increasingly complex. Terry Acord’s article “The matrix – an old concept finds new applications” noted that “the typical hierarchical business structure evolved along with the industrial revolution”(Acord). He went on to note, “When the first large textile factories started forming in the 1600s, the owners were at somewhat of a loss on how to organize the mobs of worker they now needed” (Acord). The result was the clear line of command structured after the military, also known as a mechanistic structure as depicted in Figure 1 (Acord). This was efficient and effective for
simple organizations running relatively simple systems and processes. But the “mechanistic structures with their redundant bureaucratic layers” often “wasted resources and hinder effective and timely communication” in the world of distributed systems and complex processes (Acord). These distributed systems and complex processes coupled with fast-paced competitiveness required more integration and collaboration, as well as accountability, not only down the

Figure 1

function line but also across the organization. Thus, as noted by Acord, “During the 1970s and 1980s…the advent of widespread computing and mainframe networks in large companies prompted a rethinking of how companies should be organized” (Acord). It was “communication information technology” that “blurred organizational and divisional boundaries, diffusing hierarchies, and power relationships” (Joyner 1). Another articles goes on to say that, “Thanks to the Internet and the introduction of multiple reporting lines, communication in one part of the world or business unit can rapidly migrate to another, which means organizations have less chance to compartmentalize their communication” (Jaccaud).
        The result of this increased use of technology to aid communication is the matrix organizational structure, an example of which is shown in Figure 2. In a matrix organization a person may have more than one manager. A matrix organization
also requires increased coordination and thus communication as noted by Sabine Jaccaud and Bill Quirke in their article, “Structuring global communication to improve efficiency”. In their article the authors noted that, “Matrix organizations increase the volume of communication geometrically, as managers increasingly belong to several teams – for example, geographical, functional, product, and client”(Jaccaud). It is important that today’s Systems Analyst understand this organizational structure. Failure to recognize it could

Figure 2

hamper the Analyst’s ability to not only properly identify the system in question but to communicate the results of their analysis accurately and efficiently.
        The same technology that has enabled the matrix organizational structure has also enabled teams to span the globe. No longer is the Systems Analyst just communicating with stakeholders or teammates under the same roof as they were fifty years ago or in the same country as they were 25 years ago. Now Systems Analysts are communicating around the world. One Systems Analyst could be located in his or her home in Winner, South Dakota while their teammate is located off Western Highway in Mumbai, India. In the article “Communication technology in international technology transfer: Breaking time…” the authors note that “A global firm does not regard national boarders as barriers, and integrates its operations across divisions and national borders as a way to gain a competitive advantage” (Joyner). This is why global teams exist but the challenges they present are great. Jaccaud and Quirke noted that these teams “operate across different time zones, making it difficult to manage information and keep employees up to date at the same time” (Jaccaud). But this is only the tip of the iceberg when it comes to the challenges these teams face. An article from sheds some perspective on the challenges that face the Systems Analyst operating in a global team,

When teams become more distributed… the cost of coordinating projects and managing resources increases. A variety of boundaries, including physical distribution of team members, company firewalls, time zone differences, and language and cultural disparities, can impede effective project management and team collaboration. As a result, distributed teams often suffer from project “awareness deficits” surrounding task dependencies, project milestones and deadlines, changes in project status, and team members’ availability and daily activities.

The challenges to these distributed and global teams are far too greater and varied for this paper to detail. But it is important for the Systems Analyst to understand how to communicate and to properly use the tools at hand to communicate with these teams if he or she is going to succeed in the global/distributed team model.
       So the environment is changing from the simple systems of the 1800s to exponentially more complex systems of the twenty-first century. The organizational structure a Systems Analyst must navigate with both their teams and clients has also changed from a bureaucratic structure to a matrix structure. Add these two factors to organizations and teams that now span the globe and things may appear to be hopelessly complex. But that is not the truth of the situation. While it might be more complicated for the Systems Analyst to communicate these same structures also enables more people to analyze a system so more perspectives can be identified and for every new error that could occur there is the potential for less errors to actually surface if the full potential of these environments, structures, and global teams can be utilized. Yet to fully unlock the potential this new world has to offer the Systems Analyst must master communication.


Understanding How People Communicate:
Expectation Setting and Identifying Communicator Types


       To master communication first requires understanding the need for communicating. The environment, organizational structure, and global teams are all factors that affect communication but none of that tells us why it is important for a
Systems Analyst to communicate. If it is the role of the Systems Analysis to identify a system’s properties and to potentially coordinate that investigation with others then it is imperative that the Systems Analyst be able to communicate. One of the biggest components of communicating, whether it is with teammates or clients, is expectation setting. Without expectation setting scope cannot be identified and thus the direction of a project could be prolonged with a potentially disastrous affect.
        Expectation setting will allow you to not only control scope but will help you watch your bottom line. If you don’t control scope creep and you demand more from your teams than feasibly possible then the cost can be monumental. The concept of the iron triangle of money, time, and scope (see figure 3) says that no one part of the triangle can be moved without the other two sides being affected. This concept

Figure 3

underwrites the importance of expectation management. The book Systems Analysis and Design Methods sums this up well:

Every project has goals and constraints when it comes to cost, schedule, scope, and quality. In an ideal world, you could optimize each of these parameters. Management often has that expectation. Reality, however, suggest that you can’t optimize them all —you must strike a balance that is both feasible and acceptable to management.

I would further add that communication is the keystone to managing this quandary. That communication and expectation setting go hand-in-hand.
        Let’s take a quick dive into the expectation setting with the goal of demonstrating its importance. To setup the picture we need to first look at Expectation Confirmation Theory, otherwise known as the Theory of Disconfirmation (Nevo). This theory attempts to explain the relationship between a product’s performance and a customer’s expectations. The resulting difference is either negative or positive and can determine the success of a product, or in relation to a Systems Analyst, a project. If the relationship is negative then the client does not perceive the project to be a success. In reality the only thing that could be causing this negative perception is lack of accurate expectations. The system could work beautifully but if the proper expectations were not managed throughout the project development process and the client had a different idea of what should be done and how it should work then the results can be disastrous. As one source on managing customer expectations put its, “expectations and their management are of great significance to perceived service quality and satisfaction”(Ojasalo).
        A whole paper could be written on expectation setting especially using some of the excellent frameworks developed in scholarly journals and trade publications (see figure 4 for one example of an expectations management framework). The goal of this paper is to introduce you to the importance of expectation setting and why effective communication is essential

for expectation setting. The hope is that this paper will work as a springboard for a deeper journey into this important topic. This is especially important to the Systems Analyst as this person is often times the focal point between client, management, and project team. In the end the models that help guide one to effectively manage expectations will only work if the Systems Analyst is able to effectively communicate.

       To effectively communicate the Systems Analyst must not only understand how to communicate with others and how others perceive those communications but how they are perceived by others. To demonstrate this I introduce the Feedback and Disclosure Continuums as defined by author Cheryl Hamilton in Communicating for Results. Hamilton explains that there are four types of communicators: Closed, Blind, Hidden, and Open (Hamilton 61). Understanding these types of communicators, as depicted in figure 5, allows a Systems Analyst, “To communicate more successfully and establish more meaningful working relationships”(Hamilton 60). But when using this continuum “we not only need to understand the styles of bosses, fellow employees, and customers but also to attune our style to theirs”(Hamilton 60). That is by following this model a Systems Analyst can not only learn how to understand others better but adapt their own style to the person they need to interact with. By doing this hopefully the Analyst can either get more information out of the client or more effectively communicate goals with teammates.

Figure 4


Figure 5

Figure 6

Figure 7

       The first of the communicator types are Closed communicators. These individuals, whose qualities are depicted in figure 6, are often excellent at working alone with little client or team interaction. If one were to go down the sometimes-dangerous path of stereotypes then these would be the programmers of the world. Closed communicators “tend to seek little feedback from others and disclose little information to others” (Hamilton 62). It is important to recognize these attributes when talking with a Closed individual to understand how best to relate to them.
       Blind communicators are “someone you can depend on to get the job done” (Hamilton 64). These individuals, depicted in figure 7, “tend to fall on the low feedback and high disclosure ends of the two continuums, which causes others to view them as authoritarians” (Hamilton 64). It is important when working with these individuals to know that they can seem very “critical and demanding” (Hamilton 65).
       Hidden communicators “are interested in people, are good listeners, and are generally well liked” but “they are called ‘hidden’ because they often hide their feelings and knowledge from others” (Hamilton 66). This could be tricky for the Systems Analyst who may find that they need to ask more questions then normal to really understand these individuals’ views of the process or system.
       Finally Open communicators “fall on the high disclosure, high feedback ends o the two continuums”(Hamilton 68). As the author of this model notes Open communicators are often “too open too soon”. A Systems Analyst should be cognizant of this as they talk with Open communicator as they could find

that they will need to filter the potentially overwhelming amount of data that is being provided to them.
        Just as a Systems Analyst must identify the individuals they are working with, whether at the client or on the same project team, they must also be able to identify themselves as one of these communication styles. Being able to identify one’s self as a Closed, Blind, Hidden, or Open communicator will allow one to be cognizant of how they interact with and set expectations with those around them, an important part of being a Systems Analyst.


The Tools are the Facilitators…not the Answers!


       So far on this journey we’ve looked at the environment within which the Systems Analyst has to work, the importance of expectation setting, and how to identify the communication attributes of those with whom we need to set expectations. The goal has been to learn what affects communication, why we need to communicate, and how to communicate. Yet with all of this accomplished we have yet to actually touch on the definition of communications. According to Batemann and Snell’s book Management: Building Competitive Advantage communication is, “the transmission of information and meaning from one party to another through the use of shared symbols” (Batemann 500). One of the biggest areas where technology can help the Systems Analyst is in the “transmission” part. Luckily for the Systems Analyst of today there are numerous tools at hand to aid in the transmission.
       As quoted by Joyner and Onken in their study “International Technology Transfer” tools make it so “a project can be worked on 24 hours a day” so “ as one manager finishes working on a project, the data can be sent to another in a different time zone” which “decreases time worked on a project”(Joyner). The goal of these technologies is to work in “a way for managers to ask each other questions, throw ideas

Figure 8

Figure 9

around, and coordinate the formulation and implementation of tactics to accomplish the firm’s strategies”(Joyner). The tools at hand include synchronous tools like the phone, video conferencing, and instant messaging as well as asynchronous tools like e-mail, code sharing, and document exchanges.
       Synchronous tools generally require at least two people to be engaged simultaneously. The examples of synchronous tools include the phone, video conferencing, and instant messaging. The phone is a tried and true tool that is generally easy for most anyone to use. What it gains in universal acceptance and clarity of sound it lacks in the ability to transfer non-verbal queues between participants. Video conferencing as quoted by one resource includes, “hardware and software that allows users to see and hear the person they are communicating with”(Valkovski). The same resource goes on to say that, “This is great for gaining high levels of engagement”(Valkovski). This is certainly true as the advantage for both verbal and non-verbal queues to be communicated are certainly there. Unfortunately the technology is generally expensive and less expensive tools and software have yet to prove their reliability. Finally, instant messaging is another tool that is gaining a foothold among business including project teams with Systems Analyst. As an Analyst with Accenture we relied exclusively on American Online Instant Messaging to replace many of the conversations that would otherwise require a quick phone call. It was also a source of informal communication where ideas and thoughts could be exchanged between working on different task. In the end synchronous tools like the phone, video conferencing, and instant messaging generally require two users to be engaged at the same time. While powerful this does not help the global teams on different schedules nor does every communication require instant responses that synchronous tools of communication require.
       Asynchronous tools of provide communication that does not require instant action on the receiver’s part. Instead the message or communication is sent with the expectation it will eventually be read and, if required, replied to. Examples of these tools include e-mail, code sharing tools, and document exchanges. The benefits of e-mail, as touted by the website include transferring files, an “easy way to allow others to participate,” and, perhaps the biggest, “there is not time or place barriers.” The absence of time or place barriers are indicative of asynchronous communications and coupled with e-mail’s instant send and ease of use properties it is easy to understand why e-mail is such a valuable tool. Code sharing programs, like Microsoft’s Visual SourceSafe, allow for the versioning and transferring of code between development teams. According to the benefits include: “increase developer productivity”, “improved quality”, and “low-cost”. There are all certainly compelling qualities and necessities for the Systems Analyst whose distributed teams are working on the same piece of code to utilize code sharing tools. Along the same lines as code sharing programs and perhaps most useful to a Systems Analyst are document exchanges. noted that SharePoint, Microsoft’s document exchange, provide organization, versioning, sharing, and security. These are important attributes for a team that is analyzing a system or process in many different places. The document exchange becomes a type of depository. Asynchronous tools fill that gap between the immediacy that synchronous tools require and the long-term, knowledge storing systems that projects thrive off of.
       Yet the most basic and sometimes useful tool of all cannot be overlooked, face-to-face communication. As noted by a website “much of communication is non-verbal and emotions can easily be transferred from person to person without the utterance of a single word”(Hunter). The tools above, while necessary and powerful, cannot over some this fact. Sometimes is behooves the Systems Analyst to meet with their clients, managers, or teams face-to-face as the power of a handshake is something that not even video conferencing can provide.

Awesome! What now? The Next Steps…


       Again the importance of these tools as implementers of today’s distributed teams and bridges over today’s complex environment cannot be underestimated. As we circle back around to expectation setting, a reason for using these tools, we cannot forget the importance of identify how we communicate with people or how those people communicate back with us. It is the Closed, Blind, Hidden, and Open attributes that no physical tool can identify. The “people focus” cannot be removed by utilizing these important tools. As noted in Tom Ruddy’s paper “Taking knowledge from Heads and Putting into Hands”,

Many organizations, consultants and vendors today are plugging knowledge management, but that only goes halfway. Knowledge management, by most definitions, is a technocentric approach that uses technology to create an infrastructure…These approaches emphasize technology, ignore critical social elements and rarely encourage significant knowledge sharing and creation. Organizations must move beyond these insufficient frameworks to examine and build around the work community, its social environment, and its practices.

Here we are using technology to create the infrastructure but to gain the full potential of today’s world the Systems Analyst must understand the environment, the reasons, and the ways in which people communicate and interrupt communication to be successful. In the end it is important to note that this has only been a primer for a more in-depth exploration into the topics of expectation setting, communication, and tools. The goal was to see how an Analyst like myself years ago could better handle the situation of coordinating teams in Peoria, Argentina, and India on nearly a moment’s notice. Perhaps better expectation setting, understanding of my managers, and utilization of the tools at hand could have all helped me with the request.