Software Development Costs

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.

The following is an extract from a paper written in 1978 from one of the founders of PRICE Systems: 

Two questions are often asked by those unfamiliar with TruePlanning’s approach to cost modeling: What is your CER (cost estimating relationship)? And what is your data base?

These questions are closely related.  Both are based on the assumption that the PRICE modeling approach is the same as that customarily used in developing cost estimating relationships.  This is not the case. 

The customary approach is to first gather as much relevant data as possible, then screen the data for consistency, reduce the data by formal statistical procedures and present the results in the form of one or more estimating relationships.

In contrast, the PRICE approach is process oriented rather than data base oriented. 
Models are designed to emulate the processes by which experienced managers, engineers and cost estimators assess the impacts of key cost and schedule drivers.

The strength of the classical approach is that it enables investigators to test hypotheses and identify significant factors that have affected past developments.  PRICE does not ignore these results.  Indeed, similar procedures are often used in preliminary model development.  As a consequence, there is nothing in the PRICE models that is inconsistent with classical results.  The difference is that these results are not an end in themselves.  When blended with quantifications of other subjective, but no less valid, perceptions by experience people, they contribute substantially to the PRICE methodology.

The weakness of the classical approach is that it is data base limited.  It does not extrapolate well when applied as a cost estimation procedure to new situations.  In fact, it usually does not even adequately describe the underlying data base.  Data definitions are often inconsistent, and data poorly recorded that fitted equations are questionable at best.  Extensive screening to eliminate inconsistent and unrepresentative data results in so few cases that the richness of single equation models is severely limited.  These models simply cannot account for all of the factors that drive costs.

The principal reason for the success of the PRICE model is that it does not depend on a single CER or on a single data base.  By focusing on the process of rational cost estimation, it preserves for the user the flexibility to tune the model to the particular data base most relevant to the estimate in question.  This will normally be cost histories of previous projects within the users’ own organization or product line. 

In effect, the PRICE model develops a new family of CERs to fit each specific application based on the data base it is tuned against.

Over the past several weeks several users have inquired about the best way to model software code translation when estimating software costs. Software code translation consists converting existing legacy software source code that was developed in a specific high order language (such as Ada or C) and translating it to a new high order language (such as C++). The translation does not add new functionality. For example, translating Ada code to C++, simply results in C++ code. The major benefit of the translation is maintenance. Ada experts are not needed to maintain C++ software for this example. The code and unit test activity is the major cost driver for a software translation.

Modeling this type of code translation is very straight-forward in the TruePlanning for Software model. Two input parameters should be evaluated for modeling this scenario: Auto-Translated Code Size and Auto-Translation Tool Efficiency. The translated code size should be entered for Auto-Translated code size. However, the translator may or may not be very efficient. This is the purpose of the translated tool efficiency input parameter. A drop-down dialog box is available.. The range is from “Very Low” to “Very High.” The efficiency of the translator should be selected from this dialog box. 

The purpose of the dialog box is to account for additional cost or effort due to a poor translator. For example, if the code translation size entered is 10,000 and the translation tool efficiency is Nominal or 80%, then the model will assume that 20% or 2,000 SLOC (source lines of code) will have to be manually translated into the new HOL. 

If you have additional questions concerning software code translation, please contact one of our PRICE Cost Research Analysts.

Jim Otte
Solutions Consultant, PRICE Systems
 

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.

Currently we are exploring the best approach to including a more comprehensive cost estimate for Total Ownership Costs (TOC) into TruePlanning. The current version of the software has focused on development and production costs with some life cycle costing including. The life cycle costs included are focused on the system specific O&S costs such as initial spares for priming the supply pipeline, maintenance, replenishment spares, etc. It is a system view as opposed to a program view of TOC.

As we better understand the need to conduct affordability studies it has become clear that design decisions which can be assessed in regards to their total ownership cost will result in more affordable systems. In order to do this we need to include a greater range of cost elements such as construction of system support facilities, O&M of infrastructure and system facilities, some personnel cost which are enterprise level not necessarily systems specific and so forth. What is not clear is how these elements differ from different customer perspectives.

For example, our current lifecycle costs have an original equipment manufacturer (OEM) flavor to it. Whereas I speculate that a PEO, PM, or service staff analyst might have a need for a broader set of elements. Feedback in this regard from our customers would be very beneficial.

Bob Koury
Senior Cost Research Analyst, PRICE Systems

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.

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


 

I am excited about the efforts described in Derek Kaufman’s article on the AFMC website.  For the complete story please see this link http://www.afmc.af.mil/news/story.asp?id=123202181. The DoD is investing in the rapid build up of a new foundation of acquisition workers focused on estimating costs and negotiating prices through continuous learning. 

Mr. Assad notes that Wright-Patterson Air Force Base, Ohio, was once the preeminent DoD recognized leader at estimating costs and negotiating prices with defense contractors. It's a skill that has been allowed to atrophy, he noted.   "We need to build that pricing capability back up," he said. "It's extremely important for us to have world-class pricing talent, so that we make sure that we get a reasonable deal for our taxpayers."

For over 30 years, PRICE Systems has passionately supported this same vision.

Every year we train hundreds of analysts and acquisition professional across the globe. We proudly offer training on topics such as source selection support, software cost estimating fundamentals, data collection and total ownership costs.  And recently we introduced an on-line acquisition training center, known as PRICE University, where students can gain continuous learning credits through self paced study, right from their own desktops!

If you haven’t had the chance to hone your skills as Mr. Assad suggests, I invite you to start today by taking a quick tour of PRICE University - http://university.pricesystems.com/index.jsp

I have been frequently asked to do crosschecks on other people’s software cost estimates which are potentially done in a variety of tools from spreadsheets to SLIM.

One of the common operator errors I see from other users is not understanding what activities and resources are included in the outputs of the particular tool that they are estimating with.

This is akin to deciding between two cars and not knowing if both come with the same sets of features (stereo, AC, heated seats).   With software estimation tools you need to know what work is getting estimated by the tool. (Requirements, Design, Code, Test, Documentation, System Test) and what resources are included in the effort estimates to accomplish those task/activities. (Programmers, Analysts, Architects, Systems Engineers, Testers, Tech Writers, Project Managers, QA and CM)

A common mistake I see is generating an estimate with a tool then adding in Program Management effort and cost when the tool utilized already includes those activities and resources in the estimate.

That’s why I drive a pearl black TruePlanning 2 door coupe.

Software project falures coupled with rapidly changing business needs are forcing organizations to revisit the way they go about buiilding software.  Agile development has emerged as one possible solution to the woes of the software industry.  Agile enthusiasts claim significant increases in productivity and quality, while detractors cite instances where the reverse is true.  It seems to me that probably both are right  - some of the time anyway. 

Agile means many different things to different organization.  There is a long list of agile tenets but not every method of agile applies all of them.  And some organizations have cultures which adapt well to agile methods while others don't.  All of these things affect the 'success' of applying agile practices to your organization.

Personally I don't think that most agile practices inherently improve productivity.  The long term application of agile within a cohesive development team should definitely improve their productivity but this would probably be true of the same team if they were applying some other philosophy.

I do, however  think there are agile practices specifically focused on improving the quality of the software that is delivered.  My list follows.....

Test Driven Development  No code is written until there is a test.  Business Analyst build tests that coders use to determine if the code meets the requirement.  Only enough code is written to make the test pass.  As code is refactored (improved) over time, the test remains to ensure that subsequent changes do not degrade the initial requirement.

Continuous Integration and Automated Testing  Builds are run with each change to the code base or at regulalry scheduled intervals during the day.  Suites of automated tests are run against each build.  When tests fail making them pass because a number 1 priority of the test

Pair Programming  All production code is written by two coders  one at the key board and the other navigating, correcting and thinking of better solutions.  Sort of like just in time peer reviews.  Pairing occurs regularly throughout the development - with no set pairs but rather pairs that make sense at the moment.  Driver and navigator roles should shift often. 

Customer involvement  Customers (or their surrogates) actually participate on the development team helping the business analysis develop the right tests and testing and reviewing the frequently released versions of the software

While these practices are included as tenets of agile, a shop need not be 'agile' (in the purest sense of the word) in order to incorporate one or more of these quality focused practices into their software development processes.

To read more about Agile practices and software quality check out my article in Software Tech News 

The newest version of TruePlanning has been released and distributed to customers. The new features were designed to make it easier to estimate entire systems, not just individual components  or sub-systems. TruePlanning is an excellent solution in this regards.

Systems that require you to estimate software costs, hardware costs, and the integration of multiple pieces of each can all be done in one framework. There are  specific features in this release, like input inheritance, that allow you to make changes at the top Project level which then flow throughout the entire system.  This saves an estimator or an engineer lots of time as typically they have to dedicate time to making sure that there is consistency from the top level of a systems throughout.

Other enhancements include improved help and guidance. While using TruePlanning’s built-in calculators to come up with good inputs, you are also informed through pop-up messages and alerts  about what inputs need to be entered or should be entered based on what you have already told the software. We’ve added more charts and graphs that give you visual clarity of how specific inputs of the models effect certain estimated costs. There is also a new Help System that is easy to navigate so you can  locate information that can help answer questions you may have as you are building your estimate.

For more information visit our New Release Info page.  

Failed software projects are always bad but there are additional complications when there is a contract in place to deliver the software.  Disputes over failed software can result in costly litigation that generally damages both the vendor and the buyer. According to observations of Capers Jones in "Conflict and Litigation Between Software Clients and Developers" (2007) , 5% of the projects his clients were involved in either had litigation pending or were currently involved in litigation over project failures.  His findings indicate that it is very large projects, over 10,000 Function Points that are most prone to litigation, which makes sense if you consider the relative increased complexity, as well as the large amount of money such a contract would involve.  Although one occasionally hears of pending litigation over software projects in the news, determining the background and outcomes of such litigation is difficult because they involve large customers and software contracting organizations, both of whom would rather keep their failures out of the spotlight.  This is likely a significant contributor to the fact that such litigations still occur since the industry is denied opportunities to examine and learn from the mistakes of others.

A report in Computer World [6] details a law suit filed by health insurer Highmark against KPGM for malpractice, fraud and brief of contract for a software system that Highmark had outsourced to KPMG.  While the article does not detail the outcome of this lawsuit, it makes it clear that the disagreement stemmed from misunderstandings and the failure of the two organizations to communicate and collaborate.

In light of this I have compiled a list of four responsible actions that both bidder and buyer should engage in when software projects are outsourced.  These may seem like common sense and the same old story, but clearly they bear repeating......

1. Create and Communicate Good Requirements ... misunderstood, constantly changing and new requirements are a common source of angst in software development projects.  Bidders need to understand the buyers requirements, document them fully, and incorporate the risk of requirements growth into their plans
2. Create and Maintain a credible cost estimate - the buyer needs to know what the effort should cost to evalute bids.  The bidder needs to properly assess the cost to them in order to make the project profitable and to avoid having the project cost them money
3. Understand and document risks; Plan up front for risk mitigation - bidders should work with buyers to understand their uncertainties.  These uncertainties need to be incorporated into the estimate and documented in the contract.
4. Create and maintain a cooperative relationship... when bidders and buyers collaborate and work nicely together, bumps in the road and set backs are handled sensibly, reducing the possiblities that things get out of hand.

Recently I was interviewed by Doug Beizer of Federal  Computer Weekly for an article about the shift of government agencies away from custom software development and towards the use of cloud computing.  The interest in this topic seemed to stem from the introduction of Apps.gov online store earlier this month.
 
Having been in the software cost estimation community for more than 25 years,  I have experienced this transition first hand but never really stopped to think about the whys and wherefores until questioned by Doug.  It was an interesting stroll down memory lane.  As an example, just think for a minute about how much communication has changed.  When Ifirst started working if I needed to discuss something with a co-worker or friend I either needed to pick up the phone or pick myself up out of my chair and go talk to them.  If I wanted to leave a paper trail – I actuallyneeded to use paper.  There was no internet, no e-mail, and certainly no social networking.  Like everyone else,government agencies needed to develop custom application to meet specific communication, networking and other needs.  Because the government had many communication needs – both on the business and mission side – government agencies became a leader in developing these types of applications.
 
With the advent of the Internet and ever evolving forms of social networking, the commercial sector has been forced to get really good at developing communication software – so good that the government agencies are nowl ooking more and more to the commercial sector and the cloud for such capabilities.  Not to say that all government needs can be solved with commercial solutions, but many more so than back in the day.  And while communication capabilities are my favorite example, let’s face the fact that there’s a lot of software out there– many of it that’s completely adequate (if not superior) to meet the needs of the government.

Let’s start with a simple test. Which is greater: the number of six-letter English words that have "n" as the fifth letter or the number of six-letter words ending in "ing"?

If you are like most people you’re thinking the correct answer is six-letter words ending in "ing". But most people are wrong. And the reason is simple, people rely on what they can easily recall. Since it’s much easier to think of 6-letter words ending in "ing" the fact that people come to that conclusion isn't suprising. Psychologists refer to this as availability bias. This type of bias gives more importance to things that we can vividly remember and easily recall. All too often, bias like this plays a prominent a role in the development of estimates. (By the way, the group of six-letter words that have "n" as the fifth letter include all of the six-letter words ending in "ing")

Part of the power of parametric cost estimating is the ability to substantially diminish this bias and to fill in where data is lacking. A parametric approach uses sophisticated mathematical equations along with historical data from similar systems or projects in combination with existing organizational data to produce an estimate that is external to the types of biases that often plague estimates. Once organizations are estimating software, hardware or systems of systems using a parametric model, the accuracy of the model will increase as data is captured from other projects. This systematic collection of actuals compared to estimates over time leads to data driven decision making.

Parametric cost estimating is a widely used approach for bidding on a contract, input into a cost benefit analysis, or as the pre-planning tool for project implementation. Extensive literature reviews suggest that an effective parametric cost estimating methodology is becoming an essential tool for technology-driven organizations. The use of parametric estimating in budgeting, scheduling, and control of projects will enhance the ability of project management organizations to effectively and efficiently utilize valuable resources. The benefit of parametric cost estimating tools is its use as an estimating model for better determining potential resource requirements during the project pre-planning and conceptual phase. When software cost estimation is performed using a parametric approach with proven commercial framework, the benefits realized far outweigh the cost of doing the estimating.
 

In an article in last weeks Harvard Business , IT Costs: Do You Speak Their Language), John Sviokla discusses the fact that as the information business continues to grow it is increasingly important for organizations to understand the impact of IT as it relates to their operating costs. This certainly rings True to us here at PRICE Systems who have recognized this reality. TruePlanning 2009 has been developed by PRICE specifically to help organizations get their heads around the true costs of Information Technology.

Application development projects can represent significant expense to an organization and tend to be the riskier items in the IT budgets. But it is important to recognize that they represent only a small part of most organizations IT budgets. According to Gartner’s "IT Spending and Staffing Report 2008",on average organizations spend about 20% of their IT budgets on application development. The rest of their budget is spent on hardware, software, networking, maintenance, as well as data center and help desk activities. The figure below indicates the typical distribution of IT costs based on this report:

From this last report we see that over the last 7 years the distribution of investment dollars between on-going operation and growth and innovation has remained steady with operational expenditures dominating. On average, organizations have spent 65% of their budgets to run the business, 21% to grow the business with a mere 14% of the budget left to transform the business.

With technologies such as SaaS and cloud computing, there is potential for organizations to make decisions to change this picture but they first need a way of identifying what in their IT organization is driving operational costs. TruePlanning for Information Technology makes it possible to model both your appliation development projects and the IT infrastructure (at a micro or macro leve) to help identify the best choices for optimizing Information Technology