Parametrics is more than estimating. It represents the complete process of capturing and utilizing (often with calibration) non-cost drivers, as well as associated programattics and configuration levels. The Wiki definition of systems engineering immediately speaks to project complexity, life cycle management, and logistics. Any question that parametrics and systems engineering are interrelated?
In many of our customer organizations, affordability and cost-benefit analyses have migrated to system engineering functions. How and where does your organization perform these analyses? As we enhance our capabilities and applications, it’s beneficial for all concerned to understand your adaptation of parametrics within the core activities of systems engineering, such as Life Cycle Planning, Life Cycle Integration, and Baselining. Estimation of Life Cycle Cost and Total Ownership Cost is well understood. Also appreciated here is your need to discern functional requirements, within context of missions, environments and constraints, in order to model affordability/ tradeoff studies.
I became very appreciative of the latter while teaching the Introductory True-Planning Hardware and Systems sessions last month to a class that included “old-school” Price Estimating Suite users. As part of our next release, the COM interface allows end-users to execute custom scripts from outside the framework to initiate modeling and call values (essentially using TP as a function call). For an example, I invited in a developer to demonstrate his sensitivity-tool built within Excel. The earlier-entrenched PES users were unanimous in their desire to utilize this new capability. My job is to train and empower, not to market. But I walked away impressed with how often these “estimators” were, in fact, integrated within organizations that accomplished cost/ benefit affordability activities.
Illuminate me please: how do your systems engineering functions take advantage of parametrics and tradeoffs tools?
Powered by Compendium