Software has stealthily become a common denominator in manufacturing, creeping into nearly every product sold today. Examples abound: From toasters to car keys, and even to Legos, more and more unlikely products contain software. Every new car now contains as many as 100 microprocessors, each of which is driven by software. Nearly half the cost of developing a new jet fighter goes to the plane’s software. Siemens, the German electronics firm, employs 47,000 software developers — which is even more than Microsoft does.
Software may make the world go round, but it can trip up traditional manufacturers as they struggle to integrate software development into their operations. The costs of getting the software component of product development wrong are staggering: Software errors, according to a 2002 study by the National Institute of Standards, cost the U.S. economy close to $60 billion annually. Automakers alone faced more than 30 software-related product recalls between 1998 and 2003. In the past, the most common field call for elevator makers was to fix door malfunctions, and for copier makers it was to deal with paper handling; today the number one cause of field calls for each is software problems.
Are such errors just a part of doing business, or can something be done to eradicate them? Although most manufacturers have adopted best practices, such as Six Sigma, for developing the core parts of their product to high standards of quality and efficiency, they often don’t extend those practices to their software development. Frequently, the software components are an afterthought in the process. As such, too many companies insufficiently manage their software-development efforts. This adds massive complexity to their product development, which in turn leads to poor product quality and escalating costs.
The problems begin when companies don’t fully understand the needs of their new product’s target customer; with the overall product specs left loosely defined, the software requirements intended to meet those needs are even fuzzier. That gap leads to expensive inefficiency, with companies developing the software to run new features as one-off assignments rather than as part of a comprehensive and clearly defined development plan. Moreover, without a clear understanding of customer requirements, many of these efforts simply aren’t worth pursuing. Poor planning then cascades into the development and testing phases. Because manufacturers haven’t developed a cohesive strategy with accompanying contingency plans, they often have difficulty determining how to proceed when components fail. Worst of all, there’s no one to hold accountable. Throughout this process, a lack of communication is endemic.
These problems can’t be solved without a wholesale change of the manufacturing process. Senior technology leaders within manufacturing companies must acknowledge the critical role of their software operations and take a measured approach to development and integration with other business and manufacturing processes. That strategy involves:
putting a rigorous product life-cycle management (PLM) process in place
identifying and implementing accurate metrics for measuring improvements in the development process
finding ways to reduce complexity
Following such an approach can yield a variety of benefits, including faster time to market, reduced development costs, and increased competitive advantage, in addition to improved software quality.
Implement a Process
Guessing which features customers might want and using that conjecture to design and manufacture products as quickly as possible is no way to develop software. From idea to development to testing, software developers need to establish a disciplined PLM process that ensures developers can repeat certain steps every time. A PLM process also improves collaboration, getting everyone involved on the same page regarding the appropriate process, and creates a clear niche for software development within the larger context of product development and launch.
The first step in a PLM process should be to conduct market research. This allows developers to prioritize customers’ desires, determine which product features should be developed first, and institute a series of development tollgates. The first tollgate should allow only ideas with a sound business rationale to pass through. The second gate should be passed only when the engineers have put the project through a high-level technical feasibility study and senior staff agrees that it is a high priority. This gate should be controlled by a project portfolio board consisting of a cross-functional group of senior managers.
Second, set priorities. Well-planned schedules can actually increase the number of projects that get out the door, without requiring additional resources. This stage involves another tollgate, where implementation plans are reviewed. If the plans have shifted dramatically since passing through the prior gate, they should be sent back to the senior staff at the second tollgate for more review. Project requirements and the major elements of the architecture must be frozen to keep new ideas and shifting company priorities from stalling progress.
Throughout the process, there must be accountability at every stage. Senior managers must become a visible part of the process, execution managers must be responsible for moving the project along according to schedule, and dedicated project managers must coordinate the effort and resolve the inevitable glitches that arise between silos in the course of development.
Measure Twice, Cut Once
The use of metrics — early-warning metrics, in-development process metrics, and launch metrics to gauge a product’s progress — are critical to the process of successfully developing software and integrating it into products. Tools are available for every aspect of the software development process: product life cycle and portfolio management across the enterprise; ongoing business-case management; project and resource management; workflow and cross-department collaboration; and integrated enterprise-wide product-data management. And they can produce the metrics necessary to increase the transparency of the software development process, improving efficiency and quality.
Avoid Feature Creep
Finally, software developers must take the cost of complexity into account as they make decisions about product features. Companies often add features to their products without analyzing whether those features offer enough value. “Feature creep” tends to occur because companies believe that it’s cheap or free to insert additional features without ever considering that more complex products are more difficult to use, install, and support, and are more prone to quality problems. Software developers should use their knowledge of the market to anticipate future trends and gain a better insight, from the user’s perspective, of the value of new features.
Product developers can use customer-segmentation techniques to develop products that customers truly appreciate. By creating separate products with distinct value propositions, rather than loading all of their bells and whistles into one product, manufacturers can better manage complexity.
The important result of a measured approach to software development is a viable product, but an enduring byproduct may be that, in a company with strong software-development processes, everyone involved learns to think and act more as a group. Clarifying roles and responsibilities and ensuring accountability can draw a company closer together, much as designated positions and plays are critical to molding a group of athletes on a field into a successful team. Successful software is created when good business decisions are made, and good business decisions are almost always the result of a process that encourages communication and understanding among all the players in the process.
Ultimately, maintaining quality in software is similar to maintaining quality in any other product: It’s largely a matter of cultivating an organization’s ability to look at its own processes with some critical detachment. It requires the organization to become organized enough that its leaders can step back and see where future improvements in design can be made.
Barry Jaruzelski (firstname.lastname@example.org), a vice president with Booz Allen Hamilton in New York, is the firm’s lead marketing officer. He concentrates on corporate strategy, organizational transformation, and time-to-market improvement for companies in high-technology industries and manufacturers of highly engineered products.
Michael Busch (email@example.com) is a vice president with Booz Allen Hamilton based in New York. He helps executive teams of technology providers design growth strategies, develop market entry and channel strategies for high-potential segments, establish market-driven product development processes, and execute profit improvement programs.
Jay Kumar (firstname.lastname@example.org) is a principal with Booz Allen Hamilton based in New York. He specializes in transformation efforts and improving marketing organization effectiveness in technology and medical products companies.