Estimation for Software Projects

The midterm elections are finally over. The themes of reduced spending and lower taxes showed up in force at the ballot box. But what does that mean for the defense industry?

The U.S. Secretary of Defense, Robert Gates, caused quite a stir when he announced his proposals for reigning in defense spending. There are the expected assortment of eliminations (U.S. Joint Forces Command and Business transformation Agency to name two), reductions (in service support contracts, number of senior civilian executive and general/admiral military officers, and funding for intelligence community advisory contracts), freezes (of automatic replacement of departing contractors with full-time government personnel and oversight reports), and consolidations (IT assets). All of these have created so much emotional reaction that I almost missed one component of his proposal that looks like an adder – to attach a cost estimate to every new initiative proposed hereafter. It’s hard to find more detailed explanation on this. I’m reading it as: let’s figure out what our ideas are likely to cost us before we fall in love with them. And that sounds like a fiscally good idea, as well as one that needs a community of smart cost estimators, capable of producing meaningful cost-benefit analyses.

After some recent meetings with clients I am sensing some confusion on how to estimate software reuse. I think part of the problem is in the definition of reuse, so let's start with a definition and then address the estimating issue. Software reuse is defined as “the use of existing software, or software knowledge, to build new software.” This definition came from Wikipedia. From a estimating software costs perspective the above definition is part of the problem. The definition should read: "Use of existing software with no changes for operation in the new software program.” 

If the existing software is going to be changed, re-written or modified to operate in the new program, it should be modeled as software adaptation. In this case the software will require some amount of re-testing, and software integration. Software that is being re-used has been fully tested during the original development program. In this case the reused software does not have to go through full up integration and testing. Rather it will go through a regression testing (computer aided testing) to insure it is still operating correctly.

If the software is going to be re-used as is, then clients should use the TruePlanning  “Software COTS” cost object to model and estimate. The purpose of modeling is for integration control. External integration should be set to a value of 0 to 1.0. A value of zero implies that there is no additional integration effort. Values less than one reduce the amount of model calculated software-software integration effort. The reused software can be modeled as a software component. However, do not include software adaptation or new software with the reuse data. This will overstate the integration effort. 

Some of us remember taking the Iowa tests during our early school days. The Iowa Tests of Basic Skills (ITBS) are standardized tests provided as a service to schools by the College of Education of The University of Iowa. The tests, administered to students in grades K-8, became a national standard for measuring scholastic aptitude – I was educated in Pennsylvania.

Now out of Iowa comes another test of sorts, something called an Integrity Index Score based upon a proprietary algorithm of an organization called Iowa Live. Iowa Live calls itself, “a growing network of volunteer Citizens & professionals for improving Iowa.” The organization has addressed a variety of issues in the education, health, and government areas. In July, Iowa Live published its comparison of two commercially marketed parametric estimating software products, one of which was PRICE TruePlanning. The comparison was for both estimation of software projects and estimating hardware. If you’d like to see the results, visit the Iowa Live website, where you can also learn more about the theory and derivation of the Integrity Index.  

Bruce Fad
VP Professional Services, PRICE Systems

Ahhhh, the 80s… a challenging (but often confusing) time in an evolving computing world.  Working in 1985 as a software estimator as well as SQA engineer in a quality assurance department that “audited” real-time projects using new concepts like OOD & OOP… well, you get the picture.  It was a great time to get immersed into great work.  And the good news:  that company’s process as well as its developers were bullish on a young estimation/ quality types asking plenty of questions… as long as they were of the Yes-No variety.  And ask I did.  Writing and using those checklists was great OJT, above & beyond adding their value of verifying/ enabling healthy development activities. 

Less than two years later, SEI’s Walt Humphrey formalized his Capability Maturity Model with its five levels of software process maturity.  These “CMM” levels are still used by many organizations and estimating tools, including within True Planning’s “Organizational Productivity Calculator.”  Could the CMM assessment be supplemented to include cost-driver questions for purposes of parametric estimation?  It worked in my SQA audit days. 

In fact many estimators (if only because they can’t get on an SME’s schedule twice) take the opportunity to ask qualitative and quantitative questions.  Integrating both lines into one interview should still be received as a healthy value-add.  Whether estimation is resident within a quality or financial function is moot.  We have the entrée to support both costing/ planning and productivity assessment.  A good example of an integrated approach is the David Group’s Project Profile Worksheet, cited in the text “Function Point Analysis” by David Garmus & David Herron.  Less comprehensive checklists are likely out there too, including methodologies proprietary to individual companies. 

The thought today is that the future is now and structured approaches, called audits or otherwise, will enable good practices as well as illuminate new approaches too.  In Wall Street, regulations are only good in controlling past (known) bad behaviors.  In just as creative Software, process rules help developers maximize their productivity towards current & future good behaviors.

The key cost driver when estimating software costs is the size of the product. The problem is that there is no perfect technique available to measure and quantify the size of software. The two major techniques in use today are Source Lines of Code and Function Points.  Today we will talk about Source Lines or Code or SLOC.

Source Lines of Code measures logical lines of code. It takes some of the uncertainty out of physical line of code measures by counting only complete statements (which can cross over more than on physical line). SLOC excludes comments and blank lines.

SLOC has several advantages:

·         Easily counted by automated tools, which can be configured with an organizations definition to produce consistent counts. Link to free tool from USC is provided below.

http://sunset.usc.edu/research/CODECOUNT/download/2010/UCC_Release_Notes_v.2010.07.pdf

·         Provide visibility into technical progress as projects proceed through design, code and testing.

·         Can be used to develop historical databases of past project size, which enable the more accurate prediction of size of future similar projects.

·         Design, Code and Test change to modified software can be specifically quantified

SLOC has several disadvantages:

·         It’s very difficult to predict SLOC on new programs prior to design

·         Different programming languages will require different amounts of SLOC to implement the same functions. This makes summary measures of size on multi-programming language products difficult

·         SLOC is difficult to map back to product features or requirements. Which makes usage of EVM difficult to apply to SLOC based SW projects. 

·         SLOC is a meaningless number to non Software Engineers (without detailed explanation)

Recently I came across the word “off-label”.  It is the term used by the medical community when a drug is used to treat a condition for which it has not been approved by the Food and Drug Administration.   We sometimes use TruePlanning for “off-label” purposes. A good example would be using the TruePlanning Calibration tool to answer such questions as, what is the maximum number of source lines of code (SLOC) I can get and remain within my budget?  I call this TruePlanning Optimization. Here is an example answering the SLOC question.

First begin by performing a normal cost estimate for your software project. If the cost is under your budget and the project contains all the software functionality you would like, you are “home free”. If you have excess budget and would like to see how much more functionality you can add or if you are over budget and need to consider eliminating some functionality to stay within budget, then the following is for you.

Let’s say that the requirements call for 10,000 SLOC of C++ code. Using the TruePlanning Software and TruePlanning Systems catalogs, the total cost is $873,299, but our budget is only $750,000. How many SLOC can we purchase given our budget? This question can be answered quickly and easily using the TruePlanning Calibration tool. Open the TruePlanning Calibration tool and select a New calibration. On the Calibration Settings screen, for the Inputs Cost Selection, choose the Software Component cost object and New Code Size. For the Output Cost Selection, choose System Folder and Estimated Cost. For the Target Value, enter the $750,000 and adjust the Tolerance and Maximum Iterations.

Now, on the Calibrations screen, click on Calibrate and the answer appears as the Calibrated Input. As shown below, we can purchase 8,594 SLOC with our $750,000 budget. Next the big question is, what functionality can we safely eliminate in going from the 10,000 SLOC to the 8,594 SLOC?

As you can see, the medical folks are not the only ones who use things “off-label”.    The more you use TruePlanning, the more likely you are to discover new, creative uses for TruePlanning. Off-label is not a bad word or concept.

You need 3 things for your software estimates to be successful

And I will add a fourth one in after I talk about the first 3

1.       You need qualified and experienced people to generate the estimates. They have to know how to estimate and they have to understand what the problem is that the project is going to solve…..at least well enough to estimate it. This can be one person or many depending on the difficulty of the business area. The harder it is, the better having more brains look at the problem. But not to the point where it can slow you down. A team of 2 to 5 people can be faster and more efficient that a team of 8 to 12 and it’s easier to reach consensus.

2.       You need your own data as a reference point in the estimate. As a comparison or an analogy.   Your own data makes selling and explaining the estimate easier. It provides context for it that can enable management to give a quicker and more reasonable answer. 

3.       The estimate must be used as part of the decision making process. If it’s not used its wasted time and effort. When things get tight the estimation will go away.

4.       Automated project estimating software tools to speed up the software cost estimation process and to enable some more what if analysis can be indispensible,

David Seaver,  Solutions Architect, PRICE Systems

I had expected to present my webinar,  “Best Practices for Cost Effectiveness Studies using TruePlanning” in early August. As you might know, I was planning to show a real world example from a recent engagement with a government customer. Unfortunately, since the Source Selection has not concluded with a downselect, I was not able to obtain the public release in time. However, for this month’s blog I will continue share some of the highlights of the webinar.

In last month’s blog we explored the uses of TruePlanning during Source Selection from the Supplier’s (or Contractor’s) perspective. This month, I would like to share with you some of the uses of TruePlanning cost estimating software from the Customer’s (or Government’s) perspective:

• Analysis of Alternatives (AoA) – Is proposed technical baseline cost-effective against other competing alternatives?
• Cost Realism – Are the performers bidding within an accurate range
• Data Driven Estimating – Are the performers bidding based on appropriate, traceable historical data points.
• Independent Cost Estimate (ICE) – Using the performer’s technical configuration, what does a completely independent look say about the performer’s bid?
• Risk Analysis – Is our bid over conservative, how much risk are we willing to take and how much cost exposure can we absorb?
  
• Schedule Estimating – Can we really do the job within the schedule constraints?
• Growth Estimating – What other configurations, materials or technologies might we consider?

While TruePlanning is useful in estimating project costs and all of the above types of analysis, I have found it most useful in developing AoAs. During Source Selection, TruePlanning provides a structured, repeatable framework that can rapidly develop cost estimates across a range of alternatives. These results are often incorporated directly into Operational Effectiveness models along with Measure of Effectiveness and Measures of Performance. In some cases, clients using tools such as Phoenix Model Center can directly link TruePlanning with optimization tools as well. 

Over the past several weeks several users have inquired about the best way to estimate costs associated with porting existing software to a new hardware environment. Normally for this situation some of the existing software will require some amount of adaptation to operate on a new server. However, a large portion of the existing software will only require integration into the new environment.  

Estimating software costs associated with the above will require the use of several cost objects:

- Systems cost object if program management, Quality Assurance, configuration, and    documentation costs are to be included in the estimate

- Assembly cost object to estimate integration costs

- Software component cost object to estimate software adaptation costs

- Software COTS cost object to model all existing software requiring only integration effort 

The main input parameter that should be reviewed with care in the system cost object is project complexity. The default value for this input is nominal. Recommend the low value be reviewed since the team size will be small.

The main input parameter that should be reviewed with care in the assembly cost object is system complexity. If the software is just be ported to the new environment, recommend a low value be selected, since the requirements definition system design has been completed previously. 

The software component input parameters will be treated in a normal fashion. All adapted software will be modeled as adapted new design, code and test. 

The main input parameters that should be reviewed with care in the software COTS cost object are software size, integration team maturity, and external integration. This cost object should be used for all software that will only be integrated in the new environment. Functional size should be used if the size is unknown. The input parameters for integration maturity and external integration must be reduced. The recommended value is 0.05, which is the lowest value accepted by the model. This value will account for much lower integration activity for the existing software.

If you have any further questions, please contact a PRICE Systems Support.

Recently the Director of the Office of Management & Budget (OMB), Peter Orszag issued a directive that was posted on the OMB blog that outlined three specific actions for IT reform. The actions include a freeze on all new IT modernization task orders for financial systems, reviews of current high risk IT projects and require agencies to submit improvement plans to the CIO; thirdly, the OMB Deputy Director will develop recommendations within 120 days to improve the federal government’s overall IT procurement and management practices. Orszag states:

“While a productivity boom has transformed private sector performance over the past two decades, the federal government has almost entirely missed this transformation and now lags far behind on efficiency and service quality.  We are wasting billions of dollars a year, and more importantly are missing out on the huge productively improvements other sectors have benefited from.

Quite simply, we can’t significantly improve the efficiency and effectiveness of the federal government without fixing IT.”

My experience is that government IT project managers are very competent people and they want to deliver on time, on budget results.  However, as confirmed by this survey, 78% of government IT project managers feel that they are not equipped with the people, processes and tools to determine accurate project estimates and to conduct effective program affordability management.  The root cause of late, over budget IT projects are inaccurate, over-optimistic project estimates.  I and others at my company have worked hard to change this, and to ensure that government IT project management are educated about project estimating software but little has changed over the past ten years.  Fundamental change will only result from greater leadership focus on estimating accuracy throughout OMB and agency program management. 

Next month (8/4 @ 12pm EST) I am presenting a webinar to discuss using TruePlanning on Source Selections. What prompted me to develop this webinar were the many recent success stories I’ve had using TruePlanning during the Source Selection process. Going a bit further, I am going to show an actual case study where TruePlanning was used to conduct an Analysis of Alternatives (AoA) exercise – along with cost/effectiveness results. We will explore a bit about the technical side of the proposed designs, develop the modeling in TruePlanning and discuss the results.

In addition, we will explore the uses of TruePlanning during Source Selection from both the Customer and Supplier’s perspective. While they are similar, there are a few differences. Some of the uses of TruePlanning from the supplier’s perspective are listed below.

Supplier’s Perspective

• Should Cost – Are my vendors quoting us the best price?
• Ghosting the Competition – What are my competitors most likely to bid?
• Independent Cost Estimate (ICE) – What does an completely independent look say about my bid? Are we competitive?
• Risk Analysis – Is our bid over conservative, how much risk are we willing to take and how much cost exposure can we absorb.        
• Schedule Estimating – Can we really do the job within the schedule constraints?
• Trade Studies – What other configurations, materials or technologies might we consider?

While sitting in the operatory chair yesterday, my dentist said something that made me stop. He was complaining about an increasing rate of incompetence and apathy he observes in those delivering services to him. And while I do agree with him in principal, he and I are of the age where some folks label us as grumpy old men. So, it may not be as bad as we think. Regardless, the statement he said he made to the an unfortunate poor-quality service provider was, “If you don’t have the time to do it right the first time, when are you going to have time to fix what you did?” Apparently, the excuse offered by the provider was that he didn’t have the time to do the job the correct way, so he tried a short-cut.

Wow! This hit me right between the eyes. I immediately expelled all the material and apparatus he had placed in my mouth so I could tell him how impressed I was with his logic. Plus, I had never heard that expression before. But how true it is and in it I see a glimmer of hope for realizing a key initiative of WSARA (Weapons Systems Acquisition Reform Act of 2009) - getting things right from the start with sound systems engineering, cost-estimating. The path to getting this accomplished is through the people doing the work and not through DoD leadership. As I reflect on my experience with DoD Systems Engineers and Cost Estimators, most I know want to do the job right the first time. If every one of us involved in planning and estimating software, hardware, and IT projects pledges to never take short-cuts, we can make the difference.

There are two reasons for why I don’t think this is just rhetoric: 1. getting things right from the start can’t happen if we are not committed to it; 2. I am unable to conjure up a single example of anything I have experienced in any dimension of my life that started out wrong and turned out right.

I recently had the opportunity to work directly for one of our clients on a high visibility, must-win proposal. The contractor was just about ready to commit to the bid number, but wanted to know the likely bids of the other two performers. We were asked to do a “Ghosting the Competition” study where we ethically collect open source data on two competing designs and combined with engineering technical data to develop a best cost estimate of the competitor’s bid positions.

Unfortunately, not much intelligence was known about the competing configurations, but the engineers recently noticed the other companies displaying their latest technology at a tradeshow event. Based on that information, plus some published marketing data, the engineers arrived at reasonable technology configurations and weight statements. We also established a cost baseline for the client by calibrating past data and using the client’s direct rates and overheads.  Using the TruePlanning estimation software we were able to complete all of the cost estimates in about ten hours including detailed reporting down to the resource and activity level.

Once we were done and happy with the results we were asked to brief the company President. Taking one glance at our estimates, he remarked that what he really needed was an Independent Cost Estimate or ICE in addition to our Ghosting study. The purpose of the ICE was to determine if they were really offering the best value possible to the government…and not just the lowest bid. He requested the ICE within four hours. This caused great concern for the engineers and finance as they had never done an ICE in this short amount of time.

However, using the same cost estimating tools and models (TruePlanning) we built for the Ghosting the Competition study, we were able to quickly and easily generate the ICE in less than four hours. This was done by removing the calibrated inputs for manufacturing and electronics complexity and replacing them with values from the PRICE knowledgebase. We also reverted back to the industry average rates contained in the worksheet sets.

Finally, we completed a producibility study on process improvement using the Manufacturing Process Index input. Using TruePlanning we quickly generated all of the reporting formats at the activity/resource level and export the results to EXCEL, WORD and Powerpoint.

The bottom line was that the versatility of the TruePlanning tool allowed the client to quickly and efficiently develop several types of analysis required for a must-win proposal with minimal impact on staff and in a very short amount of time.

Like titanium and other exotic metal-materials, “composites” (by definition, combinations of materials) offer significant weight-savings and reduced part counts, but at a price of high production cost. Sound contrarian to our parametric cost estimating view?   Not really. Complexity of manufacture is quite higher. Likewise process index and structural tooling values grow. Plus, design lead times drive developmental cycles.

That said, understand that composites represent more than a material type. They can involve a highly labor-intensive approach to preparing, braiding/ winding, molding, bonding and modular assemblage. Yes, some aspects of braiding and molding lend themselves to automation—which then drives tooling investment. Composite development offers design flexibility, weight savings as well as advantages in long-term deterioration. But not all pre-curing processes are the same, to include recent advances in structural co-processing before subsystem cure.

At this juncture, rather than get ON a soap box, I’d ask that you join me in help getting us INTO a soap box. 40+ (!) years ago, my engineering Dad challenged my brother & I to make a soapbox derby car from fiberglass. (My uncle worked at little known Owens-Corning at the time, and material costs were cheap!) To make a long story short, Dad required that we not get “gluey” too early and instead had his two very young sons learn the benefits of (pre-CAD/CAM) design drawing. So draw, sketch, and describe we did. Talk about information entropy! But the more we had to draw and detail a component’s design with the physical and functional features Dad needed to make it exactly right, the longer (more time) it took him with each piece… and the more our “cost” (waiting anxiously to ride) went up.

25 years later, MIT’s Hoult & Muter would have been proud: we realized that amount of information communicated was the driver in our composite manufacturing process. Multi-dimensions are one thing to grasp at a young age. Communicating corresponding tolerances is a bigger challenge. The latter are typically known as “feature parameters” in engineering circles. Suffice then that to estimate composites processing, the more effective predictor of cost is entropy between design and build.  

And how would we propose to count all relevant exchanges of information, including these latter parameters? The same way perhaps that parametricians characterize early stage software concepts visualizing inputs, outputs, data stores, elements (toleranced dimensions), operators (processes), etc. Just like using Function Points in software cost estimation! Over the next few months, we’ll examine this new approach following more composite cost research and predictive modeling using an information entropy statistic. Stay Tuned!

John Swaren
Solutions Consultant, PRICE Systems
 

Parametric modeling is excellent for all aspects of early-concept cost estimation, including go/no-go decisions downstream. So, in the spirit of bringing a transparency to (ethical) financial engineering…
why not apply our craft to pricing “real-options”?

The latter are essentially strategic opportunities for engaging resources (cost/schedule) into projects, ventures, investments, or even abandonments. The opportunity choice has value itself! 

Unlike static project Net Present Value (often, but not exclusively, approximated with Discounted Cash Flow) assuming pre-defined decisions, real-options reflect the merit of flexibility. If an R&D or proof-of-concept presents viability/ marketability learning, the option has positive value, above and beyond DCF. The more the flexibility, the higher the value. Likewise, a real-option appreciates with more uncertainty.

By now, you’re asking—“Wasn’t this a parametrics blog? I’m an engineering/ computing/ math/ science type, not a quantitative-finance geek. How could the above possibly help me any”?

Answer: In some situations, specifically go/no-go, the value of your flexibility created with the strategic choice to move forward (or not) can exceed its “option” cost. Not all options should be executed, just as all go/no-go decisions aren’t go’s. But, over time, continuing to pay less than their market value creates an opportunity to average out with total economic-value creation.

But, you say— “How do I find the cost of this flexibility/uncertainty option? It sounds great that I can make investment decisions based on buying/ executing (or not) these options, but do I really need to learn fancy finance stuff like Black-Scholes, Value Trees, Binomial-Risk Neutral Pricing… based on risk-free rates of return and (expected) discounted cashflows…. Yikes!”

Answer: (& bottom-line, for now) No. Use your parametric estimating tool! Concerned about the hardware cost of pilot-production/ tooling? “Buy” an option priced as the cost of preliminary design. 
{Note that the latter cost is your option’s premium, and the go-ahead cost is your option’s strike price.}
Interested in the nonrecurring cost of large-scale full software development? Buy an option for the
cost of first iteration increment. Concerned about COTS versus assembly? Estimate the development (and integration) of both scenarios. 

The point is take an economically-disciplined approach to valuing your strategic choices downstream. Parametric modeling works here and is “data-driven” defensible.  It is certainly applicable to strategic investment, capital -budgeting and new business decisions within both the public and private sectors. Transparency through mathematics is a good thing.

One of the great features of the TruePlanning cost management software is the fact that it makes it easy to handle complications of inflation and estimating projects performed in different countries and currencies. The costs associated with doing work in different countries, and the relative value of different currencies is constantly changing. To address this, the cost research team at PRICE does an annual economic update performed by the cost research team, and this blog will introduce some of basic concepts and research that goes into maintaining this feature every year.

The price of goods and services changes over time, and this value is measured by inflation rates (if prices have gone up) or deflation rates (if prices have gone down). These inflation/deflation rates are constantly updated for many different currencies by the International Monetary Fund (IMF). In TruePlanning, we use past and predicted inflation rates published by the IMF  to determine the cost in today’s currency of doing work in the future, for whatever currency you want to use. Within the TruePlanning tool, these factors can be applied to help produce a cost estimate of work that takes place over a long period of time, with the cost estimate shown in today’s currency values.

In addition to inflation/deflation rates for different currencies, we also recognize that the price of goods and services may be different from one country to the next (i.e. a U.S. Dollar exchanged and spent in India will buy more haircuts than a dollar spent in the United States). The degree of these price differences can be measured by looking at Purchasing Power Parity (PPP) data of a country. Standard PPP values are calculated or compiled and published by the Organization for Economic Co-operation and Development (OECD). The PPP rates published by the OECD are used in the TruePlanning tool to estimate costs of performing projects in different countries, as the cost of doing the same amount of work in different countries can vary significantly.

By automating the application of these and other economic complications of cost estimating, the TruePlanning tool helps create a process in which the effects of these economic factors can be applied consistently and correctly for all your cost estimates.

Last month I blogged about the importance of cost realism, its roots and how as estimators we must always reflect the truth, no matter how unpopular. This month I want to share with you a recent experience on a Source Selection. As part of the Source Selection team, my role was to conduct a Cost Realism estimate on each of the performers submitting bids. I want to share with you a few insights from that experience.

One of the first rules I always follow is to never ask engineers to provide data that you can readily find. I rarely will use parametric data forms, as you will get to be unpopular fast with those you task with the honor of filling them out. Rather, I dig into the technical and cost volumes to derive the configuration, technology, weight statement, rates/overheads and other juicy information to populate TruePlanning.

Once I have the TruePlanning cost management software populated with all of the data I can derive from existing documents, I will then ask the subject matter experts in each area to discuss the other qualitative/quantitative factors about each performer. I can usually guide this conversation to derive inputs such as requirements stability, engineering complexity, integration and others. I find it effective to hold this meeting remotely using Go-To-Meeting so everyone can see my desktop displaying the TruePlanning model and no one has to leave their desk. When inputs are critical cost drivers, I usually pop up the wizards or generators so the engineers can see the choices available.

Once the model is fully populated and all inputs agreed to, I will then produce a very well documented estimate with all assumptions as the final deliverable. In this particular case the Source Selection team was very pleased with the result and asked if we could extrapolate a new configuration based on some technical changes proposed by the performer.

Using our well qualified TruePlanning model, we ran the extrapolation and reported to the Source Selection team that we expect to see a large impact. Initially, no one believed the results; it could not be so they said! However, several weeks later, when the performer’s new estimate arrived, we were within 1% of the revised bid. During this time period, the Source Selection team was able to successfully prepare a negotiating stance based on the expected bid coming in as predicted.

In all my years as an estimator, I have only seen estimates go up as more is known about the technical configuration. Bottom line, as estimators we are the “front line” for telling management the hard to hear truth. In this case, at least they were prepared!

Earlier this week I conducted a webinar intended to make PRICE users aware of the Cost Research Services available to them as part of the license fee they pay to use PRICE products. I thought I would recap the highlights of this webinar for those of you who might have missed it.

At PRICE we understand that cost estimating tools, while useful and valuable, do not always present the complete solution. Every single cost estimation projects presents new and unique challenges.  We think it's important that in addition to solid, time trusted cost estimating models, our users have access to the many years of experience we have as seasoned costestimators, subject matter experts and operations researchers.

This service is nothing new.  For the 30 years that PRICE has been in existence, we have worked as partners with ourcustomers to optimize their use of our models and methodologies.  This was just an opportunity to formalize the offerings and remind the community what services are available.

So what does the Cost Research team at PRICE have to offer the cost estimating commmunity?  On average our researchers have more than 24 years of experience with hardware estimating, software estimating, operations research or some combination of the three. We are constantly engaged in cost research projects addressing market needs as they arise.  The results of these studies vary depending on the need they attempt to address.  In some cases, data collection indicates custom models should be developed.  These can be developed and deployed in TruePlanning, the flexible cost estimating framework.  Some results are published as updates to tables or calculators in the PRICE Software and Hardware cost estimation models.  White papers, webinars and the PRICE blog are all means we use to communicate the results of cost research studies.  

PRICE's Cost Research Team is available 24/7 to address users cost estimating question on an as needed basis.  Some issues require more attention than a single phone call.  Users are encouraged to schedule working sessions with one or more of our analysts to take a deeper dive into cost estimating issues that perplex or intrique them.

Some areas the team is currently studying include Total Ownership Costs, Joint Confidence Level, Performanced based models for technologies such as FPGAs and ASICs, semi-rigid cables, and  Operations and Support costs for space systems. 

The most important thing the cost research team at PRICE wants to do is make our clients better estimators while adding value to the cost estimating community as a whole.  We can't do this without input from our clients.  Share your cost estimating challenges with us.  Call, email or comment on our blog.  856-608-7201 or info@pricesystems.com