Original Post Date: Wednesday, September 25, 2013

During a recent Analysis of Alternatives (“AoA”) consulting project, our customer asked that we provide more insight into TruePlanning’s System and Assembly objects, which in our AoA context we termed Systems Engineering/ Program Management (SE/PM) and Alternative Integration/ Test, respectively. The customer’s challenge was understanding our parametric model’s treatment of principally hardware-COTS objects, combined with other cost, purchased service and training objects.Our Chief Scientist, Arlene Minkiewicz, provided us with insights that I’d like to share with you, as well as my views on how we at PRICE systems have consistently used these parent objects in our best practices of setting parameters in AoA models for child objects.

System (SE/PM) Cost Object:

Beyond aggregating the costs (and labor) of its child objects, this parent object captures those overhead activities necessary to conceptualize/ initiate/ plan, execute/ manage/ deploy, and control/ maintain/ close a project that delivers a product or service to a customer.  To quote our documentation, the System object can model either “new development, or on-going maintenance and operations, for hardware, software and/or an infrastructure represented by child components.”  In terms of WBS cost categories, this object captures project level oversight and control efforts, through the Project Planning, Project Management, Quality Assurance, Configuration Management, Vendor Management and Documentation activities. 

In our AoA, where we considered multiple technology combinations of primary and secondary hardware equipments, each pairing defined an alternative and each required a System cost object to account for SE/PM.  As we learned from Arlene, the labor requirements for the System cost object are based on roll-ups of labor requirements from subsystem children cost objects such that child development labor drives System development activities, child production labor drives System production activities, and child operations and support (O&S) labor drives System O&S activities.  These rolled up values are then tempered by the values entered for the overall parent deliverable System (e.g., primary or secondary equipment in our AoA).  Our TruePlanning™ model’s estimation of SE/PM is hence dynamically tied to child object activities, regardless of type:  hardware COTS, other cost, purchased service or training. 

In terms of how we used the System parent object for setting parameters in our AoA models, the following practices applied for child object inheritance.Both production and deployment schedules were set for each technology at this level so that the System lifecycle schedule flowed down to its subsequent subsystems.Likewise, operational hours of each system were defined and spread at this parent object level.Operating Specification and Maintenance Concept were also set at the System level. A final key input, relative to our AoA within the System cost object was the vendor complexity representing the level of oversight needed for each subcontract to ensure the system runs operationally.

Assembly (I&T) Cost Object:

Similar to the System parent above, the Assembly object aggregates child costs (and labor) as well as models all the technical activities that occur during the development and production of a system consisting of hardware children (as well as software and hardware/software combinations) to deliver specific platforms or capabilities.  Per our documentation, the Assembly’s activities “deal with those technical decisions and oversights that encompass multiple system components.”  These Assembly activities fall into three categories:  (i) Requirements Definition & Analysis, System Design, Operational Test & Evaluation, (ii) Production Engineering, Production Manufacturing, Production Tooling & Test, Assembly Operation & Support and (iii) in the case of hardware-build child objects (which again our COTS-driven AoA excluded) Development Engineering, Development Manufacturing, Development Tooling& Test.

As always, for each hardware COTS object (as well as hardware component object), both of the External Integrations Complexities for Structure and Electronics define the level of the structural contribution to the Integration and Test effort.  As we learned from our Arlene here, the requirements for the Assembly activities of the first category above are a function of rolled-up development labor from children, adjusted by complexity and index values input at the Assembly level.  The activities of the second and (if applicable) third categories are a function of rolled up size, weight and complexity information from the child hardware components, tempered by the External Integration Complexity values on the child component inputs.  The Assembly Operation and Support activity costs are a function of rolled up O&S labor from all child cost objects, with one caveat:  any “other cost” objects do not affect the Integration parent activities.

Our AoA of multiple primary/ secondary equipments, in fact, represented pairings of integrated assemblies, typically a hardware platform combined with a payload.  Certain alternatives required the integration, assembly and test of subsystems (e.g. structure and payload).  Other took into account the I&T of two primary systems.  In our large-scale AoA, the Assembly object supported both cases, allowing for implementation of new systems at proposed operational locations where the system did not exist or where the integration of an existing system and acquired second primary for particular alternatives was required.  Parameters set on the Assembly cost object were twofold.  First, a system complexity value indicated the level of effort expected to understand, design and integrate a system composed of the child subsystems.  As typical for a TruePlanning™ modeled estimate, this value measured the expected complexity of the integration task for each system as well as the experience, training and familiarity of the staff intended to do the integration effort.  The second key input for the Assembly object was the estimated complexity of both the structure and electronics of the deployed system, as integrated and tested at the site.  Again, all were tempered by the External Integration Complexity values on the child components, in this case COTS hardware.

{Note:  the AoA context here was supporting tradeoffs of acquiring hardware COTS and thus production and O&S activities only, notwithstanding the development engineering activities supporting equipment modifications.  In a follow-up blog, I’ll discuss software COTS integration challenges!}