Yes, we formed a team, a beautiful team, with 20–25 performers. Some were experienced TRW veterans, but most members of the team were in their 20s (the GEN-Ys of today), a few fresh out of college including undergraduates, some with master's and PhD degrees, a good mix of male and female personnel, a few non-natives (from South America, Asia, and the Middle East), and a lot of enthusiasm. It did not take a long time for the team to gel, with many having lunch together most days (do people still do that these days?), others even becoming good social friends. And of course, we also had your typical "nerds" who produced tons and did not like socializing much (we will tell you more about that later). Keep in mind that most of the members were totally comfortable with the new technology since they were coming from universities that were pioneers in the Internet (like UCLA). The target community, however, represented much of the standard company personnel, used to the "old" ways.
Our challenge was to convince the typical project personnel to adopt a new style of development and collaboration as a team and use the new technologies we were bringing. The SPP was aiming at changing the culture, establishing LANs, and bringing all members of the project to communicate via email and to use automation for the development and non-development activities. (Remember: that was in the '80s …. On the other hand, things haven't changed; we can observe the same issues with established personnel in large corporations that hesitate at the introduction of the latest technologies like social networking, Wikis, and virtual worlds.) We were matched up with another project that was to use the new tools/processes that our team generated and we have many interesting stories about this matchup.
We had a wonderful boss, very friendly and open-minded—after all, he took the challenge to manage this "revolutionary" project. However, he had been in the company for more than 20 years and was very accustomed to the culture. We, the young, set out to change his habits. He was enthusiastic about most of the proposed tools to automate the life-cycle process, but we noticed that he never used email (none of the managers did at that time). So, one of us played a trick on him; she scheduled a meeting with him and, upon arriving in his office, she promptly said she was going to teach him how to use email. You should have seen his face; the look of astonishment. He was used to telling his staff what to do, not the other way around. To make the story short, he could not refuse, and after learning, he really became a part of the team by participating in the online discussions and conversations, understanding the issues, and sharing the news. By avoiding the change, he was missing on much of the project chemistry. Sometime later he confessed that he "couldn't type" and therefore was embarrassed of showing his shortcoming. But this staff member and her boss became very good coworkers and friends, as the project progressed due to his openness to change. Those were key ingredients toward the success of the project.
The status quo of projects was to have offices for managers and cubicles for project personnel; developers used a development bay where a pool of shared computer terminals were located. Among the "new" ideas being implemented was to give each project person a private office independent of his or her status, and access to computers via individually assigned terminals connected to a LAN. Good ideas. The LAN idea caught on like fire; they had access to the computers from their offices at any time. Unfortunately, economics didn't allow the "individual office for all" idea, not then or now. And we tried; at that time, we knew that when the crunch for spaces hit, that wouldn't hold. Thus, the proposal was made to make the individual offices just big enough according to company policies so as not to allow more than one person. That worked for the project, and folks really enjoyed their privacy while it lasted. Unfortunately, that was one of the change proposals that did not get migrated into the rest of the organization; we were not able to prove the value proposition or to fight the economic pressures.
As a side comment, there was a lot of jealousy from those outside the project because we had private offices, terminals on our desks, and so on. We had to find ways to not aggravate that jealousy by pointing out that we were the "guinea pigs" for something that might not work, and that if we were successful, they would eventually get what we had.
The selection of technologies didn't run that smoothly all the time. And the choice of a commercial versus in-house bus interface unit for our LAN was an issue. There was an in-house product that was immature but being pushed by upper management, which is quite understandable since it was our own product. A careful trade and testing experiment was carried out, but there was a need for plenty of political outreach to convince management that there would be less risk if we went the commercial route. Does that sound familiar?
As we mentioned before, a project was assigned to use the new environment/tools being developed. The LAN idea was very welcomed, but the operating system (we were introducing Unix into a DEC VMS-oriented culture) and some of the new tools were not welcomed by all. To make it harder, the partner pilot project was using the VMS operating system, which already came with a few good automated tools. Also, several personnel in the assigned project complained that Unix on the VAX ran much slower than did the VMS operating system. That was true, but they missed the fact that that was a development environment and that overall productivity was improved because the people were the more valuable resource at that point (they still had the mindset that machine time was more important than people time). Over the course of the project, some became converts, some never did.
What was interesting, however, was to observe how sometimes something very small can have a huge effect on user acceptance. We have two examples to tell, both involving showing the value added in the new automation. The first one was about a secretary who typed most of the documents for the project and dealt with quite a few of the project personnel; many of the documents she typed had many equations for which she had to leave space to type, even if she used an automated word processor. That was both cumbersome and slow for her and her customers. Once she found out that Unix had the "eqn" tool that automated equations, she became a convert and was able to convert many more in her circle of work, including managers and system engineers, who were by then also being converted to use word processors. The other example was a savvy administrative assistant/data manager, who figured out she could automate some of their forms needs using Unix "scripts" as well as providing configuration management with the new tools; her boss was so impressed with the results that he mandated all his staff to use the system/tools. She used her creativity to solve a problem and had an open-minded boss who also dared to mandate (sometimes that is the only way to get some people to change).
Technology adoption has many facets, but we found that, even if the technology is good, sometimes adoption happens only by standardization or mandate. It happened for this project after the tools proved themselves, and it still happens today within the organization. Examples include standardizing on PCs, using Microsoft products, and other examples including SharePoint, eRoom, Livelink, and so on. Management made those decisions and the users just went along with it. On the other hand, where possible, standardizing on interfaces is better, particularly for custom software houses like TRW that have to deliver software and support tools that are compatible with different customers' environments.
Technology acceptance is easier if users are invested in its success. If they are involved from the very beginning and participate in the requirements definition, analysis, and design processes, or if they participate in the review process during its development, they will feel ownership and are more likely to defend and less likely to criticize and/or reject the technology. This was a lesson we learned the hard way. Some team members expected to spend their time developing state-of-the-art research tools, and were somewhat disappointed when users said they wanted simple (for Unix) things like putting change bars in the margin to indicate where the next version of a document had been changed. But they felt a lot better when they saw the positive impact that their amenities had on the project users.
Every project has its lone wolf, who, for reasons unknown to most of the team, appears to not want to be part of the team, lacking bedside manners. We had one of those, an extremely smart and talented person who had no patience for the "normal" people. He was extremely fast and constantly surprised us with his innovation. We remember that he got the Forms Management package to speed up performance by a factor of 4 or 5 because he just dug around into Unix until he found a few obscure interface calls. All that was said to him was that the package was running too slowly for many. He grumbled about how they should appreciate what they had, walked away, and came back two days later, all smiles and with a new version that ran four or five times faster … and we didn't even know that he was working on it.
But his aloofness turned out to be very difficult for many. It bothered the team; we wanted to bring him in, we felt it would really improve team collaboration since he was one of the most knowledgeable in the group. We don't know exactly what caused the change, but one of the members of the team, a smart lady with degrees in both music and computer science and with great wit, became his friend and broke through his glass shell. We think after that, he started trusting and actually enjoying some members of the team. Life in the project became so much better after that. The lesson here is that if people care and take their time, ways can be found to include everyone.
The project started a training program about the operating systems and its many tools. We then noticed that the managers were not coming to the class. Was it lack of time or hesitancy to show their lack of knowledge of the capabilities? We found out that the latter was true for many. As risk mitigation, we started separate classes for managers (which were not that different in content, maybe just a little more high-level) that made them feel more comfortable being within their peer group; once they were more familiar with the technology, they were more prone to use, recommend, or mandate it.
A great lesson learned was to make the SPP use the tools that it was developing. That wasn't done at first, which led to the inability to understand some of the users' needs and which hurt the acceptance process. Once the project started to use the tools, such as the requirement traceability capability, a better understanding of the user community occurred and that led to many improvements to the tools themselves, which then led to better acceptance.
What would we do without email these days? (Actually, the email of yesterday may equate to the Instant Messenger or social networks of today.) We institutionalized email across the projects with the new environment. But of course, that brought about issues, which still apply to date. Email has many benefits: it enables people to communicate or broadcast messages instantaneously to multiple recipients across a great distance, it allows one to leave messages when the recipient is not at his or her desk, and so on. However, it can also incur negative productivity in that, instead of picking up a phone to talk to another person to solve a problem or to discuss some ideas, one defaults automatically to writing an email message. That can waste time on both sides, taking longer for resolution of issues when a short phone call would satisfy. There were many frustrating moments of people not addressing issues posed in an email because they either didn't read their email carefully or they misunderstood the email.
Also, the problem of sending cryptic email can create hurt feelings and misunderstandings. Due to the non-interactive and non-personal nature of email, the "quality" of communication often suffers. Misunderstandings develop and sometimes are not clarified or remedied until significant cost in time and labor is incurred. A side effect of the SPP environment occurred when some people stopped stepping out of their private offices to talk to each other. They sent cryptic email messages rather than popping their head into their neighbor's office to ask a question or discuss an issue. That led to some team issues that had to be solved by an all-hands where management encouraged the team to "talk" to each other rather than defaulting to email as a means of communication.
Also, email is not efficient for assigning action items or important items. One should never assume that the email was read correctly on the other side, if read at all. And sometimes over-reliance on email multiplies the inefficiencies—for example, if "Reply All" is used indiscriminately or accidentally.
The same negative productivity applied to tools like word processors (e.g., LaTeX and others). Whereas being able to type their own documents made this task much faster and great for maintenance purposes, users complained that they ended up spending too much time on the aesthetics (getting the formatting just right), rather than the content of the documents. Because the document generation switched to being prepared by the engineers themselves (except for managers who had secretaries), the cost per hour was ultimately higher and the content suffered because more time was spent on debugging the document format. Of course, the advent of WYSIWYG word processors solved that problem; well, almost.
Led by the projects' needs, a forms management system was created that included many of the fourth/fifth-generation DBMS capabilities of today; those did not exist at that time. It was an excellent system which could have been commercialized, had our company been in the commercial market. That did not happen since we were (and are) a large aerospace company who works mostly on contracts. Keep in mind, as mentioned before, that the team had many young, entrepreneurial, and very creative folks who thrived in the environment being brought about by this innovative project. As a result of the lack of interest in commercialization, a few of those folks left the company, some to try new endeavors, others to work on their own to build tools that could be commercialized.
The Iron Law of Software Maintenance says that for every dollar you put into development, you will have to spend $2 to keep the product viable over its life cycle. The Software Productivity System began as a free service to projects, and it became too hard to switch to having projects pay for its maintenance. Thus, as time went by, the project had fewer and fewer resources to add new features. For example, the forms management system was the world's best system of its kind in 1982; by 1986, it was still the world's best 1982 system of its kind, but had become eclipsed by commercial forms management systems with broader financial and user bases.
Throughout this and many other projects, we identified the need for "champions," that is, people who will adopt and are passionate about the technology, both on the development and the user sides. We all know that sometimes passion can move mountains. And many times, without such champions, the momentum tends to die. However, the life of a "champion" is not always easy; it depends on the need for the technology, the economics, and the goals of the management in charge. Champions are at the heart of change; they need to be nurtured and rewarded.
The reason the project started in the first place was to bring new automated tools into the organization for the purpose of enhancing software engineering productivity. However, we found out that the pace of technology changed very rapidly and had to create means to keep looking toward the future in order to fulfill the goals of the project, to continuously bring in and deploy new technologies (that was before IT took such central places in enterprises). It wasn't (and still isn't) trivial. In parallel with the program, a future-looking activity evolved, and from workstations we moved into bitmap displays, computers at the desktop, and so forth. As this project moved on into other improvement activities, we found out that in-house technology or tools development within the organization was generally short-lived and invariably overtaken by commercial products. Each one of the efforts started with high hopes, made some progress, and caused changes and improvements, but organizations need to be constantly reinventing themselves. Many of those efforts served an excellent purpose in introducing the concepts into the consciousness of the user community and in illustrating the need and the benefits of the technologies, but many of them ultimately lost momentum due to the Iron Law of Software Maintenance and the relatively small user base across which to amortize changes to the custom in-house tools. That is the reason why, in today's world and age, most tools in use come from the commercial world, and those by themselves carry their own challenges of robustness, cost, adaptation to user needs, and evolution.
Both the productivity project manager and the pilot user project manager commented on the ability of electronic communication to flatten traditional management hierarchies. An example comment was, "On my previous project, I was never sure what was happening two levels down, and I always felt that I was too late in responding to project problems. Now that I see a lot of the email traffic, I have more advance warning of problems coming up and a clearer picture of how each part of the project is doing." Also, the fact that all of the artifacts were electronically analyzable meant that we could better identify and fix bottlenecks in such processes as change management and defect closure. A key advantage of the private offices coupled with passionate people was the ability to achieve the state of productive flow emphasized in Tom DeMarco and Tim Lister's Peopleware [6]. As the project went along, a sort of door code emerged. A closed door meant, "I need to concentrate," and an open door meant "Come in and talk." This led to examples such as the following:
Scene: The productivity project office suite, 4:00 p.m.
Steve emerges, saying, "I'm hungry. Anyone ready for lunch?"
Sue responds, "Steve, it's four in the afternoon. You've been in there programming all day."
Steve: "Well, I guess it's true that time passes quickly when you're having fun."