We’re habitual beings. We tend to do things the way we’ve always done them. I want to write about specifications in that context today. A lot of the organizations we work with utilize a specification sheet or template in to which a fill-in-the-blanks exercise is executed to create a spec sheet and communicate design intent to engineering. The problem with boilerplate templated spec sheets is they don’t distinguish the value that differentiate one spec from another —e.g. which spec is important, less important, arbitrary, etc.
A way of dealing with that issue is to divide your specifications into three categories: Musts, Coulds, and Shoulds. The Musts are those requirements that without which you don’t have a product. Without them you don’t have a competitive position in the marketplace. The Shoulds are the things on which your competitive advantage is built; things you’re trying to accomplish in your value proposition. The Coulds are things that would enhance the value of your product, but may not be worth focusing on and investing efforts to achieve.
These three categories still could be communicated as point specifications, but we can increase the value and information being communicated by expressing them differently. One way would be expressing them as ranges. Instead of having a point spec you then have a range of values. Hitting any of the points within that range would provide value as perceived by the market place. Those ranges can be communicated to the engineer and used to guide whether they reached sufficiency in their design effort.
You can take these ranges and enhance them further and make them communicate better information by placing them beside a graph to show how the market value will change over the range. That way an engineer can see that they’ve achieved the target, but with a little more effort they can achieve more value. It’s meaningful information to them for their design.
The third way of communicating the Should to engineering would be as goals, as word/statement based ideas of what you’re trying to accomplish with a particular design. The communication of goals takes this point focus defined by specifications and opens it up broadly — bounded only by conceptual boundaries defined by the goals.
The communication of Shoulds as goals allows the focus to shift from achievement of various points to the generation of new knowledge and looking for alternative ways of solving a technical problem. It allows us to rethink the very nature of how we manage engineering and product development. It also frees us from the pain and misery of testing to spec – pass/fail testing – to testing for knowledge and learning. And this knowledge that we gain from testing a full range of technology allows us to capture and apply knowledge as innovation within product design.
Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive.
Follow Bill at http://www.twitter.com/systhinking
