This Web page has been archived on the Web.

1983 Report of the Auditor General of Canada

Synopsis

4.1 The government's activities are now highly dependent on the computer.

4.2 The 1982-83 EDP expenditure was $610 million annually and has increased very little, in constant dollar terms, in the last five years.

4.3 Most government electronic data processing (EDP) is based on the conventional technology of the 1970s. We examined these conventional EDP activities to see whether they provide a base from which the government could go on to make selective and appropriate use of the new microprocessor and telecommunications-based EDP technology of the 1980s and thereafter.

4.4 All the aspects of the government's conventional EDP activities which we examined offered opportunities for improvement. Looking to the future, moreover, we saw signs that bring into question the government's ability to take prompt and full advantage of the new technology.

4.5 Availability of expertise for new systems development is limited by the need to devote an ever-increasing proportion - now about 70 per cent - of the present development staff to maintaining and making incremental improvements to the large body of existing applications. Furthermore, there was a shortage of experienced EDP personnel until last year, and it is likely to return. Three to four-year backlogs of new systems development can be found in many departments.

4.6 Adequate methodology for developing systems exists in most departments, but it is often not followed. We observed some overruns on development costs and many late deliveries. Management controls over system development, such as project cost accounting systems, need improvement.

4.7 One especially difficult problem in systems development seems to be that of establishing user needs and settling on firm specifications, particularly in small departments or those inexperienced in EDP. Similarly, improvements are required in the way departments establish the EDP equipment needs of their programs and determine priorities for meeting these needs. Both these problems relate back to the fundamental requirement for strategic planning for EDP. Strategic planning is essential to meeting long EDP lead time requirements, but few departments have been able to forecast their requirements far enough ahead to do such planning effectively.

4.8 With a few exceptions, departments are not in a position to operate at alternative sites if a main computer site is out of action for a lengthy period.

4.9 Treasury Board's policies and guidelines for managing conventional computing activities appear to provide a framework adequate to control and direct today's EDP activities, but they may need some revision and extension to meet the needs of the next few years.

Introduction

4.11 Treasury Board estimates the outlay in 1982-83 to support electronic data processing (EDP) in the federal government at about $610 million and the number of person-years primarily engaged in EDP at close to 10,000. These figures, and similar ones elsewhere in this chapter, reflect only what is called general-purpose computing; they exclude computers dedicated to particular scientific experiments and cases where the computer is wholly integrated to some larger equipment complex; for example, military weapon systems, and air traffic control. The figures, moreover, do not show the full importance of computing in government affairs. Today, the great majority of government employees handle data processed by computer in doing their daily work.

4.12 The scale and pervasiveness of computing activities in the government make them intrinsically worth examining. A number of recent developments in the EDP field, moreover, prompt particular attention at this time. New advances are occurring almost daily in microelectronic technology, advances that increase the speed and reliability of computer hardware while reducing its cost.

4.13 At the one extreme, "personal" computers are now available for a few thousand dollars; at the other, large scale processors handle millions of operations per second at ever-reducing unit costs. New devices and software make it possible to interconnect terminals and micro-computers to each other and to central computers. Advances are being made in the management and accessibility of large files of information. New languages are being produced which make it easier to define and program new applications. We appear to be on the verge of a new wave of computer applications, among them the automation of office processes fundamental to the apparatus of government. This new technology offers real opportunities to improve the efficiency of the government's operations and to serve the public better. The fundamental question is whether the present state of EDP in the government, and the initiatives now being taken, will permit the government to take advantage of the new technology of the 1980s and thereafter.

4.14 A not wholly conclusive, but perhaps significant, indication of the way EDP is developing in the government is provided by the Treasury Board's data on government expenditure on EDP. These data are shown graphically, in current and in constant dollars, in Exhibit 4.1.

Exhibit not available

4.15 This Exhibit indicates that, in the late 1960s and the early '70s, the federal government's current dollar expenditure on EDP was growing at an annual rate of about 20 per cent. By the late '70s, however, this rate had declined to about 8 per cent. With inflation taken into account, therefore, the real rate of growth was small or even, in one year, negative. Although recent data suggest that the real rate of growth may again become positive this year, the overall picture indicates that EDP's fraction of the total government budget for internal services has stabilized.

4.16 Some provincial governments - notably Ontario - appear to be increasing their EDP budgets at rates much faster than that of the federal government. This difference may, of course, just mean that federal EDP is nearer to "maturity" than is that of the provinces; new major applications, of a sort developed at the federal level years ago, may still be coming into service provincially. To decide whether this is so, we would have had to make a much more detailed analysis of provincial computer activities than it was possible for us to undertake.

4.17 Taken alone, therefore, the rates of growth of EDP expenditure do not provide clear evidence that computerization is slowing in the federal government while it accelerates elsewhere. An impressive volume of development work is still in progress. Nearly all EDP managers we interviewed, however, told us that a large and increasing proportion of their development staff was now tied up in maintaining existing systems. Also, the major projects we looked at seemed usually to be elaborations of existing systems, rather than new designs or "from the ground up" replacements. In the field of office automation, moreover, initiatives in the government are still preliminary and tentative; they do not yet represent large expenditure. In general, EDP managers appeared to be using their resources to consolidate existing systems rather than to exploit new technology. In doing so, they may act wisely, but we believe it is also important that sufficient effort be made to keep the new technology option open for the government.

4.18 There is some evidence, therefore, that, despite the very great decline in the hardware costs of data processing illustrated by Exhibit 4.2, a point may be approaching at which computerization within the federal government will be limited, by financial restraints, to rates of development that would leave the government far behind the private sector, and even behind some other governments. It is not within our province to recommend that expenditure on EDP should be increased: other priorities may prevail. The shortage of funds and expertise might be relieved by re-deployment of resources already allocated to the departments or, in some cases, already in the hands of the EDP organizations. In any case, we believe it is proper for us to draw to the attention of Parliament and the public some of the implications of leaving government EDP more or less the way it is. Our study shows, we believe, that those implications could be fairly serious; and, inevitably, some of the problems are related to the availability of resources.

Exhibit not available

Scope of the Study

4.20 The primary purpose of this study is, therefore, to assess the extent to which the federal government is demonstrating due regard for economy and efficiency by ensuring that it will be in a position to make selective and appropriate use of the computer technology becoming available to it in the 1980s and 1990s. In particular, the study concentrates on the present state of EDP in the government, and enquires whether certain essential pre-conditions are being met for any believable program for making the most effective use of the technology of the next 10 to 15 years.

4.21 What are the pre-conditions? Many could be suggested, but we believe that any sustained program of computerization in the '80s would need to rest on at least the following foundation points, which must now be in existence:

- demonstrated ability to manage the systems development process, to build (or otherwise acquire) systems on time and within budget;

- processes for acquiring computer equipment that ensure that, in making the acquisition, senior management gives full and informed attention to value-for-money considerations;

- due attention paid to the increasing dependence of departments on their computers, shown by intensified preparedness to continue operations should a computer site be made inoperable by a disaster;

- a core of expert EDP managers and technical people, with effective means at hand for recruiting and training more of them, in the face of the highly competitive sellers' market for such expertise anticipated as the economy recovers;

- long-range EDP planning processes, capable of dealing with the long development lead times now characteristic of EDP; and

- government-wide policy and direction adequate to articulate all these processes and to provide the leadership and co-ordination needed to get under way a worthwhile program of research, pilot projects, etc., directed toward judicious adoption of the new technology.

4.23 To conduct the study, we examined the activities of a sample of government departments in each of the topic areas. Our findings are drawn largely from interviews with EDP and user managers supplemented by documentation reviews where the overall scale of the study permitted. In deciding which departments to interview in respect of each topic, we tried to make a selection balanced with respect to such variables as the size and nature of the department's EDP operations, their geographic distribution, and the degree of centralization of EDP organization. Our selection of departments, grouped according to the topics studied, is displayed in Exhibit 4.3. Additionally, we drew on the findings of departmental comprehensive audits, both those of recent years and those being reported this year. We also visited the central agencies concerned with EDP.

Exhibit not available

Observations and Recommendations

Computer Systems Development

4.25 We focused on three principal aspects of the system development process in government:

- We tried to assess the ability of departments to deliver the system needed by the user on time and within budget.

- We attempted to measure the backlog of development work facing the development "shops" in the departments, since if the conventional backlog were very large, few resources would be available to exploit the new technology.

- We asked whether departments are ear-marking the resources - people and money - needed to prepare for the new technology.

4.27 Management of the systems development process. Treasury Board guidelines prescribe fairly detailed project management procedures, and computer literature is well developed in this area. Most departments we visited had, in fact, adopted a formal system development "methodology". Such a methodology prescribes rigorous standard practices for managing projects. It imposes on the project team a disciplined, step-by-step progression through well defined stages in the life of the project, and requires stringent reviews at clearly defined milestone points, to ensure that what was supposed to be delivered at the milestone was delivered. When coupled with tight program documentation standards, such a methodology will do much to enhance management's control of the systems development process.

4.28 In actuality, however, we found great variation in the degree to which development teams observe the rules of their methodologies. Many of the problems we observed would not have occurred or would have been greatly reduced if the department had followed its own methodology. Why, we asked, was that not happening? We thought we could throw light on this question by examining certain basic problems that the manager of a computer system development project must solve, in the particular context of the project. In the 10 departments we visited in this part of our investigation, we tried to find out how project managers were, in fact, dealing with these problems.

Problem 1: How can managers define the user's needs and reflect them in the system's design?

4.30 There is no easy solution to these problems. The users can usually argue convincingly that rapid changes in departmental policies and practices preclude a design "freeze". The EDP management, much as it would like to see the user pay for being "choosey", would be most unwilling to lose control of development funds to users, and thus become dependent on them.

Problem 2: How can project managers control their projects?

4.32 The managers we interviewed found it very difficult to do these things. Most of the projects we reviewed had inadequate plans, lacking in detail and long out of date; obviously, the plans were not being used as a management tool to control the project. What seemed to be lacking was the ability to re-plan quickly and effectively, to take account of specification changes and departures from the original plan in timetable and expenditure. Such planning tools as were available simply could not cope with the iterative planning - planning and re-planning - necessary to maintain project control in a rapidly changing context.

4.33 Nevertheless, we believe that, if given the incentive provided by a systems development process much more visible to senior management than it is today, project managers would develop the planning tools required to do the sort of iterative re-planning required. In a private-sector software development firm, such tools are a prime requisite if the company is to meet its contracts and stay in business. The recommendations we make later on seek to induce, in government in-house software projects, a somewhat similar environment and, with it, a greater incentive to plan - an incentive that is usually lacking today.

4.34 No matter how expert planners they are, however, project managers must still be able to get reliable feedback from a project monitoring system which tells them whether they are meeting their objectives on time, on specification, and within budget. Problem 2, therefore, leads to Problems 3 and 4.

Problem 3: In particular, how can managers control project costs?

4.36 In the government setting, however, such a two-stage process - or anything like it - is not often seen. The prolonged and ponderous approvals process discourages such an approach. And since departmental EDP management does not usually have discretionary funds to underwrite a substantial design study, management must make its decision on a sketchy, preliminary design - and correspondingly "soft" cost estimates. When approval based on those estimates is forthcoming, a full design often later shows that the system will cost far more than the sum originally estimated. Several such instances occurred among the projects we examined. At this point, too much money had been spent to allow the project to be cancelled. Typically, it is broken up into modules and stretched out in time indefinitely. It is encouraging to notice that a recent Treasury Board circular (June 1983) requires that this two-stage approval process will now apply to EDP projects involving more than $1 million. This directive would appear to meet some of the problems we have described here.

4.37 If managers can somehow overcome their problems in establishing plans and budgets, they must then find a way to monitor progress and actual cost. Here, the present state of project accounting in the government does little to help. A framework for project management is to be found in the Treasury Board's Administrative Policy Manual, and the Office of the Comptroller General has published guidelines for project monitoring and reporting; but, in the EDP projects we examined, we found few project cost accounting and monitoring systems that approached those described in the guidelines.

4.38 However much doubt there may be about the project's consumption of "internal" resources (staff hours, in-house computer time, etc.), the departments usually do keep careful track of expenditure on external contracts. Their doing so argues in favour of contracting system development out; this argument is not, however, conclusive. Generally, departmental EDP managers prefer to retain control over their computer system development projects through a project manager from their own staff. Contracting the project out to a commercial software house is thought by many managers to be unwise, because, when the system is delivered, they see no assurance of ongoing support for it, and they have no one on staff who has the builder's intimate knowledge of the system.

4.39 If the development is to be carried out in-house, therefore, EDP project managers lack a fundamental tool of management. They cannot tell how much their projects have cost to date, except by an approximate calculation based on the number of staff employed and how long they have been working.

Problem 4: How can the project manager deliver the system on time and on "spec"?

4.41 Nearly all the methodologies urge a "post-implementation" review of the project, with participation of all those involved, to decide whether the system does what is required of it, and to capture and profit by the experience all have gained in its development. The departments we visited acknowledged the potential value of such reviews, but cases in which they have been performed are rare indeed.

4.42 Since there is no government-wide standard for maintaining project logs recording what was done, when, and why, we had great difficulty in piecing together narrative histories of the projects we examined. With that said, however, we believe the following broad statements to be true:

- an incremental improvement to a large existing system, carried out by the EDP professional staff of one of the departments long established in the EDP field, is likely to be on "spec", on budget, and on time - within some reasonable tolerance; and

- in other circumstances, departments' practices in managing systems development tend to fall well below the standards they themselves have adopted - standards which we believe to be attainable and representative of good private-sector practice.

4.44 The ability of the federal government to absorb the rapid technological advances of the 1980s should be, however, the object of very real concern. Most of the departments with long established EDP organizations now report that they are using 60 to 70 per cent of their professional staff simply to maintain and enhance existing systems. EDP managers pointed out to us that this proportion has grown steadily in recent years, as new systems went into service and then required maintenance and modification. Experience in private-sector development shops is comparable. In the government, however, since the overall person-year allocations of these organizations tend to be frozen, their capacity to develop new systems diminishes with every new computer application they put into service. If no relief comes, the moment cannot be far away that systems development must almost cease. In many departments, we also found that three, four, or even more years of work for the existing staff has been identified, approved, and is in the waiting queue. Beyond that seems to lie a user "wish list" of indefinite extent.

4.45 With so much of its resources needed simply to maintain and extend systems representing conventional technology, the average systems development shop is hard pressed to make technical people available to learn about, and experiment with, the newer technological developments. A widening of the disparity in levels of technological development inside and outside government must, therefore, be anticipated. Various expedients to relieve this situation are available and may be effective, at least in some measure. New "user-friendly" computer languages, simplified programming systems which permit users to do their own programming, personal micro-computers - all these may be of help. But fundamental redeployment of person-years and money, within systems development shops and to them from elsewhere in the department, cannot be indefinitely deferred, if advantage is to be taken of the technology now becoming available.

4.46 What should be done? If senior departmental management could see through the fog which now hides the systems development process (sometimes even from the eyes of project managers themselves), we believe the quality of project management would improve dramatically. To bring about that visibility, we see the minimal requirements we describe immediately below as essential.

4.47 The overall project and its phases should be defined; that is, it should always be possible to ascertain exactly what is to be delivered, when, and at what cost. This definition is the equivalent of the contract which, if properly drawn and kept up to date, defines the intentions, rights and obligations of the private-sector systems developer and those of the developer's client, the future system user. Deliveries against this "contract" should be verified by a procedure which establishes that the user has received what was bargained for, and which also discharges the developer from further responsibility for the delivery. Included here is the post-implementation review on which the methodologies insist.

4.48 All costs of the project should be identified as such and accumulated in accounts designed to alert management, at every level, to cost overruns and missed deadlines. These accounts would comprise not only financial data but also "logs" recording the nature and estimated cost of changes in design, and a general record of who decided to do what, when and why.

4.49 To be effective and objective, the documents and accounts required by these recommendations must be matters of official record in the department, and be subject to both internal and external audit. It is not enough that they exist only as working papers in the system development shop.

4.50 To ensure the completeness and integrity of the project accounting system, and to make certain that all funds spent on developing a system are charged to it, we believe it is important that the project accounting system be fully reconciled with the department's regular accounts. Otherwise, there will be a tendency to "bury" expenses incurred in connection with the project by charging them to accounts where they will have to bear less scrutiny. For the same reason, the project accounting system should, in its financial aspects, be administered, not by the EDP organization, but by the department's financial officers, and should be based on and reconciled to the department's regular system of accounts.

4.51 We do not believe we are suggesting anything not already a feature of most of the "methodologies." The project accounting system we have in mind in no way departs from the Project Monitoring and Reporting guideline published by the Office of the Comptroller General. We should stress, too, that we do not believe project managers feel they have things they wish to hide. On the contrary, the absence of a proper project monitoring system deprives them of an essential management tool.

4.52 In summary, we recommend that departments should:

- formally define, in the early stages of a systems development project, what is to be delivered, when, and at what cost;

Acquiring EDP Facilities

- determining EDP needs of departmental programs and establishing the order of priority for meeting them;

- make/buy analysis;

- obtaining Treasury Board approval in principle; and

- open tendering, through the Department of Supply and Services, with DSS returning to Treasury Board for final approval in the case of very large contracts, before letting the contract to the successful bidder.

4.55 Determining needs and setting priorities. We found little disagreement on the broad principles to be applied in determining computer needs; they can be summarized as they were in paragraph 2.61 of our 1980 annual Report:

- The need for service should be defined and related to approved program objectives.

- There should be an adequate and up-to-date statement of the type and level of service required.

- All reasonable ways of providing the service should be evaluated as objectively as possible.

- The need for the service should be regularly reviewed.

4.57 At the heart of the institutional problem is the fact that program managers, who are the ultimate users of EDP services, neither are nor can be entrepreneurs. They must deliver certain program services to the public, with due regard for economy and efficiency. But they do not usually have to worry about the effect that acquiring a new computer will have on a profit-and-loss statement. They do, however, compete for computer service with the managers of other programs. This competition for resources is not like the competition of the marketplace; rather, it is a bidding process in which all players are tempted to exaggerate their needs to protect their positions in the final allocation of the available resources.

4.58 Even without this bias toward overstatement, the problem of needs determination would still be very difficult. The simplest case arises where a single computer, or computer complex, is to serve a single program. At least in that case, it should be possible to show that more money spent on the computer will improve the delivery of the program. The large departmental computer centres are, however, usually internal service bureaux, serving the needs of many programs and a multitude of "customers". Ongoing analysis of the needs of all these customers is something the managers of the internal service bureaux lack both the authority and the resources to do. In practice, therefore, the internal service bureau tends to base its case for additional equipment on projections of future workload based on present overall loadings and rates of growth.

4.59 This sort of justification is unsatisfactory, because it does not show how the computer services are being apportioned among the department's programs. To meet this objection, some departments use an "accounting routine" in the computer's operating system to keep moment-by-moment track of the computer resources being used by each task active in the machine. In this way, users of the machine can be "billed" for the use they make of it. This permits the internal service bureau to show how its computer supports the department's programs. Whether that use is being made with due regard for economy and efficiency is, however, a question that the bureau manager must refer to the user. Since the users are many, and the uses complex, we found few internal service bureaux prepared to carry their needs determination to the user level.

4.60 Perhaps the most difficult needs-determination problem arises in those departments where EDP activity is geographically dispersed and organizationally decentralized. Such situations are common in those departments carrying out large programs of scientific research. Getting a clear, current and reliable picture of the complex needs of all the many users is a most challenging task for the EDP co-ordinator in such organizations.

4.61 With due allowance made for these institutional constraints, however, we still found that the quality of needs analysis studies was deficient in its purely technical aspect. Here again, there is no denying that the problems are difficult. For example:

- the program's EDP needs must be forecast for the probable technological life of the equipment, a period which could be anywhere between 3 and 10 years long;

- in some cases, determining the transaction-processing capacity of an unbuilt computer system is technically difficult; and

- the trade-offs between level of service (system response time, transaction turnaround time, etc.) and cost are usually, at this stage, ill-defined.

4.63 The cycle of technical studies must be performed several times, with increasing levels of detail and technical complexity, before a worthwhile proposal can emerge. This is demanding work, requiring a high degree of professional expertise and sustained effort. At present, few standards exist for its performance in government, and there is no recognized professional specialization for those who carry it out. This is most unfortunate, because senior management cannot be expected to review technical studies of this kind; yet it must, in making the priority decisions discussed below, be able to place full reliance on their accuracy and completeness. We are convinced that there are professional people, in both the public service and the private sector, who have the technical knowledge to do this work. What is required is standards or prototypes that define the content of the technical studies and the general way in which they are to be presented.

4.64 Treasury Board and the departments should take steps to give senior management assurance of the quality of technical staff work supporting EDP acquisition proposals; in particular, Treasury Board should commission the preparation of prototypes of the studies that should support acquisition proposals at each stage of the decision process and, if required, should publish a guide for preparing each type of study.

4.65 Establishing the EDP needs of a program and translating those needs into requirements for systems and facilities are no more than half the problem. The resources available are never sufficient to provide all the EDP support that the programs could profitably use. Somehow, an order of priority must be established for meeting EDP needs. To avoid having the department's EDP management arbitrate among its customers, many of the departments in our sample have established EDP steering committees, representative of all major users, to settle these priorities. This they can do only if the committee's members are senior enough to speak with full authority for the user organizations they represent. With this proviso, we commend the steering committee concept to departments that do not have such committees. Increasingly, priorities decisions will probably have to be made within the department, since everyone seems to agree that "new money" will be harder and harder to obtain. The decisions will be difficult, because they will often require robbing Peter to pay Paul. To meet this situation:

4.66 Where they have not already done so, departments with many EDP user organizations should establish EDP steering committees, representative of all major users. The rank of the members should be senior enough to ensure that the committee's view of the relative priority of the department's programs accurately reflects that of senior management.

4.67 To make decisions in EDP matters, senior departmental management will need an interest in EDP and an understanding of it that it does not seem to possess today. Here, what is needed is not technical understanding but rather an ability to spot proposals which, though technically sound, are of high risk, or those which have a broader scope and impact on the department's operations than can be tolerated. The Office of the Comptroller General has already taken some steps toward defining guidelines to meet this need.

4.68 Treasury Board should prepare a guideline for the use of senior managers, when they are asked to approve EDP proposals, to assist them to identify proposals of high risk, those where appropriate steps have not been taken to ensure technical soundness, and those where the assessment of impact on the department's operations has not been properly carried out.

4.69 Make/buy analysis. Only the departments with a limited amount of EDP activity now remain dependent on private-sector service bureaux, although most departments supplement their in-house capability by occasional use of private-sector facilities. The preference for in-house equipment seems strong and is confirmed by the data given in the Annual EDP Review published by Treasury Board: the average percentage of total computer services costs expended annually on private-sector machine-based computer services was 14.1 per cent in a four-year period ending in 1978, and 14.8 per cent in a similar period ending in 1981; it has remained essentially constant in the interval.

4.70 Treasury Board approval. We usually found it almost impossible to locate documentary evidence of just what considerations had been laid before senior management when a major acquisition decision was being made. The documents most readily available were Treasury Board submissions. They and the other supporting documents were, commonly, advocacy pleadings in which the solution favoured by EDP management was buttressed by every available argument, and in which alternatives, if mentioned at all, were identified only to be dismissed. Clearly, the EDP people were not asking that senior management choose from a costed list - a "menu" - of options to satisfy an EDP need; rather, they sought ratification of a decision they had already made.

4.71 It was evident that the Treasury Board Secretariat is not staffed to give acquisition proposals serious technical review. The Information Management Group in the Secretariat is responsible for policy implementation in such areas as EDP and telecommunications, and this responsibility extends to reviewing all the annual plans and special submissions relating to these areas. The mere fact that there are only five officers in the group leaves no doubt that it can catch only the extreme cases where the department has produced a wholly indefensible proposal.

4.72 An important, and fairly recent, development marks an evolution in the Treasury Board's role in the acquisition process. In at least two cases, the Board has found it possible to approve the adoption by a department of a "common technology." This means, in effect, that, from now on, the department's central computers will be of the technology manufactured by IBM or by one of the companies whose computer "architecture" is compatible to that of IBM. Other suppliers, if they wish to bid equipment (tape drives, magnetic disks, telecommunications, for example), must make it compatible with an IBM-technology mainframe.

4.73 The "common technology" policy is not an easy one for a government to announce, because it tends to exclude some major mainframe suppliers from bidding, though they could bid on a requirement for an IBM-compatible satellite computer, if they wished. Once adopted, however, the "common technology" policy does open the tendering process to quite a wide range of companies now making IBM-compatible gear. The policy does not necessarily confer an advantage on IBM, since that firm has as much or more competition within the market covered by the "common technology" as it has outside it - even in mainframes.

4.74 Tender. Open tender is not absolutely mandatory, but it is clearly intended to be the norm in major acquisitions. In practice, the open tender requirement conflicts with the fact that most of the large EDP establishments are firmly locked in to a single mainframe supplier. This situation has arisen neither through the inertia of the departments nor through the machinations of the suppliers. Its cause is the enormous and ever-growing investment in application software that departments have developed to run on their supplier's hardware. Switching to the hardware of another supplier entails converting the application software to run on the new system. The coming of on-line databases and telecommunications-based systems has tended to tighten the link between application software and the hardware it was developed to run on. Today, therefore, a wide open tender to replace an existing mainframe is pretty rare: we encountered only one in our examination of the recent acquisitions of six departments and, in that single instance, the circumstances were very exceptional.

4.75 In general, therefore, open tendering is restricted to cases where an entirely new application is to run on hardware independent of existing systems, or where the tender is for equipment peripheral to the central computer mainframe(s).

4.76 It is in this context that the decision by some departments to adopt a "common technology" appears in its full significance. By making such a decision, a department that now operates on mainframes of, say, three suppliers must still convert the software now running on the mainframes of the two suppliers to be dropped. Doing so is expensive and might take as long as five years. But, within the common technology, effective open tendering can take place for equipment of all types, presumably with advantage to the taxpayer.

4.77 The other side of the coin is that the "common-technology" policy accords de facto recognition to IBM technology as the industry standard; and, in practice if not in principle, it excludes some major mainframe suppliers from the bidding. It will be of great interest to see whether other departments, whose main technology today is not IBM, see enough advantages in the "common technology" strategy to make the switch.

EDP Security: Disaster Preparedness

4.79 Why? The answer is lack of funds. Providing "credible" disaster preparations is very expensive. The departments have found that Treasury Board will not give them extra funds for this purpose, and they are unwilling to absorb the large costs in their regular budgets. A spectacular disaster would, if it occurred, make it easier for EDP managers to get departmental funds for disaster preparedness. In Canada, however, no such disaster has captured popular attention since the Sir George Williams affair in 1969. The odds against such an occurrence seem long, and departmental management has usually accepted the risk of leaving the situation the way it is.

4.80 Only one of the eight departments we interviewed in this context had believable plans, thought out in detail, for moving to an alternative site, should the facilities at a central site be knocked out for a long period. This department has several computers of the same kind, regionally dispersed. In these circumstances, a disaster plan based on moving work to another of the regional sites is believable. Such a procedure must, however, be practised every few months, because computer programs and the hardware they run on change rapidly. We know of only one department that is carrying out a sustained program of such "drills", which are expensive and disrupt ordinary operations.

4.81 We found that EDP managers were acting conscientiously in those physical security matters where no major outlay of funds is required. For example, the recommendations of the RCMP's Security Evaluation Inspection Team (SEIT) were generally acted upon, where action could be undertaken and resourced by local management. (SEIT is a central service available to a department to review its EDP security situation.) Similarly, we found that nearly all the departments we spoke to maintained back-up copies of their critical data and programs at locations away from their computer sites.

4.82 The major problem is the cost of partially duplicating facilities to provide enough surplus capacity to handle critically important workload after a disaster. How much extra capacity is required, and how long after the disaster it is needed, both depend on how vital it is to maintain continuity of service to the public. Only one of the eight departments we examined had conducted a formal review to determine its maximum tolerable period of computer outage.

4.83 Often, it was clear that management was having a problem assessing the importance of the computer to the department's operations. If the transfer payment programs were looked after, and the military and civilian payrolls met, many departments seemed to feel they could get by for a long time without the computer. From that viewpoint, spending a lot of scarce money on a back-up computer site did not seem to carry very high priority.

4.84 To see whether a similar opinion prevailed outside government, we made some enquiries in a small sample of private sector firms. And, indeed, the picture there is not very different. Most of the firms had made no believable disaster recovery preparations. There were exceptions, of course: one or two major institutions, recognizing their total dependence on centralized databases, had built ultra-secure fortresses to protect them. Others had sought to reduce the expense of a back-up site by joining forces to build a site with all the basic environment for the computer (airconditioning, raised flooring, etc.) but no equipment (since the members of the "club" operated equipment of different types). The concept would work only if a member firm's computer hardware could be replaced within a tolerable interval after the disaster.

4.85 The disaster recovery issue seems to be unresolved. Three departmental proposals for back-up facilities have recently been rejected by Treasury Board, though in each of these cases the Board left the door open for the department to make further, more fully elaborated proposals. The departments might grapple with the back-up problem more effectively in concert, rather than as individual entities, especially if a common back-up site seemed attractive. But, as far as we are aware, no formal joint initiative is under way.

4.86 Although the decision to accept the risk of going without back-up may be defensible in some cases, we believe it ought not to be made by default. We therefore recommend the following:

4.87 Departments should formally assess the length of time their programs could tolerate an interruption of computer service, and the computer capacity which they would need thereafter to provide emergency service until a site made inoperable by disaster came back into service.

4.88 In consultation with the Treasury Board Secretariat, departments should explore whether there is some joint undertaking which would provide an economical solution to the disaster-preparedness problem.

4.89 Whatever solutions departmental senior management finally adopts should be formally recorded, and the record should state what risks are to be provided for, and which are to be accepted.

Managing EDP Personnel

4.91 These sharp fluctuations in demand for EDP personnel were also felt within the federal government service. The departments' Annual EDP Reports to Treasury Board - especially those of 1981 - contain many complaints about problems in obtaining and retaining qualified computer systems (CS) staff. The Advisory Committee on Information Systems (ACIS), a high-level interdepartmental committee which advises Treasury Board on EDP matters, noted in 1981 that the "shortage of CS personnel was an extremely serious management problem." By the end of 1982, on the other hand, departments were reporting an ample supply of good applicants for these jobs, at least in the junior levels. It was still said to be difficult to get experienced systems software people and project managers. When we visited departments early in 1983, however, improving economic conditions were having an effect; the Technical Service Council was reporting the first upturn in vacancies for computer professionals in 21 months; and some managers to whom we spoke anticipated a return of the shortage conditions, perhaps intensified.

4.92 Given its dependence on EDP to support its programs, the federal government needs the ability to obtain, train, and retain the CS personnel required for that purpose. We therefore decided to look more closely at the CS group to define the extent of the 1978-82 shortage, determine its effect on a sample of departments and see how they reacted to it. We tried to identify the major constraints in recruiting and retaining good CS personnel and to develop recommendations looking to future periods of intense demand.

4.93 Extent of the shortage. The federal government CS population grew by approximately 11 per cent from January 1978 to December 1981, at which time there were 2,460 CS employed. This growth was not easy to achieve. In 1976, losses of CS staff from the government were approximately 6.9 per cent of the total CS population. By 1981, this annual loss rate had grown to almost 13 per cent. In the 1981 environment of increasing turnover and scarcity of knowledgeable EDP staff, recruitment of new personnel into the CS group from other occupational groups and from sources outside the federal government increased by 84 per cent over 1977 levels.

4.94 The losses of CS staff from the government do not seem extreme when compared to those of the private sector, where annual turnover rates of 20 to 40 per cent were common in this period. Losses experienced by the total computer systems community in the federal government do not tell the whole story, however. Individual EDP managers had also to cope with losses of CS to other departments and to other units within their own departments. Public Service Commission data on individual departments, reflecting interdepartmental transfers and promotions, confirm losses of 10 to 36 per cent annually. From the manager's point of view, therefore, the effect of the shortage and the staffing turbulence it engendered did not seem greatly different from that experienced by private-sector managers.

4.95 These sharp losses do not appear to have caused a long-term decrease in the number of persons in the CS occupational group; the losses were indeed replaced, but the newcomers to the organization were much less knowledgeable and experienced than their predecessors.

4.96 Its effect on EDP in the departments. In our sample, only Statistics Canada and Supply and Services Canada - departments with populations of CS personnel in excess of 200 - were able with any consistency to avoid wide fluctuations in the turnover of CS staff from year to year. The departments with small CS populations seemed to be those hardest hit. Statistics Canada had annual losses under 20 per cent in all of the shortage years except 1981; the Departments of Communications and Labour, however, both suffered losses in excess of 20 per cent for all but one year in the years 1977 through 1981.

4.97 Managers in departments with less than 100 CS staff indicated that they felt particularly vulnerable during the shortage. They believed that, because of the small size of their organizations, their personnel gained a broader variety of experience and were therefore in greater demand. These managers believed that the loss of 2 or 3 people in a small team of, say, 10 was a much heavier blow than it would be to a larger organization.

4.98 The managers we interviewed had no doubts about the damage the turnover was inflicting on their organizations. They found themselves having to spend a much larger proportion of their time on the staffing process, just when a staff shortage and the many new staff coming on strength made maximum demands on them to lead their teams. The staff they lost were their experienced people; those who came in were usually fresh from the community colleges and the universities. (This is confirmed by the Public Service Commission, which reports that government-wide losses of CS2s exceeded intake at that level, from outside the government, in each of the years 1977 through 1980. The situation at the CS3 level was even worse.) In short, the managers believed that the high turnover stripped their organizations of many of their best personnel - the fast learners, the brightest, and the most highly motivated.

4.99 Efforts made by departments to relieve the effects of the shortage. Given the rather dark picture of the turnover effects painted for us by the managers we interviewed, we were surprised to find how little the traditional methods of recruitment and training were modified by departments to meet the emergency. Commonly, within the departments, EDP staffing is done piecemeal, vacancy by vacancy, and there seldom seems to be sufficient co-ordination to produce an integrated program for staffing, training, career planning, and so on for the whole EDP organization.

4.100 There was little evidence of functioning plans to cycle personnel through a variety of projects to develop their skills. Similarly, although training was generally available, particularly in the departments with the large CS populations, financial constraints and operational pressures often required that it be oriented to meeting immediate operational needs rather than to developing a body of computer expertise required in the long term. Few of the departments we visited were doing human resource planning to identify their future requirements for CS staff in terms of numbers, levels and skills. Also, there was little evidence that career paths were being identified for personnel currently on strength, or that succession planning was being done for critical jobs.

4.101 In fairness to the managers, we should recognize, however, that they felt that succession planning is not easily reconcilable with the merit principle and the system of appointment to position that prevails in the public service; grooming Mr. A to fill position X can be seen, they believe, as an attempt to "rig" the eventual competition for that position. Nevertheless, it is our view that it is usually possible for managers to outline, for their staff, avenues of personal development from among which they may choose.

4.102 The increasing demand for computer systems personnel that began to be felt in 1978 was not recognized by the Public Service Commission or by the Personnel Policy Branch of the Treasury Board Secretariat until well into 1981. For reasons that are unclear to us, the pressure on the staffing processes in the departments to get CS staff did not communicate itself through to the Commission until then. Finally, a working committee of the Advisory Committee on Information Systems demonstrated to the responsible officials of the Commission that their perception of the turnover of CS staff needed revision. It was, therefore, only in late 1981 that the Commission began to react to the shortage.

4.103 To its credit, when the Commission recognized the problems identified by ACIS, it moved to react more promptly to individual staffing requests, and it initiated Job Fairs at computer conferences to allow departments to locate and recruit competent staff with a minimum of delay. Unfortunately, for many departments the shortage had already gravely depleted experienced staffs, and the damage was already done. By that time too, the economic recession had begun, and the shortage was abating.

4.104 The Treasury Board Secretariat has the primary responsibility for conducting government-wide human resource planning for critical occupational groups. The Secretariat's Human Resources Group did not initially believe the CS shortage to be critical and took no action to deal with the departments' concerns. This absence of response appears to confirm the observation made in paragraph 3.35 of our 1981 annual Report that the Secretariat "has not met its overall responsibilities for government-wide human resource planning". Noting that the Secretariat has responded to occupational group problems when they became urgent rather than by anticipating shortages and developing appropriate plans, the 1981 Report, paragraph 3.37, recommended that the "Secretariat should regularly assess human resource requirements in the public service, identify critical occupational groups for which human resource planning should be carried out by the central agencies and ensure that the appropriate action is taken." Unfortunately, these mechanisms were not in place at the time of the CS shortage.

4.105 Constraints on the EDP manager in personnel matters. Since this study is of the management of EDP, it does not attempt any general examination of the classification and staffing processes in the public service, or give consideration to collective bargaining matters. In the view of the managers we interviewed, however, these are of central significance in any explanation of the constraints which limited their ability to respond to the CS shortage. We believe that we ought to report these views without, however, asserting that the picture they present is complete or balanced.

4.106 As the managers saw it, then, the recruitment and staffing process was itself one of the prime constraints. Managers stressed that it was frequently necessary to react quickly to the availability of a qualified person before that person was lost to another job. The managers felt particularly vulnerable when they were in competition with private-sector employers. They cited the excessive number of steps, the paperwork and the bureaucracy surrounding the staffing process as causes of delays which they said averaged four to six months to fill available positions, even when up-to-date position descriptions and classifications were available.

4.107 An evaluation of the staffing actions undertaken by several of the departments included in our study confirmed that the managers' opinions were not always exaggerated. For example, data prepared by the personnel administration branch of one of the departments in our sample show the average overall elapsed time required in 1980-81 to fill vacant CS positions (at other than the entry level) by open competition was 146 calendar days. If there was a closed interdepartmental competition, 193 days were needed; or if there was a closed competition within the department, 245 days. (Officials of the Public Service Commission have pointed out to us that the staffing interval can be made much shorter if the department has forecast its needs to the Commission in time for an inventory of candidates to be developed.)

4.108 Moreover, the Public Service Commission noted in its Dialogue magazine in February 1981 that the basic process required an average of 50 working days for a "closed" (internal to the public service) competition using poster advertisements. This average was taken over job competitions for all occupational groups, not just those for CS. An additional 21 working days were required to deal with such complexities as language testing and checking for suitable candidates in the priority lists (for example, those identifying persons surplus to requirements or laid off). Later articles in the same magazine noted that three large Canadian corporations with national and multi-national operations were able to complete a similar type of competition in an average of 17 working days. Dialogue pointed out that federal government departments are bound by the Public Service Employment Act to specific procedures that account for much of the time taken to complete a staffing action.

4.109 Finally, individual EDP managers stressed their concern with the inadequacy of the training they could afford to give their computer staff. Restrictions on the proportion of departmental funds available for training forced managers - or so they said - to concentrate on courses oriented to specific hardware or software which the individual was required to use on particular jobs.

4.110 Tight person-year controls, scarcity of supply in the market for computer systems personnel and the difficulty in staffing permanent CS positions are clearly reflected in the growth of demand for contract personnel. The Department of Supply and Services maintains Regional Master Standing Offers (RMSO) covering such services; it comprises a series of contracts between DSS and participating EDP contractors that provides for the supply of suitably qualified personnel on an as required basis, at previously agreed daily rates. Departments wishing to acquire services under the RMSO agreements simply issue a requisition to a supplier specifying the requirement. In total, the actual value of contracts for the 12-month period commencing October 1981 under RMSO agreements was about $19.5 million.

4.111 In 1981, the average daily rate paid to contractors we estimate to have been $300-$320; and we have calculated they worked some 62,000 person-days, or around 275 person-years. Since, at that point, there were some 2,460 persons in the CS category, the RMSO contractors were equivalent to 11 or 12 per cent added to the numbers of the available internal CS staff.

4.112 These figures strongly suggest that some EDP managers have found a measure of relief from their computer systems staff problems by resorting to contract personnel. Indeed, some of the departments we visited are obviously dependent on these services.

4.113 Conclusions respecting management of EDP personnel. There is evidence that the economy of the country is now coming out of recession. As noted earlier, this recovery is being accompanied by increasing demands for specialist computer systems personnel. Recent projections of the demand for such personnel for the years 1983 and 1984 vary from predictions of slow and cautious growth to a return to the acute shortage of the early 1980s. At present, the departments and agencies in our sample appear as poorly prepared for a shortage as they were in 1978.

4.114 We have been told by officials of the Public Service Commission and of the Treasury Board Secretariat that a proposal for a Human Resources Management System has been scheduled (subject to ministerial approval) for implementation in 1985, and that this system might meet many of the concerns we have expressed. At present, however, the central agency machinery to deal with a shortage situation does not seem to be much better developed than it was in 1978. Nor does any department in our sample appear to have used the experience gained between 1978 and 1981 to develop a strategy for retaining existing CS staff. The ability of departments to recruit, train and develop computer systems specialists in a planned and co-ordinated way does not seem to have improved. Continuing difficulties in retaining skilled and experienced staff must, therefore, be anticipated.

4.115 In summary, we found that the EDP managers in the public service were faced in 1977-81 with a variety of extremely difficult problems caused by a very buoyant market for computer systems personnel. The scarcity conditions in this employment market created high turnover in CS positions and led to a serious loss of experienced EDP systems specialists. The losses in numbers were eventually made up, but the levels of expertise - at least in some organizations - were more permanently affected.

4.116 The private sector was also affected by the scarcity market, but its effects on the government EDP community were aggravated, at least in the view of the managers concerned, by institutional constraints which hindered them from taking appropriate, timely and vigorous steps to counter the worst effects of the losses of experienced staff they suffered.

4.117 The managers' statements on these issues should not be accepted uncritically. We believe, however, the opinions they have expressed to us are so widely held that the whole area deserves closer examination. The dependence of the government on EDP is great and increasing, as we have noted; in the last analysis, that dependence is largely on the expertise of the CS community. We believe it is reasonable to foresee a return of the scarcity employment market for CS above the entry level, and that it should be possible to find ways to enhance the government's ability to recruit and retain these people, even in such a market.

4.118 The Treasury Board Secretariat and the Public Service Commission, in conjunction with departments, should:

- review the problems identified in this study and the recent experience of departments and central agencies in the recruitment, training and development of CS staff;

Strategic Planning for EDP

4.120 The absence of these plans puzzled us, because we could not imagine how a modern EDP establishment could be managed successfully without them. The lead times to acquire computer hardware and to develop application software - and also to recruit and train technical staff - are now so long that a manager must work to a planning horizon three to six years away. Moreover, the long-range planning process provides a most useful opportunity to gain senior management's understanding of, and support for, the EDP function. If the benefits of long-range EDP planning were so obvious, why were the plans so few?

4.121 But, first, were the plans really as rare as our earlier experience indicated? In our sample of 10 departments, we found that formal plans and formal planning processes were few indeed, although there are now one or two cases where substantial planning work has been done. Most departments (7 out of 10) are now committed to producing a formal plan, but there is a wide variety of views on what such a plan should contain. We believe there is a need for Treasury Board to assist the departments here, by preparing one or more prototype plans to illustrate the sort of material they should contain.

4.122 Often, we did find informal plans and planning processes in existence that might meet much of the need. In many departments, the senior EDP managers seemed to have a pretty good idea of what they wanted to do over the next few years. Why, we asked, do we find this sort of informal planning in some departments and not in others? And, where it does exist, does such informal planning meet the need?

4.123 We found the best developed informal plans in departments where the EDP organization is large and tightly centralized. In these departments, there is usually a large, stable baseload of EDP work. This workload can be fairly reliably projected into the future, because it is unlikely to be changed suddenly by shifts in departmental direction and policy. It thus provides EDP management with a reasonably firm base for planning. Departments with small, recently formed EDP establishments usually lacked this baseload; they seem to find serious difficulty in long-range planning, even when EDP was under centralized management.

4.124 However, where the EDP function is scattered in small, geographically dispersed pockets, there is usually no single person with substantive department-wide authority over it, and the department's EDP co-ordinator is hard put to keep track of the department's EDP developments even after they happen.

4.125 The difficulty with informal planning processes is, of course, that the plans produced may not have the full approval and support of the most senior departmental managers, nor is there any assurance that all the officials who should participate in the planning do so. Many EDP managers are very conscious of this defect and can document a succession of attempts they have made to get formal approval. It usually proved impossible, however, to get agreement to more than bland generalities, especially in those departments that are really loosely-knit federations of semi-autonomous branches. The lack of formal planning processes carries with it the danger that the department's EDP plans may bear little relationship to its overall corporate plans.

4.126 The lack of a formal planning process carries with it the danger that rapid advances in technology will make EDP systems obsolete by the time they are placed in service. In an extreme case, development could begin with a concept based on the current technology and, years later, after spending millions, a system could emerge which was inefficient or inadequate in an EDP environment that had made radical advances in the interval. (No clear case of this surfaced in our sample, but we did encounter an instance in which a complex system was decided on that was based on a central database, centrally imposed procedures and the integration of a wide variety of functions, all features being characteristic of the technology prevailing in the early to mid-1970s when the decision was made. Development of the system continued for nearly 10 years on this basis and, although the organization later began to use new microprocessor and telecommunications-based technology in its work elsewhere, within the main EDP system the degree to which it could be applied was constrained by the original choice).

4.127 However difficult it may be to avoid, planning myopia can have serious consequences. One department in our sample found, in 1976, that its computer supplier was getting out of the business and passing its customers to another supplier who would, for a while, service the equipment and maintain the software. For that reason, and to meet an increasing workload, the EDP people in the department knew that they would soon have to change equipment. Yet, despite agreement in 1977 as to what should be done, little action resulted until 1980, when a review commissioned by the internal audit group reported that the equipment replacement project had fallen seriously behind schedule. At about the same time, the successor supplier gave notice of the impending withdrawal of maintenance service for the old machine. The withdrawal-of-service date was then so close that the department could not go to an open tender, because such a tender might select a supplier whose equipment would call for conversion of existing application software. A directed tender, therefore, had to go to the one supplier - the "successor supplier" mentioned above - whose hardware was compatible with the application software without a major conversion effort. Planning problems of this sort can be expected to intensify as departments attempt to put to use the new microelectronic technology of the 1980s.

4.128 It seems clear that, if departments are going to make selective and effective use of this new technology, long-range EDP planning will have to be done on a scale scarcely imagined today. The systems to be built will be central to the moment-to-moment, work-day life of nearly every public servant; they will also be "on-line" and accessible in real time throughout the day - and they will take years, and many millions of dollars, to implement.

4.129 Departments should:

- establish clearly defined planning processes to produce the formal EDP plans required by Treasury Board policy;

The Role of Treasury Board

4.132 In practice, the Board makes rather sparing use of this mandate, and its willingness to broaden its intervention in EDP issues is uncertain. Moreover, the number of Secretariat officers concerned with EDP policy does not appear adequate to support a greatly increased scale of activity. It is appropriate, therefore, to examine the role actually played by the Treasury Board in EDP before making any suggestion as to how that role might be modified. We will concentrate on the EDP functions of the Secretariat's Administrative Policy Branch (APB). The Branch:

- develops the EDP policies now principally expressed in Chapter 440 of the Administrative Policy Manual;

- receives the Information Technology and Systems Plan (ITSP - formerly the Annual EDP Report and Plan) prepared by departments and agencies having EDP activities, and advises the Board whether (and under what conditions) each Plan should be approved;

- assists Program Branch to assess the EDP content of special submissions from the departments, once again advising the Board on approval; and

- publishes an annual Review of EDP and Telecommunications in the Government of Canada. Some of the data included in this periodical are of interest both to the government EDP community and to private-sector equipment vendors. The cost of producing the data is significant: some of the larger departments have one or more person-years tied up in co-ordinating the collection of the ITSP data which are rolled up into the tables in the Review. In our judgement, the types of data collected and the way they are tabulated require revision to reflect changes in EDP which have occurred since the Reviews started to appear in the early '70s.

4.134 APB officials do not see their role as extending to monitoring departments' compliance to the policies which APB develops and promulgates in Treasury Board's name. Rather, they see compliance monitoring as being the province of the internal audit staff in departments. Our position remains that stated in paragraph 3.22 of our 1981 Report:

Policies and systems should be monitored to assess compliance and evaluated to assess their effectiveness.

- Systems should be in place to monitor the adherence of departments and agencies to policies and systems and to evaluate the degree to which they are achieving the desired result in a cost-effective manner.

- The results of monitoring and evaluation should be used in the revision and development of policies and systems.

4.136 In our interviews with officials of the Treasury Board Secretariat, we detected an understandable reluctance to have Treasury Board take a more prominent leadership role in introducing the new technology to the government. There is certainly wisdom in the view that the needs of the departments are too varied and the whole undertaking is too vast to warrant any attempt to manage the introduction of office automation "from the centre". Clearly, departments must do most of the planning and managing themselves. We are also aware, however, that, in the departments we visited, the activity directed toward office automation is fragmented, largely unco-ordinated, and very modestly resourced. It is hard to see how significant developments can soon take place without some leadership from the Treasury Board.

4.137 Plan and submission review. The APB officials seem to recognize the disparity between their present resources and the enormous task that any full review of EDP plans and submissions would represent. Of necessity they tend to concentrate attention on a few cases where unusual developments are taking place or are foreseen.

4.138 Here, we believe that our previous recommendations intended to increase the "visibility" of the system development process would, if put into effect, assist the APB in this part of its role. Although the current state of government EDP would scarcely justify dismantling the present Treasury Board machinery for its control, clearly some departments could earn a degree of autonomy by demonstrating competence to manage their own EDP affairs. But the "visibility" we have recommended would obviously be a pre-condition of that autonomy. We are not suggesting that, for such departments, the basic submission and reporting requirements would be withdrawn; rather, we believe that implementation of these recommendations would allow the Board's officials to identify departments on whose EDP proposals they could place a high degree of reliance. APB would thus be able to give more time to the proposals of the departments that had not arrived at the same level of EDP maturity.

4.139 Future policy needs - an example. Although we share the view, expressed by the Secretariat officials we interviewed, that the Board should not attempt to manage EDP in detail and across the whole of the government, we believe that as departments begin to feel the effects of some of the current developments in technology, the Board will have to intervene at the policy level.

4.140 An example will illustrate this point. We have estimated that, in 1982, the government entered into about $27.5 million of contracts for purchasing or renting the category of word-processing equipment administered by the Office Systems Group in DSS-Supply. This is by no means the whole intake of word processors, but only the part comprising stand-alone units not usually looked on as EDP equipment, though they incorporate a microprocessor. About 2,100 work stations of this type appear to have been acquired during 1982 (the precise figure is unknown, and the figure we give here is based on a sample of DSS records).

4.141 Until recently, acquisition of word processors of this type was handled at DSS by a unit separate from that responsible for acquiring electronic data processing equipment. In many of the departments we visited, these acquisitions were processed routinely by the administrative services of the department, in much the same manner as the purchase of a typewriter would be handled. The EDP organizations in some departments do have a sign-off control on these acquisitions, but most do not. The significance of these developments becomes clear when one notes that, already, about 26 per cent of these units incorporate hardware permitting them to be linked to some other computer by telecommunications. It is anticipated that this fraction will grow substantially in the next few years. But no industry-wide standard telecommunications interface between computers yet exists; therefore, an organization wishing to have its computers "talk" to each other must ensure telecommunications compatibility of the computers when they are acquired. At present, we know of only one department operating several equipment types that has an intercommunication standard.

4.142 The danger here is that a "Tower of Babel" will arise as soon as those who use the equipment discover its potential to communicate with other computers and access the big departmental databases. At present, the confusion is compounded by a very gradual, and not very orderly, approach in the EDP industry itself to a general intercommunication standard or standards.

4.143 Against this rather chaotic background, a significant debate is going on within the EDP community in the government. The managers of the large EDP organizations see uncontrolled proliferation of incompatible equipment, and foresee pressures from self-taught personal-computer users to gain access to corporate databases, in ways the managers believe will endanger the integrity of those databases.

4.144 The EDP user community tends, on the other hand, to see the coming of the microprocessor as a way to escape from the frustrations of being a captive customer of the large departmental EDP centres. At last, users may be able to do their own system development in their own way, on their own schedule, without having to wait for years in the development backlog queue. Such users are inclined to see initiatives by EDP management to assert control over microprocessors as a form of imperialism. They discount the compatibility argument, saying that the equipment becomes obsolete so rapidly that present acquisitions will be due for replacement before the intercommunication problem arises.

4.145 Some departments are attempting to resolve this issue; others are not. It is hard to see how Treasury Board can long remain on the sidelines, because departmental senior management is not usually technically equipped to arbitrate between the EDP managers and the present and prospective microprocessor users. Sooner or later, government-wide policies and standards of some sort must be established.

4.146 The Treasury Board should review, clarify and, as necessary, strengthen its role in the management of information technology so that departments may know where they can expect the Board's direction and guidance and where they are to be left on their own.

4.147 In particular, the Treasury Board should revise its definition of EDP to encompass all those aspects of electronic information handling on which it wants special reporting or wishes to exert special control.

4.148 The Treasury Board should state how it intends to monitor departments' compliance with its policies; also, it should make clear how it proposes to get feedback from departments to evaluate the effectiveness of its policies.

4.149 If the Treasury Board intends to rely on departmental internal audit organizations to monitor compliance with its policies, it should take steps to ensure those organizations have the understanding of EDP that such a role requires.

4.150 If the Treasury Board is prepared to assume a leadership role in encouraging and facilitating the introduction of new information-handling technology, it should say so. It should then take the initiative by:

- developing a strategic plan to review, consolidate and bring existing EDP policies up to date

As this chapter was being prepared for publication, we were advised by Secretariat officials of that the Treasury Board had given a mandate, on 7 July 1983, to a Task Force on Informatics whose activities will extend over the next 12 to 18 months. The terms of reference of the Task Force appear to direct its attention to concerns similar to many we have expressed in this chapter, and to signify that the Treasury Board intends to take a leadership role in developing the whole information technology area within the federal government.