IN THE EARLY 1980S, I (MARIA) WAS LOOKING FOR A JOB AFTER FINISHING MY DOCTORATE IN computer science at UCLA. I was full of enthusiasm for the field I was in and a little concerned about the kinds of jobs I would find. I wanted a place where I could follow my passion and make contributions. I had met Barry at one of the conferences where I presented some of my research results, and thus went to interview with him at TRW. During the interview, Barry described the environment around the company and told me about this new project he was starting whose objective was to revolutionize the way the company developed software.

Barry told me that he had conducted a software productivity study [1] in the company, which performed an economic analysis to determine whether a significant level of investment into software productivity aids would be justified. The factors that led to the analysis were driven by an overall corporate focus on industry and international competitiveness, but also included increased demand for software, limited supply of software engineers, rising software engineer support expectations, and reduced hardware costs—do they all sound familiar even today? This study led to the project that he wanted me to work on, the Software Productivity Project (SPP) [2,3]. He told me it would not be easy, since we would be trying to change the culture. Well, it seemed the perfect challenge for my first job in industry, so I accepted the offer and went to work on the project, together with a fantastic team of TRW veterans and newbies. We were going to attempt to change the current ways of developing software by providing a software development support environment for the aerospace part of the company.

Before it was acquired by Northrop Grumman, TRW was a conglomerate which included a large auto parts company (Thompson Products in Cleveland) and a large aerospace company (Ramo-Wooldridge in Los Angeles). It included a number of software-intensive product lines, including TRW Credit Data, and divisions producing point-of-sale systems, telecom switches, and industrial process control systems. In the mid-1980s, TRW was ranked number two in world software sales in the annual Datamation 100 lists, well behind IBM.

In the 1960s, TRW's aerospace sector pioneered in going from the code-and-fix approach to software development to the requirements-driven waterfall model, as described in Winston Royce's classic 1970 paper [4]. In the 1970s, TRW developed a set of waterfall-oriented software development policies, standards, review procedures, training courses, and requirements-driven software tools. These were a good match to TRW's engineering, science, and real-time control systems of the time, and the culture became strongly waterfall-oriented. By the late 1970s, though, TRW's applications became much more people-interactive, and the waterfall model didn't work well with requirements that were emerging as the project progressed.

At that time, the environment for projects included managers coordinating the people and activities, secretaries who typed the project's documents, meetings to plan and produce the project's activities and tasks, and system engineers and developers producing the designs and the systems. Only developers used software development tools and they had to work in batch processing mode or go to special bays with limited numbers of terminals for interactive development, using mainframe computers. Well, in the SPP we developed a new work environment where all members of the project (managers, system engineers, software developers, secretaries, and controllers) had individual offices with workstations, and communicated electronically via a local area network (LAN). Its architecture was based on the Unix operating system and it included commercial off-the-shelf (COTS) and locally developed tools in support of the full life cycle (e.g., requirements definition, traceability, design and development, forms management, and office automation tools). For this new project, we had to cope with significant technical and stakeholder-conflict risks, and with emergent requirements that could not be specified in advance; thus, we had a great opportunity to apply an early version of the risk-driven, concurrently engineered spiral model developed by Barry [5]. Those changes created culture-clash challenges, especially for the waterfall-oriented veterans and interactive-oriented newbies on the SPP itself. We can still recall heated meetings where TRW veterans would say things like, "But the policies don't allow you to prototype this early! Prototyping is coding before you have passed your critical design review!"

The project was very successful (with significant productivity gains—a factor of two or more, depending on reuse), but it was not easy to institutionalize the changes and convince the personnel. We also learned that productivity gains require an integrated program of initiatives in several areas and an ongoing and sustained effort. Even though this project happened long ago, the stories we tell in this chapter describe points that are still valid today, in spite of all the advancement in tools and technologies, both in planning and in executing productivity activities. Changing cultures is difficult, and it is even harder to keep up with the fast pace of technology in large organizations.