- Email: [email protected]
Creating a Motivating Environment in Software Development
Copyright © IFAC Experience with the Manageme llt of Soh ware Proj ect s, Indiana . USA. 19H9
CREATING A MOTIVATING ENVIRONMENT IN SOFTWARE DEVELOPMENT R. A. Checchio A lI/nic(lII T~/fphvlI ~ & Teit'g raph COli/pa llY, 290 Drn'idsoll A V l'Il II f , S()II/Ns~t ,
NJ 088 73 , USA
Abstract. Cultural norms in the United States place a greater emphasis on individual accomplishment than teamwork . Promoting teamwork and creating motivating environments become difficult when performance appraisals are based on individual accomplishments, rather than on the success or failure of the project. This paper describes efforts made by the author to promote teamwork and to create a motivating environment on a software development team that had been previously characterized by low morale and emphasis on individual action instead of teamwork. Keywords. Management Systems, Team Theory, Software Development, Social and Behavioral sciences.
training and knowledge, and the allocation of tasks. The remainder of this paper describes the problems that exist e d in the s o ftware development environment at AT&T, and the action plan developed by the author to improve performance and morale.
INTRODUCTION The technical problems involved in software development usually attract the bulk of the attention of management . Articles on improving productivity through the use of CASE tools and prototyping can be found in any trade journal . The human side of the productivity equation, however is often ignored or downplayed. Unfortunately, having the best software development tools doesn't necessarily result in people performing at their best, especially when the organization rewards individual effort and does not take into account the success or failure of the individual's project. While software development tools can indeed improve productivity, it is important to pay attention to the producti v ity gains that can come about when human performance is improved. Indeed, it is becoming increasingly r e c o g ni zed that involved workers are the key to increased productivity (Ouchi, 19 81 ) .
INITIAL CORPORATE ORGANIZATION Prior to 1988, many software development projects in AT&T Communications were characterized by the assignment of s y ste ms analysis and programming responsibilities to two s eparate organizations, the Netwo rk Operations Group (also referred to as the System Manager Organization - SMO) and Information Management Services (IMS), which were headed by different vice pr e sidents. Engineering the computer s ys tems to interface effectively with the exi s ting telephone systems operating within AT&T was s een as a function outside th e traditional programming area, and the SMO organization was given responsibility for determining system requirements based on the needs of the network elements with which the system would interface, work cent er needs, billing system needs, and any other needs. The SMO group assigned to a project would develop system specificati o n s , which would then be
Unfortunately, faced with the task of improving productivity, many managers concentrate on updating equipment rather than o n de v eloping employees (St o ner and Wankel, 1986). Indeed, studies have shown (Horton, 1983) that 75% of the American productivity gains since 1929 have come about through impro v ed worker
HI
82
R.A.Cheah~
transmitted to the programming group assigned to the project, which was responsible for the physical design and implementation of the system. The organizational hierarchy is shown in Fig. 1.
organizations had different career path plans, different salary administration plans, and different performance standards.
Conflict Resolution. President, AT&T ________ 1 _________ _
Vice President, Network Operations Group
Vice President, Information Management 1
System Manager Organization
Information Management Services
Fig. 1 Organizational Structure Problems.
One significant problem was the difficulty in getting disagreements resolved at an effectively low level. There was not a common manager for the two organizations until officer level was reached. As a result, it was not uncommon for two middle level managers to sit in an office with their project managers and attempt to mediate differences. Furthermore, failure to provide a single point of responsibility at a low level made it easy for each group to believe that it had performed its job adequately, and failure to meet clients needs were due to the other organization.
The structure led to situations where teamwork was difficult to achieve. In the more serious cases, performance was seriously diminished because of the failure to work as a team. Systems analysts concentrated on developing a satisfactory logical design, and programmers concentrated on the physical design aspects of the job. The question of where logical design ended and where physical implementation began was frequently an issue. It was not uncommon for programmers to complain that the systems analysts had specified too detailed a solution to the business need, and had crossed the line into physical design. sometimes, in an effort to avoid that possibility, analysts were not detailed enough, and an overall view of the system was lost. Complicating this problem was the lack of system documentation standards.
Another result of the dual organizations was that different agendas were often in place. The programming organization was sometimes perceived as "high-tech" oriented, interested in using leading edge technology. The system manager organization, since it designed at the logical level, and didn't have any significant contact with technology, perceived itself as more of a service organization. These two agendas were sometimes in conflict, since attempting to use new technology often led to extended development schedules. The system manager organization's priority was increasing system functionality, and longer development time needed to accommodate new technology was perceived as undesirable.
Neither organization had overall responsibility for the project. Compounding the problem, the systems analysts and the programmers assigned to a particular project were frequently located in different buildings. Studies (Keller, 1986) have indicated that close physical distances between group members are conducive to group cohesiveness, which influences performance.
To be fair, these organizational problems resulted, at least partially, from the evolutionary development of software development within AT&T, where software development was initially the responsibility of the accounting department which used computers for payroll applications, rather than from any carefully considered organizational strategy.
An additional consequence of the organizational structure was replicated lines of upper management. Staff functions such as recruiting were duplicated. More importantly, the two
Goal Incongruence.
CORPORATE STRUCTURE AFTER REALIGNMENT In November 1988, in an attempt to
Creating a Motivating Environment in Software De \'e1opmenl create a more effective and more efficient organization, the corporation merged the Network operations Group and Information Management Services organizations, resulting in the organizational structure shown in Fig. 2. In many cases the systems and analysts were separated into two different groups. This continued division of the development team along analyst and programmer lines resulted from a concern that the development teams were too large to be managed by a single manager. In almost every case, the requirements manager position was staffed from a member of the previous SMO organization, and the programming manager position was staffed by a member of the previous IMS organization. While this might have seemed logical from span of control perspective, it preserved the previous partition of the development team into analysts and programmers.
Vice President, Network Services
------------ -1 ----- --- ----------
83
position was somehow perceived as the more favored position. This opinion was often held by the systems analysts, since most of the systems analysts had started out as programmers, and had moved to (i.e., grown up to) the systems analyst position. The systems analysts frequently had the attitude that the programmers "worked for" the analysts, since the systems analysts produced the logical design that was then used by the programmers to develop the physical implementation of the system. This attitude frequently led to resentment on the part of the programmers. Occurring in the middle of this reorganization was the down-sizing of AT&T, which is still going on. This down-sizing had the effect of limiting career growth opportunities, thus creating the perception that it was more important than ever to ranked high in the rating group. Unfortunately, company policy is to limit the percentage of staff members that can be given the best ratings, forcing staff members to compete against each other for the top ratings.
Director, customer Services
-------------1------------TEAMWORK PROMOTION ACTION PLAN Division Manager, Systems Support
District Manager, Teleconferencing
Project Manager
Requirements Manager (Systems Analysts)
Programming Manager (Programmers)
Fig. 2
In some cases, where project teams were small (no greater than 10 or so analysts and programmers), the functions of project manager, requirements manager, and programming manager were consolidated into a single staff position. In general, however, the corporation did not perceive a divided software development team as a potential problem. As a result, teamwork remained difficult to promote. Even when the systems analysts and programmers reported to the same project manager, serious performance problems persisted. There was a strong feeling among the programmers that the systems analyst
When the author assumed responsibility for an existing project, teamwork was absent and morale was low. The institutionalized rewarding of individual performance instead of team success had led to perceptions on the part of a number of the staff members that other staff members were primarily interested in their own careers, even at the cost of the project. In an attempt to create a sense of teamwork in the organization, and to create a motivating environment, the project manager saw the need for a systemic approach. An five part action The first part was plan was developed. an unofficial mini-team structure that was overlaid on top of the official organization. The second part consisted of increasing self-determination for the staff members. The third part consisted of broadening the job responsibilities made available to the staff members. The fourth part consisted of increasing the level of participation and decision-making by staff members during all phases of the project. Last, frequent feedback sessions were initiated.
R. A. Checchio
84
Initial Project Organization. Due to the relatively small size of the author's project (two systems analysts and seven programmers, plus two additional human factors support staff), the original project organization consisted of a single manager, with the analysts and programmers reporting directly to the manager (Fig. 3). As indicated earlier, the analysts tended to talk to each other, and the programmers talked to each other, but the communication between the analysts and the programmers was usually limited to the official exchange of system documentation.
Project Manager I
Analysts
to perform the logical and physical activities necessary to define the requirements for, and integrate into the rest of the system, a particular component. The development of work teams has been identified (Poza and Fuchs, 1987) as a factor in improving employee morale. Each mini-team usually consisted of a systems analyst and a programmer, both of whom served on a number of mini-teams. It was made clear to the staff that the team would be held accountable for the successful completion of the work, and that individual performance appraisals would depend, at least in part, on the ability to which the individual functioned as a team member, both on his/her own mini-team(s) and when interfacing with other mini-teams.
Project Manager
Programmers
Fig. 3
The communication paths that existed in the group are shown in Fig. 4.
Component N Component 1 Component 2 / I /- Analyst /- Analyst /- Programmer /- Programmer
Project Manager
~p,og\imm.'
~
Ann",t1 Analyst
Programmer
11
Fig. 5
The guidelines that were applied to the mini-teams are as followed:
Programmer
1/
1.
Each mini-team was allowed to allocate the work according to the individual strengths of the team members. There was no attempt to define a strict dividing line between logical design and physical implementation, as there had been before. The analyst and the programmer were allowed to divide the work as they saw fit, as long as system documentation standards were met . The intent was to avoid the arbitrary specification of the dividing line between logical and physical design. Instead, the team members could decide where that line lay themselves, so as to best utilize their individual strengths.
2.
The mini-teams were to meet with the project manager no less frequently than once every two weeks, to review
Programmer Fig. 4
Mini-Team Approach. In an effort to create a motivating environment in which a premium was placed on teamwork, the author eliminated the practice of assigning logical design responsibility for a particular system component to an analyst, and physical imp~tation of that component to a progra~er. Instead, the author created "mini-teams" (Fig. 5), consisting of pairs of staff members who, between the two of them, had the complement of skills necessary
Creating a Motiva ting Environment in Software Development current project status and to give the project manager the opportunity to take action on any issue that needed it. In general, it was left to the mini-team members to decide when action by the project manager was needed. It was made clear, however, that failing to involve the project manager until it was too late for the project manager to act effectively would be treated as a serious breach of trust.
Increased Self-Determination. Schedules and work activities were to be developed jointly by the analyst and the programmer, in order to give the team members greater control over their work environment. Team members could schedule vacation time, courses, and other uses of their time without explicit approval of the project manager. Investigators (Rarick, 1987; Sherwood, 1987) have shown that employees are most productive when they have autonomy in their work, and that flexibility and choice are important factors in employee morale. The team members were asked to verify the total elapsed time needed for task completion. The project manager consolidated the function schedules to insure that the overall project schedule would be met. This required each team member to work with the other team member and with the other mini-teams to develop schedules that were acceptable to everyone. This process was potentially very complex, since each staff member served on multiple mini-teams, usually with different team-mates. As a result, the project manager performed an initial scheduling function, using a PC-based project management tool.
Job Enrichment Program . In order to take complete advantage of the skills and talents of the staff, programmers were encouraged to ask for the opportunity to perform as the analyst for given functions. Subject to having the necessary qualifications, such as having previous experience or appropriate educational background, programmers were permitted to function in the systems analyst role. The analysts were offered the opportunity to perform in the programming function, again subject to having the necessary
qualifications and skills. A policy advocating taking advantage of training courses offered by the corporation was instituted. In the past, heavy workloads had been used as a reason for deferring education. Although this may be effective in the short-run, eventually productivity falls as skills become outdated . The author felt that restoring the emphasis on education would increase skill levels and would facilitate the job enrichment program that had been for the author, as the corporation was in the process of cutting expenses wherever possible.
Staff Participation Program. A policy promoting programmer as well as analyst attendance at all project meetings was instituted . This was to overcome programmers' perception that the analyst's job was a favored one, since the analyst, with the job more closely affected by the users of the system, attended external meetings and the programmers did not. Regular staff meetings were scheduled to provide a forum to express concerns over the project, identify any open issues, and to generally enhance the perception that the group was a team .
Feedback Sessions. In addition, the project manager initiated on-going one-on-one meetings with the staff members to provide them with an environment in which they could say anything they wanted to without fear It was that anyone else would hear . stressed that the meeting room was a "safe room" - anything said would stay within those walls, and that the project manager would not take any action based on what was said unless the staff member wished it.
Results. Although some of the project team members were not used to the degree of autonomy present in the new structure, the staff soon appreciated being treated as competent professionals . Each member felt that being given the responsibility to manage one's own work was largely " r esponsible for significant productivity gains. Morale has improved
85
R. A. Checchio
86
substantially, and the interaction between the mini-teams has resulted in the group being on its way to becoming a high performance team.
MORALE AND PERFORMANCE SURVEY. In order to measure the effects of the author's program, a study was developed. In order to isolate the effects of the author's program versus other environmental factors, such as the organizational changes that had occurred over the past year, four target populations were selected: 1. The author's work unit. 2. A work unit in the same district as the author's. 3 . A work unit in the same division as the author's, but in a different district. A division is composed of a number of districts. 4. A work unit in the same department as the author's, but in a different division. A department is composed of a number of divisions. The work unlts selected were composed of a mix of systems analysts and programmers . In addition, each work unit had a similar number of staff members. In order to avoid introducing any bias into the study, a double-blind method was used . After the survey was developed, the survey was distributed and collected by a member of divisional staff . Respondents were not required to identify themselves, but the surveys were coded so that individual responses could be associated with a particular study group . It was not possible to associate any response with an individual. Except for coding to allow the identification of the population, all surveys were identical. The surveys were designed to measure the degree to which the work environment contributed to self-perceptions of empowerment, self-actualizati~ professional development, anff~a~eer growth.
•
CONCLUSIONS Achieving optimum performance on a software development team means more than acquiring state-of-the-art software tools. Paying attention to the human aspects of software development is just as important. Improved productivity can be achieved from simple, low-cost policies such as making the staff a part of the decision making process, giving staff increased responsibility, and enriching jobs by broadening the scope of job responsibilities, in short, trusting the people who have the necessary skills to do the jobs we ask them to do. REFERENCES Horton, R. H. (1983). Training: A Key to Productivity Growth . Management Review 72. no. 9. Keller, R. T. Performance of organizations. Journal. December 1988,
(1986). Predictors of the
project groups in R & D Academy of Management p. 715.
Ouchi, W. G. (1981) . Theory Z: How American Business Can Meet the Japanese Challenge. Addison-Wesley, Reading. Poza, E. J., and C. J. Fuchs (1987). Improving morale and customer service in banks: a case history . Personnel, May 1987, p.
58(4) .
Rarick, C. A. (1987). Selfdetermination : the new management paradigm . SAM Advanced Management Journal. summer, 1987, p. 47(5). Sherwood, A. (1987). A Bakers Dozen of Ways to Motivate People. Management Solutions, May, 1987, p . 14(3). stoner, J. A. F . , and C . Wankel (1986). Management. Prentice Hall, Englewood Cliffs.
CREATING A MOTIVATING ENVIRONMENT IN SOFTWARE DEVELOPMENT R. A. Checchio A lI/nic(lII T~/fphvlI ~ & Teit'g raph COli/pa llY, 290 Drn'idsoll A V l'Il II f , S()II/Ns~t ,
NJ 088 73 , USA
Abstract. Cultural norms in the United States place a greater emphasis on individual accomplishment than teamwork . Promoting teamwork and creating motivating environments become difficult when performance appraisals are based on individual accomplishments, rather than on the success or failure of the project. This paper describes efforts made by the author to promote teamwork and to create a motivating environment on a software development team that had been previously characterized by low morale and emphasis on individual action instead of teamwork. Keywords. Management Systems, Team Theory, Software Development, Social and Behavioral sciences.
training and knowledge, and the allocation of tasks. The remainder of this paper describes the problems that exist e d in the s o ftware development environment at AT&T, and the action plan developed by the author to improve performance and morale.
INTRODUCTION The technical problems involved in software development usually attract the bulk of the attention of management . Articles on improving productivity through the use of CASE tools and prototyping can be found in any trade journal . The human side of the productivity equation, however is often ignored or downplayed. Unfortunately, having the best software development tools doesn't necessarily result in people performing at their best, especially when the organization rewards individual effort and does not take into account the success or failure of the individual's project. While software development tools can indeed improve productivity, it is important to pay attention to the producti v ity gains that can come about when human performance is improved. Indeed, it is becoming increasingly r e c o g ni zed that involved workers are the key to increased productivity (Ouchi, 19 81 ) .
INITIAL CORPORATE ORGANIZATION Prior to 1988, many software development projects in AT&T Communications were characterized by the assignment of s y ste ms analysis and programming responsibilities to two s eparate organizations, the Netwo rk Operations Group (also referred to as the System Manager Organization - SMO) and Information Management Services (IMS), which were headed by different vice pr e sidents. Engineering the computer s ys tems to interface effectively with the exi s ting telephone systems operating within AT&T was s een as a function outside th e traditional programming area, and the SMO organization was given responsibility for determining system requirements based on the needs of the network elements with which the system would interface, work cent er needs, billing system needs, and any other needs. The SMO group assigned to a project would develop system specificati o n s , which would then be
Unfortunately, faced with the task of improving productivity, many managers concentrate on updating equipment rather than o n de v eloping employees (St o ner and Wankel, 1986). Indeed, studies have shown (Horton, 1983) that 75% of the American productivity gains since 1929 have come about through impro v ed worker
HI
82
R.A.Cheah~
transmitted to the programming group assigned to the project, which was responsible for the physical design and implementation of the system. The organizational hierarchy is shown in Fig. 1.
organizations had different career path plans, different salary administration plans, and different performance standards.
Conflict Resolution. President, AT&T ________ 1 _________ _
Vice President, Network Operations Group
Vice President, Information Management 1
System Manager Organization
Information Management Services
Fig. 1 Organizational Structure Problems.
One significant problem was the difficulty in getting disagreements resolved at an effectively low level. There was not a common manager for the two organizations until officer level was reached. As a result, it was not uncommon for two middle level managers to sit in an office with their project managers and attempt to mediate differences. Furthermore, failure to provide a single point of responsibility at a low level made it easy for each group to believe that it had performed its job adequately, and failure to meet clients needs were due to the other organization.
The structure led to situations where teamwork was difficult to achieve. In the more serious cases, performance was seriously diminished because of the failure to work as a team. Systems analysts concentrated on developing a satisfactory logical design, and programmers concentrated on the physical design aspects of the job. The question of where logical design ended and where physical implementation began was frequently an issue. It was not uncommon for programmers to complain that the systems analysts had specified too detailed a solution to the business need, and had crossed the line into physical design. sometimes, in an effort to avoid that possibility, analysts were not detailed enough, and an overall view of the system was lost. Complicating this problem was the lack of system documentation standards.
Another result of the dual organizations was that different agendas were often in place. The programming organization was sometimes perceived as "high-tech" oriented, interested in using leading edge technology. The system manager organization, since it designed at the logical level, and didn't have any significant contact with technology, perceived itself as more of a service organization. These two agendas were sometimes in conflict, since attempting to use new technology often led to extended development schedules. The system manager organization's priority was increasing system functionality, and longer development time needed to accommodate new technology was perceived as undesirable.
Neither organization had overall responsibility for the project. Compounding the problem, the systems analysts and the programmers assigned to a particular project were frequently located in different buildings. Studies (Keller, 1986) have indicated that close physical distances between group members are conducive to group cohesiveness, which influences performance.
To be fair, these organizational problems resulted, at least partially, from the evolutionary development of software development within AT&T, where software development was initially the responsibility of the accounting department which used computers for payroll applications, rather than from any carefully considered organizational strategy.
An additional consequence of the organizational structure was replicated lines of upper management. Staff functions such as recruiting were duplicated. More importantly, the two
Goal Incongruence.
CORPORATE STRUCTURE AFTER REALIGNMENT In November 1988, in an attempt to
Creating a Motivating Environment in Software De \'e1opmenl create a more effective and more efficient organization, the corporation merged the Network operations Group and Information Management Services organizations, resulting in the organizational structure shown in Fig. 2. In many cases the systems and analysts were separated into two different groups. This continued division of the development team along analyst and programmer lines resulted from a concern that the development teams were too large to be managed by a single manager. In almost every case, the requirements manager position was staffed from a member of the previous SMO organization, and the programming manager position was staffed by a member of the previous IMS organization. While this might have seemed logical from span of control perspective, it preserved the previous partition of the development team into analysts and programmers.
Vice President, Network Services
------------ -1 ----- --- ----------
83
position was somehow perceived as the more favored position. This opinion was often held by the systems analysts, since most of the systems analysts had started out as programmers, and had moved to (i.e., grown up to) the systems analyst position. The systems analysts frequently had the attitude that the programmers "worked for" the analysts, since the systems analysts produced the logical design that was then used by the programmers to develop the physical implementation of the system. This attitude frequently led to resentment on the part of the programmers. Occurring in the middle of this reorganization was the down-sizing of AT&T, which is still going on. This down-sizing had the effect of limiting career growth opportunities, thus creating the perception that it was more important than ever to ranked high in the rating group. Unfortunately, company policy is to limit the percentage of staff members that can be given the best ratings, forcing staff members to compete against each other for the top ratings.
Director, customer Services
-------------1------------TEAMWORK PROMOTION ACTION PLAN Division Manager, Systems Support
District Manager, Teleconferencing
Project Manager
Requirements Manager (Systems Analysts)
Programming Manager (Programmers)
Fig. 2
In some cases, where project teams were small (no greater than 10 or so analysts and programmers), the functions of project manager, requirements manager, and programming manager were consolidated into a single staff position. In general, however, the corporation did not perceive a divided software development team as a potential problem. As a result, teamwork remained difficult to promote. Even when the systems analysts and programmers reported to the same project manager, serious performance problems persisted. There was a strong feeling among the programmers that the systems analyst
When the author assumed responsibility for an existing project, teamwork was absent and morale was low. The institutionalized rewarding of individual performance instead of team success had led to perceptions on the part of a number of the staff members that other staff members were primarily interested in their own careers, even at the cost of the project. In an attempt to create a sense of teamwork in the organization, and to create a motivating environment, the project manager saw the need for a systemic approach. An five part action The first part was plan was developed. an unofficial mini-team structure that was overlaid on top of the official organization. The second part consisted of increasing self-determination for the staff members. The third part consisted of broadening the job responsibilities made available to the staff members. The fourth part consisted of increasing the level of participation and decision-making by staff members during all phases of the project. Last, frequent feedback sessions were initiated.
R. A. Checchio
84
Initial Project Organization. Due to the relatively small size of the author's project (two systems analysts and seven programmers, plus two additional human factors support staff), the original project organization consisted of a single manager, with the analysts and programmers reporting directly to the manager (Fig. 3). As indicated earlier, the analysts tended to talk to each other, and the programmers talked to each other, but the communication between the analysts and the programmers was usually limited to the official exchange of system documentation.
Project Manager I
Analysts
to perform the logical and physical activities necessary to define the requirements for, and integrate into the rest of the system, a particular component. The development of work teams has been identified (Poza and Fuchs, 1987) as a factor in improving employee morale. Each mini-team usually consisted of a systems analyst and a programmer, both of whom served on a number of mini-teams. It was made clear to the staff that the team would be held accountable for the successful completion of the work, and that individual performance appraisals would depend, at least in part, on the ability to which the individual functioned as a team member, both on his/her own mini-team(s) and when interfacing with other mini-teams.
Project Manager
Programmers
Fig. 3
The communication paths that existed in the group are shown in Fig. 4.
Component N Component 1 Component 2 / I /- Analyst /- Analyst /- Programmer /- Programmer
Project Manager
~p,og\imm.'
~
Ann",t1 Analyst
Programmer
11
Fig. 5
The guidelines that were applied to the mini-teams are as followed:
Programmer
1/
1.
Each mini-team was allowed to allocate the work according to the individual strengths of the team members. There was no attempt to define a strict dividing line between logical design and physical implementation, as there had been before. The analyst and the programmer were allowed to divide the work as they saw fit, as long as system documentation standards were met . The intent was to avoid the arbitrary specification of the dividing line between logical and physical design. Instead, the team members could decide where that line lay themselves, so as to best utilize their individual strengths.
2.
The mini-teams were to meet with the project manager no less frequently than once every two weeks, to review
Programmer Fig. 4
Mini-Team Approach. In an effort to create a motivating environment in which a premium was placed on teamwork, the author eliminated the practice of assigning logical design responsibility for a particular system component to an analyst, and physical imp~tation of that component to a progra~er. Instead, the author created "mini-teams" (Fig. 5), consisting of pairs of staff members who, between the two of them, had the complement of skills necessary
Creating a Motiva ting Environment in Software Development current project status and to give the project manager the opportunity to take action on any issue that needed it. In general, it was left to the mini-team members to decide when action by the project manager was needed. It was made clear, however, that failing to involve the project manager until it was too late for the project manager to act effectively would be treated as a serious breach of trust.
Increased Self-Determination. Schedules and work activities were to be developed jointly by the analyst and the programmer, in order to give the team members greater control over their work environment. Team members could schedule vacation time, courses, and other uses of their time without explicit approval of the project manager. Investigators (Rarick, 1987; Sherwood, 1987) have shown that employees are most productive when they have autonomy in their work, and that flexibility and choice are important factors in employee morale. The team members were asked to verify the total elapsed time needed for task completion. The project manager consolidated the function schedules to insure that the overall project schedule would be met. This required each team member to work with the other team member and with the other mini-teams to develop schedules that were acceptable to everyone. This process was potentially very complex, since each staff member served on multiple mini-teams, usually with different team-mates. As a result, the project manager performed an initial scheduling function, using a PC-based project management tool.
Job Enrichment Program . In order to take complete advantage of the skills and talents of the staff, programmers were encouraged to ask for the opportunity to perform as the analyst for given functions. Subject to having the necessary qualifications, such as having previous experience or appropriate educational background, programmers were permitted to function in the systems analyst role. The analysts were offered the opportunity to perform in the programming function, again subject to having the necessary
qualifications and skills. A policy advocating taking advantage of training courses offered by the corporation was instituted. In the past, heavy workloads had been used as a reason for deferring education. Although this may be effective in the short-run, eventually productivity falls as skills become outdated . The author felt that restoring the emphasis on education would increase skill levels and would facilitate the job enrichment program that had been for the author, as the corporation was in the process of cutting expenses wherever possible.
Staff Participation Program. A policy promoting programmer as well as analyst attendance at all project meetings was instituted . This was to overcome programmers' perception that the analyst's job was a favored one, since the analyst, with the job more closely affected by the users of the system, attended external meetings and the programmers did not. Regular staff meetings were scheduled to provide a forum to express concerns over the project, identify any open issues, and to generally enhance the perception that the group was a team .
Feedback Sessions. In addition, the project manager initiated on-going one-on-one meetings with the staff members to provide them with an environment in which they could say anything they wanted to without fear It was that anyone else would hear . stressed that the meeting room was a "safe room" - anything said would stay within those walls, and that the project manager would not take any action based on what was said unless the staff member wished it.
Results. Although some of the project team members were not used to the degree of autonomy present in the new structure, the staff soon appreciated being treated as competent professionals . Each member felt that being given the responsibility to manage one's own work was largely " r esponsible for significant productivity gains. Morale has improved
85
R. A. Checchio
86
substantially, and the interaction between the mini-teams has resulted in the group being on its way to becoming a high performance team.
MORALE AND PERFORMANCE SURVEY. In order to measure the effects of the author's program, a study was developed. In order to isolate the effects of the author's program versus other environmental factors, such as the organizational changes that had occurred over the past year, four target populations were selected: 1. The author's work unit. 2. A work unit in the same district as the author's. 3 . A work unit in the same division as the author's, but in a different district. A division is composed of a number of districts. 4. A work unit in the same department as the author's, but in a different division. A department is composed of a number of divisions. The work unlts selected were composed of a mix of systems analysts and programmers . In addition, each work unit had a similar number of staff members. In order to avoid introducing any bias into the study, a double-blind method was used . After the survey was developed, the survey was distributed and collected by a member of divisional staff . Respondents were not required to identify themselves, but the surveys were coded so that individual responses could be associated with a particular study group . It was not possible to associate any response with an individual. Except for coding to allow the identification of the population, all surveys were identical. The surveys were designed to measure the degree to which the work environment contributed to self-perceptions of empowerment, self-actualizati~ professional development, anff~a~eer growth.
•
CONCLUSIONS Achieving optimum performance on a software development team means more than acquiring state-of-the-art software tools. Paying attention to the human aspects of software development is just as important. Improved productivity can be achieved from simple, low-cost policies such as making the staff a part of the decision making process, giving staff increased responsibility, and enriching jobs by broadening the scope of job responsibilities, in short, trusting the people who have the necessary skills to do the jobs we ask them to do. REFERENCES Horton, R. H. (1983). Training: A Key to Productivity Growth . Management Review 72. no. 9. Keller, R. T. Performance of organizations. Journal. December 1988,
(1986). Predictors of the
project groups in R & D Academy of Management p. 715.
Ouchi, W. G. (1981) . Theory Z: How American Business Can Meet the Japanese Challenge. Addison-Wesley, Reading. Poza, E. J., and C. J. Fuchs (1987). Improving morale and customer service in banks: a case history . Personnel, May 1987, p.
58(4) .
Rarick, C. A. (1987). Selfdetermination : the new management paradigm . SAM Advanced Management Journal. summer, 1987, p. 47(5). Sherwood, A. (1987). A Bakers Dozen of Ways to Motivate People. Management Solutions, May, 1987, p . 14(3). stoner, J. A. F . , and C . Wankel (1986). Management. Prentice Hall, Englewood Cliffs.