Tag Archives: hardware component

What Does That Button Do?

As promised last month, I’m starting a blog series that focuses on a few critical TruePlanning® inputs.  We will tackle the definitions, intent, and effects of these inputs through a generic use case.  You may be well aware that there is interdependence among cost objects in TruePlanning®.  To keep things simple, we will focus on effects at the hardware component level.  First up, let’s talk about all things related to quantities!

In the hardware component, there are six primary activities spread across two phases as shown below:

At the project level, we generally provide quantities for prototypes and production units.  In addition to number of units, we can also phase quantities over time.  Prototypes are those components, assemblies or end items that are manufactured to support the development phase, to include development of engineering models, test units, and other common items that are qualified through acceptance tests during the development phase of the project.  Prototype quantities greater than zero will generate effort for all three development activities.  With zero prototypes, effort will still be generated for Development Engineering.  However, there will be no effort for Development Manufacturing or Development Tooling and Test.  This technique (zero prototypes) is useful when estimating “paper studies” or other design efforts where test articles are not required.

Production units are those components, assemblies or end items that are manufactured to support the production phase and meet the total demand for deployable assets.  When production quantities are zero, no production effort (or cost) will be generated in TruePlanning®.  This technique (zero production units) is useful when estimating a “development only” project.  When production quantities are greater than zero, cost will be generated for all three of the production activities.

Now, at the hardware component level, we have several additional inputs related to quantities.  First, there is Quantity Per Next Higher Level.  This input is used when you need to produce “X” number of hardware components for “Y” number of overall systems.  In aerospace terminology, this is often referred to as a shipset; it takes into account redundancies within a system.  As an example, consider wheels for a car.  If you need to produce 50 cars, and each car needs to have four wheels, a quantity per next higher level of four would ensure you generate cost for 200 wheels (50 x 4).  Quantity Per Next Higher Level also affects prototypes.

There are two other quantity-related inputs at the hardware component level:  Number of Additional Production Units and Number of Additional Prototypes.  Whereas the Quantity Per Next Higher Level input was multiplicative, these two inputs mentioned here are additive as shown by the formulas below:

Development Demand = Number of Prototypes * Quantity Per Next Higher Level + Number of Additional Prototypes

Production Demand = Number of Production Units * Quantity Per Next Higher Level + Number of Additional Production Units

I should have changed the name of this blog from “What does that button do?” to “What do those buttons do?” because we covered five separate inputs here.  However, the quantity-related inputs essentially have the same effect within a given hardware component, depending on if it is a prototype- or production-related article.  I started with these relatively straightforward inputs with good reason.  Next time, we will build upon the idea of quantities over time as we look at inputs related to cost improvement (i.e., learning curves).  As always, feel free to contact me at joe.bauer2@pricesystems.com with any questions.  See you next time!