A Model For Change Copyright CAUSE 1994. This paper was presented at the 1993 CAUSE Annual Conference held in San Diego, California, December 7-10, and is part of the conference proceedings published by CAUSE. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, that the CAUSE copyright notice and the title and authors of the publication and its date appear, and that notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To copy or disseminate otherwise, or to republish in any form, requires written permission from CAUSE. For further information: CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303449-4430; e-mail info@cause.colorado.edu A Model for Change William R Brunt Regents College Albany, New York This presentation will cover management principles and organizational structures with specific strategies which are both applied and untried to create an IT provider capable of change One principle is to take those tasks which have been traditionally assigned to the IT provider and distribute to the user community For example, a specific strategy is to share the process of technology implementation which is demonstrated, documented and encouraged by the user community An educated user community which can carefully articulate their needs into report or processing specifications can be achieved through cooperation of provider and user Users will become familiar with the concepts of files, fields, directories, reports, break points, sorting and filtering The user community will actually write a large percentage of their own reports Introduction This paper and presentation is intended to present a model for change. This model covers management principles and organization structure to facilitate the implementation of change. As each concept is introduced, actual strategies are described. Some strategies have been used and a discussion of their success follows. Others are untried and it is hoped to implement them in the future. The following management prineiples and their specific application are discussed. 1. Work Groups Specify, Code & Test Individual Reports 2. Distributed Training/Support Computer Trainer & Computer Training Group E-mail SUPPORT 3. Flatter Organizational Structure Management Team & Technical Pool 4. Functional Specification by the User Community New Projects initiated with a specification 5. Operational Responssibility Transition Technology Implementation Human Resourees creates/maintains user accounts Facilities trained on the table plant and equipment moves 6. sharing the Resoures Allocation Decision The Automation Planning Committee and the request queue Some of these techniques have been used at Regents College in Albany, New York. The College required a structure capable of embracing change as technology introduction had been essentially on hold for 12 years. During the last two and a half years, the College went from having a single person responsible for technology to a staff of 12. During that time, the College went from having approximately 30 stand alone personal computer to 200 in a network configuration and its own administrative data proeessing system using a commercial product. Work Groups Work groups can be utilized in a variety of ways. One involves the production of services. A second use of work groups is in the reporting and task assignment. All projects, tasks and delivery of services can be completed within the framework of the work group. The minimum size of this work group is two. Consider the creation of a new screen to enter applications from students who already posses significant college level credit. The initial conceptual discussion and final product are all accomplished within the framework of a work group. In the conceptual discussion, the team approach utilizes a dialogue between the head of a program, the advisors to prospective students and a representative from the computer services department where an outline of the basic functionality is covered. Contrast this approach to the traditional hierarchial structure where the program director indicates the screen requirements in a separate discussion to the representative from computer services in the absence of others. In the team discussion, the staff from computer services are able to listen to the operational needs as outlined by the staff on the front lines. The program director can react and provide feedback on the larger operational issues. The staff from computer services are able to comment on the functionality which can be provided and the relative costs thereof. The program director can react to the costs of different functions and features and judge the benefits with feedback from those on the front lines. In a traditional hierarchial approach, this same information will need to be communicated and will take about the same total amount of staff time but will occur over a longor period of time. For example, the program director will work with the front line staff to create a rough functional specification. A separate discussion will then be held between the program director and computing staff. The task will be outlined with little opportunity for any cost benefit analysis of functionality. The computing staff will then begin a specification and subsequent coding. Any questions which arise during the coding will be presented to the director of the program and will require further consultation with the front line staff to resolve. Once the application has been coded, a team approach will require that testing be performed by another member of the computing staff. This accomplishes several things. The application becomes familiar to at least two poople on the technical staff. The testing by someone who did not write the application ensures a higher quality product and also provides some redundancy for support of said application. Additionally, a formal program review of one person's code by another ensuras that new programming techniques are shared and a sense of consistency is continually refined. Using a work group in the delivery of services shortens the product life cycle and improves quality. This technique of sharing the development of new applications has been used very successfully at Regents College. It has resulted in higher quality and increased sophistication of the applications. The reporting and task assignment in a work group means that all members of the group will be aware of the activities of each other. An actual strategy can take the form of individual reports at staff meetings of the tasks since the last meeting and those planned until the next one. This has the benefit of drawing upon the different experiences and talents of all members of the group as plans are developed. It has been my personal experience that these meetings often result in a new better course of action. People must be encouraged to freely comment without personal bias on the work of others. This is perhaps the most difficult to achieve when personnel are at different levels. It has taken several years for this sort of communication to develop and flow freely. Success in this area will only come in the long term. Distributed Training Support Training can be accomplished in a distributed fashion by having both a dedicated computer trainer and a computer training group. The computer training group are staff from throughout the organization who are interested in computer training. They serve on a committee responsible for developing and providing training. Distributing training among a group accomplished several things. As large projects come to completion, a sizable group of trainers is available to bring even larger groups of people on line. The computer trainer can act as an expert providing guidelines and standards to facilitate a structured guided learning process. The amount of training which can be completed over a short period of time is increased. The demand for training will cycle as the IT providers alternate between development and delivery. For example, it may take several months to bring a new application into production. If it is a large application, the demand for training will be great. The period of time to accomplish this training will be shortened by having a large pool of trainers available. The computer training group will also serve to critic new lessons as instruction is developed. This process has been termed piloting. It is assumed the computer training group will assist both the dedicated computer trainer and other trainers in the group when piloting new material. Equally important to distributing training is feedback on the quality of instruction given. Each lesson will require written surveys covering th quality of instruction and relative value of content to expectations. Flatter Organizational Structure In computer services, Regents College has managed to flatten the organizational structure. There are 12 positions within the office. Of the twelve, ten are professional staff. The interaction and supervioion of professional staff requires significantly more time as the decisions and day to day work are more complex than the route tasks usually assigned to support staff. The flattening of the organizational strueture has been achieved by supervising work on a project by project basis. The director and associate director divide the supervision and the pool of technical staff to work on these projects. Rather than having individuals report on rigid lines of communication, reporting is accomplished on the individual project. Upon completion of the project, the portion of time dedicated to a particular project is put back into the pool and the next task is begun. On a weekly basis, the director and associate director meet to update one another on each other's progress and to critic and comment. It is assumed communication is complete and sufficient to allow either to assume the other's role. Functional Specification by the Userr Community It has happened where new applications are begun with nothing more than a thumb nail sketch on a napkin over lunch. The project is described as very straight forward and easily completed in several days. The actual result takes many weeks and encompasses issues which were never considered in the initial discussion. There is little appreciation for the issues which arise during the application life cycle. The solution is to require a complete function specification be completed by the user community. It used to be that concepts such as top down or bottom up design were terms used solely by systsms analysts. Today, it is common for people to understand some fundamental design techniques and functional requirements. Training should not only encompass the use of applications but the specifying thereof. Users are becoming increasingly familiar with terms such as files, fields, directories, reports, break points, sorting and filtering. Several levels of end user functional description can be put to use. For example, IT providers may in fact write the process description and merely require that decision makers within the end user community sign off on th deliverable. This will have mixed results. Some will read ln details the proposed system and others will not even glance at the description and place their signature at the bottom. I have found a direct correlation in demand for services and the depth of review. The most sophisticated users will completely describe an entire system and deliverable. This will allow those involved in application development to concentrate their skills on producing deliverables. Many are wanting to have ad-hoc query tools placed in their own hands. The writing of reports by end users serves to make information more accessible and give a greater approciation for the work of IT providers. Regents College has achieved mixed results in these areas. The level of participation is really left to each unit manager. Those who have chosen to beeome very involved will ask for the most sophisticated application. Additionally, those who are quite involved also require the least re- work as the application is put to use. Operational Responsibility Transition Operational responsibility transition involves taking those tasks which have traditionally resided in the IT domain and distributing them to the user community. Examples of this include technology implementation, system account management and hardware relocation. The implementation of technology has usually fallen on the shoulders of IT providers. The real work in provlding technology is to articulate a particular solution and build concensus. This does not reguire the skills and capabilities of a seasoned data proeessing individual. On the other hand, it is not a realistic expectation to call upon the end user to fully articulate a solution without some prior experience. Partnerships between IT providers and end users will be formed through the successful completion of projets. This will give the end users a better grasp of the steps required to introduce technology. The process will beeome clear and the role of introduction can transfer from IT provider to end user. The final result will be that the IT provider can concentrate on creating and supplying new technology in concert with the end user eommunity. It has been the norm for decades that only IT providers could be entrusted with the task system aceount maintenance. This requires that Human Resources and/or the hiring program notify the IT providers of new employees. The notification requires communieation and overhead for a task whiech is route and can be best accomplished by Human Resoures. In other words, have Human Resourees create the new aceounts on the various systems. The hiring of new employees always involves providing a physical space. Either facilities or office management are called upon ensure such space is provided. Increasingly, this space will involve a work station of some form as the "PC on every desk" is the norm. Physical facilities would then deliver and install the PC or equivalent to the desk top. Any cross-conneection at an intermediate distribution frame or main distribution frame would be handled by facilities as well. The maintenance of accounts and providing of desk top computers are just two examples where responsibility for providing technology can shift. It is a case of making a single entity responsible for servicing the new and exiting employees. Sharing the Resource Allocation Decision The decision of which projects to work on next when provided with a limited amount of resources is best shared among those expecting service. A high level committee entitled the Automation Planning Committee could be charged with examining the projects and determine what is to be done next. This process would not divide the resources equally based on some pre determined budgeted charge back system. Instead, it would be the committee's charge to prioritize projects in the order which would give the institution the most benefit overall. The request queue and its handling by a committee has had mixed success. Some new initiatives and programs are started without regard for needing computer support. The automation of the initiative then bypasses the queue and receives immediate and rushed attention. At the time of this writing, I am trying to create a system which would be responsive to the needs of all and fair in the distribution of services. I have found the most difficult challenge in creating a model for change is to determine which project will be worked on next. Those who receive attention from the IT providers will consistently use the queue mechanism. Those who do not receive service based on the committee's decisions will seek alternate providers whether they integrate into the developing information systems or not. The task of actually deciding within the framework of a committee is not easy by any means. Each member of the committee will view the projects with different returns and costs. Some members may require several lists in different categories while others will prefer to work in a single format. As I said earlier, this is one of the biggest challenges in creating a model for change. Conclusion I hope that you enjoyed the presentation and this paper. I would be most interested in any comments you may have. I am particularly interested in any techniques which I have not mentioned which facilitate the introduction of changing technology. The paper is geared towards creating a core of highly capable people within IT to provide services and relying on many operational aspects from the user community. It is most useful when organizations need to play catchup. It is not meant to be utilized when organizations are wanting to downsize and consolidate.