IS6840 Term Paper
Paper Links
Other Links
Contact
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 |
|
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 www.groove.net 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 |
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. |
| 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!
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 |
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 www.e-strategyguide.gov.au 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 www.microsoft.com 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. Computerperformance.co.uk 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 Stanford.edu 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.