Conceptual Costing: How Much Could this Possibly Cost?

Introduction

I recently gave a presentation at the DFMA International Forum on the journey the new product development team I led took in developing and using cost modeling and target costing methods for an entire new mining machine. It was a really interesting experience presenting to a group that, for the most part, has been cognizant of their product costs and have working with various methods of product cost modeling. Many in the audience were also utilizing a target cost as one of the constraints in the new product development process. For product that has already been produced it is quite easy to have access to the cost information for the product, rank the cost drivers, and then drive cost out. Even for new, but derivative product development, knowing what the cost for the reference product serves as a useful starting point. Most cost-reduction or cost-conscience NPD projects have a starting point for the product cost and established methods for developing good estimates. A "clean screen" NPD effort that starts from a functional specification and a target cost (at the full machine-level) can present difficulties when trying to consider product cost in the conceptual design phase.

It is difficult to estimate costs during the conceptual phase largely because there is nothing concrete to cost! Concepts, and there may be many concepts under consideration making things more difficult, are just that, concepts. There may be no components conceptualized yet at all and only abstract notions of how a system should perform. to put it concisely: there is no BOM to work from. For many organizations that lack a strong legacy in new product development or costing (or both) this can be a very challenge situation. I have found it helpful to take a methodical approach and concentrate on what is information is available rather than what is not. 

The first thing I found helpful in tackling the cost of multiple concepts is to create a cost matrix consisting of Functional Groups (rows) and Component Types (columns) for each concept Functional Groups can be similar to systems but do not have to rigorously be defined that way; the functional groups simply need to be convenient groupings to manage at the conceptual phase when many configurations can be under consideration and there may be considerable flux. For a car, as an example, functional groups might be Suspension, Steering, Drivetrain, Structure, Interior, Electrical, etc. Component Types could be general classifications of the components that exist in any functional group. Examples are: Hardware (fasteners), Structures, Mechanical (gears, bearings, etc.), Hydraulic, Electrical, etc. For any given concept configuration, populating this matrix can provide important insight as to what functional groups and component types are the cost drivers for that concept. The figure below shows what it might look with the numbers removed, but using color scaling:

Cost allocation matrix (heat map)

By understanding where cost is concentrated in a concept's design, rational decisions about how to address the cost can be made. A similar technique can be used to allocate cost by normalizing the costs in the matrix to the overall product cost. This affectively results in setting target costs for the functional groups, if the distribution of costs across functional groups is both well defined and stable (may not occur early in conceptual phases).

To support population of  cost allocation method, several techniques may need to be employed. I have used a variety of methods depending on what type of component or system is being costed, how much supporting information is available, and what confidence-level is required at that stage of development to support decision making. One of the methods I have used is to find a single, dominant parameter that drives the cost (overall mass, volume, power, number of connections, etc.) and scale (linearly or non-linearly). If you have enough information based on past history with similar components or systems and it there is reasonable ability to estimate or derive the dominant parameter for the new concept, then this technique is very powerful. Sometimes, it may be required to derive a cost function from two parameters (for example overall mass and volume of machined features). The goal should be to try to find the dominant cost-driver(s) of a particular type of component or system and build a simple function around them.

I've found it useful sometimes to keep things in perspective; ask yourself "how much could this possible cost" and go with that number until you have a better estimate to avoid getting paralyzed by not knowing. One other metric to track is the confidence in a cost particular estimate. Over time the goals should be to lower the costs (reduce the delta to the cost target) and have higher confidence in those estimates. By the time the project reaches the detail design phase, the team should be in a great position to deliver on all the project's objectives, including cost.