Cost Estimation Models

The IEEE published “Top 11 Technologies of the Decade” in the  January 2011 editions of the IEEE Spectrum magazine.  It should come to a surprise to no one that the Smartphone was number 1 on this list.  The answer to the author’s question “Is your phone smarter than a fifth grader” was a resounding YES![1] 

 In 1983 Motorola introduced the first hand hell cellular phone.  It weighed in at two and a half pounds, had memory capacity for 30 phone numbers, took 10 hours to recharge and had a selling price of $4000 ($8045 in 2006).  The phone was the size of a man’s head and would sustain an hour of conversation before a recharge was required.  In June of 2007 Apple announced that it was launching the iPhone which would basically integrate all of the electronic gadgets teenagers carried around in their pockets into a complete package – phone, web browser, iPod and camera.  The iPhone 5 which should be available by Fall 2011 incorporates NFC technology, an upgraded operating system with cloud integration, music streaming, voice interface, 4G connectivity and an embedded social networking tool. NFC technology makes it possible to use the phone effectively as a credit card – making payments by swiping the phone near a device that can read its information. [2][3][4][5]

The proliferation of smartphones and tablets has led (and will continue to lead) to the proliferation of mobile applications.  And it seems as there are no bounds to the kinds of applications that are being developed for smartphones.  A sampling of some popular applications is listed below:

* Chase Mobile – which allows users to check account balances and review transactions
* Angry Birds – very popular gaming software
* Facebook - allows users to report their status from anywhere
* Yelp – allows users to locate places to eat, shop , etc. along with reviews from local patrons of said establishments

The list goes on but clearly if you can dream it – there’s an app for that (or at least there could be an app for that).  As practitioners in the art of estimation, all this mobile application development leads to the inevitable question of what does it cost to develop mobile apps and how is mobile application development different from more traditional forms of development? 
Mobiles apps can be categorized as either native applications – which run entirely on the device or web applications - with small clients resident on the device which interact with applications running on a remote server.  It appears that in general the web applications are less complex than the native ones, and thus less effort is required to build, test and deploy them.
While mobile application development is still in its infancy so a lot of what is going on in the industry now has a bit of the Wild West feel to it.  This stage of any technology is impacted by learning curve issues which may dampen productivity but at the same time there is the newness factor – where smart people are excited about the promise of new technologies and are willing to work extra hard to make things happen.  So while there is some effort/cost data available for mobiles apps, we must temper our enthusiasm.
Another concern when developing mobile applications is which platform(s) it is being developed for.  If an application is being developed for iPhone, Android and Blackberry the effort is significantly increased.  Although there are elements of the design that can certainly transcend platforms, each of these platforms has its own operating system and development environment. There are additional potential compatibility issues in cases such as Android where there are multiple companies manufacturing devices. Additionally, application developers need to determine which versions of OS for each of the platforms the application will work with.  They also need to be aware of and respect the user interface guidelines developed for the device(s) for which they are building apps.
Mobile applications may need to respond to various forms of external data from sensors, a real or virtual keypad, a GPS, microphones, etc.  They also may need to respond to movements of the actual device as well - so the screen adjusts when the user changes the orientation of the device.  There are also many instances where mobile apps will need to interact with other applications on the device.  Often the mobile application will need to share elements of the user interface with other applications. 
Mobile applications need to be developed in such a way as to limit the consumption of resources.  No matter how good your killer app is, if it drains the phone battery in half an hour no one is going to use it.  Along with all other applications that have access to the Internet, they should be built with a focus on security so that the users data is protected from malicious intrusions.
All of the issues listed above are likely to impact the complexity of the development effort of the mobile application – thus they have the potential to be an important part of the cost equation as well.  In many cases mobile applications are smaller than traditional applications so increased complexity may be offset because the projects and corresponding project teams are small.  Still this increased complexity is important to consider.
Another area where mobile apps are dramatically different than traditional apps is in the testing of the application.  Simulators and emulators exist and can be helpful in some circumstances but they are not always easy to use, effective or efficient.  There are also issues, with some platforms around the maturity of the technology that allows applications to be transferred from the development environment to the mobile device – further complicating the testing process.  Finally there is just the sheer magnitude of making sure that the application functions correctly on all the combinations of hardware, operating system and carriers on which it will be expected to perform.  The cost and effort associated with testing may present significant differences when being evaluated for mobile applications.
Smartphones are here to stay and more and more businesses will want (or need) to develop apps for them in order to remain competitive.  With the technology still relatively immature there is limited data that will help us develop cost models but there is feedback from the field on what issues are most likely to impact costs.  Though the technology is still emergent – there is some data available from commercially based mobile app developments – so at least we have a place to start.
Share your experiences with mobile application development by leaving a comment for this post.

[1] Ross, Philip E., “Top 11 Technologies of the Decade”, IEEE Spectrum, January 2011
[2]  http://www.motorola.com
[3] http://www.apple.com
[4] http://en.wikipedia.org/wiki/Mobile_phone
[5]http://www.ibtimes.com/articles/170418/20110628/quick-look-at-iphone-5-features-as-september-release-date-looks-probable-nfc-camera-8mp-lte-4g-displ.htm

Going to ISPA SCEA in New Mexico?  If so, join us for a workshop on data driven cost estimating.  Register: http://www.pricesystems.com/services/predictive_modeling_schedule.asp#/?i=3

Description:  Building transparency and traceability into your estimating process leads to more defendable estimates.  This hands-on workshop demonstrates how historical data is transformed into predictive models.   You will learn how your organization’s data can be synthesized into custom models that can be employed in support of third party models within a single analytical framework. 

Participants will learn:  (1)   To develop system level estimating relationships to provide a test of reasonableness and historical cross-check to proposed estimates. (2) To develop sub-system level relationships that estimate Software Lines of Code based on requirements. (3)  To develop historically-based relationships across classes of aircraft systems in support of “ball-park” estimates based on specific program actuals.

Location:  2011 ISPA/SCEA Joint Annual Conference /  Hyatt Regency Albuquerque - Fiesta 1-2 /  June 7^th, 2011 /  9:00 am – 1:00 pm (includes complimentary lunch).  Hope to see you there!  To register go to: http://www.pricesystems.com/services/predictive_modeling_schedule.asp#/?i=3

I was recently asked by a client to provide a synopsis of what TruePlanning offers in response to the Ashton Carter Memorandum – Implementation of Will-Cost and Should-Cost Management. In the memo, the Undersecretary of Defense AT&L listed “Selected Ingredients of Should Cost Management”. It was interesting to note how much capability is provided by TruePlanning to effectively support efficient should cost management. In this month’s blog, I will share with my response to our client with you.

Agile software development practices are predicated on the following tenets as introduced in 2001 in the Agile Manifesto [1]

•  Individuals and interactions over processes and tools
•  Working software over comprehensive documentation
•  Customer collaboration over contract negotiation
•  Responding to change over following a plan

Agile development processes rely on experienced, highly skilled people communicating with clients and each other to deliver software that provides the clients with the most value for the money they spend.  This requires both developers and consumers of software to accept the reality that things will change over the course of the project and that the software that is eventually delivered may not be the same as that was envisioned when the project was first kicked off.

At any given time, the agile software development team is only working on the feature that the customer currently feels is the most valuable.  Estimation is performed by the team (including developers, BAs, QAs and customer representatives) and is only focused on the feature that is currently on deck.  At the end of an iteration, the customer has an opportunity to review the implementation to date and can reprioritize remaining features based on changes in their requirements, market or expectations.  So estimating beyond the current feature doesn’t really make agile sense.

Unfortunately, the fact that estimation doesn’t make sense for the agile team does not mean it doesn’t make sense for the business.  The business needs to see the forest not just the trees.  Customers need an idea when their software will be delivered, businesses need to prep the market for new products and features, businesses need to be able to optimize resource allocations across many projects, etc.   This of course begs the question of how to perform an estimate for software when you really don’t know exactly what software you’re going to build.  As an industry, we’ve been pretty unsuccessful estimating software projects even when we think we have a handle on the end product – how can we be successful with so much uncertainty.

First we accept uncertainty and commit to incorporating uncertainty into our estimates.  Once we’ve made that commitment we are then free to pursue one of many top level estimating techniques to help us get our head around a likely range of values for cost and schedule based on what we currently know about the software project.  Parametric techniques are particularly suitable for this task especially for an organization that has some historical data from previous agile projects.  Parametric estimating models like TruePlanning for Software provide a repeatable framework through which an organization can study their past performances on similar projects (similar number of features, similar market, similar customer, etc) and use what they learn to perform estimates on the project at hand.   The amount and nature of the similarities should guide the amount of uncertainty in the estimate.  Organizational history can be used to map Story Points or User Stories to a size measurement such as source lines of code, function points or user points.  Analysis of performance on past projects can inform decisions about productivity and other project drivers.  This information can be used to drive the parametric algorithms to develop estimates for cost, effort and schedule.

Since we have already acknowledged that we didn’t get the question right, it’s unreasonable to assume that the answer will be ‘the right answer’.  What we do come away with is a range for cost, effort and schedule which will give decision makers realistic data to work with. If we have properly studied our history and thoughtfully assessed uncertainty, we can present these ranges with a quantifiable degree of certainty. 

What process does your organization employ to plan around agile induced uncertainties?

[1] Agile Alliance, “Agile Software Development Manifesto”, Feb 2001, available at www.agilemanifesto.org (retrieved January 2010)

“I think we have an obligation to work with industry to ensure that our suppliers do not just remain world class in defence, but aspire to be world-class manufactures that can withstand comparison to other industries.”

Chief of Defence Procurement, Sir Robert Walmsley

Is this a practical proposition or is it a pipe dream?  The following excerpt from Dale Shermon’s Systems Cost Engineering attempts to make the case that this type of comparison is possible.


Many of the statements in proposals and marketing literature stating the superiority of a company are anecdotal or at best qualitative evidence. It has not been possible to quantify the productivity of industry to demonstrate that one manufacturer is more efficient than another.

In the ship building industry it is possible to benchmark commercial ship yards using a metric called Compensated Gross Tonnage (CGT). CGT measures the complexity of building a ship. It is calculated by multiplying the gross tonnage by the relevant CGT coefficient (calculated by the Organisation for Economic and Commercial Development [OECD]).  However, this is only applicable to this one industry. Other metrics exist in other industries, but what is really required is a single benchmarking technique and measure.

Benchmarking with Cost Normalization.  Forty years ago, PRICE Systems developed a metric that can be used to normalize cost and support the benchmarking practices needed to reach Sir Walmsley vision.  Manufacturing Complexity represents the normalized cost density of an item that has been manufactured. It has two dimensions: technology and productivity. Hence, more than one Manufacturing Complexity can exist. As aircraft are made using different technologies and by different companies, these have various complexity figures. However, if the technology is constant, the only dimension that changes is productivity. As a result, it is possible to compare the efficiency of companies that produce similar technologies.

Supplier Assessment.  One obvious and practical application of this technique is Supplier Assessment. This technique exploits the capability of parametric models to compare organization’s normalized cost density or Manufacturing Complexity. If, on paper, you have very similar proposals, how can you judge which organization will provide the best value for money? Heritage data will determine the level of development that is required and Operating and Support Cost will establish the Through Life Cost, but if these cannot differentiate the proposals perhaps the productivity of the companies should be considered. This is not a simple comparison, but with manufacturing complexity this can be achieved easily.

This process will lead to your suppliers knowing that you are able to control them; they will need more control on themselves. It will enable you to perfect your negotiation skill, leading to more success, as better negotiation material is utilised based on technology cost drivers. A parametric questionnaire is a possible tool to enable proposal validation in minutes.  All this information can be garnered at a very early stage in a project if required, providing better estimating accuracy for the purchased items. Normalization enables a bigger data sample as previous proposals received from the same companies can be compared. This in turn enables the establishing of trends. Are the suppliers becoming more or less efficient? Ultimately, these comparisons can be used to determine preferred suppliers.

Conclusion.  This method of benchmarking a project or company can be used for all environments. With the ability to move across environments it is possible to compare commercial and military organisations equally. Decisions and judgments can be made between Commercial and Military suppliers where no military competition exists.  It is possible to assess the productivity of an organisation or country at System, sub-system and equipment levels. The technique can be used to compare the whole cost or just the labour cost if that is the focus of your efficiency drive.

It is possible to determine preferred suppliers on a justified basis, or alternatively it is possible to demonstrate the efficiency of your organisation when the customer is skeptical about your productivity or your drive to improve productivity.

Finally, many organisations already have a license to use the PRICE models and over 8,000 people worldwide have been trained and are familiar with the PRICE methodology. This is not a new idea, PRICE has been established since 1975, but this new application of an established technique can help decision maker take the right decision regarding source selection cross industry and national companies. Alternatively, it can enable industry to demonstrate, with proof, that they are more effective than other solutions.

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.

My previous blog discussed a “Should Cost” methodology used by PRICE Systems to complete an analysis. In the article I included a chart depicting calibration results for manufacturing complexities for each weapon system (X-Axis). Manufacturing complexities are a major cost driver within the model. This parameter can be derived from model knowledge tables, generators or from calibration. Many times the calibrated results are simply averaged and used for predicting cost for the new system. This assumes that the new system is very similar in technology and performance as the systems used for calibration. In general this is not the case. Below I discuss how data driven cost estimating relationships (CER) can be developed between the calibration results and a selected independent variable. The CER will then be used to derive the manufacturing complexity, which then matches much closer to the new technology.

Figure 1. Calibration Results for each Weapon System

Since the data was already collected and calibrated within the model, the next step was to identify an independent variable. For manufacturing complexity for structure, thrust was selected. However, other variables could have been selected.  Maximum take-off weight, range, ceiling, empty weight, thrust per pound, or speed were all candidates for an independent variable. For manufacturing complexity for Electronics, frequency speed was selected as an independent variable. Again there are many potential candidates for an independent variable for electronics. 

The next step was to graph and complete regression analysis. Figure 2, depicts the results for manufacturing complexity for structure, and figure 3, depicts the results for manufacturing complexity for electronics.  I normally select a power function when regressing data. One could select any function except linear. Linear regression does not always work very well and as a practical matter technology advancements are rarely linear. 

Figure 2.  Manufacturing Complexity for Structure

Figure 3. Manufacturing Complexity for Electronics

Using the above equations now require information be collected on the aircraft thrust requirement for structure, and frequency speed for electronics. These requirements are then used to calculate the appropriate manufacturing complexity. This approach insures that the cost estimate now match up with the requirements. 

The next time you need to complete a cost analysis, talk to one of our expert PRICE Solutions consultants for help.

I consistently run into this idea of data driven estimating.  Yet, there is no clear explanation of this concept.  I am not trying to provide one here, however, I am interested in is what is at the root of this growing movement.  My take is that it is an attempt to scratch an itch.  But what’s the itch?

I believe it is related to my early post (Accuracy is Risky Business).  In the struggle to answer the accuracy question people have decided that understanding the data used in the estimating process is key to understanding its accuracy.  To a certain degree this makes sense.  It is useful to gain insight into the information upon which a cost estimation model was based.

• How much data was available?
• How current was the data?
• Was it relevant to the project being estimated?
• What statistical techniques were employed to analyze the data?

In terms of data, there are two general areas considered relevant: data quality and fit. Understanding how much data was used; how old it was; where the data came from sheds additional light on the results. Once the amount, age and source of the information is established, the next concern is how the information was analyzed. 

Descriptive statistics are often used to describe a collection of data in quantitative terms. They aim to quantitatively summarize a data set. Descriptive statistics include many measures including central tendency (mean, median, mode), dispersion (standard deviation, range, quartile) and association (correlation). Additionally, there is statistical inference, which makes propositions about populations, using data drawn from the population of interest via some form of random sampling. 

The industry is fraught with estimates backed by reams of data surrounded by all the necessary statistics. But does understanding descriptive statistics and statistical inference alone improve our understanding and confidence of an estimate?  If so, why then is expert opinion one of the most widely used forms of estimating?  Why do programs based on these data driven estimates continue to perform poorly?  Is data driven the answer?  What do you think?

The concept of the fuel cell was first published in 1938 by Christian Friedrich Schonbein.  Based on this publication Sir William Grove invented the precursor of the fuel cell in 1839. The Grove Cell created current by applying two acids to zinc and platinum electrodes separated by a porous ceramic pot.  In 1842 Grove developed the first actual fuel cell which produced electricity with hydrogen and oxygen, much like many fuel cells in use today.

Fuel cells remained an intellectual curiosity until the 1960’s when the US space program identified a requirement for extended life batteries for which fuel cells seem to offer a promising solution.  The focus on green technologies has increased interest in consumer uses of fuel cells for transportation, residential and commercial power supply, emergency backup power and portable power supplies for consumer and battlefield applications.  Increased usage of any technology begs the question of how to address the costs associated with that technology. 

A fuel cell is an electrochemical cell which converts some fuel, usually hydrogen, into electric current.  It does this through a reaction between the fuel and an oxidant in the presence of an electrolyte.  The waste product of this chemical process is water and heat.  Fuel cells, unlike conventional batteries, consume reactant from an external source rather than one stored in the battery. They do require a continuous supply of fuel, but given that this supply is available, they will not run out of charge like a conventional battery. 

Because fuel cells require neither flame nor combustion to convert fuel to electricity, there is much hope that they will become a viable power source of the future as we try to reduce our carbon footprint.  Fuel cells are very reliable and less likely to be effected by the environment as some more conventional power delivery systems are.  Because of this they are being adopted in industries such as the telecommunications where outages are particularly problematic.  They are often considered for power generation in remote areas where energy from the grid is expensive and outages are frequent.  Because heat is a waste product of the fuel cell electricity generation process, micro combined heat and power systems are gaining popularity for residential and small business needs.  Other interesting uses of fuel cell power include material handling, backup power systems and uninterruptable power supplies.

Despite increases in the use of fuel cells, they continue to evade wide spread use because they are expensive.  Certainly significant progress has been made through increases in efficiency and improvements in manufacturing processes, but it is still more expensive, in most domains, to get electricity from fuel cells than from more conventional methods. According to a report from the Department of Energy in May 2010, high volume automotive fuel cell stack cost has been reduced from $275/KW in 2002 to $61/KW in 2009 and appear to be on track to reach the $30/KW goal by 2015.   The same report indicates a 24% increase in system power density for stationary fuel cells making it possible to reduce the fuel stack volume, weight and cost.

PRICE recently conducted a research effort using publically available data to develop cost estimating relationships for various types of power systems utilizing fuel cell technology. For a white paper describing this project and the resulting cost estimating models email info@pricesystems.com with the code word FUEL in the subject line.

What follows is PRICE's interpretation of the DOD-HDBK-343, which addresses design, construction and testing requirements for a type of space equipment. Within the document are specified several levels of Class Definitions for space programs, space vehicles and space experiments. The classes are briefly described below.

• Class A - High Priority, Minimun Risk
• Class B - Risk with Cost Compromises
• Economically Re-flyable or Repeatable
• Minimum Acquisition Cost

HDBK-343, originally published in 1986, was reviewed and found to be still valid in 1992.  We can't due justice to the 79-page document in a blog, but we can give you a brief description of each class and PRICE's interpretation of the platform for those classes.
 

The PRICE Platform alters the cost estimating relationships (particularly in the development phase) between the groups of hours and cost within the model, and is used to describe the operating specification of the item being costed. For example, as the platform is increased, the amount of design hours (thus cost) changes to a higher proportion of the development cost. This reflects the extra specifications and tests needed to qualify the design for a given operating specification.  Electronic and structural complexities are also linked platform.  Thus, when considering the platform for a specific HDBK-343 Class, the estimator must also choose appropriate complexities.

Class and Platform Descriptions

• Class A:  Defined as high-priority, minimum risk effort. Characteristics usually involve some combination of: high national prestige, long Life, high complexity, high use of redundancy, soft failure modes, independent qualification items, complete flight spares, highest cost, and a critical launch time.  This class is considered to use a Platform of 2.0 for UNMANNED equipment; 2.5 for MANNED equipment.  NOTE:  It is possible that this Platform may have a higher value IF a number of conditions force higher quality components, longer testing, and other conditions above the HDBK-343 descriptions for this class.
• Class B:  Defined as a risk with cost compromises effort.  It is a high priority, medium-risk, with cost saving compromises made primarily in areas other than design and construction.  Characteristics usually involve a combination of: high national prestige, medium life, high complexity, soft failure modes, protoflight qualification, limited flight spares, limited use of redundancy, high cost, short schedule, and a critical launch time.         This class is considered to use a Platform of 1.9.  NOTE:   It is possible that this Platform may have a higher (or lower) value IF a number of conditions force different quality components, different testing, and other conditions varying the HDBK-343 descriptions for this class.
• Class C:  Defined as economically re-flyable or repeatable.  It is a medium or higher risk effort, that is economically re-flyable or repeatable.  Characteristics usually involve a combination of: medium to high national prestige, short life, low to medium complexity, small size, single string designs, hard failure modes, very limited flight spares, medium cost, short schedule, and a non-critical launch time.  This class is considered to use a Platform of 1.8.  NOTE:  It is possible that this Platform may have a higher (or lower) value IF a number of conditions force different quality components, different testing, and other conditions varying the HDBK-343 descriptions for this class.
• Class D:  Defined as a higher risk, minimum cost effort.  Characteristics usually involve a combination of: medium to low national prestige, short life, low complexity, small size, single string designs, simple interfaces, hard failure modes, and a non-critical launch time.    This class is considered to use a Platform of 1.7.  NOTE:  It is possible that this Platform may have a higher (or lower) value IF a number of conditions force different quality components, different testing, and other conditions varying the HDBK-343 descriptions for this class.

 If you need help with this or other aspects of parametric modeling, post a comment or reach out to our subject matter experts through help@pricesystems.com

As is often the case, there is a difference between definition and connotation. The intended meaning of consumerism at these events was the phenomena of the consumer goods infiltrating and influencing government IT policy.  The IPad was all too visible in the audience as were the comments from CIO staff about their user base wanting to integrate IPad-like products into the work domain.

Like it or not we are all consumers; and consumers are getting more tech savvy.  As the adoption of these products or services increase in our daily lives, the question becomes unavoidable – Why can’t I use these for work? It was clear that for the CIOs attending these conferences this question was top of mind.  While most of the U.S. government is attempting to identify, inventory, consolidate and remove redundancies of IT infrastructure in response to Mr. Kundra’s IT modernization plan, CIOs are also feeling pressure (and criticism) from users about their ability to support seemingly everyday applications.

I’m sure there are many reasons why these aren’t supported; my intention is not to address them here.  Instead I’d like to posit an opinion.  There are  tools supporting new paradigms in how we communicate, at work and home, which are becoming the norm.  They are no longer ‘toys’ for the younger crowd.  For those waiting for this social media fad to pass, I’d suggest another look.  Recent events in the Middle East are real illustrations of their significant impact.  The U.S. State Department is beginning to use a nation’s access to internet and social media as a barometer for civil liberties.  Yet, there is still much resistance in adoption or more fundamentally understanding and embracing these venues. 

I’m encountering resistance and sometimes denial of these forces on a daily basis.  I don’t think you need to have 500 Facebook friends or Tweet until thumbs bleed.  Nor do I think being a LinkedIn Pro replaces human interaction.  It is important though to recognize the shift in communication.  Take just a few minutes to understand the different tools.   You’ll find it’s not unlike a conversation you may have in a coffee room or a hallway if you still have a coffee room or a hallway.  Many don’t.  For those who are time, money or resource constrained, you can access industry experts, thought leaders and practical advice on your own time at no cost.  There are plenty of free introductory videos or articles on line.  You can decide which mediums work best for you. 

At PRICE, we are raising discussions, sharing product capabilities and answering questions about cost estimation models through our social media.  Because people have different preferences for certain outlets or certain restrictions at work, we repeat similar material across our social media networks.  You can check us out on Facebook, LinkedIn, Twitter or follow our blog.

PRICE Systems recently accepted an assignment to complete a "Should Cost" estimate for a U.S. ally on a weapon system. The estimate included not only analysis on production costs, but also should cost on various operations and support costs. The only information provided by the client was quantity and time frame for production. A major ground rule for the estimate was that all data specific to the weapon system must come from publicly available information.  For example, mass, manufacturing process, and learning curve information must come from the public domain. 

After reviewing the scope for the estimate, we decided to also collect data on four similar weapon systems. This would allow us to provide not only a “Should Cost” estimate, but additional information to support the estimate. 

The initial task was to collect data on each weapon system. Pertinent model inputs were collected from various public sources. Flyaway costs were collected for each weapon system and used as the cost input for calibration. Manufacturing complexity for structure and electronics were the key input values solved for via calibration. The calibration results are displayed in a line graph, depicted in Figure One below.

Figure One. Calibration Results for each Weapon System

We then translated all calibration input data and calibration results into a predictive input file. Estimates were completed for each weapon system. All results were reported in the form of a graph depicting average amortized production costs, average flying hour cost, and average operations and support costs for each weapon system. 

The assignment could not have been completed without the capability of the PRICE Models. Model calibration was a critical task. Only a few pieces of data were required: quantity produced, production schedule, and mass. 

The model’s capability to solve for values for manufacturing complexity and a graphical depiction of the results enabled the client to quickly understand the results even though some of their personnel were not familiar with the PRICE models. Do you have a question about should cost?  Post it and we'll do our best to answer your question.  Need help? Contact one of our experts for assistance.

PRICE Systems is currently developing a COM interface for TruePlanning. I know, I know…  What’s COM you say? COM stands for (Component Object Model) and it's a programmable interface which exposes the TruePlanning estimating brains for integration and analysis!  I know it sounds boring but it’s really cool because it allows anyone, including our users, to build “apps” for TruePlanning similar to the way “apps” are built for the iPhone.  Let me give you some examples of some apps that you can build:  Excel solution, sensitivity analysis,  project comparison, risk simulation, total cost of ownership (TOC) solution, calibrate multiple inputs, optimize maintenance concepts and more.  The apps can be developed using a host of tools including VBA which comes with Microsoft Office.  Expect some apps to be built by PRICE but anyone can do it.  If you have an idea for a creative TruePlanning “app” let us know about it because that will help us build the right COM interface for you.

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?

Today, PRICE Systems, Senior Research Analyst, Bob Koury, will be presenting on Will Cost/Should Cost management.

The presentation will focus on two main requirements mandated in the Ash Carter memo (mentioned here several times): Developing Should Cost/Will Cost targets and establishing Affordability as a requirement.  An example will be provided of how parametric estimating models were used to establish “Should Cost” targets and how they can be used by a budget authority (government or Industry) to be an informed consumer of contractor or sub-contractor bids. The demonstration portion of this webinar will focus on a process for using a parametric estimating model to produce the reasonable affordability targets.

To sign up for the webinar go here: https://www2gotomeeting.com/register/142598427

In last month’s blog I wrote about Ash Carter’s (Under Secretary of Defense for Acquisition, Technology & Logistics) Memorandum for Acquisition Professionals, Better Buying Power: Guidance for Obtaining Greater Efficiency and Productivity in Defense Spending (14 September 2010).

I concluded the TruePlanning unified framework and comprehensive cost models, is a tool very well suited to provide the types of analysis outlined in the memorandum. In terms of Should Cost and Independent Cost Estimates (ICE), TruePlanning estimation software provides the industry standard capability to conduct Should Cost and calibration (actual program history) for ICE. Most interestingly and to the point of the Carter memo, TruePlanning has the capability of breaking the “self fulfilling” prophesy of business-as-usual.

On November 3^rd, Ash Carter issued a follow up memorandum outlining specific actions to implement the September 14^th Guidance. For this month’s post, I wanted to point out some specific comments about Milestone A and B actions and specifically how TruePlanning can help.

At Milestone A the memorandum specifics establishment of an “affordability target to be treated by the Program Manager (PM) like a Key Performance Parameter (KPP)…This analysis should show results of capability excursions around expected design performance points to highlight elements that can be used to establish cost and schedule trade pace.

At Milestone B, the memorandum requires ”a system engineering tradeoff analysis showing how cost varies as the major design parameters and time to complete are traded off against each other.” Thus, Integration between parametric cost models and performance models is needed to allow full exploration and optimization of the trade space, treating cost as another design parameter

Did you know that TruePlanning through its integration with Phoenix ModelCenter is a powerful tool to provide exactly this type of analysis? ModelCenter contains a native plug-in to interface with TruePlanning directly. Through the ModelCenter interface, analysis can easily perform Design of Experiments (DOE), Carpet Plot Analysis (trading performance KPP’s against cost) and Optimization Analysis.  If you are interested in seeing some examples, especially system engineering trade off analysis, please get in contact with me and I will send you a few presentations.

In his August blog-entry here, Zach Jasnoff outlined typical client perspectives for the different types of analyses that TruePlanning can accommodate. Working on a large project, we’ve experienced situations that, realistically, can happen where the initial intent and model structuring later have the boundaries of model appropriateness stretched. An Analysis of Alternatives (AoA), for example, is meant to measure deltas between baseline and its alternatives. If common costs “wash” then they can be excluded… which becomes an issue when treated as a Rough Order Magnitude for customer budgeting. 

Likewise, if a ROM or Independent Cost Estimate (ICE) of acquisition costs is extended to Program Lifecycle Costs, significant gap analysis is in someone’s future. TruePlanning can handle these tasks. But obviously it’s always best to establish use of an estimate and its underlying model, beyond initial application. TruePlanning has enormous flexibility. We analysts endeavor to do the same.  Clients, particularly those new to parametric cost estimation, just need coaching and synchronization up-front sometimes. They may think they have “the estimate” when it only covers certain configurations, activities, phases or cost-categories. Expanding a model is simple enough; creating and defending changes can be tough for the customer internally. 

I’m continuing to realize that when in doubt, make it clear what an estimate & model is meant for, and what it’s not.

John Swaren
Solutions Consultant, PRICE Systems