Read the case studyYou work for a small company that builds high$-$end consumer electronic packages for niche customers.

A recent project in the company failed miserably$$an electronic assembly being delivered to an

automotive manufacturer has numerous issues. The assembly is for the user interface in the center

console of the automobile to control the radio, temperature, navigation and phone synchronization.

When the package was put into service, numerous software bugs caused the software to crash and

reboot, causing outages for several minutes. Additionally, user feedback was generally not positive

regarding the interface design. Primarily, it was too slow and there was a noticeable delay between a

button push and a response from the system. Hardware issues were found that occasionally caused the

system to fail altogether and require a new unit to be installed. These hardware failures were an order

of magnitude more common than expected. Additionally, the remove and replace performed at the

dealership was significantly more complicated than expected, leading to high maintenance costs. The

project was seven months behind schedule and delivered lower performance than expected by the

customer. The customer decided to terminate the contract with your company, leading to millions of

dollars in lost revenue.

You are one of the few trained systems engineers on staff at your company. The CTO has asked you to

perform a postmortem on the project to determine the causes of these issues and to make

recommendations on how to avoid these problems on future projects. She doesn$$t feel like the

company can withstand another failed project like this without going out of business$$therefore$,$ she is

willing to make substantial changes to the engineering process if necessary.

You start by having a meeting with the Program Manager and Chief Engineer for the project. Your

discussion with the two of them is enlightening. The PM tells you the project was doomed from the

start. When the company was bidding on the project, they were desperate to win the contract and get a

foot in the door in the automotive market. As a result, they included too many features in their offering

for the price and the schedule was dramatically compressed to meet the time to market requirement.

To achieve this schedule compression, they dramatically cut the planned requirements gathering time

and the planned integration time. The chief engineer felt that the team was not adequately staffed to

execute the project. Due to the price cuts in the proposal, the experience level of the technical staff

were reduced in order to keep the engineering costs down. Formal milestone reviews were tailored out

of the process in order to streamline the development activities. They organized the team around the

four primary system functions as well as the hardware. The top level of the Work Breakdown Structure

$($WBS$)$ was structured the same way at the top two levels. The organization is shown in Figure $1.$

Figure $1.$ Technical Organization

Reviewing the project documentation provided by the Chief Engineer causes you some concern. There

was no Concept of Operations or top$-$level requirements document. Each of the primary functions

$($navigation$,$ phone interface, etc.$)$ had an associated specification. There was also a specification for the

hardware. You are unable to find an Interface Control Document $($ICD$).$ Looking at the test logs for the

formal test effort, the subsystem requirements were tested in detail $($every requirement verified$).$

However, at the system level, test procedures were developed to test high level functions $($change the

radio station, turn on defrost, etc.$),$ but the procedures didn$$t appear to map to any requirements.

You then spoke to the design teams. None of the design teams had a good appreciation for the depth of

the technical issues that occurred during fielding. They seemed to be comfortable with their part in the

project$$they met their requirements, after all. Looking at the Navigation Team$$s documentation, you

notice something alarming. The specification the Navigation Team used for development did not match

the specification you saw previously. Requirements in the Navigation Team$$s specification did not exist

in the requirements the Chief Engineer provided. They actually had a handful of requirements in their

specification that were completely omitted from the specification the Chief Engineer provided. You

called the Chief Engineer and confirmed the specification he gave you was the most current. You asked

the Navigation Team about the discrepancy and they told you the customer has requested those

features, so they added them to the specification. It didn$$t impact any other team, so they didn$$t bother

communicating the changes.

The hardware team was frustrated with the whole project. The hardware design kept changing due to

updated requirements from the customer. The hardware changes led to several workarounds being

developFigure $1.$ Technical Organization