In all that has been said about the computer in business, there are few clues as to how the EDP department ought to grow or what management ought to be doing about the department at each stage of its growth. Here is a convenient categorization for placing the life crises of the EDP department in perspective, for developing the management techniques necessary or useful at various points, and for managing the human issues involved. These human issues, as a matter of fact, complicate the problems of growth at least as much as the hardware and software questions, which have been so well massaged in the literature; the authors show how these issues change shape as a company moves through the four stages of development. This article will be
particularly helpful to the new business that is about to buy its first computer. For the company in the throes of later-stage development, it offers a framework useful for identifying issues and evaluating and controlling the growth of EDP. From the viewpoint of the executive vice president, “The EDP manager always waffles around when he has to explain his budget.” From the viewpoint of the EDP manager, “The executive vice president never seems to understand why this department needs a lot of money.”
The reason for this kind of impasse is clear enough: EDP, as corporations use it today, is so complex that controlling it, or even understanding it, is almost too difficult for words. However, through our work with a number of companies, we have reached certain conclusions about how EDP departments grow and how they should fit into the company..s organization. These conclusions offer a framework for communication for both the EDP manager and the senior managers to whom he reports.
There are four distinct stages in the growth of all EDP facilities, each with its distinctive applications, its rewards and its traumata, and its managerial problems. By breaking the evolution of the EDP department into four easy stages, it is possible to sort out the affairs of the department, if not into four neat, sequential packages, at least into four relatively small, sequential cans of worms.
The basis for this framework of stages is the recent discovery that the EDP budget for a number of companies, when plotted over time from initial investment to mature operation, forms an S-shaped curve.1 This is the curve that appears in the exhibits accompanying this article. The turnings of this curve correspond to the main events—often crises—in the life of the EDP function that signal important shifts in the way the computer resource is used and managed. There are three such turnings, and, consequently, four stages.
In the companies we know, there are remarkable similarities in the problems which arise and the management techniques applied to solve them at a given stage, despite variations among industries and companies, and despite ways in which EDP installations are used. Moreover, associated with each stage is a distinctive, informal organizational process. Each of these seems to play an important role in giving rise to the issues which need to be resolved if the stage is to be passed without a crisis and if the growth of the resource is to be managed to yield maximum benefit to the company. Our purpose here is to describe the four stages in turn, listing the key characteristics of each and explaining the underlying organizational forces at work in each.
In the space of an article we can touch only on the main problems of EDP management at the different stages. Hence the view we present is bound to be somewhat simplified. Caution is advisable in another respect, too: history has not yet come to an end, and we are sure that the S-curve we describe and the stages it seems to follow do not represent the whole story. At the end of the Scurve of contemporary experience there will doubtless be more S-curves, as new EDP technologies emerge, and as companies become more ambitious in their use of EDP techniques and more sophisticated in systems analysis. However, we hope that the
dynamics of later cost escalations will be clearer after the reader has finished with our description—clearer, and perhaps even predictable and controllable.
Four Stages of Growth
Three types of growth must be dealt with as an EDP department matures:
A growth in computer applications—see Exhibit I.
A growth in the specialization of EDP personnel—see Exhibit II.
A growth in formal management techniques and organization—see Exhibit III.
The S-curve that overlies these three kinds of growth breaks conveniently into four segments, which represent the four stages of EDP growth: initiation, expansion, formalization, and maturity. Most notable are the proliferation of applications in Stage 2 (as reflected in Exhibit I) that causes the budget to increase exponentially, and the proliferation of controls in Stage 3 designed to curb this increase (as reflected in Exhibit III). This sequence of stages is a useful framework for placing a company..s current problems vis-à-vis EDP in perspective and helping its management understand the problems it will face as it moves forward. It is especially helpful for discussing ways to smooth out the chaotic conditions of change that have caused so many derailments in Stages 2 and 3. Even in our work with small companies, we have found the framework helpful—in obviating crises before they arise and in suggesting the kinds of planning that will induce smooth growth. Thus one virtue of this framework is that it lays out for the company as a whole the nature of its task at each stage—whether it is a new company planning to buy its first computer, or a company in the throes of developing advanced applications, or a company with a steady, mature EDP facility.
Stage 1: Initiation
When the first computer is implanted in the organization, the move is normally justified in terms of cost savings. Rarely, at this point, does senior management assess the long-term impact of the computer on personnel, or on the organization, or on its strategy. Thus management can easily ignore a couple of crucial issues. The Location Question In Stage 1, the priority management issue is to fix departmental responsibility for the computer: Initially it makes economic sense to locate the computer in the department where it is first applied—very frequently, in accounting—and to hold that department responsible for a smooth introduction and a sound control of costs and benefits. The costs and benefits can be clearly stated and rigidly controlled under this approach—and they usually are. However, the department where the computer will first be used—accounting, say—may not be the best location for the EDP facility later on. The later and more complex applications, such as inventory control and simulation modeling, should ideally be located in an autonomous department of computer services or management information systems which reports through a high level
manager. But granted this longer perspective, management may decide on a less rigorous application of payback criteria for judging the performance of the initial application. Costs for “future development” may not be scrutinized too closely at this stage, and budgets may expand very early under this arrangement.
Many companies resolve this issue in obvious fashion. Management simply locates the facility within the department of first application for an initial period; then, when its viability has been proved and other applications develop, management creates the autonomous EDP unit. In practice, however, this seemingly simple resolution conceals a serious trap. The department that controls the resource becomes strongly protective of it, often because a manager or a group within it wants to build up power and influence. When the time comes for computing to assume a broader role, real conflict arises—conflict that can be costly in terms of management turnover and in terms of lingering hostilities that inhibit the provision of computer services and applications across functional areas. Fear of the Computer Another priority issue is to minimize the disruption that results when high technology is injected into an organization. Job displacement anxieties appear; some people become concerned over doing old jobs in new ways; and others fear a loss of personal identity with their work. These fears may lead to open employee resistance. While reactions of this kind may occur at any
of the stages, they can be particularly destructive in Stage 1, where the very survival of the EDP concept is at stake. In plain fact some of these fears are probably justified. For example, some employees (although usually relatively few) may indeed lose their jobs when the computer is first installed. On the other hand, the concerns that develop from rumor or false information are usually overblown, and they are readily transformed and generalized into negative sentiments and attitudes toward management, as well as the computer itself. The wise course for management is to spike rumors with the most honest information it has, however the chips may fall. Such openness will at worst localize fears and resistances that must be dealt with sooner or later anyway. Unless management is willing to recognize the seriousness of this anxiety, it risks a more generalized reaction in the form of unresponsive and uncreative work behavior, a broader and higher level of uncertainty and anxiety, and even sabotage, as a surprising number of cases have demonstrated.
Management can make no bigger mistake than to falsely reassure all concerned that the computer will not change their work or that it will mean no less work for everyone. Such comfort blankets lead to credibility gaps that are notoriously hard to close. Thus the key to managing this process of initiation to the computer is to accept the fact that people..s perceptions of reality and their views of the situation are what have to be understood and dealt with, rather than some “objective” reality.2 These perceptions will be diverse; management cannot assume that all organizational members are equally enthusiastic about introducing efficiency and reducing costs. Where you stand depends on where you sit and on who you are. In communicating its intention to introduce EDP, management should remember this and tailor its communications accordingly. There will be variations from one situation and company to another in the manner and detail in which management releases information about future location and about the impact of the computer. Depending on circumstance, management directives may best be communicated downward by an outsider, by a department head, or by the new EDP manager. In settings where employees are rarely informed of management planning, it may even be wise to explain to the echelons why they are being given the
explanation; again, in settings where the echelons have participated in planning, a formal presentation may be less effective than open group discussion.3
Stage 2: Expansion
The excess computing capacity usually acquired when a company first initiates an EDP facility, combined with the lure of broader and more advanced applications, triggers a period of rapid expansion. The EDP area “takes off” into new projects that, when listed, often seem to have been selected at random. As Exhibits I..III show, Stage 2 represents a steady and steep rise in expenditures for hardware, software, and personnel. It is a period of contagious, unplanned growth, characterized by growing responsibilities for the EDP director, loose (usually decentralized) organization of the EDP facility, and few explicit means of setting project priorities or crystallizing plans. It is a period, further, in which the chaotic effects of rapid development are moderated (if they are moderated at all) only by the quality and judgment of the personnel directly involved in the process. While top management may be sensitive to some of the ill effects of the computer, it tends to be attracted to and carried along with the mystique of EDP as well. This stage often ends in crisis when top management becomes aware of the explosive growth of the activity, and its budget, and decides to rationalize and coordinate the entire organization..s EDP effort. The dynamic force of expansion makes this a fairly
difficult thing to do, however. Dynamics of Early Success Once Stage 1 has passed, and the management and personnel of the computer area have justified and assured their permanent place in the organization, a new psychological atmosphere appears as the users from other departments (the customers) grow in number and begin to interact with the technical EDP staff. Although some users stick to economic value in judging the utility of computer applications to their particular problems and functions, other users develop a fascination with the computer and its applications as a symbol of progressive management techniques or as a status symbol for a department or individual. This fascination breeds an enthusiasm not moderated by judgment.
For their part, the technically oriented systems analysts tend to overgeneralize from the successes they have achieved with transaction-oriented computer-based systems (e.g., order processing, payroll, accounts receivable) in Stage 2. They often feel that “now we can do anything”—in other words, that they have mastered problems of communication with users, that their expertise is solid, and that they are ready to select and deal with projects primarily on the basis of their technical and professional interest. In this heady atmosphere, criteria of economic justification and effective project implementation take a back seat.
When the users.. exploding demands meet the technicians.. euphoric urge to supply, in the absence of management constraint, exponential budget growth results. Overoptimism and over-confidence lead to cost overruns. And once this sharp growth has begun, rationales created in the mood of reinforced enthusiasm are used to justify the installation of additional capacity; this in turn provides the need for larger numbers of personnel and for more rationales for applying the now expanded resource to whatever new projects seem attractive to the crowd. So the spiral begins. The spiral is fed by the fact that as the resource increases in size and ambition, it must have more specialists.4 Indeed, even without this capacity expansion, the continuing pace of technological development in the computer industry creates a constant need for new specialist talent, especially in Stage 2 and beyond. This “technological imperative” is a driving force that has caused the growth of numerous and quite diverse professional groups of computer personnel in the industrial environment. (The reader might find it helpful to review Exhibit II at this point.) Many of these personnel come into the company with a primarily professional orientation, rather than an understanding of or sympathy for the long-term needs of an organization. Like the EDP specialists already employed by the company, these people will be far more interested in tackling technically challenging problems than in worrying about computer payback. If they are allowed to pursue their interests at will, the projects potentially most valuable from the company..s viewpoint may never be worked on. Moreover, the chores of program maintenance and data-base development may be neglected, sowing the seeds of costly future problems.5 All these factors together lead to the evolution of an informal structure among computer personnel and between computer personnel and users. The lack of clear management guidelines for project priorities, for example, often results in sympathetic wheeling and
dealing between EDP systems analysts and the user groups with a preference for those projects which offer the greatest professional challenge. Without specific directives for project developments or new hardware acquisition, too, computer personnel develop expectations of a loose work environment. Some of the users, at the other end of the string, are easily enmeshed in impractical, pie-in-the-sky projects. For short periods such an environment may be highly motivating for some, but, as we need hardly point out again, the other side of the coin is a rapidly growing budget—and a number of vocal and dissatisfied users. In view of these informal dynamics and structures, what can management do to make this period one of controlled growth? How can control be introduced that will head off the impending crisis and dramatic cutbacks characteristic of such situations but at the same time not choke off experimentation with the resource and not turn off the motivation of specialists? Here it is useful to compare the lists of management techniques shown for Stages 2 and 3 in Exhibit III. For the most part, the problems that arise toward the end of Stage 2 can be greatly alleviated by introducing right at the start of Stage 2 the techniques that companies ordinarily use in Stage 3.6 Before carrying out this step, however, attention should be given to two other important strategies acquiring necessary middle-management skills and improving. the company..s procedures for hiring computer personnel.
Acquiring Managers
The main key to successful management in this stage is acquiring or developing middle managers for EDP who recognize the need for priorities and criteria in project selection and who have strong administrative skills: the ability to prepare plans and stick to budgets, the ability to seek out significant projects from users who may not be demanding attention, and, generally, the ability to manage projects. Finding such managers more often than not means going outside the company, especially since most potential middle managers among systems analysts are usually caught up in the computer growth spiral. However, where it is possible, selection from within, particularly from the ranks of systems analysts, can serve the important function of indicating that career paths exist to management ranks. This can show computer technicians and technical experts that there are career rewards for those who balance organizational needs with professional interests. Once those at the general-management level have determined that the time has come to institute such “human controls,” the EDP
manager must be brought to recognize the need for them (if, indeed, he does not recognize that need already) and the fact that he has the countenance and support of top management. For his part, the EDP manager himself must resist the tempting pressures to see his resource grow faster than is reasonable. He has a delicate and important selling job to do in communicating this to other department managers who want his services. Once he is shored up with competent subordinate managers he will be free to carry out this role.Finally, in addition to applying administrative controls, management needs to assess continually the climate of the informal forces at work and plan growth with that assessment in mind. The formal organization of middle managers in the EDP department makes such planning, and its implementation, viable. Acquiring Diverse Personnel Senior management must also recognize the increasing specialization of personnel within the computer department: At one extreme are the highly skilled and creative professionals, such as computer systems programmers. Their motivation and interest are oriented to the technology with which they work; they have relatively little interest in organizational rewards. Their satisfaction and best performance may be assured by isolating them organizationally, to some degree. At the other extreme are the analysts who work closely with functional departments of the company. These people may be expert in particular fields relevant to only a few industries or companies, performing tasks that require close interaction with both users and programmers. Their interests and value to the company can coincide when they perceive that career-path opportunities into
general management are open to them.
There are also the operators with important but relatively low-level skills and training, with some capabilities for organizational advancement, and with relatively little direct interdependence with others. To organize and control these diverse specialists requires decisions based on one basic trade-off: balancing professional
advancement of specialists against the need for organizational performance. To cater to specialist professionals, for example, a company might isolate them in a separate department, imposing few
organizational checks and gearing quality control to individual judgment or peer review. Such an arrangement might motivate a systems analyst to become the world..s best systems analyst. Emphasis on organizational values, in contrast, suggests that the company locate and control the specialists in such a way as to increase the chances that short-run goals will actually be achieved on schedule. This strategy risks obsolescence or turnover among specialists, but it successfully conveys the important message that some specialists.. skills can advance a management career. However, in the early stages management is well advised to avoid the issue entirely: the highly sophisticated professional should not be hired until his expertise is clearly required. Moreover, at the time of hiring, the specialist..s expectations for freedom and professional development should be explicitly discussed in the context of organizational structure and controls (these controls
include those administered by the middle level of EDP management), as part of the “psychological contract.”7
Such discussion can go a long way toward avoiding misunderstanding during the period of rapid growth of computer applications. In effect, making clear the terms of the psychological contract is an example of the management of expectations. In this instance, it is one of the means that can be employed to introduce the organization, controls, and planning procedures that are needed to head off the crisis atmosphere of Stage 3.
Stage 3: Formalization
Let us assume that Stages 1 and 2 have run their bumpy courses without too much direct attention from top management. More likely than not, top management becomes aware of the runaway computer budget suddenly, and it begins a crash effort to find out what is going on. Its typical question at this point is, “How can we be sure that we can afford this EDP effort?” Top management frequently concludes that the only way to get control of the resource is through drastic measures, even if this means replacing many systems analysts and other valuable technical personnel who will choose to leave rather than work under the stringent controls that are imposed during the stage. Firing the old EDP manager is by no means an unusual step.8 From the perspective of computer personnel who have lived through the periods of initial acceptance and growth, but who have not developed a sense of the fit of the computer resource within company functions and objectives, the changes top management introduces at this time may seem radical indeed. Often what was a decentralized function and facility is rather suddenly centralized for better control. Often informal planning suddenly gives way to formal planning, perhaps arbitrarily. This stage frequently includes the first formalization of management reporting systems for computer operation, a new chargeout system, and the establishment of elaborate and cumbrous quality-control measures (again, see Exhibit III). In short, action taken to deal with the crisis often goes beyond what is needed, and the pendulum may swing too far. In response, some computer personnel may leave. What may be worse, most will “hunker down”—withdrawing from innovative applications
work, attending to short-term goals, and following the new control systems and plans to the letter. All of this can occur at the expense of full resource utilization in the long run. In addition, there is a parallel development that dovetails with the budget crisis to reinforce the over control syndrome. Studies of computer usage show that the machines are first applied to projects that reduce general and administrative expenses—typically,
replacement of clerical personnel in such tasks as accounting. Next come projects that reduce cost of goods, such as inventory control systems. The crisis atmosphere of Stage 3 roughly coincides with completion of these first two types of applications. At this juncture the applications that have real potential for increasing revenues and profits and facilitating managerial decision making are still untouched. Financial-planning models and on-line customer service systems are two examples of such applications.
As senior management ponders the problems of Stage 3, it tends to associate the applications of the earlier stages with preexisting manual systems and straightforward cost-justification and control. In contrast, it finds projected applications for revenue producing and decision-making projects hard to envision and define. The natural tendency is to assume that these projects will call for a faster, higher spiral of risk and cost. Thus senior management tends to introduce inappropriately strong controls that are designed, consciously or unconsciously, to put a stop to growth. This clearly may be too strong a reaction for the company..s good.
Three Sound Steps In general, three control steps that are appropriate and not unduly restrictive are available for most large EDP facilities in Stage 3. First, certain of the more established and less complex operations and hardware can be centralized. Second, the increasing impacts of computer applications can be flagged and defined for the top by introducing overseer and resource-allocation mechanisms at the general-management level. Third, some parts of the systems analysis function can be decentralized and other parts centralized, depending on where the systems work can best be done (we shall say more about this shortly).9 Of course, this final step requires that the decentralized systems work be coordinated through a formal integrative mechanism. But the real problem in Stage 3 is not what steps to take; it is how to take them. Management here is introducing change into a web of informal relationships and expectations. How the changes are managed is as important as what the changes should be, but more difficult to define. That is, although there are few formal controls in the first two stages, the informal social structures and norms that have grown up by
Stage 3 are very much a reality to the personnel involved. While it may appear that systems are replacing no systems, this will not be true: Lacking guidelines for project selection, systems analysts will have projected their own sets of priorities, either individually, as a group within the company, or as members of their profession. They will have created criteria and standards, although these will not ordinarily have been written down or otherwise articulated for higher levels of management. Without project management guidelines, systems analysts and users will have developed their own rules and procedures for dealing with each other.
On the whole, the stronger these informal controls and structures are (and the weaker the formal controls and structures are, the stronger they will be), the more resistant the personnel will be to change and the more chaotic and traumatic the introduction of formal systems will be. In managing changes as pervasive as these there is probably nothing worse than doing the job halfway. Doing nothing at all is disaster, of course; but management action that is undertaken on a crash basis—without enough attention to execution and second
and third-order consequences—will sharpen, not resolve, the crisis.For example, management cannot afford to be either squeamish or precipitous in making personnel changes. Trying to introduce needed formalization of controls with the same personnel and the same organizational structure more often than not encourages
conflict and the reinforcement of resistance rather than a resolution of the crisis; by refusing to fire or to enforce layoffs, senior management may simply prolong the crisis, create further dissension, and further demoralize personnel. On the other hand, management must be sure that it retains the experienced personnel who have the potential to function well in the mature stages of the operation—it may not always be obvious who these people are or what their future roles will be. Thus, although the crisis of Stage 3 calls for action, it first calls for analysis and planning—planning that sets forth clear and explicit objectives for exploitation of the computer resource vis-à-vis the user departments.10 Such a plan, once it is developed and understood, can turn anarchy back into evolution, while at the same time avoiding the kind of overkill control that results in
underutilization and underrealization of the potential of the resource. Here are our suggestions for general plan direction.
1. Reposition the established components of the resource.
Whether or not EDP has been carefully managed in the past, most companies need to centralize some parts and decentralize other parts of the computer resource at about this point. The issue arises here because the company reaches a turning point in the way it uses the resource. As the EDP function evolves from the early cost-reduction applications of initiation and early growth toward projects aimed at improving operations, revenues, and the quality of unprogrammed and strategic decisions, the influence of the computer will begin to move up and spread out through the organization. The function may truly be called “MIS” instead of “EDP” from this stage forward. We have already discussed the need for middle managers.. involvement in this stage or an earlier stage. The internal structure they represent reinforces the desirability of making the MIS department autonomous and having it report to a senior level of management. At this point, also, it becomes imperative to reexamine and make explicit the rationales for existing applications that have proved beneficial and to routinize them, so that expensive specialist skills can be turned to new applications. The pressures of new applications ventures, maturing management, specialist personnel, and increasing routine make
centralization of the company..s core hardware resources just about mandatory at this stage. Too, the centralization eases the tasks of maintenance of data and programs, database development, and some of the applications that will be coming up in Stage 4. The very creation of a central “MIS division,” however, creates additional problems.
2. Provide for top-management direction. While centralization goes a long way toward placing the longer lead times, the greater complexity, and the higher development costs of new applications in perspective, it does not automatically help senior management to control the direction the resource takes.
Effective control derives from understanding, and some device is needed to educate senior management so that it can track and evaluate the department..s progress sensibly. The device must also let the resource know what senior management..s policies are and what is expected of it operationally and strategically. This communications device becomes vital in Stage 3 because the resource has grown to a size and a power whereby its applications can affect the strategy and structure of the company as a whole. In a company where a working data base can be used to back up the corporate planning process, for example, corporate planning assumes a somewhat different shape from what it does in a company that has no such data base available. This is clearly a point at which a person at the vice-presidential level (or even the presidential level) must accept responsibility for directing the evolution of the resource.
An active, high-level steering committee is one such device.11 It provides a means for setting project priorities. It not only brings together those who should be concerned with overall management and planning for the company; it also provides a vehicle for confronting and resolving the political problems that inevitably arise with the computer..s more direct impact on managers.. roles,organizational structure, and resource allocation in Stage 3. For, from a behavioral perspective, political issues dominate at this time as never before. Managers throughout the company now see that the applications coming through the pipeline may affect their own roles directly. In the past it was their subordinates who were most affected, and it was largely their own decision to approve or not approve a project; but now a given application may be supported from above and may impinge on their established patterns of work, their decision making, and even their ideas about
what it is they do for a living. Moreover, the prospect of applications that hint at long-term changes in organizational structures and formal departmental roles raises concern within both formal and informal groups of managers—concern about the impacts these changes will have on the strengths of their positions relative to other groups. Such political issues can only be debated fruitfully before top management, and an expert, informed steering committee provides a convenient forum for this debate. For his part, as a member of this committee as well as the head of his own department, the MIS manager should expect to assume a stronger role in general management councils. He should not, of course, expect to be exclusively responsible for setting priorities among projects that would benefit different groups, or for implementing significant changes completely under his own initiative.
3. Reorganize the systems analysis function.
Centralization, and tight guidelines and arbitration from a steering committee, however, can create a distance between the resource and its customers throughout the company. As Stage 3 draws to a close, the company will be planning its most important, most ambitious MIS applications to date. This is hardly a point at which to divorce the users from the resource by erecting an impenetrable divisional barrier. Complete centralization of the systems analysis function would constitute such a barrier. In fact, gearing up for this new era of applications and controlling their impacts requires that the company revise the Stage 3 concept, staffing, and organization of the systems analysis function. The concept should change from systems analysts as
developers of products for users to systems analysts as developers of processes affecting users. The distinction between product and process means, among other things, that the new applications should rarely be considered bounded projects; they will require continual modification as they are integrated into user decision making. Therefore, systems analysts themselves will necessarily become more and more a constant element in the functioning of the users.. areas. As a corollary, they will act as communications conduits between the users, on the one hand, and the computer resource and its programmers, on the other.
Organizationally, this suggests that some systems analysts should be decentralized to user locations while others are retained at the core to build a research and testing facility for the company and its planners. Thus the problem boils down to a trade-off between centralization and decentralization of systems analysts.
These, then, are our best suggestions for minimizing the strains of Stage 3: centralize certain components of the resource, install a steering committee or some equivalent thereof, and spread enough of the systems analysts through the company to ensure that users.. needs are met adequately. For the company wise enough to employ these suggestions at the outset of Stage 2, the trauma of Stage 3 may be almost entirely avoidable.
Stage 4: Maturity
When the dust has settled over the changes of Stage 3, the computer resource will have reached maturity in the organization, and it will have the potential to return continuing economic benefits. The applications listed for Stage 4 in Exhibit I suggest how very significant the contributions of the resource can be, if only they can be achieved. The Manager..s Dilemma At this point the MIS manager has broken into the ranks of senior management, having risen to the level of vice president or equivalent thereof. In some instances he may even enjoy more than proportional support from the president for his view of his own function within the company. He faces this integrative dilemma: On the one hand, he is under pressure to maintain a steady work environment within his own unit. His line managers and specialists are now familiar with relatively formal structure and procedures; they are presumably satisfied with their career prospects, either within their professions or within the company. Thus they may well constitute a force resisting dramatic change,
reorganization, or innovation. Similarly, at this point, senior management and the users probably have a general grasp of the existing technology and existing applications of the resource, and they are reluctant to see major changes. On the other hand, the MIS manager, if he is doing his job well, will be heavily involved in planning for the future. He will be aware that computer technology and modes of application and organization are continuing to change. Thus, if he chooses to maintain stability, he knowingly runs the risk that his resource will become outdated and inefficient. If he chooses to keep up with technology, he knowingly runs the risk that he will lose the integrative fabric that makes his function applicable to the user groups and the company as a whole. The MIS manager must strike a balance between protecting an organizational entity and keeping that entity up to date in its technical environment. He has power and credibility, but he sees that these can be threatened either by too little change or by too much change.
There are no hard and fast rules for resolving this trade-off. The key, however, lies in the quality of communications between the MIS manager and top management, and between the MIS department and users.
Communications with the Boss
By definition, the mature Stage 4 function is one which is being applied to the key tasks of the organization. This may well mean that most of the funding for MIS development is devoted to applications touching directly on critical business operations. This is the case of a large petrochemical firm with which we are familiar, where new applications focus on synthetic-fiber production activities. But whether applications are for line operations or for management decision making, the computer manager in Stage 4 is, perhaps for the first time, in a position to communicate with top management in terms of meaningful, detailed plans.12 Because of the nature of his dilemma, he is bound to come under fire from the users—either for allowing parts of his department to
obsolesce, in the name of stability, or for introducing change, in the name of progress and the state of the art. His relationship and communications with the top must be sound enough to allow him to weather the inevitable storms—given, of course, that the balance he strikes between stability and change is indeed reasonable in broad outline. The experience of many suggests that the MIS manager and senior management think in terms of a three-year contract for the position, with explicit recognition that there will be organizational pressures to push out the MIS manager. With long-term support from the top founded in such a basis, the MIS manager is in a position to legislate policies internally that will exploit the computer as fully as possible. For his part, the senior line manager to whom a mature EDP department reports can little afford not to know the language of the computer personnel—at least to the extent necessary to evaluate project proposals.
Relations with Users In Stage 4, the MIS manager must also move to strengthen the bridges that have developed between the users and computer personnel. Assuming that it is well managed internally, the computer resource still has a continuing extensive interdependence with departments it serves. The first difficulty here is that the users are many and the MIS manager only one. He cannot hope for identical relationships with all departments. Secondly, users naturally tend to co-opt computer personnel into their organizational spheres. If this occurs to any significant extent, user parochialisms will erode the potential for the computer unit to act as an agent for innovation and change However, the bridges can be strengthened and the innovative capability of the unit can be increased simultaneously through a policy of “buffering” the different subunits from user influence. Specifically, performance standards and short-term control devices
should be formalized for the more routine tasks (such as all machine operations and some programming) and the MIS personnel involved with these should be removed from frequent interaction with the users. A system of project management, too, serves much the same function. Finally, the systems analysis function at the core should by this time have taken on the character of an influential research unit, controlled primarily through checks on the progress of its projects. These projects will probably not be within the direct purview of
the user groups; in a mature department, they are usually focused on long-term applications not likely to be demanded spontaneously by user groups or by the systems analysts decentralized into those groups (e.g., corporate inventory control). The weight of this core group of analysts can be used to counterbalance undue user influence. For example, when a user needs a new application, the core group might rough it out and approve the final, detailed design; but the final, detailed design itself should be the work of the systems analysts located in the user department. The decentralized analysts will be most familiar with the user..s needs and best able to produce a working system for him; for their part, the systems analysts at the core can ensure that the system that is finally designed will mesh efficiently with the company..s MIS efforts as a whole, to
whatever extent this is possible. The picture of EDP-user relationships that emerges here is one of considerable complexity and subtlety. Correspondingly, integrating this more specialized and internally differentiated EDP resource into the company as a whole becomes more difficult. This integration requires that the MIS manager take steps to achieve common understanding of his objectives, not only with senior
management but with all other functional managers at the vice-presidential level as well. The steering committee will be important as never before, not only as a committee for determining project priorities, but also as a sounding board for new techniques, policies, and changes within the MIS department itself.
Beyond Stage 4 Currently some large companies have reached the tail end of the S-shaped EDP budget curve: their departments are mature, in the sense defined by the exhibits. But has EDP evolution really come to an end for these companies? What can they expect in the future? In retrospect, the curve seems to have been primarily driven by developments in hardware technology in the second- and third generation
computer systems. One thing certain is that computer technology advancements are continuing at an unrelenting pace. More S-shaped curves are inevitable. Now, however, the advancements seem to be taking place more in software than in hardware; and at present the breakthrough most likely to start off another S-shaped EDP budget curve is the development of data-base technology. This development is providing a way to make the data collected and retained by the organization a company wide resource; and scores of middle
management applications, such as computer modeling, appear to be on the way. In the blush of enthusiasm for this newest advancement in computer technology, however, it is important to remember the painful lessons of the past. To efficiently exploit the newest technology, it must be managed. It must be reconciled with the capacity of the organization to assimilate new ways of doing business better. It is our belief that the forces underlying the crises and problems of the four stages we have described will also underlie future Scurves, such as one created by the emerging database technology. Consequently, management may be able to anticipate the problems and resolve them before they begin. A sign of success would be a dampening of the S-curve, with budgets rising more smoothly as future needs demand continuing investments and increasing
budgets.
References:
1. Richard L. Nolan, “Managing the Computer Resource: A Stage Hypothesis,” Communications of the ACM, July 1973, p. 399.
2. For a related argument, see James G. March and Herbert A. Simon, Organizations (New York, John Wiley, 1958), Chapter 6.
3. For further discussion of this point, see Paul R. Lawrence, “How to Deal With Resistance to Change,” HBR January–February 1969, p. 4.
4. John Dearden, “MIS Is a Mirage,” HBR January–February 1972, p. 90.
5. Richard L. Nolan, “Computer Data Bases: The Future Is Now,” HBR September–October 1973, p. 98.
6. For an approach to introducing these steps in either Stage 2 or Stage 3, see F. Warren McFarlan, “Management Audit of the EDP Department,” HBR May–June 1973, p. 131.
7. Harry Levinson et al., Men Management and Mental Health (Cambridge, Harvard University Press, 1962).
8. See Richard L. Nolan, “Plight of the EDP Manager,” HBR May–June 973, p. 143.
9. See the section which discusses the McKinsey study on effective users, in F. Warren McFarlan, “Problems in Planning theInformation System,” HBR March–April 1971, p. 78.
10. For mechanisms for improving the interface between EDP and users, see John Dearden and Richard L. Nolan, “How to Control the Computer Resource,” HBR November–December 1973, p. 68.
11. F. Warren McFarlan, “Problems in Planning the Information System,” HBR March–April 1971, p. 75.
12. Ibid.
13. Paul R. Lawrence and Jay W. Lorsch, Organization and Environment (Boston, Division of Research, Harvard Business School, 1967).
