What is it? Is it a cell phone? A message pad? A computer? A camera? It's all of the above. But who needs it? And why? Marketers tell us we need it. Kids seem to want it. Is this complexity elegantly packaged or complexity run amuck?
Today's devices and software have become so complex that they almost defy testing. By the time all of the bugs seem to be eradicated, we're blessed with a new version we have to partially test in the field. Aren't you glad that aircraft systems are more rigorously tested? (If they're not, please don't tell me.)
Martin Stoehr assures us that greater complexity in the design world is a trend that won't change. Consumers want more in what they buy. Manufacturers are always looking for more integration. And, this pressure is directly related to the complexity of future projects. What are the best ways of managing complexity? Think manageable pieces, reuse, and design teams. In fact, when working with customers and marketers, Douglass George suggests asking "do we really need this?"
Keep the customer in mind. Jaynes says that when it comes to medical lasers, most doctors don't want a product that "sort of" can do 25 things. They want a product that does five things very well, is easy to use, and doesn't have downtime. Developing new products based on customer communication and needs ensures that products will fit the customers' applications.
Frank Van Hooft suggests creating a common, flexible, programmable platform and building upon it. "This allows us to quickly release a basic product, get it into the marketplace, and gain revenue. Then we can incrementally add features, charging higher prices for those models."
"It's almost like a product 'evolution' as compared to the 'big bang' development (everything in the first release)," he continues. "Given the size and complexity of the final product, doing the big-bang development would take too long, cost too much, and be too risky. So we do a staged rollout."
Similarly, Shawlee suggests breaking every complex project down to its manageable components and working on each. He recommends solving what can be solved and seeing how each solution leads to the next step. Every project has a step in the flow chart that seems to require a small miracle. Filling in that step often calls for wide-ranging knowledge of issues not related to engineering. Often, the best solutions come from people who see the issues in a fresh way.
It's important to understand that every project really involves two disciplines: design and engineering. Design is the underlying concept, which may never have existed before. Engineering is the translation of that concept into reality. It takes both kinds of thinkers to bring a new product to life.
Dan from the data-acquisition company suggests targeting products toward specific markets rather than general markets. This enables a company to "spin" a product to do what is needed in one industry and then spin it again for another. Specific industry products are simpler to create and also simpler for customers to use since they don't need to navigate a lot of unnecessary features they don't care about.
Odell has a helpful hint. "We design and deploy large and complex systems as well-defined subsystems," he says. "We invest significant effort in maintaining abstraction between the layers or subsystems, whether they be hardware, software, firmware, or 'vapor-ware.' "