Original Post Date: July 2, 2015

One topic we’re focusing on for the next version of TruePlanning is supporting a variety of methods for estimating an activity.  For example, we currently have sophisticated algorithms supporting our estimation of spare units/modules/parts, which depend on characteristics of the item, as well as the operating and support (O&S) scenario described.  However, there are often good reasons for wanting to use a different method to estimate these costs, and we’d like to give users the ability to pick from a variety of methods.

Many users want to be able to estimate initial spares costs before the O&S scenario is well defined.  Initial spares costs tends to correlate well with production costs, and by using a simple factor of production costs, you can quickly get a good estimate without modeling all of the detailed potential O&S scenarios.  For some organizations doing early-phase estimating, this is considered the best estimation method.  Another method would be to allow the estimator to directly enter the number of required spares, because, perhaps a detailed study has been performed to find the right number of spares, or perhaps there is a required spare quantity built into a contract.  Finally, the estimator might want to use our detailed algorithms, but would rather apply them at a higher level.  This might be useful when the cost modeling was done at a very low level of detail, where the line-replaceable unit is actually an assembly of multiple parts, which were modeled at low levels for development/production, but are modeled from a higher level for O&S.

Our plan for the next major version of TruePlanning® is to give users the flexibility to model costs in a variety of ways, for initial spares, systems engineering, and many other activities.  We will certainly maintain our existing estimating capabilities for users that like it the way it is.  We want to generically allow options such as “Activity X = 20% of Development Cost of this subsystem,” or “Activity Y = 5% of the production cost for the entire system,” and so on.  We may even allow the use of attributes like development cost, UPC, total weight, etc. to be used within a complex equation entered by the user.

Do you have any “rule of thumb” estimation methods you’d like to make sure we support?  Do you think we’re on the right track?  Leave a comment below, or give us a call/email!