Case Study: New Technology—Is It Always the Best?

Directions

You can read the case study independent of the chapter background, because it will still be useful; however, you might benefit from reading the background material before reading the case study. If you choose to read the case study first, then read through it once quickly in “story-reading mode” just to set some context for the information in the chapter. Then read the chapter material. Finally, reread the case study in an analysis mode.

Case Summary

Description

This case will discuss the decisions a software product manager working for Transport must make regarding using a new technology component for a project. The product manager must make decisions regarding how much additional new technology can be incorporated into a transit component. This new technology involves new techniques for the development group that might require staff training and other issues. The manager must decide whether the benefits outweigh the risks.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Understand examples of product management issues

• Understand that there are different aspects of product management that govern decisions made on the project

• Understand the long-term impact of product and project decisions

• Understand the impact of the development techniques you can use on your own projects

Subjects Covered

Product management, quality issues, product-line development, and change management

Setting

A decision regarding using new technology on a development project is imminent. The decision will determine to some extent how and if new technology can be integrated into future projects and how the new technology will affect the future development efforts for the group and possibly the entire Transport organization. If the new technology effort fails, future use of new technologies will be rejected because this product will be used as an example of what might happen. The key issues behind the decision are how much “new technology” is enough on a project and how to know when you have too much new technology. The manager must keep in mind the key tenants of product management to ensure that the delivered product meets the customers’ expectations in the time needed.

Key Concepts

These are the questions project stakeholders must answer when making product management decisions:

• How much newness can a project take?

• Who is affected by decisions made in development?

• What are the best ways to integrate new technology?

• Who is responsible for change?

Some principles for managing product are the following:

• Product management involves the consideration of long-term issues. The product you deliver today is the product you have to maintain tomorrow.

• Different project stakeholders affect product management in different ways and to different degrees.

Terminology

BFM: Brake feedback monitor.

Greenfield development: Completely new development; interfaces to older systems but internally starting from a clean design.

OO: Object-oriented. This is the use of software structures that model physical structures in the product or system context to implement a new product.

QA: Quality assurance.

Reuse: The idea that software components or features are reusable in future products.

TC: Train control.

The Case

Scenario

The Wabash Project for Transport was an 11-month software development effort. Sal Altery, the software engineering manager, had to make a major decision. A new hardware platform was being proposed by the hardware group to solve the brake feedback requirements on the Wabash transit system. Sal knew that each new hardware component in a system required some 5,000 engineering hours to design, implement, and install the software to run on the new hardware. He had obtained this information by looking at historical data for the last eight years of projects. Sal knew that the new component was being proposed as a product-line component, so that it could be used on other similar projects across existing transit systems.

The Train Control Group in which Sal worked was in charge of both the hardware and the software that provided propulsion to the train. The group was in charge of all the control logic, implemented both in hardware, which initiated braking on the trains, and in software, which directed the motors on the train to start and stop. This included an energy saving/recycling feature in which the motors could be reversed, when the train wanted to stop, to regenerate rather than use power. In effect, this feature involved converting a train’s kinetic energy into power that could be used by other trains in the network. The train system either used brakes to reduce the velocity of the train by friction or put the excess electricity generated from reversing the motors into resistor banks on the train. Have you ever felt a big blast of hot air in a subway station when a train stops at the station? That blast is from the resistor banks as they heat. The new hardware was supposed to help the operator of the train provide just the right amount of braking pressure to stop the train without wasting energy.

Because this new component was an innovative “greenfield” development, it created many opportunities to be considered and required many decisions to be made. Bill Madley, the lead engineer for the Wabash Project, asked whether the new software could be developed using object-oriented (OO) techniques. Until now, all development on projects at Transport had been highly structured. This was probably because Transport originated from a hardware-based background and the people were very familiar with that type of environment. The software had always been “structured” to make the hardware components work. For example, the engineers thought that the software ran on hardware components that did all the work. As technology changed, the software was performing more and more of the logical operations on the hardware components. The decision of what method would be used for development might determine the future success or failure of the Wabash Project as well as the future of this new hardware product, called the brake feedback monitor (BFM).

The Wabash Project had the advantage and disadvantage of working with a new customer for the company. The customer, Facilidades Automaticos de Carril (FAC; a European company), had never worked with Transport before but had great expectations for the product and for what could be done in a train development project. The customer expected that everything would go “very well.” This was a potentially great opportunity with some associated risk. If the customer’s expectations for the product were not met, then Transport could lose a customer, and Sal might get blamed. However, if the product met the customer’s expectations, then this could be “the beginning of a beautiful friendship” (IMDb.com, Casablanca).

FAC was a heavy-industry manufacturer in Spain. Transport had primarily been bidding contracts with a Japanese partner but had decided that it needed another partner as a safety valve. FAC also had production facilities that were closer to the Wabash Project than the Japanese partner was. Crossing the Atlantic would cause a two-day reduction in shipping time for vehicle bodies to the project site. FAC was also more receptive to the idea that new techniques might be used to save money on contracts as well as on future jobs. FAC was a heavily standards-driven group with pride in its ISO certification for quality products.

The person from FAC who was in charge of the Wabash Project was Arturo Llopart, and he visited Transport a number of times during the reviews and during the early phases of the project. He was also the person who expressed the most interest in seeing how things were done at Transport. It was obvious that he wanted to see how well integrated the Transport processes were in product development.

Project Environment

The BFM was considered a safety-critical component. This had a significant impact on the development process. Care had to be taken on how the component was interfaced to other components, and the development process had to be more disciplined than was normally used when developing new components in the group. Sal also had the idea that, since the BFM was a safety-critical component, the project might not only create a new reusable component for the company but also define new practices that could be used for safety-critical development in the future. Safety-critical requirements made the brake feedback component for the Wabash Project highly visible and a critical development in the Train Control (TC) Group. Figure 5-1 shows the Transport organizational chart.

Figure 5-1: Transport organizational chart

Sal had many issues to consider before making his decision on using “new technology” for this new product. Many of the issues affecting the TC group would directly affect the engineering hours spent on the project. With the fact that too many of the recent TC software projects had been running overtime and therefore over budget, this was a serious consideration for Sal. In addition, the issues of object-oriented development would affect the Quality Assurance (QA) group and even the customer, who also participated in code reviews. Using the customer in the reviews was a little odd, but it was in response to previous problems on another project. By involving the customer, the hope was that the customer expectations would be properly set for this product. Sal had to decide whether these outside groups would accept the decisions that he would make regarding the techniques used to develop the BFM.

Sal was concerned with how to make the best decision. He wanted to make sure that the decision he made was the best for the project.

Sal’s boss, Harry Smith, did not have educational background or practical experience in software engineering. Having come up through the hardware ranks, he did not have a positive view of software and did not understand the issues and problems involved in developing software. Sal remembered one conversation where Harry drew a bell-shaped curve on the board and said, “Software development is 40 percent requirements, 20 percent coding, and 40 percent test. What else is there?” (see Figure 5-2).

Figure 5-2: The boss’s view of software development

Sal, on the other hand, had a software background both from his education and from a number of years of practice in the software industry. Sal was finally able to help Harry realize that a significant part of the software development process involves design, but Harry still had his idea that software was “easy.” Sal knew the value of object-oriented development and reusability and thought that the organization’s structured development methodology was creating maintenance issues for the TC group. He could not possibly propose changing the basic software programming languages that were used at Transport, but he might be able to affect the elements of design. The key languages being used in the TC group were C and Assembler code. Most systems had been designed using the Intel 80386 processor, which was soon going to be phased out of production.

Another Problem

As Sal was considering his decision, a serendipitous event occurred that had a bearing on his decision. Harry came and talked to him.

Harry said, “We must make our software more reusable.”

Sal replied, “OK, that will probably require some additional work to set up reuse libraries.”

Harry then stated emphatically, “No! You don’t understand. Just make our current code reusable!”

This was another example of Harry’s simplistic understanding of software; for Sal, it also indicated an opportunity that might help with the decision he had to make. From his past education, Sal knew that the cost for reusable code was about 25 percent more than for regular code. Therefore, if the decision was made to create reusable code, the code needed to be reused to gain the benefit.

Sal continued to weigh the issues for the BFM project. Sal considered that the BFM was only one piece of the Wabash Project. Other controllers and train management functions had to be built and tested for the Wabash system. The TC group was responsible for everything involved with moving and stopping the train. All of the code had to be “embedded” in system ROM, and this created some constraints for the decision Sal had to make.

Project Bidding

Transport bid on projects six months in advance of any work being done on them by the development group. Projects were significant and from start to finish could represent two years of work for the company. The development portion of the project alone could represent payment for 20,000 engineering hours at a loaded cost of $100 dollars per hour. For the Wabash Project, Transport had bid the effort with a new supplier with whom it had never worked. This was unusual for this industry because everyone knew everyone else. It was a small family of suppliers that provided all the components for the transit systems across the world. Occasionally, the primary contractors would change as some new country would try to get into the industry. This was the case on this project.

What Sal Knew

Sal was responsible for six projects at the time he was considering his decision for Wabash (see Figure 5-3). Sal had initiated an effort for general software process improvement on some of the projects about three months earlier. This effort had begun after Sal had been with the company for about six months. The Wabash Project had been selected to try one of the new techniques for software development improvement. The project had been slated to use software code reviews on all software produced for the project. Sal had decided to use this technique to improve the quality of the products that the TC group was producing. In reality, Sal had a hidden reason, which was that he did not want the senior engineers in the TC group to have to keep fixing defective products in the field on older projects. It appeared to Sal that defects might be keeping engineers from completing their new projects on time.

Figure 5-3: Rail Systems Group organizational chart

One of the critical considerations for Sal on the project was that a new BFM algorithm would need to be validated to determine whether it was going to be safe. Assigned to the project was one of the newer engineers in the company, Tom Smiley, and the lead engineer from the Wabash Project, Bill Madley. The designation as a safety-critical device made the BFM a component that had to be isolated from all other parts of the system. Safety-critical devices have a tendency to make the software embedded in them as well as other components that communicate with them safety critical simply because of association or contact. This created a mind-set of minimizing exposure to this “new” component.

Tom Smiley was a mathematician, and he was intrigued by the required BFM algorithm. The original design for the BFM algorithm required seven inputs. Usually for an embedded system, each input to a hardware-based system represents a wire connected to the component. The software group was proposing a new algorithm that could be tested in the new BFM, and it required only three inputs. Reducing the number of inputs would incur a cost savings for the company and simplify the configuration for the Wabash system. These advantages all depended on getting the new algorithm to work with the inputs provided by the Wabash hardware engineers.

To test the waters for the new object-oriented development concept, Sal identified the person in the QA group who would be supporting the Wabash Project. Albert Quinn would be heading up the QA efforts of the Wabash Project, so Sal decided to take him to lunch to float the idea of object-oriented development.

Sal inquired, “Albert, have you heard about object-oriented programming?”

Albert replied with a sigh, “Yes, I wish we had time to learn it, but we don’t have time to learn anything new. Besides, my manager never wants to pay for training.”

Sal then asked, “Have you ever thought about anyone using it at work?”

Albert explained, “It would never happen. Management is too stuck in its ways. They are all hardware guys, you know.”

The conversation set the parameters, from the QA group’s point of view, of what would be minimally needed to do an object-oriented development project. They need training and approval from a higher level of management for object-oriented development to be allowed.

The last factor in the decision was the customer. With a new customer on the project, management clearly wanted to have this Wabash Project hit its scheduled dates. Management always had the philosophy, “If you take care of the schedule, the budget will take care of itself.” The customer would have to be receptive to the idea of object-oriented development for this to be a consideration for this project. The maintenance, monitoring, and verification of the system by the customer meant that the customer must be able to read and understand the code. Using object-oriented coding techniques would help with future projects by making reuse easier but might make this project more difficult to manage.

Attitude . . . Attitude . . . Attitude

There had been efforts in the past to try to make the structured code base used by the development group more reusable, but these efforts had not succeeded. These efforts failed because of the attitude at Transport that software was simple (shown in Harry’s comment “Just do it” when talking to Sal about reusable code). Sal wanted this effort to succeed and to be done so that the code would be reusable, but he needed to convince all the parties involved, including the customer, that it was the right thing to do.

Sal therefore was actually thinking about a number of new technologies and efforts for the Wabash Project. They were considering a new algorithm, a new development approach and programming language, new techniques for the QA group, and a new interaction with the customer. From everything Sal had been taught, creating too many “new things” for a project was always a big risk. Many projects had died on the “bleeding edge,” and Sal did not want his project to be one of them. Sal was confident about the new development approach and programming language because, though new for his company, they were well understood and used successfully by the software industry.

Sal wrote down a set of issues so that he could clearly understand the decisions he had to make:

• He has to get his engineers training in OO.

• QA needs to read and understand the code during the testing phase, especially for the safety-critical code.

• Customer involvement in code reviews means the customer needs to understand the OO methodology used.

• Compliance with standards would be difficult since there were none set for the company in OO methodology.

It just so happened that a project review for the Wabash Project was going to be conducted. All interested parties would be present, and this might offer an opportunity to field the idea of object-oriented development for this new and exciting component called the BFM. Sal talked over the issues with the lead engineer, Bill Madley, and they discussed how the idea could be addressed. Since Sal was a graduate of a software engineering program, he knew that the analysis of requirements could be represented in a number of ways. Some ways contribute to OO, while others contribute to structured views. The decision was made to represent the analysis for the BFM component using an object-oriented technique because Sal knew this would not significantly impact a structured development if they decided not to pursue OO, while it would enhance the use of an OO approach.

Looking for dual-use methodologies was a standard that Sal had been pursuing in projects since he was hired as a development manager. Sal even had to provide the engineers in his group with books on how to do OO analysis, design, and development in C. This was again a hedge against critics if C++ was not portable to the new hardware configurations. At this time, an effective real-time C++ was not available, so C was the language of choice and was well entrenched at Transport.

During the review, the customer asked about the different representations the Wabash Project had used. In particular, the customer indicated a preference for the OO analysis format used on the BFM, rather than for the more structured “flow-chart-like” format. The Wabash Project customer said during the review, “Your diagram showing the object that does the operations on the BFM helped us understand the need for very clean signals and straight paths on the links to the monitor.”

Sal’s boss asked to meet with him after the Wabash Project meeting. Harry’s comment was, “Good job on the presentation, but we need to talk about the BFM.”

The time to make a decision on the Wabash Project development methodology had come. Sal thought he understood enough about the product to make this critical decision. He would now have to convince Harry that the BFM idea was based on his idea regarding reusable code. Sal was prepared to handle the questions he knew that Harry would ask, at least most of them.

Case Problem

The case study has a number of problems in addition to the main one concerning the use of a new technology in developing a product for the company. There were transition problems between the development and quality groups and trust issues that had to be managed. Chapter 8, “Managing People Interactions,” can shed more light on these issues.

The expectations of both the internal and external customers had to be properly managed, or the project could fall apart. Pitting one group against another group works only for so long before the issue impacts the development of the product. Managing an evolving product is always challenging in a software development environment. You might also look at how the relationship between the people on the project might interfere with the proper management of the product.

Case Analysis

Analysis Activity

Analysis Background

First Case Problem

(P) Problem: Sal has to decide whether he will use new OO development techniques on the BFM project.

(E) Experience: The BFM is already a new piece of hardware that Sal knows will take some 5,000 engineering hours to develop and install the software to run on the new hardware.

(A) Assumptions: The BFM will be ready on time, and the only issue Sal’s group will have to worry about is getting the software operational on the new board.

(K) Knowledge: Using OO development techniques would imply less risk because these techniques are well understood in the industry.

Solution: Develop the new BFM software using OO techniques.

Assumed Risk:

• The hours might exceed the 5,000 hours allocated for the job.

• The project team, the QA team, and the customer are not in practice able to adopt OO technologies seamlessly and on time.

Second Case Problem

(P) Problem: Sal has to decide whether they should be updating the algorithm while building the BFM to cost the company less for future brake modules.

(E) Experience: The BFM is already a new piece of hardware that Sal knows will take some 5,000 engineering hours to develop and install the software to run on the new hardware.

(A) Assumptions: The BFM will be ready on time, and the only issue Sal’s group will have to worry about is getting the new algorithm operational on the board.

(K) Knowledge: The mathematician can solve the algorithm reduction problem from seven inputs to three. Solving this problem should imply a simplified and well-understand algorithm, which means simpler code to understand in the final product.

Solution: Use the new algorithm on the new BFM board, and make the product even more attractive by reducing costs.

Assumed Risk:

• The project team does not find a solution to the input problem associated with the BFM algorithm.

• The configuration of the system cannot in practice be modified to minimize the cost by using three inputs versus the seven inputs that were required for the old algorithm.

Analysis Questions

1. What decision would you make as the project manager?

2. What issues of product management do you think Sal needs to handle to ensure the success of the Wabash Project?

3. Do you think that Sal really does understand the problem thoroughly and is ready to make the decision? If not, what else might he need to know to help him with the decision he has to make?

4. Is the issue with OO development the real decision that has to be made?

Results

The BFM was built using OO development techniques. The new standards established for reviews during the development process made this possible and allowed the QA group enough understanding of the process that it was able to conduct significant testing on the BFM prior to its successful implementation on the Wabash Project. The most significant event for the Wabash Project was the revolt by the engineers when they were asked whether they wanted to stop reviews to speed up delivery. Their unanimous answer was no. They agreed that the only way the team would make the scheduled delivery date was by continuing reviews. The team knew the quality they were producing on the code was keeping them on schedule. The final product delivered on the Wabash Project had only minor defects that could be attributed to the software from the TC group. A number of defects were found, but all were quickly shown to be from other components in the system.

Discussion

As you can see from the results, the product was successful. Not only was the product delivered as expected, but the processes used were integrated as standard practices for the teams to ensure product quality. The normal testing time for a new development in the test lab was one to three months. The new Wabash system took only three weeks to clear testing in the lab. The team was able to use the new techniques to develop the software as expected. But what can also be seen is that Sal had to do some product development analysis prior to making the final decision. Sal also had to involve the key stakeholders in the effort to ensure that everyone was receptive to the idea of the new development technique.

There were many problems to overcome even after the decision was made. Training the engineers to use OO techniques in conjunction with a non-OO programming language was probably the most difficult. New concepts such as OO can help in understanding and developing reusable components, but the environment, such as embedded systems for trains, might preclude the actual use of OO languages. OO concepts existed before OO languages, and on this project they were used even though an OO language was not available for the embedded development. It required the use of “brown-bag lunch” training and many lectures by the lead engineer Bill Madley who explained key concepts.

The other issue was that there were many other ongoing environment issues (a new customer, a new process improvement effort, and new engineers coming into the company) that had to be handled. This created opportunities and problematic conditions that had to be dealt with to ensure that the product was properly managed and delivered to the customer. As you can see from the case study, the customer was interested not only in the product but also in the product production process.

Product management begins with the development of the product and continues with the transition of the product to the customer. In this case, Sal used code reviews with the customer as a way to help with the final product transition. The new customer on the Wabash Project gave Transport the opportunity to try new techniques and appear competent in what they were doing.

Conclusions

You must recognize the decisions associated with the product when they come into your projects. These product decisions normally surround the quality issue of the project but can also be tightly coupled with the process decisions you make to support a development effort. Sal had the advantage of an education in software engineering. We hope this case study has given you the ability to recognize product decisions when they are needed as well as provided you with the understanding to get the information you need to use PEAK to make a product decision to support your project.

Key Ideas to Remember

The key idea here is that each product decision you make will impact the product. If these are not managed, then you are not managing the product. Product management in software development involves not only the final product being built but also how the product being built is represented to the customer and all stakeholders.

Case Study: Why Is This Product Wrong?

Directions

Read this case study after reading the chapter material. Look at how you might think you have all the information you need but some critical aspect is missed that directly affects the usability of the product.

Case Summary

Description

A developer is pondering how his company got the product wrong after having done everything right, at least from his perspective. He is wondering where things went off track and why he couldn’t deliver a customer’s product on time, on schedule, on budget, and in a way that meets all the customer’s needs.

This case study will present the idea that although things appear to be “easy” in the product definition, this doesn’t always mean that you will get them correct. There are hidden assumptions, issues, and expectations that, if not properly understood, will lead to poor product management decisions and possibly project failure. This case study illustrates that the failure of the product was set by the very first decision that was made for the Three-Tech phone search product. By the time the developer is brought on to the project, decisions have been made that have a lasting impact on the final product and that may not be recoverable.

Case Study Objectives

After reading the case study, you will be able to do the following:

• See how decisions made early in the life of a product can have a dramatic impact on the product management to be done later

• Understand how various product management decisions affect the product and why

• Understand that scope and time are not all that matters

• Show that early bad decisions can create poor customer expectations

Subjects Covered

Product versus process issues, what makes a good product in the eyes of a customer, quality attributes, and perceptions of product

Setting

The case study occurs in a garage with a start-up company that always wants to take shortcuts. “You can figure it out” and “Doing things for fun” are common phrases that usually present risks in a project. The environment is a small project. But the case product is interesting and has enough technical challenge to leave you saying, “I could have made that mistake.” The case study should help you see that a dumb question is simply one that is not asked. The product is managed correctly, but the influences of the environment determine the project’s success or failure.

The Case

Scenario

Three-Tech is a consulting company that was in its customer-building phase. The CEO, John Smith, was on the East Coast of the United States with most of the administrative offices, while most of his development team was on the West Coast. Fred Moresay had been hired by John and sent to training on how to build software for phone switches. The other developer on the West Coast was Tom Billings. Tom was a hardware guy and knew how to get systems to work. He had run his own small company but was essentially “doing this job for fun.” Tom was more of a systems engineer than purely a hardware engineer, and he thought software was “foo-foo,” although he did know what it was supposed to do. Tom was like the professor on Gilligan’s Island; he could make a satellite reflector out of coat hangers, but if it had software, he wanted someone else to do that part.

Fred had gone to work for this small company called Three-Tech after leaving his old job in a large government organization where he had worked for more than ten years. While working for Three-Tech, Fred found that the projects were smaller in scope than those he had handled in his old job, but they appeared to offer some interesting opportunities to learn new technologies. The pay was better than that for the old job, and one of the nice things was he got to work from home. He remembered waking up one day and telling his wife Ann that he was off to work. Fred put on his slippers, got a cup of coffee, went to the desk on the other side of the room, and sat down. He logged in and was at work.

Project Activation

On January 25, 1999, the day began for Fred with a phone call from John:

John started the conversation by saying, “Fred, I have a project for you. Maybe I can get my money’s worth out of that training I provided you.”

Fred replied with a laugh, “Sure . . . what is it?”

John stated in a matter-of-fact way, “The project is a phone switch answering service with automated menu selection and advertisement playback. You have two months to deliver it.”

Fred replied, “Sounds interesting. Are there requirements for the software?”

John abruptly answered, “Call Tom. He got all the details from the company while you were at training. He is already getting some of the parts for the system. Let me know if you need anything.” <click>

When the hour became decent, Fred called Tom who lived about three miles away, and they made arrangements to meet on the new phone lookup project that afternoon.

Team Initiation

Fred drove to Tom’s house in the hills near San Diego. It was a typical California day, and he was eager to get all the details of the new project. The first meeting went something like this:

After briefly explaining what he knew about the new project, Tom concluded, “Well, it looks pretty straightforward, as long as you can make the software work.”

Fred replied, “Thanks, Tom. Do we understand the requirements? Are they written down?”

Tom did not answer Fred’s question but said, “I talked to the customer, and they want to have someone call an 800 number service. The customer is then given a basic list of restaurants. The list is broken down into categories by cuisine such as Mexican, Italian, American, and so on. The users can then go through a category menu and try to locate restaurants that interest them.”

Fred then asked, “Sounds neat, but who is going to enter all the restaurant information?”

Tom answered, “The customer has some ideas about this. We just have to provide them with a format that they can use.”

Fred did not say anything for a while and then quizzically replied, “Hmmmmmmm.”

From Tom’s description, the product seemed straightforward, but of course, from Fred’s point of view, there appeared to be a few holes that still needed to be filled. In general, any time Fred heard the phrase “The customer has some ideas,” the hairs on the back of his neck stood up. Tom was not a software person; he was a hardware guy who put systems together. From Tom’s point of view, all they had to do was to install a new phone switch server and create the database to provide information to a user who accessed the server. Tom always felt that software was “easy.” Then the system would have to allow the user to navigate through a menu of options as specified by the customer. The menus had to be simple, intuitive, and easy to use. Fred was a little concerned, especially about the format of the menu, but the overall product seemed simple enough.

Fred had been sent to school to learn how to set up the phone system. Fred and Tom quickly experimented to create a server that basically could answer the phone with the new phone switch hardware. They tested the system online and used Fred’s cell phone to call Tom’s home phone and test the basic switch. It seemed that this part of the product was going to be easy. Next, the server was set up to turn control over to the software, which Fred would program to do what the customer wanted. The phone switch server and the interface software were implemented as commercial, off-the-shelf software that had to be integrated to function together. Most of this work was done in Tom’s living room.

Fred took a copy of all the software to create a duplicate server in his home environment so that they had two systems with which to test software and to get the system operational.

The option selection software Fred was supposed to use consisted primarily of a database that also appeared to be simple; after a few experiments, the basic system was in place. The project had been scheduled for two months; after the experiments, the schedule appeared as though it would not be an issue for Tom and Fred. There were still some requirements that were a little unclear, but everything was on schedule or a little ahead of schedule.

Problems Appear

The first problem came when the customer asked whether the information that was played back to the user could come from the database. In other words, could the database feed the sound system of the phone server? The problem was to find a format for the audio data that could be stored in the database and used without conversion by the phone switch. After some questions to the switch company and some more experiments, Fred and Tom found an audio file format that could be stored in the database and used by the phone switch. Prior to this, text-to-voice information was all that was supported by the phone switch. This is the normal type of information that phone switches use when “passing a call to Phil in accounting.” However, this “suitable” format would result in some consequences later in the project.

Some sample files were created using a simple recording technique, and the entire system was ready for a demo. The issue of who could provide the data for the database and the audio files came up, but the customer had an idea and said he would take care of it.

As it turned out, the database that pleased the customer was Microsoft Access. The system was installed at the customer site two days ahead of schedule. Fred and Tom decided that this would give them a buffer if something went wrong. The system worked perfectly when activated, no defects appeared in the code, and the customer loved some of the added features that had been provided.

Then a major issue appeared. The customer asked what other audio file formats the phone system could accept. This put the development team back into the search mode. The team was forced to research what formats were available to play messages to users on the phone system. There were compatibility issues with the database and with the phone system’s ability to digitize and convert the information for the switch. This all resulted in a phone call to the phone switch company and Phone Switch Customer Service (PSCS):

The PSCS representative asked, “What are you guys trying to do with this system?”

Fred explained, “Well, the customer says the sound does not have the ‘fidelity’ he wants.”

The PSCS representative replied, “Well, I’m sorry, but as of right now, the only audio format we accept is 8-bit format. Most people just want to record a short message such as, ‘Hi this is Julie, leave your message.’ It sounds like you need more than this.”

Fred then asked, “Maybe. Are there any options we can buy?”

PSCS regretfully replied, “My boss says development might be interested in the task, but he doesn’t know of anything else. The person to contact in development is . . . .”

The answer was none. The famous story about Henry Ford selling the Model T came to Fred’s mind: “You can have it in any color you want, as long as it is black.”

The issue was that the customer wanted to use commercial-quality sound files on the system. The minimum bit storage requirement was 16-bit data, but when the files were converted to the format that the phone system needed, the greater fidelity of the commercial recordings was lost because the data was changed to 8-bit. The customer said this made the files that were called up sound “tinny.”

There appeared to be no fast technical or other solution to the problem with the system being used. Three-Tech could ask the switch provider to enhance the system, but the cost would be prohibitive and would make the system one of a kind. This was not very attractive to the customer, who was already starting to think that he did not want to “throw good money after bad.”

From Three-Tech’s point of view, it had delivered the system on time, on schedule, and with everything that the customer wanted. The customer viewed the system as if it didn’t work. Fred thought about how to avoid this problem in the future. He asked himself, “What were the mistakes?” This project was a nightmare. How could the product not be acceptable when it did what was agreed on?

The next day started with a phone call from Fred’s boss, John. Fred was thinking that many people have a tendency to measure the quality of their product by the presence or absence of calls from upset customers. Software has the ability to bring out the worst in people. There is always the view that it should be easy to develop a product that involves only software. His boss was asking how things were going with the phone switch project.

Case Problem

Will the product satisfy the information needs of the customer?

Case Analysis

Analysis Activity

Analysis Questions

1. What are the major issues that are affecting the product?

2. What would you have done differently if you were in the developer’s place?

3. What key issues about product management did the developer fail to consider when dealing with the product?

4. What were the decisions that Fred had to make?

• What are the PEAK inputs for these decisions?

• What are the alternative solutions and assumed risks associated with these solutions?

Key Ideas to Remember

The product is more than just the set of functions that the customer says they want the product to do; it is greatly influenced by how the functions do their job. The quality with which the functions are delivered determines whether the product meets or exceeds the customers’ expectations. When you look only at the requirements as a set of functions that must be accomplished with no care of the quality with which they perform the functions, you have an infinite number of choices of what you can do. However, when you must consider the quality with which the functions are delivered, you are left with only a few solutions that will deliver the correct product.

In software, since you deliver something that is not very tangible, that is, a disk or a download of electronic bits, the idea of quality is paramount and highly integrated with the product. Early requirements were met with decisions that later impacted the final product being delivered. You must manage the product by managing the quality that goes into the product. The quality is directly measured by the requirements used to establish the product being delivered.