What are factors?

Factors represent an issue, or a requirement that has an impact on the final "cost" of a product. In electronics, a "cost" will either be an increase in monetary value of building an item, or an increase in time to delivery. "Costs" in the software domain might be -

• Cost of hardware or hosting monthly fee(s)
• Increase in time to develop or deploy
• Compensating technology required for security, or risk mitigation

This isn't a complete list, but its a good start. Our ultimate goal is to define a set of "Weighted Factors" that we will use to score a particular design option. But first, lets explore the different types of Design Options, and explore a few examples in the Software engineering domain.

Key Point: Each factor varies in how linearly it will effect the "cost" value. Higher costs are bad, lower costs are good. Costs will be normalized by the weighting scale applied to each factor to ensure one factor doesn't overly control the outcome.

Types of Factors

Binary Decision Factors

Binary factors are those constraints that are an absolute Go or No-Go. Any factor that will clearly eliminate an option should be the first criteria analyzed. If a certain criteria is met (or not met), the highest cost should be assumed - ensuring that this option can never be chosen (not without due negotiation anyway!)

Tipping Point Factors

Some factors have no "cost" impact until they pass a certain threshold. An example might be disk space use. Until your product passes the requirement to need more than 100MB of disk space, there is no cost; After that you pay a premium. These factors need to place the lowest cost on a factor, once the tipping point is reached, the factor must assume the highest cost ensuring this option cannot be chosen, otherwise this factor should be zero and not impact the rest of the decision tree.

Scaled Factors

These are general quantifiable factors. The offer a mechanism to determine (and indicate) how a factor impacts cost. E.g. Adding an extra business service layer will increase the deployment complexity and may need extra servers. We'll discuss how to formulate a scale for these factors in a future article, but in this example you can imagine that adding servers has a cost, and each extra architectural layer increases the cost accordingly.

Determining the Relevant Factors

This is the crux of the story. We need to identify the factors that we will score. There is no master list of factors to draw upon. It is important that each factor fall into a category listed above - Binary, Tipping Point or Scaled.

The basic process is to get all the stakeholders into a room and extract (brainstorm) factors that will in their opinion cause an extra cost. No factor is too small at this stage (we'll filter them later), just keep the crowd focused on identifying issues that can increase/decrease effort, cost, time and risk.

By then end of a session you should have a stack of post-it notes littering a whiteboard. Use post-it notes so that you can join and link duplicate concepts and ideas. If you involve the right people, you should end up with a big list of factors. How many are too many? Impossible to quantify, but once a list of Factors is defined, the weighting process should spotlight those factors that fall below a level that will alter any outcome. These factors can then be dropped.

I've not got a complete list, or even a recommended list at the moment. Hopefully sometime in the future I'll have something more, but for the fact of this article, here are a few I jotted down in three minutes (some overlap, some are duplicate, some can't be measured, and some don't make sense at all - all problems to look at later)-

• Bandwidth utilization
• Disk space required
• Number of Architectural Layers
• Database size
• Number of Database Objects
• Number of different development languages
• Number of different technologies
• Number of integration points
• Number of external partners integration points
• Number of config settings, and ease of changing
• Production event logging, how much, to where, how often?
• Ease of deployment
• Number of Servers
• Number of third party components
• Ease we could host at a co-located facility

In future articles, we'll look at how to take this list and refine it down to a manageable set, and how we would scale and weight each factor.

Troy.

In electronics design, many elements can directly impact the cost of manufacturing a product. DfM aimed to move the tradeoff analysis for decisions affecting manufacturing as early as possible in a design phase. I'll attempt to move this into the software architecture realm in a future article, but for now I want to explain how this worked in Electronic Product design.

What design decision matter in Electronics?

In electronic product design, here are a few to start your thought process -

Component Selection - Choosing components from an approved supplier and components that meet requirements but don't exceed specification (giving latitude to safety margins) directly impact cost of an item. Assisting engineers choose preferred part, parts already purchased and in inventory, and offering alternatives can really decrease costs and improve turnaround time.

Printed Circuit Board Size and Shape - Small PCB's aren't made one at a time. They are panelized onto larger sheets, fabricated and even assembled (components positioned and soldered into place) in that form before being broken apart and put into their cases. The more individual boards you can fit to a panel, the less waste and fewer panels need to be moved through auto-assembly equipment.

Printed Circuit Board Technology - If you make the board smaller to fit a certain device, you often need to add 'layers' for interconnecting components. This adds cost; If you make individual features smaller to fit more interconnects onto fewer layers, the manufacturing yield decreases due to mis-registrations. Its a real trade-off and highly dependent on your partners capabilities.

Printed Circuit Board Hole Count and Sizes - For some PCB technologies, drilling holes can be time consuming. Smaller holes needs to be positioned more accurately and these drill bits break more often. Normally, fewer holes of larger sizes is the cheapest way to go; However, some PCB technologies don't incur a cost per hole - which one will you specify?

Component Placement - Where is it safe to put large components? Where will the battery connect? Where are the pushbuttons? All of these decisions need to be considered when the PCB is being designed - BUT they seriously impact the final case design. How can the electronics designers and the mechanical (and brand) designers collaborate to agree on an acceptable design? For extremely high volume designs, placing similar components in the same orientation can reduce the number of machine rotations and component reel changes which reduces the total time of assembly. Saving 1 minute for 1 million pieces is substantial!

Early Focus and Scoring Matrix Definition

Design for Manufacture initiatives aimed to bring focus on the types of decisions made above and allow engineers and designers to perform trade-off analysis as early as possible in the process. The product might have to be smaller than a competitors and that forces a smaller PCB size and shape, which then causes a specific choice of technology - However, the key aim was to understand that early and make informed choices about which remaining options fulfill the global good.

To build a Report Card or Scoring Matrix, the basic process is -

1. Get together with all of your partners, suppliers, fabricators and designers and brainstorm a set of issues that impact cost. Similar to the list provided above, the idea is to get the 'issues list' on the table.
2. Group these issues into a sub-set that can actually be measured and scored. E.g. "Number of boards per panel", "Number of holes smaller than 0.5mm", "Number of different components types", etc.
3. Determine relative weighting for each measurement. Some requirements cannot be broken, other just incur a cost. I'll propose a process for determining this weighting in a future article; for now, just understand they won't all have the same weighting factor.
4. Build the scoring scale for each factor. This step tries to normalize the different scales of measurements into a smaller linear set (i.e. 1 to 5, rather than 1 to 1 million for one factor, and 1 to 10 for another)
5. Calibrate the scorecard by testing on existing systems. Agree and alter the specific factor "Weightings" until you gain confidence in the scorecard
6. Use the scorecard on future design discussions.

Summary

Is it just as simple as substituting "IT Operations" for "Fabricators"; "Usability/Interactive Designers" for "Packaging Designers"; "External Hosting Partners" for "Suppliers"? 

In future articles i'll look deeper into -

• How to build a weighted score card based on issues relevant to software
• Propose some software specific issues and attempt to weight those appropriately
• Test our new scorecard and determine if it is achieving the goal we intended.

Be interested in comments as to whether other people agree there might by parity between DfM in Electronics to DfM in Software.

Troy.