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.