Structural Change and Change Advocacy: A Study in Becoming a

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

STRUCTURAL CHANGE AND CHANGE ADVOCACY: A STUDY IN BECOMING A SOFTWARE ENGINEERING ORGANIZATION Kay M. Nelson, The University of Utah, [email protected] Mari Buche, The University of Kansas, [email protected] H. James. Nelson, The University of Utah, [email protected] Abstract Most organizations desire higher quality, lower cost IS projects. To achieve this goal, many organizations are moving to formal project management and software engineering practices. Two tools used to formalize processes and practices are structured development and maintenance methodologies (SDMM), and the Software Engineering Institute's Capability Maturity Model (SEI/CMM). While SDMMs and the CMM are excellent tools to instill project discipline in IS organizations, they are not silver bullets. A great deal of culture and structural change must first occur. These other changes include reward systems, online shared services, and knowledge reuse. This longitudinal study examines one 500 person IS organization over a four year time period. The results of this study confirm previous literature on change advocacy, and yield rich insight into how to change a typical ad hoc IS organization to a software engineering organization.

1. Introduction Organizations are constantly looking for ways to decrease information systems (IS) costs and to increase the quality of delivered systems. This often requires a significant change in the way that the IS organization performs its function. It has been suggested by Markus and Benjamin [1], [2] that for IS change to reach beyond the boundaries of the IS organization, a combination of structural change in the way IS performs its work as well as change advocacy is required. This research investigates this assertion through a longitudinal case study of one 500 person IS organization. In the IS discipline, initial theory building often begins with qualitative, single organization case studies [3], [4], [5], [6]. One of the results of this study is a more formalized model of Markus and Benjamin's assertions about structural and cultural change. This model can be tested by other researchers using both qualitative and quantitative techniques. The IS organization in this study implemented changes suggested by the Software Engineering Institute's Capability Maturity Model (SEI/CMM) [7], [8]. This organization used change advocacy and organizational

structure change to achieve performance goals of lower cost and higher quality software services. Quantitative and interview data is used to gain insight into how this organizational change initiative was achieved [6], [9].

2. THE BLUEJAY ORGANIZATION This paper describes the experience of the IS organization within a large manufacturing firm, Bluejay, Inc. (a pseudonym). The IS organization studied performs all software maintenance activities for the Woodson division of Bluejay, and has approximately 500 full time IS professionals. The ratio of development to maintenance activities in this organization is about 20:80. Central data management, networking operations, and a new ERP implementation in Bluejay are not a part of the group studied. The information systems function at Bluejay has an interesting history. In the 1980s, this function was a separate subsidiary company of Bluejay, selling computer services to Bluejay and to a select group of other companies. The organization gained a national reputation as a leading edge IS organization, known for being early adopters of CASE tools and object oriented design. In the early 1990s, Bluejay senior management decided to merge Bluejay Computer Services back into the Bluejay Company, citing the need for closer relationships between line and computing organizations, and potential cost savings. The re-acquisition of the IS organization was completed in 1993. In early 1994, senior management decided to adopt the SEI/CMM as a way to improve IS performance. The CMM was developed by the SEI as a framework that describes key elements of effective software processes [7], [8]. The framework is designed as an evolutionary path from an ad hoc or chaotic software organization to a disciplined "software engineering" organization (Figure 1). It is estimated that at least 80% of U.S. non-defense related software organizations are at Level 1 CMM maturity, operating in a chaotic manner [10]. At the next step of the CMM, Level 2, organizations have repeatable processes and policies for managing a software project. Level 3 CMM organizations are described as "defined". These groups have standard processes for developing and

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

1


maintaining software that is documented and used across the organization. Level 3 moves the criteria for successful process management from the project level to the organization level, with integrated IS teams as the unit of measurement. Moving to Level 3 requires substantial organizational change, since it institutionalizes processes across an entire IS organization. Figure 1: CMM Levels Paulk, Weber, Curtis, & Chrissis (1994)

Level 5 Optimizing 4 Managed

Focus

Defect prevention Technology change management Process change management

Product and process quality

Quantitative process management Software quality management

Defined engineering process

Organization process focus Organization process definition Integrated software management Software product engineering Intergroup coordination Training program Peer reviews

Project management and process commitment

Requirements management Software project planning Software project tracking Software subcontract management Software quality assurance Software configuration management

3 Defined 2 Repeatable 1 Initial

Key Process Areas

Continuous process improvement

Heroes/Gurus Chaos

The CMM provides two more advanced levels, which are not discussed in this paper. The Bluejay organization plans to seek these levels in the future, but at the time of this study had only recently achieved Level 3 certification. Bluejay's initial CMM effort failed due to lack of change advocacy within the IS organization, and a lack of structure to facilitate change. One of the Blujay project managers commented on this initial failed attempt: I felt that we had a bunch of people leading the initiative who had never been involved in a real project. They didn't have the background and they were telling a lot of people who'd spent years and years doing IS how to do their job. It didn't go over very well. Another problem with the initial attempt was a lack of organizational structure to document processes. Various projects across the companies were using different methodologies, resulting in different terminology for the same process artifacts, such as a design document. After analyzing the initial failure, Bluejay decided to move more slowly and one unit, the 500 person Woodson (a pseudonym) IS organization, was chosen as the test site for implementing the CMM framework. This organization formed a Software Engineering Process Group (SEPG) to assist in the effort. The Woodson organization also created the position of software engineering manager to add credibility to the initiative. None of these things had been done in the failed attempt. To add structure to the IS organization, Bluejay also implemented a standard software development and maintenance methodology (SDMM) across the company.

Software development and maintenance methodologies (SDMMs) have long been advocated as a way to control and optimize the software process [11]. One of the main reasons why SDMMs impact IS productivity is the percentage of time software teams actually spend programming. Yourdan [12] estimates that less than 15% of development and maintenance time is spent writing code. Structured methods not only structure the coding process, but also the more time-consuming management processes which are involved in system support, such as meetings, reporting, documenting, inspecting, testing, and communicating. The use of an SDMM supported the Bluejay CMM processes, providing standard templates and documents that were consistently used and reused across the organization. The process artifacts were made available to all projects online in a process asset library (PAL), facilitating and encouraging reuse and adaptation. The Woodson division implemented the SDMM in 1995, reaching CMM Level 2 in the summer of 1996 and Level 3 in the fall of 1997. While the CMM was the measurement tool used to internally gauge success and improved IS performance in Woodson, there were several key elements in creating this organizational transition. One of these key elements was the pervasiveness of the culture change that had to take place in the organization between Level 1 and Level 3. The change process is discussed in the following section.

3. ADVOCATING CHANGE

AND

REALIZING

The role of a change agent can take any combination of three forms: traditional, facilitator, or advocate [1]. Traditional change agents are typified by IS analysts who believe that technology causes change, and their role is to develop systems as technology specialists. Facilitators promote change without influencing decisions for implementation by exerting their expertise. In contrast, advocates are change agents that use their expertise to persuade users and clients to adopt a particular form of technology [1], [13]. Change agent roles are influenced by structural conditions of the organization. “Structural conditions are social and economic arrangements, e.g., reporting relationships and policies, that influence the processes of IS work…and the outcomes of IS work,” [1, pp. 387]. In other words, structural conditions define the reality of the work environment for IS analysts and organizational members. The work environment creates and dictates, to a degree, the form of change agent that emerges as successful. Traditional agents work best in circumstances where the clients have few technological options and the centralized IS department provides all of the clients’ technology services [14], [15]. Facilitators are most effective in

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

2


settings where IS analysts are positioned outside of the formal hierarchy of control and they aren’t directly responsible for the client’s business outcomes [16]. Advocates function best in work environments that are characterized by one of the following conditions: (1) lack of specific management authority, but control allocation of necessary resources, (2) line authority and responsibility for outcomes of business units, or (3) staff positions in the hierarchy of the organization [1]. The change agents that we identified in this study came from both upper levels of management and the IS analyst level. Based on their individual placement within the organizational hierarchy, different forms of change agents developed. The "visionary" from corporate headquarters helped the analysts visualize the goal of the initiatives [17]. His role was to advocate change, encouraging adoption of the initiative through persuasion and dialog [1]. As an advocate, he developed the future picture of the organization and influenced the change targets to move in the direction that he determined to be desirable, based on his experience as an SEI/CMM expert. Members of the SEPG described the visionary in this way, He did a good job of saying here’s where we’re going. And the fact that he’s not from this site, that he’s from corporate, added a level of integrity to it. When someone else, an expert from the outside, comes in and tells them [the analysts] something, they tend to believe it a little more. The visionary used face-to-face meetings with analysts and project managers to promote awareness of the need for change and his plan for change. His emphasis was on communication [18]. However, in his particular role, the visionary would take little credit for the success of the change effort. The visionary had no formal authority in this instance, however he did have valuable information and insight into the change process. His main influence was in the formation of the anticipated change event [19]. After the initiative was underway, the visionary observed the progress from a distance, becoming supportive in a secondary capacity. An advocate promotes his/her change direction, drawing on personal experience and expertise [1]. The software engineering manager in this study was the cheerleader and champion of the project. He advocated adoption through enthusiasm and energetic support. An energetic person can often harness the intensity of others [20], and this individual exemplified that ability. The IS analysts described the software engineering manager like this: The software engineering manager was obviously one of the big catalysts in getting things going. He wasn't the manager that started things out, but I think he helped generate a lot of the enthusiasm.

The software engineering manager was assigned to the Woodson division, but he was not in a direct reporting relationship with the IS analysts or project managers who were the change targets. He was in a staff assignment, with delegated authority to implement the change. Although Markus and Benjamin [1] discuss the disadvantage of delegated authority in such circumstances, this manager was able to successfully influence analysts and project managers. He not only promoted the original anticipated change project, but he also supported and encouraged other employees to develop additional opportunity-based changes [19]. One of his main functions was to enhance the relationship between IS analysts and clients through improvements in procedures and processes. He worked directly with the projects, insuring that the team members understood the benefits of the standardized methodology and the SEI/CMM. He encouraged participation through his belief that the improvements exceeded the costs of change [21], [22]. He would not be considered a traditional IS change agent because he pushed people, not technology, as the instrument of change [1]. Likewise, he wouldn’t be classified as a facilitator because he proposed a particular direction, not allowing the change target to determine the course of action [1], [15]. This manager was a change advocate, who was very familiar with the intricacies of the change initiative and shared his knowledge with the organization. His positive perspective encouraged project teams to adopt the changes. One project manager described the software engineering manager like this: I think he was the big push. He was a very much a champion for the process. More than just an advocate, he was, if you're familiar with what the real term chauvinistic means--chauvinistic toward SEI/CMM, and he had an uphill battle because our brothers in corporate were not cognizant of it or, if they were, they weren't paying attention. Even though the entire company supported the SEI/CMM initiative, with Woodson as the pilot site, this manager identified the initiative with the advocate, not with the company as a whole. At a higher management level, the Woodson division IS manager had line authority and responsibility over the IS projects. The change targets, project managers and analysts, reported to him in the organizational hierarchy. The software engineering manager and SEPG also reported to the division IS manager. It was his responsibility to ensure the adoption of the change initiative and to realize performance-based benefits from the effort. In other words, he was partially responsible for the business outcomes of the division [1]. This structural condition is compatible with the change advocate role. The division IS manager encouraged participation through structured means, basing a significant portion of project

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

3


managers’ pay increases on achievement of Level 3 goals. Each person reporting directly to him was told to create a formal plan of how he/she would move his/her project to SEI/CMM Level 3 within the timeframe allotted. Later, progress toward achievement of Level 3 goals was discussed during each manager's annual performance appraisal. Before the division manager took action to base pay on goal achievement, the change initiative received only cursory attention from project managers. In contrast, participation improved dramatically after he included the pay incentive in the performance appraisal system. One analyst commented: In our initial year or two of getting going, we had the verbal support from the division IS manager. But we still didn’t have it really catching on. Then he put it into everyone’s performance measurement and forced it to trickle down. That was the year that there was an incredible acceptance for it. The division IS manager was a change advocate because he promoted a particular, detailed, change position using his expertise and authority to invite support for the change effort. Although he was directly involved with the original anticipated change plans, he was also responsible for providing the resources and creating a culture that encouraged the identification of ancillary changes, both follow-on anticipated and opportunity-based changes. Resource availability and encouragement are necessary for an improvisational change to evolve, as was observed in this study [19]. Finally, the SEPG was a collection of experienced systems analysts charged with the task of developing detailed plans for meeting management’s goals. This group actually ran themselves using the CMM key process areas and the SDMM. They believe that this greatly enhanced their credibility. It changed the perception of the group. The analysts knew that we might know what we were talking about because we were actually doing it too. The SEPG analysts acted as teachers, coaches, guides, assistants on projects, and interpreters of SEI/CMM documentation [23], [24]. They went as far as writing many of the deliverables and processes for the pilot teams, gaining credibility and teaching by example [14], [1]. One analyst summarized the SEPG role as follows: They showed us the road map of what we needed to do. They produced the plans, the training, whatever it was you needed that led you down the path, Then it was basically a matter of us following through. The SEPG members devoted their time to deciphering the technical jargon of the SEI/CMM and producing templates to assist project analysts in creating deliverables in the SDMM. They were staff members, with no line

authority, responsible for implementing the change throughout the division. They were not directly responsible for business outcomes of individual projects, one of the sufficient structural conditions for change advocates. Their purpose was to articulate the benefits of adoption and to convey the detailed processes necessary to make the change a success. They realized that people, including themselves, make change possible. The analysts and project managers we interviewed agreed that the initiative wouldn’t have been as successful without the dedication and influence of the SEPG. In summary, change advocacy was implemented in several ways in the Woodson IS organization. The visionary advocated a new direction for the organization, the division manager compelled project managers to change procedures through pay incentives, the software engineering manager cajoled and built acceptance through personal enthusiasm and charisma, and the SEPG analysts taught and coached project managers through the implementation of the new IS business processes. Each of these advocate roles impacted the structural conditions of the organization, altering the organizational culture in specific ways.

4. STRUCTURAL CHANGE THROUGH STANDARDIZED PROCESSES When change advocates implement an initiative, they are modifying the structural conditions of the organization [25]. This can take the form of a change in policies or procedures, alterations in reporting relationships, redirection of corporate philosophy or vision, or the implementation of new business processes [26]. Individuals at the management level formulate initiatives. Agents act on behalf of top management to see that changes are implemented. Therefore, structural conditions both influence, and are influenced by, change agents [1]. In this study, the Woodson change advocates were determined to modify the structural conditions of the organization through the implementation of the CMM framework and the SDMM. By integrating the two initiatives, a single composition of change agents could promote both simultaneously. These structural changes resulted in project management activities and processes being explicitly defined and tracked through a series of numbered documents. There is a language of project management deliverables that is somewhat congruent. My 004 may look different than someone else's 004, but at least we know what it is we're talking about when we're saying it, and that's a real benefit. Each document was created by a project analyst in a way that other analysts could read and comprehend the process

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

4


without time consuming research and faulty conjecture. An additional benefit was that new employees could be brought “up to speed” more quickly, allowing them to contribute to the project sooner. However, moving the organization to detailed documentation and process management required a significant culture change. The impact on individual projects and analysts depended on their degree of nonconformity prior to the implementation. Those projects that already practiced formal IS discipline and performed detailed documentation were least affected by the changes, but those that did not had to invest a great deal of up-front time in documentation and process analysis. One analyst described it this way: It obviously had a negative impact in terms of spending time to do documentation. The positive impacts I've seen are the way people know what everyone else is doing because they have a standardized process and we're all basically doing things the same way. It makes it much easier, if somebody's gone, to take over for them. The change initiative was a planned change event [19] that began with a planned framework and a schedule for completion developed by the change advocates. However, as the project evolved and was implemented, emergent changes occurred. Emergent changes are informal reactions that emanate from the original change. In this study, coordination between projects on creating documentation and borrowing examples of documentation are examples of emergent changes. Opportunity-based changes also occurred in the course of the initiative [19]. One example was the development of a tracking system for change requests. It is a small program built onto the analysts' e-mail account to monitor and record requests from clients. This program was developed by one project and communicated to the IS organization through the PAL. Other projects then adopted this process and toll for tracking change requests. Do change advocacy and structural change make a difference? While it is interesting to observe and understand the processes of change advocacy and structural change in an IS organization, it is equally important to determine if these changes result in improved IS performance. The impact on IS cost and quality was measured objectively in this study, comparing Woodson's cost per function point and defect rates at Level 3 to their Level 1 rates. We also used qualitative observation and insights from the participants in this change event to evaluate whether structural change had actually occurred in the organization. Objective measures of IS performance.

As indicated by Markus and Benjamin [1], cost has often been used as an IS performance measure. Therefore, in this study used actual IS project cost per annual supported function point [10]. To measure the quality of the Woodson IS products, we used actual defect rates. Lack of defects is a clear and widely used indicator of IS product quality [27]. Hypotheses H1:

The Level 3 software systems in the Woodson IS organization will have lower actual annual cost per supported function point than systems in the Level 1 sample.

H2:

The Level 3 software systems in the Woodson IS organization will have actual lower levels of total defects within the system than systems in the Level 1 sample.

5. RESEARCH DESIGN The basic design of this research is a longitudinal single site field study [6], [9]. The methods used in this study were case methodology and analysis of actual cost and quality data. Level 1 data was collected from 35 Bluejay projects in 1994. The researchers observed the implementation of the SEI/CMM and SDMM over the next four years. In 1998, a sample of 35 systems assessed as part of the Level 3 organization were sampled. While several of the current projects contained pieces of systems measured in the earlier sample, the systems and organization have evolved to a degree where it was impossible to do a project to project analysis. The systems in both samples deliberately represented a wide variety of ages, sizes, programming languages, and hardware platforms. This was done so the data reflected process and methodology, rather than the use of a specific language or platform. The ages of the systems varied from six months to thirty years old. The sizes range from 130 function points to over 10,000 function points. The programming languages range from mainframe COBOL to client server C++. The hardware platforms the software systems are running on include mainframes, workstations, client/server installations, and personal computers. To test the hypotheses, objective data about cost per function point and defects was gathered directly from the IS project team documentation. One way analysis of variance (ANOVA) was used to detect if the means in the Level 3 sample (n=35) were significantly different than those in the Level 1 sample (n=35) at the .05 and .10 confidence levels. Interview data was used to assess whether structural changes had in fact occurred and what the implications of these changes were to both the Woodson IS organization and their internal customers.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

5


6. RESULTS Did the Organization Really Change? As suggested by Markus and Benjamin [1], changing the structure and culture of the Woodson IS organization was an interactive process. One manager put it this way: There are really no short cuts. You need to have time to change the culture, and without that culture change the SEI/CMM is not going to work. It's the biggest lesson to learn, that the culture needs to change. Until the culture changes, you're not going to really be able to fully implement Level 3 or beyond. You've got a good chance of slipping back. Many of the people interviewed stressed that this magnitude of structure and culture change is not a short-term process. It took this organization four years to implement the SDMM and achieve a CMM Level 3 certification. One of the ways that respondents see a permanent culture change is in the behavior of the IS analysts. One of the SEPG members observed: When I have analysts complaining that the process isn't documented in an 032 [document] the way it should be, I'm thinking I actually might have made a difference here. It might have sunk in some here. That is a big change. Another area where we observed a change in the organization was in the amount of process, artifact, and code reuse. For example, one analyst said: All of the stuff that we built for our install is being totally reused now, or at least looked at and maybe adapted. Now the concepts that we built get totally reused. The way that projects manage themselves has also changed in the Woodson IS organization. The concept of continuous documentation and process improvement seems to have become a priority, even in small projects. Being a small group, we delegated and rotated responsibilities in terms of SEI/CMM efforts and in terms of enforcing processes. Any time anybody sees an opportunity to improve the process or a procedure of any kind, it's documented and placed in the online process asset library for other projects to use. Finally, one concrete artifact of organizational change is the SEI/CMM Level 3 certification itself. To attain this certification, which is formally registered in the SEI database, analysts across the organization had to articulate understanding and demonstrate use of consistent processes across the organization. These processes include project tracking, project documentation, software quality assurance, configuration management, requirements management, and sub-contractor management. In 1994, at

Level 1, this organization had no documented processes in these areas. While some individual projects were performing some of these functions, there was no consistency whatsoever in how they were done. CMM Level 3 certifies that these processes are institutionalized across the organization. Cost and quality analysis The Level 3 objective cost and quality measures all showed highly significant (p 0.005) improvements from the Level 1 sample, supporting Hypotheses 1 and 2. Table 1 Analysis of Variance (ANOVA) Level 3 Sample Compared to Level 1 Sample Objective Measures (actual data) n=35 to n=35 Variable (Hypothesis #) F value Significance 13.41 .00 Maintenance Cost Per Function Point (H1) 112.85 .00 Total Defects (H2) These results indicate that that the structural and cultural changes from the SEI/CMM and SDMM did have some relationship to IS organizational performance. One project manager attributed some of the cost improvement to better estimating processes driven by the CMM and the availability of historical information from the SDMM: We knew we had to improve on our cost and flows, so when we were doing that we set out the best process that we knew how to do. That just followed right into a better estimating procedure. Another Woodson project manager discussed how the SEI/CMM contributed to quality improvements: Software quality issues had already been in the forefront, but we kind of toyed around with different things, and this is finally something that we could really latch onto, so I think it improved things one hundred percent. One analyst discussed how the CMM contributed to defect reduction: Once you've achieved Level 2, you've done a lot of the work in getting your processes documented. Level 3 brings in measurements, so you start refining your processes because you see from your measurements that you need to work on certain areas. Then you can really start concentrating on defects and controlling defects before they get to the customer. While the IS group and the objective data show cost and quality improvements, the IS organization had some concern that the customers didn't value the changes that had been made.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

6


Our customer in engineering is somewhat cognizant of CMM and what it means to the quality of software that we're delivering to him. I think he's indirectly seeing that the software we're delivering is not breaking, it's working well. Outside of engineering, though, they haven't quite caught on yet. One of the biggest issues that came out of our observations and interviews was that customers saw the new formal processes and prioritization that occurred in the new IS environment as negatively impacting responsiveness. They were used to instant gratification. In the past, they'd come in, yell, and get work right out. But now they have to wait until things are prioritized in the work load, which is really the smart thing to do in the long term and probably helps them out the most. But there's some perception out there that many users are saying they're not getting as well serviced as they had in the past. Even though many of the IS organization's customers were engineers, there seemed to be resistance from them when IS moved to a more software engineering culture. One IS project manager described it this way: I think the customer puts up with it. There's a little tendency from them to want us to just go off and code instead of produce the necessary documentation. However, some users, especially those that were involved on the steering committee for the SEI/CMM initiative, did believe they were benefiting from the changes in the IS organization: We don't see nearly the problems we used to have. The systems run more smoothly. Any extra support we need is there quicker. Our problems are solved much faster. We were waiting months before. Now we're waiting just minutes and they come back with answers for us since they have things documented. The coordination is much better. When we discussed these somewhat contradictory findings with the software engineering manager and the SEPG, they admitted that the value of the changes that the IS organization had made had not been clearly communicated to all of their customers, especially to higher-level customer managers. While the advocates had focused on people rather than technology as the focus of change [1], the focus was on the people within the IS organization, rather than those outside it. The advocates realized in retrospect that this might have been an error since complete acceptance from the user community was a critical component of ongoing improvement and change [28]. While the advocacy strategy of showing a series of small successes [1] worked with first level users, it had not been dispersed to the upper levels of customer

management. The advocacy role has succeeded in improving communication and credibility at the user/analyst level of the organization, but had not succeeded at higher levels. Our data suggests that the change initiative may have even hurt the perception of the Woodson IS organization at the second management level and above. Organizational culture and politics clearly have influence over the way that Woodson customer managers perceive the information systems organization and function [29], [30]. From discussions with these managers, it almost seems as if they believe IS is like air conditioning -- they can just crank it up and immediately get better service. The complexity of the information systems function, as well as the time required to effectively utilize the new SDMM and CMM processes, was not well understood by upper-level non-IS managers. This may be in part due to the engineering culture at Bluejay, and the perception that IS professionals are not "real" engineers. However, the general lack of knowledge about IS and about the structural changes in the IS organization must be considered as a cause of some ofthe negative customer perceptions.

7. DISCUSSION AND CONCLUSIONS The model of change agentry proposed by Markus & Benjamin [1], [2] that combines IS change advocacy and structural change appears to have worked well at the IS organizational level of Bluejay's Woodson organization. The results of this case study indicate that the combination of change advocacy and structural change did change the way the IS organization operated, and did contribute to IS cost and quality performance. In addition to the quantitative data collected, interviews and researcher observation confirmed that the Woodson IS organization had changed, both culturally and structurally, and was performing better. Despite these findings, some of the IS organization's internal business customers did not seem to understand the value of the changes made in the IS organization. The results of this case study reinforce and further details Markus and Benjamin's [1], [2] assertion that IS organizational change has two primary factors: structural change and culture change. Figure 1 provides a structured diagram of the findings of this study.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

7


Figure 1 Stakeholder Support Process Reward

Structural Change

Measures IS Org Change

IS Org Performance

Functional Advocacy Visionary

Culture Change

Hierarchical Advocacy

Proposed Model of IS Organizational Change

In this study, the use of the SDMM is a process change, shown in Figure 1. Rewards were exemplified by the way reaching CMM levels were built into the organization's performance appraisal system. Measures at Bluejay were demonstrated by the assessment of CMM levels. This study demonstrated that cultural change occurs at three levels in the organization. The corporate visionary guided the way and educated the organization. Hierarchical advocacy was performed by both the division IS manager and the software engineering manager. The SEPG personnel performed hands on functional change advocacy. The fact that management outside the IS organization did not recognize the value of the changes indicates that outside or stakeholder support is a moderating variable in the proposed model of IS organizational change. It is possible that the customer perceptions of this change might have been improved with the addition of a large group intervention by the division IS manager and his counterparts [31]. Although significant change appears to have taken place within the IS organization, it is clear that this change requires stakeholder support for the IS organization to gain credibility as a full business partner and contributor. This will involve both education about IS as a software engineering discipline and demonstrations of that discipline. This will have to take place at all levels of the organization to be effective. The final factor in our proposed model is IS organizational performance. This was measured in a limited, but objective manner in this study as cost and quality. This factor could be measured in a variety of ways in future studies. Limitations and future research This study suggests that Bluejay expand the change advocacy in the Woodson IS organization to the most senior ranks of the division. At the same time, the entire Bluejay organization should consider the lessons learned at Woodson, and use a combination of change advocacy

and structural change to make the IS function an accepted part of the engineering culture at the company. The SEI/CMM framework and the use of a SDMM to support CMM processes appear to be effective tools for this purpose. While the domain of this study is a change from a chaotic CMM Level 1 IS organization to a disciplined Level 3 organization, the proposed model of IS organizational change could be tested in different change environments. For example, an IS organization moving from all work performed in-house to partial outsourcing could invoke the basic factors of the model to facilitate the transition and measure its effectiveness. One of the limitations of this study is that it is a single organization case study. As more IS organizations implement structured business processes like the CMM and begin to fully document their work, additional studies should try and generalize these results and further explore the phenomena of IS organizational change. A barrier to doing this will be that most IS organizations do not take measurements at CMM Level 1, therefore it will be difficult to make comparisons. This study strongly suggests that organizations and researchers should attempt to take measurements of "undisciplined" IS organizations to allow longitudinal comparisons to be made. The imposition of software certification programs such as the CMM with the corresponding introduction of standardized IS business processes is one of the most significant structural changes occurring in IS organizations today. This is especially critical in the primarily maintenance environment investigated in this study, since most new software development in organizations is being outsourced or purchased off the shelf. This study also suggests that as Markus and Benjamin [1] proposed, responses to IS organizational change can greatly vary at different organizational levels. Future research could confirm or disconfirm this finding. IS organizations are in the process of becoming full business partners [32]. By incorporating the moderating variable of stakeholder support, this model provides a holistic way of looking at IS organizational change. This study represents only one organizational setting, and should be contrasted with studies in other organizational settings to gain the fullest possible insight into the mechanisms of change in IS organizations.

8. References [1] Markus, M. & Benjamin, R. 1996. Change Agentry – the Next IS Frontier. MIS Quarterly. 20(4) 385-407. [2] Markus, M. & Benjamin, R. 1997. The magic bullet theory of IT-enabled transformation. Sloan Management Review. 38(2): 55-68.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

8


[3] Orlikowski, Wanda, and Jack J. Baroudi. " Studying Information Technology in Organizations: Research Approaches and Assumptions," Information Systems Research, v2n1, 1991, pp 1-28. [4] March, James G., Lee S. Sproull and Michal Tamuz. “Learning From Samples of One or Fewer,” Organization Science, v2n1 (February, 1991), pp. 1-13. [5] Lee, Allen. “A Scientific Methodology for MIS Case Studies,” MIS Quarterly, March 1989. [6] Benbasat, Izak, David K. Goldstein, and Melissa Mead. “The Case Research Strategy in Studies of Information Systems,” MIS Quarterly, v11n3, (September 1987), pp. 369-386. [7] Humphrey, W. 1995. A Discipline of Software Engineering. Reading, MA: Addison Wesley Longman. [8] Paulk, M.C., Weber, C.V., B. Curtis, and M. B.Chrissis, ”The Capability Maturity Model, Version 1.1", IEEE Software, July 1993, pp. 18-27. [9] Huber, G. & Van de Ven, A. (eds) 1997. Longitudinal Field Research Methods: Studying Processes of Organizational Change. Thousand Oaks, CA: Sage. [10] Sanders, J, & Curran, E. 1994. Software Quality: A Framework for Success in Software Development and Support Essex, UK: Addison-Wesley.

[21] Beer, M. 1992. Leading Change. Managing People and Organizations. Edited by John J. Gabarro. Boston, Massachusetts: Harvard Business School Publications. [22] Strassman, P. 1997. The Squandered Computer: Evaluating the Business Alignment of Information Technologies. New Canaan, CT: Information Economics Press. [23] Armenakis, A., Fredenberger, W., Cherones, L. & Field, H. 1995. Symbolic actions used by business turnaround change agents. Academy of Management Journal. Best Papers Proceedings: 229-235. [24] Kahn, W. 1995. Organizational change and the provision of a secure base: Lessons from the field. Human Relations. 48(5): 490-515. [25] Larsen, E. & Lomi, A. 1999. Resetting the clock: A feedback approach to the dynamics or organisational inertia, survival, and change. The Journal of the Operational Research Society. 50(4): 406-421. [26] Hammer, M. & Stanton, S. 1999. How process enterprises really work. Harvard Business Review. 77(6): 108-118. [27] Gibson, V. R. & Senn, J. 1989. System structure and software maintenance performance. Communications of the ACM. 32(3): 347-358. [28] Johnson, P., Leenders, M. & Fearon, H. 1998. Evolving roles and responsibilities of purchasing organizations. Journal of Supply Chain Management. 34(1): 2-11.

[11] Nelson, K., & Ghods, M. 2000. Evaluating the contributions of a structured software development and maintenance methodology. Journal of Information Technology Management. (forthcoming 2000).

[29] Buchanan, D. & Badham, R. 1999. Politics and organizational change: The lived experience. Human Relations. 52(5): 609-629.

[12] Yourdan, E. 1989. Managing the Structured Techniques: Strategies for Software Development in the 1990's. New York: Yourdan Press/Prentice Hall.

[30] Buchanan, D., Claydon, T. & Doyle, M. 1999. Organisation development and change: The legacy of the nineties. Human Resource Management Journal. 9(2): 20-37.

[13] Agocs, C. 1997. Institutional resistance to organizational change: Denial, inaction, and repression. Journal of Business Ethics. 16(9): 917-931. [14] Sprague, R. 1995. Electronic document management: Challenges and opportunities. MIS Quarterly. 19(1): 29-50. [15] Marion, L. & Marion, D. 1998. Information technology professionals as collaborative change agents: A case study. Bulletin of the American Society for Information Science. 24(6): 9-12.

[31] Coghlan, D. 1998. The process of change through interlevel dynamics in a large-group intervention for a religious organization. The Journal of Applied Behavioral Science. 34(1): 105-119. [32] Roepke, R., Agarwal, R., and Ferratt, T., "Aligning the IT Human Resource with Business Vision: The Leadership Initiative at 3M," MIS Quarterly, 24 [2], pp.327-353

[16] Levinthal, D. 1997. Adaptation on rugged landscapes. Management Science. 43(7): 934-950. [17] Nutt, P. & Backoff, R. 1997. Facilitating transformational change. The Journal of Applied Behavioral Science. 33(4): 490-508. [18] Brown, S. & Eisenhardt, K. 1997. The art of continuous change: Linking complexity theory and time-paced evolution in relentlessly shifting organizations. Administrative Science Quarterly. 42(1): 1-34. [19] Orlikowski, W. & Hofman, D. 1997. An improvisational model for change management: The case of groupware technologies. Sloan Mangement Review. 38(2): 11-21. [20] Martinsons, M. 1993. Cultivating the champions for strategic information systems. Journal of Systems Management. 44(8): 31-34.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

9