# Communication and Collaberation: Skills for the New IT Professional

Simon McGinnes
Royal Holloway School of Management
University of London
Egham, Surrey, TW20 0EX, U.K.
email: s.mcginnes@rhbnc.ac.uk

### Abstract

The skills of communication and collaboration are important ones for IT professionals, and yet they have often been undervalued in computing courses. In the business world, dealing with technical issues is only one part of the IT professional's job. IT specialists must understand how different functional areas of the business operate and how they interact with one another. They must be able to relate the business goals of the organisation to the information systems they create. In particular, they must be competent in the skills of interpersonal communication so that they can deal effectively with their customers, colleagues and management. The inevitable result of poor communication and ineffective collaboration is a lack of quality in the information systems that IT professionals produce. This paper argues for the importance of endeavouring to alter an IT culture that emphasises technical knowledge at the expense of teamwork skills. The skills of communication and collaboration are given insufficient weight in computing courses at degree level, which are strongly influenced by the `computer science' model and therefore have a heavy bias towards technical topics such as design and programming.

### Introduction

Computing has often been seen as a technical or scientific type of occupation. Reflecting this view, university computing courses have typically required prospective students to have a background in mathematics or other numerate subjects. Now that the use of computers is so widespread, in business as well as in education, we might expect that the technical/scientific model of computing would give way to a more broadly-based view, incorporating organisational and social factors alongside the technical concerns. Yet, this model is, if anything, being reinforced with the introduction of software engineering qualifications and certification in engineering for IT professionals.

Despite the widespread view of computing as a highly structured activity based on sound principles, software development practice traditionally has been rather informal, and results have often been disappointing. A large proportion of computerised information systems have proved difficult to use or have been outright failures (Forester and Morrison, 1990). Doubts have been raised over whether many expensive IT investments are worth having at all (Strassman, 1990), (Scott Morton, 1991). The continuing concern over quality and productivity has spawned debate about ways of making the practice of software development more `mature' (Paulk et al, 1993); it is argued that IT specialists must apply an engineering discipline to their activities. Increased formality and discipline are seen as important ways of improving quality and reducing the likelihood of failure.

There is no doubt that the practice of software development must become more professional. However, concentrating too much on the technical, `engineering' issues will lead us to neglect other important aspects, such as communication. There is an argument that the place of computing courses at tertiary level is to teach more formal and technical aspects of computing, and that the interpersonal skills needed by computing practitioners cannot easily be taught and must be learned `on the job'. It is indeed true that communication skills must be honed through practice. But existing courses in drama, communications, psychology and other disciplines are evidence that it is both feasible and acceptable to teach communication skills at university level. According to Denning (1992), on engineering courses in general, and computing courses in particular, "... a student must learn not only the technical side of engineering, but also skills of listening, completing and communicating". Despite the popular stereotype of the introverted computer specialist, most of an IT professional's working life will be spent working in teams; "It is important that students learn the skills for working effectively as members of groups" (Denning, 1992).

### Why communication and collaboration are important

In recent years we have seen a general shift in the way business information systems are developed, away from bespoke systems development, and towards the use of packaged software, systems integration, fourth-generation languages, CASE tools and other aids. The requirement for in-house computer programmers is likely to tail off or even diminish, and we can expect a corresponding increase in the need for professionals with good analysis and design skills. Accordingly, this paper focuses on some of the analysis and design skills that analyst/programmers need, or are likely to need in the next few years.

Systems analysis and design is in many ways a multi-disciplinary activity, involving the interaction between requirements and solutions, between people and systems, between technical skills and communication skills, and so on (Miser and Quade, 1985). In teaching systems analysis we should be able to give students a good appreciation of the `totality' of the information systems world. Indeed, the importance of a holistic view of software development has recently been emphasised (Blum, 1993).

Many analysts have a background in computer programming, and may therefore tend to concentrate on technical issues rather than business issues (Vitalari, 1984). It is often necessary to emphasise non-technical aspects in the training and selection of analysts, and one way of doing this is by employing `business analysts' (Mann 1985). In a similar vein, there have been calls for the emergence of the `hybrid manager', a role that combines specialist IT knowledge with business and management acumen. Proponents of the hybrid manager idea recognise the fact that, while IT managers must understand the technology they are responsible for, they must also have a strong appreciation of organisational objectives and strategies, understand how the business works, and be able to manage effectively to achieve the organisation's aims.

An over-reliance on technical know-how has been blamed for many failed information systems projects. These days, quality is high on every software developer's list of priorities. Practically every organisation that develops software would claim to have implemented some sort of quality programme. Yet, disastrous and often expensive information systems failures are reported in the press with alarming frequency (Forester and Morrison, 1990). Recent and well-publicised disasters with serious consequences include the ambulance command and control system and the London Stock Exchange's planned TAURUS system. Many reasons were found for these failures, but common themes were: (a) Weak or nonexistent project management, leading to an inability to monitor and control collaborating individuals and organisations; (b) Over-ambitious plans and over-optimistic planning, leading to infeasible schedules and cost overruns; (c) Failures of communication between participants, leading to ill-specified systems and poorly coordinated development efforts; (d) Failure of analysts and users to communicate effectively, resulting in specifications that were unrealistic or failed to meet real needs. Few of these reasons for failure have anything to do with technical quality. Rather, they concern the quality of the development process, and they follow largely from poor communication, a lack of teamwork, and an over-reliance on technical solutions. We argue that these failings have much to do with the prevailing work culture amongst IT developers (Rout, 1992).

### IT culture

A recent survey (Cusumano, 1991) revealed that software written by Japanese programmers, while of a similar level of sophistication to software written by American programmers, contains on average less than half the number of errors. Japanese programmers are also more productive, turning out about 70 per cent more lines of code than Americans do in the same amount of time. While we may argue about the effectiveness of using lines of code counts as a measure of productivity, it seems apparent that there is some significant difference in performance between American and Japanese developers, from the evidence of this survey at least. The superior performance of Japanese software developers can be attributed to any number of causes, but it would seem likely that work practices, and especially the well-established use in Japanese industry of quality management techniques, play a large part.

Perhaps other factors are important too. For instance, in a competitive work environment, there can be strong motivating factors that prevent information from being shared between colleagues. The dynamic nature of the western computing industry has led to an environment in many organisations in which individuals may deliberately keep to themselves information they regard as valuable. This information may include knowledge and experience of products, methods or systems. Because employment prospects in IT are often directly related to knowledge and experience, which may have been gained through significant personal effort, individuals may well be averse to sharing their knowledge.

The western model of individualism and competition in the workplace no doubt contributes to this phenomenon. In times of economic prosperity, competition between co-workers has generally been regarded as a healthy thing, despite the potential impact on software quality of failing to share and capitalise on knowledge. During recession, professionals fear for their jobs and may become even less likely to share information with their colleagues, with further deleterious consequences for the organisations they work for. By all accounts, Japanese employees tend in general to be concerned with collective cooperation as opposed to individualistic competition (Forester, 1993). They are more likely to act for the good of the organisation than out of self-interest. In comparison, American workers are seen as far more individualistic (Patterson and Kim, 1991).

Software development is one sphere in which cooperation and communication are particularly important. The individualistic, entrepreneurial model is can help to foster originality and brilliance. But if developers do not work together to achieve a common goal then the quality of the resulting software is bound to suffer. Given the cultural differences, it is not difficult to see how software development efforts could naturally tend to produce a higher quality result in Japan than in America or Europe.

Japanese IT professionals take quality seriously. Although Japanese software developers may have lagged behind their American and European rivals in terms of output and sales, there is no doubt that they have a head start in quality. The American invention, Total Quality Management (TQM), achieved popularity first in Japan. The Japanese `software factories' have been set up with the avowed intention of producing very high quality software on industrial lines (Aoyama, 1993). Central to these efforts is the concept of `continuous process improvement'. Treating the software development process in much the same way as a manufacturing process, improvements are continually sought and applied so as to result in a higher quality product, produced more efficiently (Roos et al, 1990). Cultural predispositions towards conformance and achievement mean that quality measures are often a natural extension of the Japanese way of working (Forester, 1993).

In the West, quality management ideas have been applied in recent years to software development. However, quality systems in British and American companies are often culturally foreign and may cut across established, informal ways of working. Re-education and cultural change is often necessary for the systems to work. From personal experience, it is frequently the case that even the most well-intentioned quality management systems are abandoned as soon as a deadline looms or some other crisis occurs (Paulk et al, 1993). Quality is unsustainable without a high degree of effective collaboration.

To meet the challenges posed by Japanese software producers, American and European software developers must adapt their own behaviour to alter the workplace culture. Cultural change is difficult to achieve; organisational culture often persists despite the most determined attempts to change. As many a `new broom' has found out, systems introduced to streamline organisational processes are often subverted because of strong existing cultural forces. Perhaps the only really effective way of ensuring cultural change is to combine measures in the workplace with education, and for this reason it is important that the correct attitudes are instilled in technology students before they enter employment. Teaching students only the technical subject matter and hoping that they pick up the rest is wrong; it perpetuates a damaging workplace culture that threatens our software industry. `Communication and management skills ... are vital to the success of a software engineer and as such they cannot be left to be learned by "osmosis"' (Engle, 1989).

It would be wrong to say that these ideas are new or that they are not being applied in existing IT courses to some extent. However, we feel that the need for stronger attention to communication skills in IT courses has not been articulated clearly enough, and even where it is explicitly acknowledged, implementation is very often inadequate. Communication skills and the ability to collaborate effectively are not clear objectives for many computer science and information systems courses. In the following sections we focus on particular aspects of these skills, and look at some instances where they are needed.

### Communication skills

Communication between developer and user The process of gathering requirements for computer systems is primarily an act of communication and collaboration. Effective communication between analyst and client is important if fundamental errors in a new system are to be avoided. Such errors often spring from misconceptions about the way the business operates, and they can be very costly, leading perhaps to inadequacies in a system's underlying architecture. Yet, new IT professionals are rarely prepared adequately for the necessary collaborative effort. To give one example, it is known that a large proportion - and perhaps a majority - of face-to-face communication is non verbal (Birdwhistell, 1970). Very few computing undergraduates are trained to interpret non-verbal communication. It is often assumed that clients will find it easy to express their requirements verbally, and when requirements fail to come up to scratch, blame may be placed on the client rather than on the analyst.

It is interesting to compare the role of the systems analyst when consulting clients and gathering requirements to that of a psychoanalyst. Both types of analyst are highly trained in their respective fields, with extensive bodies of highly technical knowledge to master; they must be good listeners; they must appreciate the difference between what people say and what they mean; they must be able to adapt their own manner to suit the situation, and they must be able to deal with people of different types and from varying backgrounds. After the consultation, both sorts of analyst must be able to provide an objective and analytical account of what has gone on, drawing unbiased conclusions. Despite these parallels, the training methods practised in the two disciplines are remarkably different.

Communication between developer and developer IT professionals must be adept at communication and cooperation with their customers, but they must also be good at working with other IT professionals. When communication between team members fails, some very familiar problems can arise. For instance, software can fail to meet its specification. It may be difficult to monitor progress and thus to manage effectively. Essential information about systems and procedures may not be shared. Anyone who has first-hand experience of business software development will recognise these problems as commonly-occurring ones (Kiesler et al, 1984). To avoid them, we need to ensure that the next generation of computing specialists are good at talking to each other.

Despite the sort of problems mentioned above, the need for communication between developers is often glossed over, in education and in the industry itself. For example, the process of creating systems is often portrayed as a straightforward construction process that proceeds from well-defined specifications to a final system. CASE tools have been designed to support this process, allowing the information about requirements to be captured and converted into designs. It is sometimes assumed that using CASE automatically has positive effects, but in projects of any reasonable size, it must be possible to coordinate and combine the work of many people. CASE tools have not been particularly good in the past at meeting this requirement, and to share the use of a CASE tool between several developers often requires considerable coordination and management. Although a CASE tool can provide the mechanism to store and manipulate models, it cannot remove the need for skills like negotiation, arbitration and persuasion.

### Collaboration skills

Collaboration means working effectively with others to achieve a common goal. Communication with one's clients and colleagues is one prerequisite to successful collaboration. Basic collaborative skills include those required for management, supervision and participation in group activities. Denning (1992) identifies the following collaborative skills: (a) bringing new members into the group; (b) assigning work tasks to members of the group under your supervision; (c) assessing the progress of work performed by those under your supervision; (d) knowing who the group's customer is and what it will take to satisfy that customer; (e) making and grounding assessments; (f) participating in an effective review meeting (Denning, 1992). Added to these is, of course, the ability to get along with one's colleagues! Denning makes the point that these skills must become part of the curriculum for engineering undergraduates such as computing students. In addition to the basic skills listed above, specific collaborative roles can be identified; two examples are given below.

Facilitator It may be fruitful to view the analyst's collaborative role as that of a facilitator (Wood and Silver, 1989). Facilitation can apply to all sorts of IT activities, but is especially useful in the process of systems analysis and design. For instance, users generally have a deep knowledge of the business area to be examined, while the analyst often does not. Rather than wastefully educating an analyst in the user's area of expertise, simply so that the knowledge can be expressed in the `correct' way, the user can be encouraged to express the knowledge directly without using the analyst as an intermediary. The analyst facilitates this process. Taking the idea one stage further, the IT professional may be required to facilitate the user's own systems development efforts.

The skills of facilitation involve far more than the technical knowledge of system design itself. In JAD sessions, for instance, it is often important for the facilitator to take a back seat when it comes to discussion of particular technical issues, so as to retain a position of impartiality.

Catalyst It is obvious that certain project teams work together more smoothly and more successfully than others. Demarco and Lister (1987) explore the phenomenon of the catalyst, an individual who improves communication between team members and generally helps to create an optimistic mood. The catalyst is often not officially in a management position, but nevertheless manages to influence the thinking of other team members and helps to produce a positive outcome. In the author's own experience, a positive outlook and generally optimistic attitude can be one of the chief critical success factors which determine the difference between success and failure in a software development project. Perhaps even learning how to be a `catalyst' should be on the curriculum!

### Communication and collaboration in the curriculum

It can be argued that existing courses in information systems and computer science are product-oriented rather than process-oriented. They focus on end results - the information systems - rather than the processes used to arrive at them. They also concentrate on technical rather than social aspects. For instance, a typical core software engineering syllabus is given in Table 1 (based on Hooper, 1992).

##### Table 1 Typical computing syllabus (after Hooper, 1992)

Fundamentals of Computing
Introduction to Computing
Introduction to Computer Engineering
Computer Organisation and Assembly Language Programming
Analysis and Design of Algorithms
Introduction to Systems and Software Engineering
Computer Architecture
Introduction to Programming Languages
Software Engineering
Operating Systems
Project

Although content of some of the course units is apparently given over to `social' skills like communication, it is clear that the bulk is devoted to exploration of technical issues. Nevertheless, Hooper stresses the need for communications skills to be included in the curriculum. Kantipudi et al (1992) call for the inclusion of teamwork, management and motivational aspects in coursework. According to Engle (1989), "the conduct of a design review, besides its obvious technical requirements, is rooted in "people" skills".
Ardis and Ford (1989) present an alternative software engineering syllabus which exhibits the same technical, product-orientation as the one given above. Out of twenty modules, only one covers communications, and this module is restricted to coverage of technical communication such as documentation. Key skills such as listening and interacting are not mentioned at all. Systems analysis is one area where communication and collaboration are especially important, and so we might expect some of these skills to be covered in courses on systems analysis and design. However, such courses often focus on technical methods like data flow diagrams and normalisation. Similarly, students carrying out project work are frequently expected to collaborate and communicate with their peers, but often without being offered any explicit training.

We argue that skills like communication and collaboration cut across the main content of typical computer science and information systems courses. It makes sense for them to be applied across the board and not only taught as individual topics. This can be achieved in several ways:

- a. By incorporating a strong case study element in which all aspects of the >systems development process must be considered - systemic, technical, strategic, psychological, social and so on.
- b. By explicitly teaching communication and collaboration skills, and allowing these skills to be rehearsed and assessed in context - that is, during the creation of information systems. Many IT professionals have little formal training in computer science or in systems analysis, and have developed their skills `on the job'. It can be argued that better integrated skills are developed in this way (Bandura, 1986). Formal IT education could strive to emulate this integrated mode of learning.
- c. By adopting a less sequential mode of delivery. We would all agree that reading a reference manual would be a poor way for a beginner of learning a computer language. The manual is arranged logically and contains all of the required information. But it does not allow for an organic, associative way of learning, where new ideas are incorporated by integrating them with old (Bandura, 1986). The structure of many lectures, text books and other educational material on IT attests to the strength of the `linear' model of course progression.
- d. By adopting a new model for the IT professional. Table 2 gives two opposing views; we argue that the latter view should be given more weight than has been the case.

Table 2 Models of the IT professional

- Definition 1 A highly-trained technical specialist who applies sound formal principles to design optimum solutions to clearly stated problems.
- Definition 2 An adaptable all-rounder who works with others to understand and improve an organisation.

Neither model particularly implies the use of IT. The emphasis in the first is the analytical application of first principles and technical knowledge to derive solutions; the emphasis in the second is communication and collaboration. Using a medical analogy, the difference is akin to that between surgery and preventative medicine.

### Conclusion

The debate on the teaching of computing is not new (Lewis and Tagg, 1988). Business computing or information systems is very evidently a vocational discipline. The computing industry naturally perceives that a major aim of computing courses is to turn out budding computing professionals who can take their place in industry. Universities often have quite different views, focusing on carrying as many students as possible forward into higher degrees and research. In a sense, the conflict between these views is nothing more than distinction between education and training. But because computing is a vocational field, we must not neglect the training element (Pollard et al, 1988).

Although the term `training' may be associated in people's minds with low level or menial tasks, the only real difference between education and training is that education implies the transmission of knowledge from an educator to a student, while training implies the development in the student of the ability to do something to a required competency (Wilkes and Krebs, 1988). Clearly, a model of IT education based mainly on the first view falls far short of the mark. Perhaps it would be useful to consider much more of the teaching of computing as competency based training.

Many of the ideas put forward in this paper have been tested informally by the author in courses over recent years, with encouraging results. We feel that practical skills, and especially collaborative ones, can be developed best through practice. Teamwork and role-playing exercises are therefore fruitful. Students benefit greatly from practical communication exercises, such as making presentations and then discussing their performance with their peers. Theory is relevant too, in areas such as psychology, body language and group dynamics. For instance, one example of the kind of communications theory that might provide students with insight into communication is neuro-linguistic programming (NLP) (Dilts et al, 1980), which attempts to account for the variation in preferred modes of communication between different individuals. The student is therefore given a framework for increasing the effectiveness of his or her own communication.

#### References

Aoyama M (1993) `Concurrent-development process model', IEEE Software, July 1993, pp. 46-55.
Ardis M, Ford G (1989) `SEI report on graduate software engineering education', Software Engineering Education, SEI Conference 1989, Pittsburgh, July 1989, Proceedings, Springer-Verlag.
Bandura A (1986) Social Foundations of Thought and Action: A Social Cognitive Approach, Prentice-Hall.
Birdwhistell R L (1970) Kinesics and Context, University of Pennsylvania Press.Cusumano M A (1991) Japan's Software Factories: A Challenge to US Management, Oxford University Press.
DeMarco T, Lister T (1987) Peopleware: Productive Projects and Teams, Dorset House.
Denning P J (1992) `Educating a new engineer', Communications of the ACM, 35 (12), pp. 83-97.
Dilts R, Grinder J, Bandler R (1990) Neuro-Linguistic Programming Vol I, California, Meta Productions.
Engle C B (1989) `Software engineering is not computer science', Software Engineering Education, SEI Conference 1989, Pittsburgh PA, USA, July 1989, Proceedings, Springer-Verlag.
Forester T (1993) Silicon Samurai: How Japan Conquered the World's IT Industry, Blackwell.
Forester T, Morrison P (1990) Computer Ethics: Cautionary Tales and Ethical Dilemmas in Computing, Blackwell.
Hooper J W (1992) `Planning for software engineering education within a computer science framework at Marshall University', Software Engineering Education, SEI Conference 1992, San Diego, California, USA, Oct 1992, Proceedings, Sledge C (ed.), Springer-Verlag.
Kantipudi M et al (1992) `Software engineering course projects: failures and recommendations', Software Engineering Education, SEI Conference 1992, San Diego, California, USA, Oct 1992, Proceedings, Sledge C (ed.), Springer-Verlag.Kiesler S, Siegel J, McGuire T (1984) Social Psychological Aspects of Computer-Mediated Communication, American Psychologist, 39, 1123-34.
Lewis R, Tagg E D (eds) (1988) Informatics and Education: An Anthology of Papers Selected from IFIP TC 3 publications since the establishment of TC 3 in 1963, North-Holland.
Mann E (1985) The Need for Business Analysts, Journal of Systems Management, Feb. 1985, 10-13.
Miser H J, Quade E S (1985) Handbook of Systems Analysis: Overview of Uses, Procedures, Applications and Practice, Wiley.
Patterson J, Kim P (1991) The Day America Told the Truth: What People Really Believe About Everything That Really Matters, Prentice-Hall.
Paulk M C, Curtis B, Chrissis M B, Weber C V (1993) `Capability maturity model, version 1.1', IEEE Software, July 1993, pp. 18-27.
Rout T P (1992) `Quality, culture and education in software engineering', Australian Computer Journal, 24 (3), 86-91.
Strassman P A (1990) The Business Value of Computers, Information Economics Press.Vitalari N P (1984) `Critical assessment of structured analysis methods: a psychological perspective', Beyond Productivity: Information Systems for Organisational Effectiveness, Bemelmans T H (ed.), North-Holland 1984.
Wilkes G A, Krebs W A (eds) (1988) The Collins Concise Dictionary of the English Language, Collins.
Wood J, Silver D (1989) Joint Applications Design: How to Design Quality Systems in 40% Less Time, Wiley.

[Return to Papers for CTI Annual Conference 1994]