Project Implementation Using a Team Approach Copyright CAUSE 1994. This paper was presented at the 1994 CAUSE Annual Conference held in Orlando, FL, November 29- December 2, 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 resources 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; 303-449-4430; e-mail info@cause.colorado.edu PROJECT IMPLEMENTATION USING A TEAM APPROACH Sherri Yerk-Zwickl Lafayette College Easton, PA Lafayette College is a small, private liberal arts college in Easton, PA. The administrative activities of the College are supported by the five member staff of Administrative Computing Services who provide software programming, analysis and training to administrative personnel. In the fall of 1993, Administrative Computing began the process of evaluating commercial software to replace the hybrid home grown/commercial software that had been in use since 1983. In February of 1994 a package was chosen and the process of converting the old system to the new was begun. The Team method of implementation was chosen for this 18-month project. What makes this implementation unusual is that this five-member team is self-directed; there is no formally appointed team leader or project manager. This presentation will serve to share our experiences to date working as a self-directed team; where we have been successful and why, as well as the problems we have encountered along the way and what we have done toward their resolution. INTRODUCTION Lafayette College is a small to medium size private undergraduate-only liberal arts college in Easton, Pennsylvania. The College's curriculum is distinguished by the rare combination, on an undergraduate campus, of degree programs in both the liberal arts and engineering. The full- time student enrollment is approximately 2000, with faculty and administrative staff numbering approximately 500. In 1980, the College decided to stop using a local service bureau in favor of in-house processing using a commercial, college- oriented software package. This software has been extensively modified over the past thirteen years with additional modules developed in-house using the development tools present within the package. In the Fall of 1993, the College decided to evaluate other commercial software packages in order to take advantage of current and future technologies to better support the activities of the College. In February 1994, after extensive evaluation of the available software packages that would run on DEC equipment, a decision was reached and the software was purchased. The primary objectives of this acquisition were to improve student services through integrated administrative systems, provide consistent information throughout the campus community and to assist the user base in receiving timely information to support their decision-making capacity. This project was started in March of 1994 and encompasses the following: the installation of new hardware and software, training (both technical and user), conversion of existing data, evaluation of work flows in each functional office with an eye toward maximizing efficiency, system and parallel testing and cutover to the new software. This project will initially affect every administrative area of the College. The systems to be implemented include Student (Admissions, Registration and Student Billing), Alumni, Financial Aid, Human Resources and Finance. The estimated length of time to complete this project is 24 months with the implementation schedule calling for the final module to be implemented by July of 1996. The Administrative Computing staff is composed of five programmer/analysts who have been with the College five to ten years. Prior to the start of the current project each staff member was assigned to one or many functional administrative areas with very little overlap. For example, one person was assigned to support the Alumni and Development offices as well as the Registration area, another the Human Resources, Admissions and Recruiting offices, a third the Student Billing, Payroll and Financial Aid offices as well as some system management tasks, the fourth person handled Business Office requests (Accounts Receivable, Endowment, and other financially-oriented areas). The fifth person was responsible for developing and maintaining projects that distributed Administrative information (student schedules, transcripts, department budgets) on the campus-wide information system for use by students, faculty and staff. Requests for software modifications, enhancements or new development would be reviewed by the Director and then typically assigned to the appropriate staff member to complete. There was very little collaboration between staff members on projects since a typical request wouldn't involve more than one functional area. Each person was responsible only for their own work and usually didn't need to rely on anyone else for assistance. TYPICAL PROJECT MANAGEMENT SCENARIOS In most projects of a medium to large scope there are defined leadership roles. Some of these roles have been called project leader, project manager, team leader, and systems analyst., among others. As some of these titles suggest, there are leadership activities that are handled by these people in an effort to schedule resources, manage and coordinate tasks, as well as just plain keeping the project running (hopefully) smoothly and on- schedule. Responsibilities of a Supervisor * Transmit information, knowledge, and skills, in a timely manner to project members * Interpret and apply policies and work specifications for the project members * Teach project members how to manage work processes effectively and evaluate results * Establish communication channels between departments and project members in order to eliminate duplication of effort * Support goals of the project to internal and external customers * Troubleshoot for project members in areas of expertise * Track and communicates progress to management * Serve as a mediator in conflicts * Schedule resources in the most efficient manner (Harrington-Mackin, 1994). While this list is by no means exhaustive, it does give a glimpse into what the skills are that need to be present in order to manage a project effectively. LAFAYETTE COLLEGE'S TEAM APPROACH TO PROJECT MANAGEMENT While the use of teams to accomplish tasks is by no means a new concept, the manner in which we have decided to use this model is somewhat unusual; we have no permanently assigned team leader. We are what is called a "self-directed work team". What makes this interesting is that we didn't start out to be self-directed work team - it just evolved from the existing staffing structure. In an effort to understand where we were heading, some research turned up the following: Self-Directed Work Teams Description * Comprise an intact team of employees who work together on an ongoing, day-to-day basis and who are responsible for a "whole" work process or segment * Assume "ownership" of product or services and are empowered to share various management and leadership functions * Are limited to a particular work unit * Function semi-autonomously; are responsible for controlling the physical and functional boundaries of their work and for delivering a specified quantity and quality of a product or service within a specified time and at a defined cost. * Are all cross-trained in a variety of work skills * Share and rotate leadership responsibilities; team members have equal input in decisions * Accept the concept of multiskills and job rotation (except for jobs requiring years of training and technical expertise) * Work together to improve operations, handle day-to-day problems, and plan and control work * Set own goals and inspect own work; often create own work and vacation schedules and review performance as a team * May prepare own budgets and coordinate work with other departments * Usually order materials, keep inventories, and deal with suppliers * Are frequently responsible for acquiring new training and maintaining on-the-job training * May hire own replacements and assume responsibility for disciplining own members * Monitor and review overall process performance Most self-directed work teams gradually take on responsibility for these tasks as they gain confidence in their own skills and are able to redefine the role of the supervisor. The shift to self-direction represents change, and with change comes resistance. (Harrington-Mackin, 1994) An excellent point made by Harrington-Mackin is that this shift in direction is change and that change is always accompanied by resistance. Even though we were all enthusiastic about the new project, resistance managed to rear its ugly head more than once. When the project began it became obvious that there would be new technical areas of interest. In an effort to maximize our effectiveness, the Director of the department surveyed the staff to find out what areas interested each person with the end objective to be the assignment of an area or areas to each individual. This individual would then become the "specialist" for that area and receive more advanced training than the others in order to become the expert in that area. While this was a great idea in theory, we all soon found out that not everyone could have the area they wanted and this contributed to some tension for a short time. Initially there were some "turf" struggles - especially in those areas that overlapped. Both ends of the spectrum emerged - some people wanted to do their "own thing" and protected their knowledge zealously, others felt some task or the other really belonged to the other person and couldn't understand why the other person didn't see it that way. A big factor in these turf wars seemed to be personalities and egos. Suddenly we were all equals in our technical knowledge. Seniority didn't guarantee "expert' status anymore and while this was refreshing it was also nerve-wracking at times. Eventually these problems dissipated as everyone settled into their new role; we all soon found out that there was more than enough work to be done by all and that there was no chance that anyone was going to be left behind in their technical knowledge. It also became clear whose strengths could be used positively for the team and what weaknesses had to be worked on. While this change was positive in some respects, it also had a negative side. Since the implementation schedule was based on the processing requirements of the school year, we had to adhere to the timeline pretty strictly. Everyone was so busy keeping up with the aggressive schedule that there were times when people who needed help with something were told by others that they didn't have time to help. Tempers flared when people believed that the other team members had no appreciation of the pressure that was on them to complete a task for a deadline. It became evident that these situations were due, in large part, to miscommunication between team members. Prior to this project we had held weekly staff meetings that allowed each person to give a brief review of the projects they were working on and share any new things they had learned that might help someone else. Since we were so busy trying to keep up with our tasks these meetings fell by the wayside which resulted in additional "people" problems. This lack of communication resulted in many misunderstandings between people about their responsibilities. In order to alleviate this problem we re- instituted the weekly meeting with a formal agenda published in advance with input from all the team members on the topics to be covered. Vendor communication was also an issue that we had to resolve. Initially there was one person designated as the vendor contact on training issues. As the project progressed there became more vendor issues that had to be resolved and no one was sure who was handling what. In this situation, as in so many others, it became clear whose personal strengths best suited the task and this person became the vendor contact on non-training issues. The turning point for the team actually came six months into the project. During a team meeting a member brought up an excellent point about our method of operation; it needed a mind-shift. We were trying to operate as a team in the same manner we had worked on individual projects. Prior to this project we never had to rely on each other or wait for someone to accomplish something in order for someone else to move on. Although it was something we knew at a logical level, we finally realized that other people depended on us - and that dependency brought added responsibility to the other team members. A breakthrough! We were actually starting to think AND work as a true team - not just a bunch of individuals. A final difficulty that we needed to resolve was keeping the "big picture" in mind while tracking the progress of the project. We finally had to admit that since we were so busy at the detail level of administering this project we needed someone else to keep track at the macro level. We brought this up to the Director and he agreed that we needed additional support in this area. In order to improve this area he agreed to have bi-weekly individual status meetings with each team member to discuss their current goals and the progress made toward meeting these goals/deadlines. This has helped keep him in touch with where we are as a team as well as head off any potential conflicts before they escalate. IF WE HAD TO DO IT ALL AGAIN This project is still underway; we have another 18 months until the last module is installed. We have come a long way in the past six months and I'd like to believe that the worst is behind us. However, being a few months older and feeling years wiser, the following recommendations may help other institutions considering using a team approach to project implementation. * Understand what you are getting into BEFORE you begin. Read some books on team building, attend some seminars, talk to other people using teams. * Realize that some personality types are not well suited to team work - consider the people you intend to have on the team carefully * Management must support the team openly and without reservation, including empowering the team with the authority it needs to accomplish the designated tasks * Identify the roles needed by the team and allow each member to be flexible in these roles. Example roles include facilitator, scribe, timekeeper, single point of contact (SPOC), etc. Participative leadership is a requirement of an effective team. All team members must develop team leadership skills. The facilitator must neither dominate the team nor decide team rules alone (Harrington-Mackin, 1994). * Team work is risky business - understand that it will take longer than you think for the team to be an effective working unit * Communicate, communicate, communicate. Meetings are necessary-not time wasters. * Set clear agendas for your meetings and stick to them. Distribute agendas in advance. Make it clear that all are expected to participate - the facilitator of the meeting must make sure that no one dominates the meeting. * Realize that conflict will happen - anticipate what methods will need to be used to resolve conflict * When identifying tasks to be done make it clear whose responsibility it is to complete the task, when it has to be completed and who is dependent upon that task being completed. We found that posting these tasks in a prominent area helped remind people of their outstanding tasks. CONCLUSION The experiences we have had working as a self-directed team have been enlightening to all of us. While Lafayette still has a long way to travel before this project is complete I believe that the lessons we have learned in the past six months have made us more valuable - to each other and to the College whose activities we support. Team work has been frustrating, maddening and crazy but it has also been very rewarding and mind expanding. REFERENCES Bellman, Geoffrey M. Getting Things Done When You Are Not In Charge. San Francisco: Berrett-Koehler Publishers, 1992. Douglass, Merrill E. and Donna N. Time Management For Teams. New York, New York: AMACOM, 1992. Harrington-Mackin, Deborah. The Team Building Tool Kit. New York, New York: AMACOM, 1994. 11/01/94 (SLY)