focus process change Successful Process Implementation Anna Börjesson, Ericsson Lars Mathiassen, Georgia State University H ow do you measure success in software process improvement? The answer is perhaps not as straightforward as it seems. Success is traditionally measured as the difference in quality and productivity between the old and new engineering practices.1 However, this measure requires systematic benchmarking and data collection over long periods of time, and few software organizations can meet this demand. So, how can we more realistically measure SPI and practically guide our SPI efforts toward success? We propose measuring SPI success through implementation success—the extent to which initiatives lead to actual changes in software engineering practice. First, without implementation success, SPI success is impossible. Second, only when implementation succeeds can we see how SPI initiatives affect software practices. Third, implementation success is easy to assess. Finally, focusing on implementation success is a pragmatic way to steer SPI initiatives toward success. We studied the approach and outcome of 18 different SPI initiatives conducted over a fiveyear period at the telecom company Ericsson AB, based in Gothenburg, Sweden. Doing so gave us insight into how SPI initiatives can best ■ Ensure stakeholder commitment Traditional approaches to measuring software process improvement are typically lengthy, data intensive, and cost prohibitive. A simple indicator, the extent to which engineering practices change, can provide enough information to guide initiatives toward success. 36 IEEE SOFTWARE Published by the IEEE Computer Society ■ ■ ■ Support organizational learning Distribute resources over different activities Manage customer relations The Ericsson experience Ericsson has provided packet-data solutions for the international market for more than 20 years and is among the world leaders in this area. Between 1995 and 2001, the company grew from 150 to 900 employees. During this period, SPI played a key role in improving software productivity and quality, and the company conducted many SPI initiatives with varying degrees of success. The initiatives were executed in the same organizational context and, in most cases, involved the same SPI people. The initiatives also followed the same IDEAL approach2 to SPI (see “The IDEAL Model” sidebar): After initiation, the initiatives went through one or more cycles of diagnosing problems, establishing focused improvements, acting to improve, and learning from results. However, the SPI initiatives had important differences (see Table 1). They focused on different improvement areas, had different vol0740-7459/04/$20.00 © 2004 IEEE The IDEAL Model The IDEAL (Initiating, Diagnosing, Establishing, Acting, and Learning) approach,1 developed in 1996 by the Carnegie Mellon University Software Engineering Institute (www.sei.cmu.edu/ideal), presents a five-phase, cyclic approach to software process improvement. The initiating phase (see Figure A) is where you establish the initial improvement infrastructure, define the initial roles and responsibilities for the infrastructure, and assign initial resources. You create an SPI plan to guide the organization through the completion of the initiating, diagnosing, and establishing phases. Also, you obtain approval for the SPI initiative along with a commitment of future resources for the tasks ahead. The diagnosing phase lays the groundwork for the later phases. The SPI action plan is initiated in accordance with the organization’s vision, strategic business plan, lessons learned from past improvement efforts, key business issues the organization faces, and long-range goals. You perform appraisal activities to establish a baseline of the organization’s current software operation. You reconcile the results and recommendations from the appraisals with existing and planned improvement efforts for inclusion into the SPI action plan. During the establishing phase, you prioritize the issues that the organization has decided to address with its improvement activities and develop strategies for pursuing the solutions. You detail and complete the SPI action plan on the basis of the adopted strategy and the decisions made. You design focused projects to address each prioritized improvement area. In the acting phase, you create, pilot, Learning Propose future actions Analyze and validate Implement solution Refine solution Stimulus Set Build Character for a context sponsorship infrastructure change Initiating Pilot test solution Characterize current and desired states Develop recommendations Create solution Diagnosing Set priorities Acting Develop approach Plan actions Establishing Figure A. The IDEAL model presents a five-phase approach to software process improvement. (Special permission to reproduce “Ideal Model Graphic,”  2003 by Carnegie Mellon University, is granted by the Software Engineering Institute.) and deploy throughout the organization solutions to address the areas for improvement discovered during the diagnosing phase. You develop plans to execute pilots to test and evaluate the new or improved processes. After piloting these processes and determining their readiness for organization-wide adoption, deployment, and institutionalization, you develop and execute plans to accomplish the rollout. The learning phase (called the “leveraging” phase when IDEAL debuted) aims to make the next pass through the IDEAL model more effective. By this time, you’ve developed solutions, learned lessons, and collected metrics on performance and goal ume, and targeted different parts of the organization. In addition, the initiatives adopted assorted improvement tactics and went through a varying number of IDEAL model cycles. Also, while commitment is generally recognized as a key factor in SPI success,1,2 different social forces drove each initiative.3 The process push depends on the competence, commitment, and active participation of process engineers in developing and implementing new engineering practices. The practice pull instead depends on achievement. These artifacts are added to the process database as a source of information for personnel involved in the next pass through the model. Also, on the basis of this information, you can evaluate the strategy, methods, and infrastructure used in the SPI program. By doing this, you can correct or adjust the strategy, methods, or infrastructure prior to executing the IDEAL model’s next cycle. Depending on the resources organizations commit to their SPI program, they can pursue IDEAL activities in parallel, and some parts of the organization can pursue activities in one phase of the model while others pursue activities in a different phase. the competence, commitment, and active participation of software practitioners in developing and adopting new practices. These differences in improvement tactics (that is, the number of iterations, degree of process push, and degree of practice pull) resulted in varying levels of implementation success. SPI participants collected data both during and after the initiatives using time-reporting systems, project specifications, final reports, and interviews with process engineers and July/August 2004 IEEE SOFTWARE 37 Table 1 Process implementation data on Ericsson’s software process improvement projects SPI initiative Improvement area Volume Target Ideal iterations Process push 1 Configuration management Several units 1 full cycle 2 Design information Several units 3 Estimation and planning 4 Historical data 1 full cycle; stopped during establishing in the second cycle 1 full cycle; stopped during establishing in the second cycle 1 full cycle 5 Introductory training 10 weeks 300 person-hours 4 participants 21 weeks 400 person-hours 6 participants 14 weeks 600 person-hours 11 participants 16 weeks 200 person-hours 4 participants 14 weeks 620 person-hours 11 participants Weak. Process engineers focused on designing a generic process, with no commitment to or plan for actually deploying the process. Weak. Process engineers focused on designing a generic process, with no commitment to or plan for actually deploying the process. Weak. Process engineers focused on designing a generic process. Time for mentoring and process deployment was limited. Weak. Process engineers focused on identifying historical data, little of which had been recorded. SPI participants planned very few activities to communicate the results. Weak. Process engineers were dedicated to defining and describing the process. No plans for how to deploy the process and support its actual use. 6 Module tests 7 Project tracking 8 Resource handling 9 Requirements management 10 Requirements management implementation Subcontract management 11 12 Requirements management 13 Analysis and design 14 Implementation 15 Test 16 Configuration management 17 Project management 18 Process development map 38 IEEE SOFTWARE Several units Several units Several units 1 full cycle 12 weeks 400 person-hours 10 participants 9 weeks 300 person-hours 7 participants 4 weeks 250 person-hours 8 participants 10 weeks 200 person-hours 5 participants 12 weeks 330 person-hours 7 participants 18 weeks 650 person-hours 9 participants Several units 1 full cycle; stopped during establishing in the second cycle 1 full cycle; stopped during establishing in the second cycle 1 full cycle Weak. Process engineers focused on designing a generic process. Too little time was planned to help the project actually use the result. Weak. Process engineers were given time only to define a process, not to implement it in projects. Several units 1 full cycle Project 1 full cycle; stopped during establishing in the second cycle 1 full cycle Weak. Participants spent most of the time defining requirements management; they planned little time to help implement the results. Strong. Management made time for the process engineers to help implement the project results. 30 weeks 1,200 person-hours 3 participants 30 weeks 1,000 person-hours 4 participants 30 weeks 1,000 person-hours 4 participants 30 weeks 1,300 person-hours 2 participants 30 weeks 1,650 person-hours 6 participants 10 weeks 150 person-hours 2 participants 30 weeks 200 person-hours 2 participants Project w w w . c o m p u t e r. o r g / s o f t w a r e Several units Several units Several units Project 4 full cycles; stopped during diagnosing in the fifth cycle 5 full cycles; stopped during establishing in the sixth cycle 4 full cycles Unit 4 full cycles Unit Unit 4 full cycles; stopped during diagnosing in the fifth cycle 3 full cycles Unit 4 full cycles Unit Weak. Process engineers focused on solving the problem through a well-defined process. Weak. Process engineers were strongly committed to solving the problems, but the resulting process wasn’t grounded in current practices. No time was planned for activities to make change happen. Strong. Management made time for process engineers to mentor and support the project in action. The SPI initiative was dedicated to solving the problems for one project. Strong. Process engineers planned the deployment activities and made time available for mentoring and support. Strong. Management gave process engineers time to participate in the project to support implementing the results. Strong. Process engineers participated in software tests and came to understand the tester’s specific needs. Strong. Management dedicated sufficient resources to daily mentoring and support to make the change happen. Strong. Some process engineers were also customers who would be using the results. The SPI commitment to the initiative was very high. Strong. Process engineers saw the need for a well-defined process development map to help communicate and deploy all SPI work. Practice pull Implementation success Weak. Projects focused mainly on making generic process descriptions. Practitioners were eager to solve problems on a general level but had little commitment to using the results. Weak. Projects focused mainly on making generic process descriptions. Practitioners were eager to solve problems on a general level but had little commitment to using the results. Medium. Projects were dedicated to solving generic process problems, but only one project manager was interested in actually testing the results. Low. Potential users considered results hard to use. SPI participants used part of the result indirectly, when they applied the knowledge gained to other projects. Medium/low. The intention was to provide a design framework. The results were mainly implemented in one project that one process engineer worked on. Low. The results were tested in one project, but the project ran into difficulties. Support was weak, and no one helped the project; resources from the SPI initiative were no longer available to make necessary changes. Low. The purpose was to build a database of old data and take action from there. Participants found no interesting data and thus made no changes. Medium. An estimated 50 percent of managers used the process. Some didn’t know about it and weren’t given the opportunity to learn about it. The SPI initiative gave managers supporting guidelines. More assistance was sometimes needed. Medium/low. The process was used only when process engineers were members of a project or when section managers strongly believed in systematic module tests. Medium/low. Only one project, which was supported by the SPI initiative’s driver, used the process. That project team was content with the outcome. Weak. Managers were eager to find out about historical data. When they found very little, their commitment to change dropped dramatically. Strong. The result was focused on supporting managers who were asking for help and interested in applying the results. Weak. Many practitioners believed in performing systematic module tests, but no one was committed or given the time to implement the results. Weak. Most project managers believed good follow-up on a project was necessary, but only one was committed and willing to try out the results in practice. Everyone else waited to see if someone else benefited from the process. Medium. The managers believed in supporting resource handling, and most of them were willing to use the result. Weak. Everyone knew that managing requirements was important, but no one was committed to acting on the results in his own project. Weak. The targeted project was interested but not committed to spending the time required to make the change happen. Medium. An estimated 75 percent of managers used the new process. Those not using the results either didn’t get the help they needed or didn’t believe in the approach. Low. The results were hard to use. They were used mainly as a framework by the members of the SPI initiative. Medium. Initiative 9’s low impact spurred this initiative. This initiative focused on one project, and all results were designed to suit its needs. Weak. Managers were strongly committed to creating better routines for subcontract management, but no time was planned for the projects to actually implement the new process. Low. The results needed further adaptation to be useful for different projects, but no one tried to tailor them. Project engineers used some results indirectly in other projects. Strong. A few highly respected practitioners were strongly committed to the initiative. They helped ensure the results would actually be used. High. The process was adapted to a specific project but needed further adaptation to be useful. Process engineers and practitioners solved these problems jointly and made the change happen. Medium/high. This is a complex area and required several iterations of experimenting with processes before the result was satisfactory. Strong. A few well-respected practitioners were convinced (after a few difficult weeks) of the need for improved practices and committed to making them happen. Strong. The practitioners were receptive to adopting a stronger focus on implementation, and they participated actively in the change process. Strong. The practitioners came to understand that the SPI initiative was responsive to their specific needs, and they became committed to using the results. Strong. The configuration managers were highly involved in both defining and deploying the results. Strong. The project managers wanted to implement their own ideas and took the time to do it. Strong. All software practitioners needed a process description that would provide templates, guidelines, and other relevant information. High. Two slightly different adaptations were made to fit the needs of different products developed on different sites. Collaboration between process engineers and software practitioners made the change happen. High. The result was adapted to the specific needs of a specific project. Process engineers and software practitioners solved difficulties together. High. Each specific situation has hundreds of possible solutions. Choosing one and focusing on making that happen required extra attention. The software practitioners’ dedication played a key role. High. The results were actually used, and the project managers’ dedication to SPI work within project management continued. High. The development-process map’s use is measured in both “hits” to a site on the process web and subjective opinions of need. All measurements are very positive. July/August 2004 IEEE SOFTWARE 39 Practice pull Crossroads Highway Initiatives 3, 5, 8 Initiatives 12–18 High Software process improvement Software process improvement can happen. will happen. Dead-end Street Country Road Initiatives 1, 2, 4, 6, 7, 9, 11 Initiative 10 Low Software process improvement Software process improvement won't happen. can happen. Low High Process push Figure 1. Four roads to process implementation. software practitioners. One of us was directly involved in and responsible for all of these initiatives; the other had conducted SPI research in many other organizations. Analyzing the data revealed how important it is to actively manage commitment, learning, resource distribution, and customer relations if SPI efforts are to succeed. Managing commitment Categorizing Ericsson’s SPI initiatives on the basis of the degree of process push and practice pull, we arrive at four different roads to process implementation (see Figure 1). The Dead-end Street initiatives focused on the process itself—specifically, on process definition and specification. The initiatives targeted several Ericsson units, but the new process was often hard to apply because process engineers had to make many compromises to meet everyone’s needs. The process push toward implementation was low because the process engineers focused on defining a generally applicable process. Few resources and incentives existed for the process engineers to become engaged in the involved units’ different engineering cultures. The practice pull was also low because it was difficult to engage software practitioners from different units in one common initiative. Needs and backgrounds differed across the units, and they had no tradition for communication and collaboration across units. The Dead-end Street initiatives never amounted to much. No one was seriously committed to implement the processes, so the organization saw little overall benefit. The Country Road initiative targeted a specific project’s engineering practices. The process engineers worked in the project and had time to help implement the results. The 40 IEEE SOFTWARE w w w . c o m p u t e r. o r g / s o f t w a r e process engineers, therefore, understood the particular culture and practices in the project, and they were strongly committed to support and change practices. They focused on requirement issues and created a process that fit the project’s particular needs. However, the practitioner commitment was weak. The software practitioners weren’t motivated to change requirements practices. They didn’t understand why they had to be involved and didn’t allocate time to work with process implementation. The process push was high, but the practice pull was low. A typical Country Road initiative can happen, but it’s slow going and likely to fall short of changing engineering practices. The Crossroads initiatives targeted several company-level units with similar requirements. Practices and needs across the units had little variation, so process compromises were unnecessary. The practice pull was high: Software practitioners understood the need for new processes and were committed to using them. But the process engineers failed to allocate sufficient time and resources to implement the process, so the process push was low. A typical Crossroads initiative can happen, and at Ericsson, the initiatives might succeed. However, the software practitioners might yet face barriers to effective implementation,4 and process engineers are no longer available to guide them and facilitate the change process. The Highway initiatives targeted practices in a single unit or project. The main focus was on solving specific problems identified by software practitioners, and they required few compromises. Both process push and practice pull were high. The process engineers were committed and allocated time to process implementation, and the software practitioners understood why they needed the new approaches and appreciated the SPI initiative. The process engineers and the software practitioners worked closely together and communicated intensively about needs, problems, and progress. A typical Highway initiative will happen, and engineers will implement and use the results. Organizations directly benefit from such initiatives. Managing learning Successfully changing software practices requires learning, and helping organizations learn is by no means easy.5,6 Iterations support learn- Implementation success 17 High 14, 12 16 15, 18 13 Medium 5 8 10 2, 6, 7 Low 1, 4, 9, 11 1 3 2 3 4 Number of iterations 5 6 Figure 2. Implementation success and number of iterations (1 through 18). More iterations meant more implementation success. 12, 14–16, 18 Performance ing by letting you correct failures and modify processes based on practical experience. Although CMM founder Watts Humphrey doesn’t use the word iteration, he does discuss the importance of performing SPI work in steps and repeatable sequences.1 Several SPI approaches emphasize iterative development, including the IDEAL model2 and methods that implement plan-do-act-check cycles.7 We examined how Ericsson’s SPI initiatives used iterations and feedback from practice to support learning. Figure 2 illustrates the relation between the initiatives’ implementation success and the number of iterations they executed. As the figure shows, the number of iterations significantly affected SPI implementation success: As the number of iterations increased, so too did implementation success. However, because factors apart from iterations affect implementation success, this pattern has exceptions. Initiatives 5 and 8, for example, executed a single iteration but still achieved moderate implementation success. One possible explanation is that both initiatives had high practice pull. Also, Initiative 13 executed two iterations in the last phase alone and still failed to achieve high implementation success, while Initiative 17 executed only three iterations total and was highly successful. Compared to the other initiatives, however, Initiative 13 was by far the most complex and difficult and consumed the most time and expertise. In contrast, Initiative 17 had an experienced project manager who exercised considerable practice pull. So, projects can succeed with few iterations. In general, however, more iterations support more learning and better facilitate change. To further illustrate the importance of iterations, we mapped each initiative to Gerald Weinberg’s four phases of successful change (see Figure 3).8 As the figure shows, initial attempts to introduce a new process lead to chaos. The process then becomes integrated as engineers attempt to practice it, eventually giving rise to a new and stable status quo of engineering practices. However, each phase has barriers that make implementation difficult, and these barriers can cause the process to regress to previous phases. As Figure 3 illustrates, an initiative typically took one full iteration to pass one phase in Weinberg’s change model. Most SPI initiatives must pass the chaos phase and enter the 17 13 1–11 Old status quo Chaos Integration and practice New status quo Time integration and practice phase to successfully implement a new or modified process. SPI initiatives that execute only a single iteration will therefore seldom enter the phase of using the new process as an integral part of engineering practices. Thus, the process simply won’t be adopted as intended. Managing resources As Humphrey says, “SPI requires investment—it takes planning, dedicated people, management time, and capital investment,” and, for an organization to improve, “someone must work on it.”1 To drive SPI work toward success, organizations must commit and manage their resources accordingly, and they Figure 3. Performance and distribution of iterations (numbered 1 through 18). The jagged line illustrates Weinberg’s optimum learning curve. The circles denote the number and distribution of iterations over phases. July/August 2004 IEEE SOFTWARE 41 Effort spent significant fear and uncertainty. Because Initiative 12 invested considerable resources in these later phases, the process engineers could better manage and address change issues as they emerged. Managing customer relations Initiate Diagnose Establish Act Learn Time Figure 4. Effort spent over IDEAL phases. Initiatives that overinvested in early phases, represented by Initiative 1 (the red curve), had low implementation success. Initiatives that invested most resources in later phases, represented by Initiative 12 (the green curve), had high implementation success. must constantly motivate people to participate and contribute. Any significant change can create substantial fear and uncertainty throughout the organization. It’s essential that process engineers possess change-management skills.8 Skillful change agents can work closely with software practitioners to solve potential difficulties that arise regarding both the new process and the change process itself. Ericsson’s process engineers managed resources quite differently in the SPI initiatives. Figure 4 shows how the process engineers distributed their time over the IDEAL model’s phases2 in two ways. Initiative 1 is representative of the pattern in initiatives 1 through 11. It had low implementation success, and engineers invested most of their effort into the model’s early phases (the red curve). Initiative 12 is representative of initiatives 12 through 18. It had high implementation success, and the process engineers invested most of their effort in the model’s later phases (the green curve). As this comparison indicates, spending considerable effort in the model’s later phases might be more successful than putting most effort into early phases. Most of Initiative 1’s process-engineering resources were used to analyze, design, and describe the new process. This meant few resources were available during the difficult implementation phases, in which software practitioners can experience 42 IEEE SOFTWARE w w w . c o m p u t e r. o r g / s o f t w a r e To achieve SPI success, process engineers must have a positive, collaborative relationship with their customers, the software practitioners.9 Positive customer relations will help process engineers better understand engineering practices and problems and thus develop more useful processes. A good relationship also helps software practitioners overcome their resistance to change: When the status quo is challenged, they often become defensive and alienated.8 For managing customer relations, a dedicated SPI approach seems more likely to succeed. As Table 1 shows, Initiatives 1 through 11 generally supported several units and thus used a relatively generic SPI approach that achieved moderate success at best. Initiatives 12 through 18 supported only one project or unit and used a more dedicated approach with greater overall success. Of course, other factors influence SPI outcome, and rules always have exceptions. Nonetheless, generic approaches make it difficult for process engineers to build and maintain good customer relations—there are too many different relationships, needs, and requirements. In dedicated approaches, process engineers and software practitioners can work closely together and focus on the project’s specific challenges. Also, in generic approaches, it’s difficult to handle the many personalities and requirements when relationships with the software practitioners become fragile. In such situations, it’s much easier for process engineers to simply focus on the process design and description and forget about troublesome implementation issues. Lessons learned Our experiences with the Ericsson initiatives offered several lessons about how organizations can more successfully manage SPI. Focus on implementation When it comes to software, we already know that test-and-repair strategies fail to deliver quality. To achieve quality, software projects must consider it and plan for it from the start. Similarly, in an SPI initiative, you should consider implementation issues early on. Such considerations should include10 tions, you’re more likely to overcome resistance to change and facilitate learning. Expect chaos ■ ■ ■ ■ ■ Critically evaluating the new process from an easy-to-adopt standpoint Examining the roles that stakeholders must play during implementation Choosing an implementation strategy that suits the initiative Assessing and resolving implementation risks Outlining an initial plan for implementation Such early focus on implementation can help you design processes that software practitioners are more likely to adopt and thereby reduce the risk of failure. Take the Highway At Ericsson, process engineers initially perceived some initiatives, such as Initiative 1, as successful because the operations went smoothly. They viewed other initiatives, such as 12, as problematic because they caused debate, anxiety, and active resistance among software practitioners. Paradoxically, Initiative 1’s implementation ultimately met with low success, while Initiative 12 was highly successful. The explanation is simple: If you emphasize process analysis and design, you won’t experience the tension that arises between your design and current engineering practices. If, on the contrary, you engage in process implementation activities, you’ll be confronted with misfits and psychological reactions. You should therefore expect a certain level of chaos in SPI initiatives. Chaos is often a sign that the implementation process is on its way and that you’re about to receive valuable information that will help you succeed. To succeed with SPI, you need a serious commitment from key stakeholders.1,7 To develop this commitment, you must ensure that process engineers have sufficient change-management skills and resources to create high process push. This in turn facilitates the active involvement of software practitioners to create high practice pull. Also, it’s important to focus on the cultural environment of the change process.11 Are the involved actors motivated? Are senior and middle managers involved? Are the recognition and reward systems appropriate? And, is communication between the involved actors supportive? The Highway is the best route to SPI implementation success. The Country Road and Crossroads are risky and require additional attention and resources to create complementary pull and push, respectively. As its name implies, the Dead-End Street leads nowhere. Achieving SPI success is difficult if process engineers aren’t involved in the action phase of the IDEAL model, in which practitioners experience considerable fear and uncertainty.2 During implementation, process engineers with change artistry8 should work closely with software practitioners to resolve difficulties with both the new process and the process of change. You should, therefore, distribute available resources to ensure that process engineers and software practitioners are actively involved throughout the initiative, until the process has been successfully implemented. Iterate, iterate, iterate Organize dedicated initiatives SPI initiatives that execute only a single iteration never enter the phase in which the new process is exposed to practice. In such initiatives, the process engineers get no feedback on whether the process is useful, and the process won’t likely be used. SPI initiatives that execute several iterations are more likely to enter and pass through the phase in which practitioners resist change; when the defined process meets actual practice, process engineers can learn and react. The result is a process that practitioners will likely use. If you plan for several itera- SPI initiatives that target several units and projects often lack the resources and motivation needed to address the extremely complex change issues involved. Process engineers also sometimes prefer the early IDEAL model phases, in which they analyze and design the process, rather than the later phases, in which their challenge is to handle resistance and other barriers to change.2 SPI initiatives supporting a single project or unit are less time consuming, require no compromises, and make it easier to create an open, collaborative relation- Chaos is often a sign that the implementation process is on its way and that you’re about to receive valuable information that will help you succeed. Focus on action July/August 2004 IEEE SOFTWARE 43 About the Authors Anna Börjesson is a software process improvement manager at Ericsson AB in Gothen- burg, Sweden, and an industrial PhD student at the IT University in Gothenburg. Her software engineering skills cover such areas as CMM, Rational Unified Process, Rational Tool Suite, SW metrics, SW quality assurance, change management, SW diffusion and implementation theories, and SW process adaptation work. She received her M.Sc. in informatics from Gothenburg University. She’s a member of the IEEE and ACM. Contact her at Ericsson AB, Lindholmspiren 11, 417 56 Gothenburg, Sweden; anna.borjesson@ericsson.com. Lars Mathiassen is a professor of computer information systems at Georgia State Uni- versity. His research interests include information systems and software engineering, with a particular focus on business process innovation. He received his Dr. Techn. in software engineering from Aalborg University. He’s a member of the IEEE, ACM, and AIS and coauthor of Computers in Context (Blackwell, 1993), Object Oriented Analysis & Design (Marko Publishing, 2000), and Improving Software Organizations (Addison-Wesley, 2002). Contact him at the Center for Process Innovation, J. Mack Robinson College of Business, Georgia State Univ., PO Box 5029, Atlanta, GA 30302-5029; lmathiassen@gsu.edu; www.mathiassen.eci.gsu.edu. O ur experiences at Ericsson focus on improvement tactics that affect SPI implementation success. You should, however, be cautious when you transfer the lessons to other software organizations. Factors such as process complexity, volume of initiative, organizational culture, and individual skills also affect SPI outcome. And, of course, there are always exceptional situations and those in which other approaches to process implementation are feasible. Ultimately, these are guidelines, not absolute truths. Our advice is to stay pragmatic but actively use these lessons to guide your SPI initiatives toward success. References ship between process engineers and software practitioners. You should, therefore, opt for dedicated SPI initiatives over generic ones whenever possible. SOFTWARE ENGINEERING Construx Software ■ steve.tockey@construx.com GLOSSARY Cash-flow statement: One of the main financial statements, it shows how the company is paying for its current operations and future growth by detailing the actual flow of cash between the company and the outside. It answers the question, “How much more or less cash does the company have now than it did before?” Capital: Money that is, or can be, used for the purpose of making more money. Interest: Literally, a fee for renting money. Someone who borrows money from another is usually obligated to return the original amount borrowed plus some additional money. That additional money is the interest. The interest rate is a measure of the rental fee for money in terms of a percentage over some period of time. At 10 percent interest for a year, someone who borrows $100 is obligated to pay $110 back at the end of one year. For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib. ■ S t e v e To c k e y 44 Software Engineering Economics IEEE SOFTWARE 1. W.S. Humphrey, Managing the Software Process, Addison-Wesley, 1989. 2. B. McFeeley, IDEAL: A User’s Guide for Software Process Improvement, tech. report CMU/SEI-96-HB001, Software Eng. Inst., Carnegie Mellon Univ., 1996; www.sei.cmu.edu/pub/documents/96.reports/pdf/hb001. 96.pdf. 3. R.W. Zmud, “An Examination of ‘Push-Pull’ Theory Applied to Process Innovation in Knowledge Work,” Management Science, vol. 30, no. 6, 1984, pp. 727–738. 4. R.G. Fichman and C.F. Kermerer, “The Assimilation of Software Process Innovations: An Organizational Learning Perspective,” Management Science, vol. 43, no. 10, 1997, pp. 1345–1363. 5. C. Argyris and D. Schön, Organizational Learning, Addison-Wesley, 1978. 6. J.S. Brown and P. Duguid, “Organization Learning and Communities-of-Practice: Toward a Unified View of Working, Learning and Innovation,” Organization Science, vol. 2, no. 1, 1991, pp. 40–57. 7. R.B. Grady, Successful Software Process Improvement, Prentice Hall, 1997. 8. G.M. Weinberg, Quality Software Management, Volume IV: Anticipating Change, Dorset House, 1997. 9. L. Mathiassen, P.A. Nielsen, and J. Pries-Heje, “Learning SPI in Practice,” Improving Software Organizations: From Principles to Practice, L. Mathiassen, J. PriesHeje, and O. Ngwenyama, eds., Addison-Wesley, 2002, pp. 3–21. 10. S. Tryde, A.-D. Nielsen, and J. Pries-Heje, “A Framework for Organizational Implementation of Software Process Improvement in Practice,” Improving Software Organizations: From Principles to Practice, L. Mathiassen, J. Pries-Heje, and O. Ngwenyama, eds., AddisonWesley, 2002, pp. 257–271. 11. P. Fowler and M. Patrick, Transition Packages for Expediting Technology Adoption: The Prototype Requirements Management Transition Package, tech. report CMU/SEI-98-TR-004, Software Eng. Inst., Carnegie Mellon Univ., 1998. w w w . c o m p u t e r. o r g / s o f t w a r e