Tuesday, December 30, 2008

Engineering design for business value

We can observe that the economic cost of the use of the product or service of a technology business exists or has effect in terms of the client's time, money, choice, convenience, or effort.

Likewise we can observe that a change to the product or service of a technology company has (at least) qualifiable economic costs.

And so this is how we know the economic relation between design and value.

Constraints are an element of design. Some constraints are selected as precursors to the process of the development of a design, these are design requirements. Some constraints are selected during the design process as necessary to the implementation of a design. And then some constraints are implied by or effects of design or development choices.

Generally constraints restrict degrees of freedom for the future use or development of a product or service. Positive constraints contribute to the client's benefit from using the product or service. Negative constraints contribute to the client's economic cost of using the product or service, and are a debt to value.

One of the murkiest sources of negative constraints is design or development complexity. A failure to realize the simplest possible solution (to a design or development problem) is to install known or implied negative constraints, present or future economic costs to the use of the product or service.

Negative constraints are debits to the fundamental multipliers of business growth and sustenance. We know this to be true because we know the client's economic costs of use are the determinants of acceptance and productivity.

Minimizing design complexity is maximizing business value.

The process of Qualifying engineering design complexity is like the process of Quantifying computational complexity. First we need abstractions to capture significance. More explicit expressions of complexity are available at the small end of the domain, while comparative complexity is practical throughout most of the domain.

We also need to identify internal and external elements of technical design complexity, implementation versus interface, how they are distinct and how they are not. Internal issues may be independent of external ones, and thereby not immediately relevant.

When we master these processes for the recognition, identification and clarification of design constraints we master the processes for delivering technological growth and sustenance to the business.

No comments: