“Velocity” has been a mantra of IT in engineering for years. Cambashi Managing Director Peter Thorne says the pressure points of product development can be relieved with an informed mix of speed and delay.

Delay is usually associated with confusion, uncertainty, procrastination, lack of clear responsibility, and error. So it is hardly surprising that we all work to eliminate delay from our professional lives. Business gurus over the years have often emphasized ‘speed’ as a key contributor to the effectiveness and results of an enterprise.

But it’s not as simple as ‘speed good, delay bad’. For example, “Just-in-Time” can be a very good thing—don’t start too early, don’t tie up working capital. In this case, higher speed in execution enables deliberate delay to the start of an activity—and you still deliver on time.

Another example can be found in production and supply chain management. Here, “postponement” is a well established strategy with a simple concept—make the basic article now (the platform), but add the finishing touches (options, flavor, country-specific configurations such as label or power cord, etc.) as late as possible. The result is more flexibility with less capital tied up in completed products that are unsold.

However, the ‘right sort of delay’ I’d like to look at in this article is delay where the core purpose is to keep design options open. What type of ‘speed’ will help design engineers delay decisions and achieve better results?

Don’t make a decision yet!
In design, the ability to delay a decision can have positive effects. More time means more information to support the decision, and in theory and often in practice, more information increases the chance that the decision will be optimum.

This chance to create better designs comes at a cost. Making a choice now allows the design team to focus on just the design options that match the decision. Delaying the choice makes it necessary to keep a larger range of possible designs in play, and this makes things more complicated. Managing this trade-off has always been part of the art of design engineering. Make relevant decisions in the right order. Allow a project to backtrack when someone sees a better way forward. Divide the design into functional or technology or spacedefined units to maximize design freedom within each unit. Apply just the right number of standards, design rules and reviews to ensure design integrity and consistency.

Of course, this trade off is something that experienced and skillful designers handle instinctively. A chess-playing algorithm prunes the tree of possible future moves in a way that reduces the range of possible futures to consider, yet ensures the ‘best’ moves stay in consideration. Similarly, a designer will instinctively make decisions that keep the right subset of options open.

But the team needs a decision!
Things that work for individuals may not scale to a geographically distributed team comprising many individuals. In this case, the instinctive and continuous juggling of a sequence of decisions is an ability that decays rapidly with size of team. So, where the complexity or scale of a design project means that many people must cooperate and coordinate their work, it becomes increasingly costly and difficult to delay decisions.

The ‘divide-and-conquer’ approach to problem solving tends to allow a large project team to be structured, and to function, as a connected and perhaps integrated set of smaller teams. Though the scope of each team is reduced, the fact that they are solving a more constrained set of requirements makes it more possible to delay decision making and keep options open.

But what about information technology? Study more options and still make the decision on time!
The goal is to allow each individual or team to remain productive even when there are more live options in a design. In design, the ‘single-version-of-the-truth’ that is needed to coordinate a team is a complex ‘truth’. It must contain all the options that are being considered. This is unlike most other areas of the business, where the ‘truth’ required can be a number, or the current version of a document.

Consider the key moment-of-truth that occurs as a design engineer is deciding what to do about an idea they’ve had. The idea may relate to:

• requirements, and/or to
• the alternative sets of capabilities (or functions) that fulfill the requirements, and/or to
• the many and diverse possible solutions and technologies that could implement these capabilities.

Whichever type of information best matches the center-of-gravity of the new idea, the engineer will need to think about all three types of information. It will be necessary to find the relevant context for the new idea, then review related material and consider how the new idea might impact existing and perhaps future work.

These three types of information—requirements, capabilities and solutions—form a hierarchy. Each requirement may be satisfied by alternative sets of capabilities. Each capability may be satisfied by alternative sets of solutions (such as part features or software for a control unit). Organizing design information into this hierarchy, and supporting easy, quick navigation across requirements, capabilities and solutions is key to efficient management of the maximum number of live alternative design options.

Modern design systems address this need with approaches that integrate functions ranging from configuration management to requirements engineering. Systems engineering also covers these concepts, and extends the scope to consider project issues including logistics and the management of teams.

Whatever approach is supported, the design engineer needs to be able to create, maintain, and use bi-directional links between the data items that represent requirements, capabilities and solutions. The design engineer needs to navigate from any starting point, for example, to find the source requirement, look at the alternative sets of capabilities that may implement this requirement, and check the parts of the product structure that provide a particular capability.

This needs integration between requirements management and design creation. If a design system makes it easy to structure design information in this way, as well as navigate and manage the resulting network, then design engineers will have the speed they need–speed that delivers effective tracking of alternatives so they can keep more design options open, and delay commitment to particular design choices. The result will be better designs.

Decide to act!
The good news is that leading global vendors and niche specialists are active and offering products, solutions and service in this area. Dassault’s Collaborative Systems Engineering, PTC’s Windchill RequirementsLink, and Siemens PLM Teamcenter Systems Engineering and Requirements Management address the data access that an engineer needs in order to keep more options open. Autodesk’s Revit Building Software provides an environment to support holistic parameterized and calculated requirements in its focused domain. For example, color-codes for rooms based on airflow requirements; or electrical load requirements calculated from equipment specifications. The International Council on Systems Engineering (Incose) lists 25 products identified in its requirements management tool survey. The Incose list includes IBM, whose acquisition of Telelogic has extended the capability of its Rational line to address not only software development but also other design environments that benefit from systems engineering.

But before talking to vendors, have a word with your design engineers. Do they have the flexibility they need to navigate, maintain and adjust requirements, capabilities and solutions? This is the area where speed and agility will give them the option to delay decisions on design choices, study more alternatives, and come up with better designs. §

Peter Thorne is Managing Director at Cambashi, a global strategic IT advisory firm specializing in management, marketing, industry analysis and market research for engineering, manufacturing, construction, and related industries. You may contact Cambashi at 52 Mawson Road, Cambridge CB1 2HY, UK; Tel: +44 (0) 1223 460 439. www.cambashi.com © 2010 Cambashi Limited.