Asset Valuation

The PRICE Calculator for Electronics Manufacturing Complexity, shown below, has a subtle but very powerful feature for Quality Adjustment, based on Mil-Hdbk-217E Quality Levels. 

 The above shows “None” which yields the standard MCPLXE, in this case a 8.07 value applying 100% Large Scale Integrated Circuits for Display (with CRT) equipment as an example. Yet, in the course of estimating a mission-critical automatic tester  with multiple controller-card assemblies for an airborne-military platform, I adjusted for more stringent quality levels—specifically “S-1” level consistent with Mil-Std-975/ Mil-Std-1547 per below.

Note that for military airborne platforms, as well as manned and unmanned space, the default is a “B” quality level. {For military mobile and ground, the defaults are “B-1” and “B-2” respectively.} The result of adjusting up to a more stringent “S1” quality/tolerance level was a much higher 8.94 MCPLXE value which significantly drove up costs. Out of curiosity, I did sensitivities on these quality levels, from “S” down to “D-1” {again B-1 & B-2 are moot} as shown in the boxed center column “Display” below (in purple).

As you can see, all electronic types (in this airborne military specification) are highly sensitive to quality levels. Graphically, we have the following results. 

 

Rule of thumb: when the quality requirement is in question— ask!

While teaching an introductory TruePlanning for Software Estimating course this week at an Army location, I was asked to follow up with a clarification on “percent adapted” calculation. 

The official PRICE training materials definitions are:

• Percent of Design Adapted - the percentage of the existing (adapted code) design that must change to enable the adapted code to function and meet the software project requirements;

• Percent of Code Adapted - the percentage of the adapted code that must change to enable the adapted code to function and meet the software project requirements.

The former, Design, was received by the class as straightforward. Again, this adaptation includes architectural design changes, detailed design changes, and any necessary reverse engineering. Entered as a percentage of the Adapted Code size, this metric essentially captures the effort to modify/ enhance the underlying concepts for data and transaction algorithms.

As my class later reviewed a fellow-student’s modeling of a “real-world” example, we found that our jury was hung on the verdict of what’s really meant by adapting the latter, Code. Again, the instruction is to also enter this metric as a percentage of the pre-determined adapted code size.

But the legitimate question was: “Why isn’t it always 100%?” If we labored to already identify new code, deleted code and reused code… then isn’t any remaining modified code all adapted?

The answer, per our resident software Yoda, is consider the code in terms of modules, not just source lines. To answer what percentage of a target must change to meet new functional and project requirements, evaluate what sub-modules/ CSCIs must change and what are reused WITHIN each module. If an entire module is not modified, then it’s count is reflected in the percentage of reuse. But if module(s) have some components that are modified and some that are not, that information is captured in this latter percentage of code adaptation.

If you’ve followed my blogs, you know what’s coming next: another car example! 

Say I have an automobile to rebuild. The body, wheels & tires are fine. Even the suspension requires no modification. (No car guy would ever accept not spending time & money on handling too, but suspend your disbelief for now).

Only the motor needs “adaptation”… but also, only in certain areas. The ignition, fuel injection, water pump, A/C & exhaust all require little to no adaptation. But the cylinder heads, valves, camshafts, rods, pistons & crank all must be worked on. My percentage of motor component “code” that actually needs modification is clearly less than 100%. 

Of course, the changes made above are a function of what requirements we're trying to acheive, e.g., horsepower, torque, RPM, etc.  Likewise, this analogy holds true in typical software modification. What we are given, as previous deliverables, is more than just total lines of code. It’s functioning modules/ systems that may, or may not, require some re-work under the hood. 

Agree?

Additional insight into how TruePlanning defines and utilzes these inputs is detailed in the True Software White Paper.

I’m not a golfer. But we’ve all heard one say “that’s why I play” after hitting a shot and feeling like it all came together. What “it” is, in terms of mechanics and timing, I’m not really sure. 

In our own world of parametrics, it’s the feeling of adding value in that golden moment of facilitating decisions and forward momentum. We wear many hats: estimating, consulting, systems engineering...even cost accounting.  Building an AoA, ICE or ROM is where rubber-meets-the-road in regards to configurations and assumptions. 

Not too long ago I was in a discussion with a number of Subject Matter Experts and realized that most of us at the table hadn’t had a chance to hear each other’s perspectives. Enter the consensus-maker! With parameter pick-lists and definitions displayed as talking points, we talked through the scenarios and operational expectations. 

We clearly needed a common frame of reference to get to a real-time resolution. The group built momentum, carrying over past the meeting. My role that day was to facilitate. When it all comes together, bridging between representatives from business operations, program management, systems engineering and field operations, it’s a very good feeling to add value. Maybe not as perfect as a hole-in-one, but I’ll take “it” every time!

1. A round table peer review, where we describe and defend our parametric modeling approach as well as consistency across similar objects/ systems/ alternatives. 
2. Introduction of an independent 3^rd party, not part of the estimating team, who is an experienced modeler. This resource can take the client perspective in reviewing, say, procurement versus cost-of-ownership as well as comparables from similar program experiences.  
3. Take an agile approach where your project leader is the “product owner” who reviews all interim deliverables top-down.  
4. Another option is incorporating a client representative into your pre-release reviews for similar validation testing. 
5. Finally, we pair off internally to verifying each other’s work against the real-time documentation we keep per common templates.  (Available from PRICE Systems, for both hardware and software modeling inputs). They are great visualization tools for internal parameter-tracking, plus external pre/ post model review with customers.

...wear the worst shoes. The cobbler was a master at his craft; he was just too tired to practice it when he got home from the shop.  Sound familiar?

A disciplined approach to understanding (functional) requirements as well as analogous projects (with actuals) is our not-so-secret sauce. Why run the risk of creeping back up our career learning curve? There’s already enough scope creep to keep us busy. Plus, for you management types charged with prospecting, a consistent approach towards estimation is a great way to connect with people who've felt the pain of being the cobbler's kids.

I recently reconnected with a colleague who found himself immersed in an early-stage, large-scale federal software project. Discussion points ranged from parametrics utility to sizing to Earned Value Management. Not leaving my toolset at the shop translated into good conversation with followup request. A bad example is yours truly, a year ago, so immersed in a highly-featured personal project, that he neglected to find agreement on scope and cost with his team. Bad idea! Now my “shoes” (a one-off custom hot-rod) are way behind schedule and way over budget. Keeping on my professional cost estimation consulting hat would have saved on both… bigtime! 

True Planning results have many options, including viewing Costs by Activity. While simple, this view can be quite powerful, especially when exported for re-organization manipulation. 

In a recent exercise, the WBS mapping of common objects, estimated by separate multiple scenarios, presented a non-trivial chore in Excel. “Transposition” features work fine for matrices, as do pivot tables. But how does one map object by activity grids into activity lists, similar to MIL-STD 881a, with singular “roll up” instances of all nonzero object costs? 

The secret is in how True Planning appends each activity output with the [object] tag. Once exported (via “Send to Excel” or “Copy Grid” options), a simple Data-Sort by Activity name will, by default, alphabetically group activities. From there, either then group by phase and/or group by scenario. The latter can be the original organization or an entirely new one. Next, use Excel’s Data-Group option to build subtotaling and roll up controls. This also gives you the ability to hide/view object instances, which are essentially activity subtotals. Finally, at your discretion, shred any scenario-shared costs such as SE/PM or personnel. Of course, build checksums to cross-check. 

Last piece of advice on this: for each step in your approach, document process refinements and save your interim artifacts as templates. The next time you are asked to rework the steps with a new scenario set or organization, your life will be even easier.

In my blog last week on Work Breakdown Structures, we reviewed the subtleties of using the [object] tag to your advantage in creating different sorts and roll up subtotals. As a followup, I’d like to drill down a bit on the initial step of using the “copy grid” exports. Each row number is unique, thus creating an identifying key for the vlookup function in Excel. Since all object X activity instances are allocated 100% to one of the three phases (with very rare exception), these row keys allow you to sort and re-group outputs while maintaining lookup visibility to corresponding grids. In the case of that rare exception, percentage spreads easily solve for allocation of that shared activity cost. 

The real trick to transpose into a WBS "Activity then Object" listing is to use the [object] tags as group delimiters. As long as you keep the row-key associated with the cost outputs, your options are not limited to just one activity list order. You could map to 881A format or to your accounting system. You could map your PBS transposition to 1921 or 1921-1 orders. In the end, cost will still match TruePlanning's output. Grouping by phase or by system won't change the bottom line.

One note: If you need activity subtotals immediately, True Planning’s Activity by Cost Object output works just fine. It’s a grid that is available for export to Excel, Word or XML. My process above solves for the often-demanded request of listing (and numbering, indenting, subtotaling) linearly. In the near future, look for PRICE Systems to utilize the COM layer feature of TP 2010 SR1 to give you yet another option in mapping PBS to WBS format. 

My June blog entry suggested the use of parametrics in real-options valuation. This month, I’d like to offer the generalized use of our type of modeling in valuing tangible assets. 

Typically, fundamental analysis evaluates the intrinsic value of securities. I won’t attempt to compete with Warren Buffet here. But it is certainly the case that a company, or portfolio of securities reflecting many companies, is based in part on the market value of its product assets and their potential for future earnings, as well as other objective and subjective considerations.

In parametric estimation, we take a top-down approach to developing models of estimating ultimate acquisition and ownership costs. In the case of the former, I’d argue that we can readily… and uniquely… estimate operating costs for companies developing and selling, say, technology-based products.  Marketing can determine pricing, based on their competitive landscape analyses and market-demand for unmet needs. 

We are in an excellent position to complete the forecasting of earnings (and hence, discounted cash flow) using our parametric methods to evaluate a product-system’s should/will costs. Anyone who does detailed bottoms-up budgeting for “go to market” expense, as well as production delivery, would find value in our modeling.  

And again, once estimated costs are subtracted from revenue forecasts, the netted estimate of earnings and cash flows will allow for traditional market value assessment of this asset or entity. For example, your organization needs to compare economic potentials of emerging new software products. There are no balance sheets. There are no income statements. Yet. 

Now your sales and marketing function has a good independent sense of revenue opportunity. So it’s left to you to estimate the costs of developing and delivering. Independent parametric estimation is the answer. No idea on sizing, either SLOC or function points? No problem. 

Data-driven True Planning has years of data modeling that allow you to run application-specific calculators. In addition, you can take advantage of calibrating actual data from similar projects. Likewise, this process of valuing assets holds true for IT infrastructure products as well. Cloud computing, SAAS and ERP are all further examples of where new IT/software products are emerging… and need estimating as well as financing via valuation.

I think parametric estimating has significant value commercially in the estimation of value of future product assets, and consequently their companies and associated securities.  What do you think?