It’s a common practice to measure failure or success of a project based on the initial functionality requirements and initial cost and schedule estimated.

 

The Standish Group publishes its Chaos report for software projects which terms a project as a "Success" if it is completed on time, on budget, and satisfying all the initial requirements. Projects are deemed a "Challenged" if functionality is achieved but cost and schedule over runs occur and "Failed" if a project is cancelled while in execution.

 

However there are other factors e.g. Tom DeMarco’s  Estimation Quality Factor  and Boehm’s Cone of Uncertainty (COU) or combination of these two (a brief analysis of these two factors can be found in the Jan/Feb IEEE Software magazine The Rise and Fall of the Chaos Report Figures: http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2009.154).  

 

The questions is, does your company measure project success/failure based on initial software estimation? If yes , what methods are used at your company to establish the matrix (Standish, EQF, COU, any other)? In your opinion what is the value of software estimation accuracy?

 

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.

The cost estimating community mourns the loss of a true pioneer this week. Our thoughts and prayers are with his family. Frank Freiman has a special place in the history of PRICE Systems as his innovative work is directly responsible for the company’s existence today. This is a classic case of where one man can truly made a difference. Thousands of estimators across the world have benefited and continue to benefit from his accomplishments.

Frank began studying the applications of statistical quality control as an officer in the US Army during World War II. It was this experience that led him to pursue graduate studies at NYU where he began examining cost estimating relationships or CERs. It was during this time that Frank began early development of his weight based production model, which would later serve as the fundamental assumption for the first commercial parametric cost estimating model, PRICE H.

After graduation Frank was employed at Federal Manufacturing and Engineering in Brooklyn, NY. It was here that Frank analyzed the cost and physical parameters of more than 700 products. From this analysis he developed a method for "normalizing" the effects of production, schedule, organizational experience, and product staging. His study also included the effects of differing production schedules on cost as well as the impact that mature technology had on reducing manufacturing costs.

In 1957, Frank was hired by RCA Missile & Surface Radar Division in Moorestown, NJ to lead its cost estimating department. His main responsibility was to review cost proposals. In 1969, Frank began to integrate his database of CER’s into a basic time-share computer (BTSS) which was connected by a phone line. This was the origin of the first PRICE model.

In 1975, Frank became the first Director of the newly developed PRICE Systems business unit. Frank would also later be instrumental in the establishment of ISPA, the International Society of Parametric Analysts. The Frank Freiman award is the society’s highest honor given to individuals recognized for exceptional achievement in the area of parametric cost estimation.

Frank had retired to Pompona Beach, FL and passed away on December 13, 2009.

A special thanks to Hank Apgar, much of the bio information came from his article "Who is Frank Freiman" published in Parametric World. Please add any rememberances to our comments section.

It seems that business and government today is mired in cost-benefit analysis. The cost side is fairly easy to understand: how much money will the business (or government) have to expend to deliver a given service? Benefits are a little harder to quantify.

First, there is the difference between monetary versus non-monetary or social benefits. Some things like the office Christmas Party do not make any money but they keep morale high. Second, there is the difference between short-term and long-term costs and benefits. The company using Blackberries may bring the immediate satisfaction feeling mobile and linked into work but there may be some long-term costs.

Does our decision-making process really take these factors into consideration? Do people who live beyond their means really weigh the long-term financial cost of living on credit versus the immediate (non-monetary) benefit of feeling important? Do we consider the long-term productivity gains by investing in work-force/employee training immediately?

Unfortunately, I think the heart wants what the heart wants. Businesses and individuals do not weigh benefits in a methodical manner. So until the day when benefit analysis ceases to be in the eye of the beholder, we should focus on accurate cost estimation.

Bill Scheessele’s article in the Washington Technology, Time for a hard look at marketing strategies,  is a quick read about organization’s reacting to these new economic conditions.

He suggests that most organizations are...

"Attempting to move forward with an obsolete business development operation, reacting to fewer opportunities and shifting budgets by shedding business development personnel, sticking with an outdated business development process that everyone in the industry uses, or doing nothing while waiting on the sidelines for conditions to change are not reasonable decisions."

This is further supported by the recent flurry of acquisitions both inside and outside of the federal market space.　 At least organizations acknowledge their lack of agility and ability to evolve and are acquiring expertise and capabilities in new market areas that provide the HOPE of growth – and stability.　 Regardless of the methods, business as usual is not an option.

Mr. Scheessele proposes a few proactive ideas that organizations should consider:

Invest Resources in conducting a comprehensive assessment of your entire business development operation: plans, personnel, and processes.

Design, build and implement an up-to-date, customized busines development methodology that fits your organization's mission, culture, and offerings and provides the structure, discipine and thinking necessary for revenue growth.

Like Mr. Scheessele, PRICE Systems believes in developing processes that enable organizations to become more nimble and proactive. 　　We are constantly asked to support process improvement initiatives to do just that. 　

If you are interested in how your organization can achieve some of the practices Mr. Scheessele’s promotes, take a look at Dale Shermon’s recent webinar or go take a look at PRICE Systems Bid & Proposal Solutions 

Recently, Dale Shermon presented a webinar, "Preparing Bids Faster with Fewer Resources".  The content for the webinar was taken, as the title of this post suggests, from the recently released book Systems Cost Engineering.

The webinar discussed how parametric estimating could dramatically decrease the time and thus the cost that is required to make important business decisions about whether or not to pursue contract opportunities. There are critical activities that organizations engage in every time there is an RFP such as Bid/No Bid decions or competitive assessments.  So whether the RFP calls for estimating software costs or a system that requires hardware/software integration, parametric estimating can provide fast and accurate information for making decisions. PRICE has been able to save its clients millions of dollars by reducing the resources typically needed to make these decisions and ultimately win the contract.

The presentation also does a nice job of walking through the different applications of parametrics. So if you are unfamiliar with this type of estimation, Dale's commentary at the beginning of the presentation can be very useful. But I'll let you be the judge.

To download the recorded version of this webinar go here.

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.

Whlie most of the books on the topic of parametric modeling take a look at detailed techniques and fundamentals, such as building parent/child relationships or the mathematics behind models, Systems Cost Engineering, takes a more practical perspective to answer a very basic question:  What can parametric estimating do for my organization and how can we implement it? 

The book covers an array of business processes that can be dramatically improved with the application of a standardized parametric cost estimating framework. These processes exist across multiple phases of a program's lifecycle  such as early concept planning through development and production. Chapters are devoted to various How To's such as preparing bids faster, better business planning, evaluating vendor quotes, estimating software costs and schedules and analyzing risk and uncertainty.

The book is a collaboration of work over the past 30 years in the field or parametric cost estimating. It was brought together by PRICE Systems executive, Dale Shermon, who was recently awarded the Frank Frieman Award the International Society for Parametric Analysts' highest honor.

The book is available for purchase at Amazon.com and from Gower Publishing.

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

 

Bad project estimates lower profitability.  Despite this fact many business leaders don’t invest in improving their estimating capability, buying into the fatalistic myth that this is as good as it gets.  This is patently wrong.  Project portfolios are prioritized based on the total expected Return on Investment (ROI) of projects.  Investments in the wrong project based on bad estimates could lead to lost revenue or delay of net benefit.

All around us we see reports of software projects which are over budget, delivered late or cancelled because they are taking too much time and money.  This very fact makes it easier for business leaders to throw up their hands and accept bad estimates instead of proactively looking to improve their estimating capability and their profitability.  It doesn’t have to be this way.  Any organization can turn this around with careful analysis of their own history combined with analysis of relevant industry benchmarks.  TruePlanning by PRICE Systems contains the methodology and cost estimating software  to help business leaders utilize history to improve project planning and avoid making bad decisions. 
 

It's finally Spring!  And along with the leaves on the trees, the beautiful flowers and the happy chirping birds.... it is once again Baseball Season.  Baseball season is a beautiful thing - and not just because, as a resident of South Jersey, my team is the 2008 World Champion Phillies.  I just love the game and everything about it.  I believe this is because with baseball the impossible becomes possible because anything can (and will)  happen and with a good plan in place you can still be successful.

I didn't always love baseball.  When I was a kid growing up in Baltimore - my Dad - a huge baseball fan - would take our family to Memorial Stadium to watch our beloved Orioles play. It was fun for the first few innings but after the hot dogs, sodas and peanuts were finished - it started to get a little boring (Sorry Dad but I just didn't get it).  Years later, as the mother of young little leaguers I actually detested baseball.  The only things worse than spending all your evenings at the little league field watching bad pitchers (cause they were learning) throw balls to bad batters (who were also learning) was the drive home with aforementioned (now angry) bad pitchers and/or hitters.  But as my boys matured something miraculous happened.  The kids started to play well and I started to enjoy the games.  The more enjoyable the games were the more I cared about the rules, the nuances, and the numbers of baseball.  Only after this journey did I realize what a great game baseball is.  A good team with good players, passion and a coach with a good plan can turn almost certain defeat into victory.

Project Planning is not all that different. When starting a software development project you need to start off with a plan and then you need to recognize that absolutely anything can happen.  Like a good coach you need to understand your risks - and you need to have contingency plans in case something unexpected happens.  A tool like PRICE Systems  TruePlanning for IT is a good place to start.  TruePlanning not only supplies cost and effort estimates based on descriptions of your project and your team, but it lets you indicate the uncertainty in these descriptions to add a level of confidence to the plan produced.

I have to say that my foray into blogging has been an interesting one.  By definition, the Chief Scientist should be a nerdy sort of geek too high brow to pontificate on topics in such a pedestrian format.  Actually I kind of like it.  In part because I enjoy writing and I'm not picky about what I write - technical documents are OK but pontification works as well.  And in part because I know that in order to be a good writer in a particular genre one must read extensively from that genre.  In other words I now have a good excuse to surf the web for related blogs and have found great ideas that have fueled my imagination

Today I want to share an article I found on 'Quips On Software Development' by David Longstreet called "Ancient Wisdom for Software Estimating".  In it Longstreet traces the need for good estmating all the way back to the Bible.  From Luke 14:25-33 Jesus says to the crowd of discipleship "Which of you wishing to construct a tower does not first sit down and calculate the cost to see if there is enough for its completion?  Otherwise after laying the foundation and finding himself unable to finish the work the onlookers should laugh at him and say, 'This one began to build but did not have the resources to finish'"

Of course this was posted on April 1st so my first thought was of practical jokes. After thinking about how cool it would be to get this kind of powerful buy-in on the importance of estimating I figured I would check it out.  So I powered up another browser and went to Bible.com (who knew!).  Sure enough it was the real deal.

So what's my point here?  Regardless of your religious beliefs - it seems prophetic that a document representing life and times more than 2000 years ago recognizes the importance of estimation and resource management.  And further acknowledges the fact that people will notice if you say you're going to do something and then don't finish it because you've run out of time or money.  Even before there were machines or factories, computers or software; before the words process improvement had ever been uttered - people understood that estimation was important when embarking on a project. 

The next time you think about starting a project with a WAG (Wild A** Guess) or with the number your boss wants to hear - first stop and ask yourself... "What Would Jesus Do?"

Here’s a great article I happened upon while doing research for a paper I’m writing.  “Lessons Learned: IT’s Biggest Project Failures”  In this article we are treated to stories of IT projects that “first make people laugh and then” (hopefully) “make them think.”  As a long time student of the failed software project, I was neither surprise nor disappointed with the projects relayed.  The projects noted failed for reasons such as:

• Failure to perform a should-cost analysis before selecting a supplier
• Failure to recognize an unhealthy project before it was too late
• Unrealistic and aggressive timelines
• Scope creep.

Doing business with the Department of Defense (DOD) requires that you have disciplined company governance in specific areas as noted in the Defense Federal Acquisition Regulations (DFARs). In particular, DFARs 215.811 and 252.215-7003. DFARs 215.811 requires all DOD contractors, large and small, have adequate estimating systems to support their proposals. As part of a regulatory oversight requirement, the Defense Contracts Audit Agency (DCAA) will periodically perform contractor estimating system reviews. If you are a large defense contractor, you can expect your estimating system to be reviewed routinely. Smaller defense contractors can be audited at any time at the request of their customer. If DCAA finds that you have estimating system deficiencies, "Flash" reports are broadcasted to your customer and other defense agencies. If the deficiencies are serious, you may be suspended from submitting any further proposals until your estimating system is deemed adequate.

So what is an adequate estimating system? It is DOD policy that contractors have estimating systems that consistently produce well supported proposals acceptable as a basis for negotiating fair and reasonable prices. Estimating systems should be consistent and integrated with a contractor's related management systems, and be subject to applicable financial control systems. To be considered adequate, an estimating system must be established, maintained, reliable, and consistently applied. It must also produce verifiable, supportable and documented cost estimates.

DFARs 215.811-70 delineates attributes of an adequate estimating system. So if your estimating system is tested, you will be scored on following:

The Contractor…

1. Establishes clear responsibility for the preparation, review, and approval of cost estimates.

2. Provides a written description of the organization and duties of personnel responsible for contributing to the estimating process

3. Ensures that relevant personnel have sufficient training, experience and guidance

4. Identifies sources of data and the estimating methods and rationale used in developing cost estimates.

5. Provides for appropriate supervision

6. Provides for consistent application of estimating techniques.

7. Provides for detection and timely correction of errors.

8. Protects against cost duplication and omissions.

9. Provides for the use of historical experience, including vendor pricing information where appropriate.

10. Requires use of appropriate analytical methods.

11. Integrates information available from other management systems as appropriate.

12. Requires management review [of the estimating system]

13. Provides for internal review of and accountability for the adequacy of the estimating system, including the comparison of projected results to actual results and an analysis of any differences.

14. Provides procedures to update cost estimates in a timely manner.

15. Addresses responsibility for review and analysis of subcontract prices.

The new Administration has renewed attention to Defense Acquisition Reform. I suggest that you do not wait for DCAA to come knocking at your door to ensure that you have an adequate estimating system. Do a self-audit of your practices using the attributes above. Put yourself in the shoes of your local DCAA auditor – did you pass the test? Fill in the gaps, document your process, practice what you documented, and revisit and renew your vows periodically. An adequate estimating system is not just a DFAR requirement; it is a sound business practice.

The US Department of Defense (DOD) continues to be plagued with cost overruns on major weapons systems.  Last month  Senators Carl Levin (D-Mich) and John McCain (R-Ariz) introduced the 2009 Weapon Systems Acquisition Reform Act intended to put measures in place to force the DOD to address the issues that cause overruns and schedule slippage.   Among other things,  this legislation would create the position of Director of Independent cost assessment for Major Defense Acquisition Programs (MDAPs) and require the DOD to perform trade-offs between cost, schedule and performance early in the program lifecycle. Read more about this legislation

The DOD's experience with cost overruns and schedule slippage is certainly not unique to them.  The size and complexity of the problems that they are trying to solve, along with the fact that their projects are funded with US tax dollars, makes their contract difficulties more dramatic and more public.  Everyone who builds large systems knows that the bigger their system the more risk there is that things will change between the time the project is first estimated and the time it is delivered.  And most changes that occur within a project involve adding requirements rather than removing them.  This is why cost, schedule and performance tradeoffs are so important – early and often in every project. 

And while there is no silver bullet that will solve the problems that the DOD and many other systems developers have with projects failing to meet goals  – there are tools and methodologies that will facilitate success with cost, schedule and performance tradeoffs.  TruePlanning for Products from PRICE Systems provides a framework in which systems developers can translate their own past performance to provide forward looking analyses that facilitate trade-offs between cost, performance and schedule. TruePlanning provides a trade space to help project managers create realistic expecatations for the cost and schedule of complex systems.

Barak Obama's 2010 U.S. Federal Budget proposal promises a "New Era of Responsibility", and in the introduction he says,  

"...we must begin the process of making the tough choices necessary to restore fiscal discipline, cut the deficit in half by the end of my first term in office, and put our Nation on sound fiscal footing."

Tough choices indeed. There in lies the greatest challenge.  With the best intentions, our government tries to do good things, but always starts more projects than it can afford.  And often the expected "value" of an initiative is never fully vetted before a project is launched. 

How can you decide among project alternatives and choose an optimal strategy if you have not determined the value of each?

How can you restore fiscal discipline and cut the budget deficit if you do not know the cost-benefit analyses your projects? 

Since a new era of government spending responsibility will hinge upon making tough decisions, they must be supported by the disciplines of 
business case analysis, analysis of alternatives, and portfolio management optimization to be successful.


 These disciplines have been areas of study for us at PRICE Systems for the past two years and our work was released this week in TruePlanning 2009.  There are three innovative new features in this release:

1. Value models - enabling analysts to estimate the value and benefits of project once it is delivered, and over its lifetime
2. Business Case Analysis - enabling analysts to prepare and score a case for the project including the cost/benefit analysis, payback period, investment rate of return, strategic benefits, and other evaluation criteria scoring.  The business case tells the story of the project.
3. Analysis of Alternatives and Portfolio Analysis - enabling decision-makers to view Risk/Reward charts of alternatives and planners to reconcile total project estimates to budgets.

In this post I will give you an overview of these features and I hope to dive deeper in future posts.  Consider the decision a government planner must make on whether or not to launch a Business Process Automation (BPA) project.  The figure below shows a TruePlanning Payback view for the BPA project.



The three panels in this view tell the story of the project and make its business case.  The product breakdown structure view below identifies the elements of the project that will cost money and identifies the various benefits expected from the project implementation.



Each element in the tree represents either a cost item or a benefit associated with the project.  The cost items and benefit items are grouped into separate folders so that they can be reviewed individually or summarized.  

The Payback chart below shows how costs and benefits are realized over time so that project cost/benefit cash flow can be analyzed.



Each bar quantifies the costs and benefits realized in each year, the line shows the cumulative cash flow over time.

The Metrics table shown below shows the most commonly used financial metrics used for business case analysis.



This alternative of the BPA has a payback period of just over five years and has an IRR of nearly thirty-nine percent.

However, there is a problem.  When we combine our BPA project with the other projects in our portfolio we identify an estimated budget overrun.  As shown in the project portfolio view below, the sum of the project estimates exceeds our agency budget over time.




Now we must decide what we cannot do or what project we must cancel to stay within budget.  We know the business case for the BPA project,  how does that compare to the other projects?  The chart below shows the risk/reward for the projects under consideration. 



Tough decision time!  If you only had budget for two projects, which would you choose?  Are you willing to say NO to the others? 

TruePlanning 2009 has been delivered just in time to empower government decision-makers with the right tools so that they can "begin the process of making the tough choices necessary to restore fiscal discipline, cut the deficit in half by the end of my first term in office, and put our Nation on sound fiscal footing".  TruePlanning cost management software estimates software development costs, IT project costs, and now, the value of those projects. The value of determining a project's true value is more important than ever. 

Author Nassim Taleb describes a Black Swan as an unexpected event that ultimately leads to what best can be described as a paradigm-shift. In his book, The Black Swan, he includes 9/11, the rise of the Internet, Google and the personal computer as Black Swan events. We could not have predicted those events but they have had a huge impact on us.

Even positive Black Swans can be a source of frustration. Since so few people are prepared for them, it becomes impossible to profit from them. The group that is most frustrated by Black Swans are probably those whose jobs involve cost estimation.Cost-estimators rely on past data to forecast costs so it becomes very difficult to estimate the costs of Black Swans. So where are the new Black Swans and how should Cost-estimators prepare?
I think that the new Black Swans are those that deal with smart technology. This category includes:

• Smart Infrastructure: roads, bridges, etc that have built-in detection and analysis capacity
   
• Smart Energy: While there has been a lot of emphasis on alternative energy, the real paradigm shift will be in a grid that adjust itself to maximum efficiency. This will involve estimating software costs for new systems
• Smart Healthcare: Healthcare IT will create efficiencies in our bloated healthcare ecology. The digital exchange of records will eliminate redundancy and enable cost-effective delivery. This will usher in the need to develop effective IT project cost estimation.

Many of these technologies are captured in the stimulus. With the blessing of the federal government, we will see venture capital quickly follow suit. So how does the cost-estimator adapt?

First, we must analyze analogous systems. The ATM/Banking System is usually good place to start since there are a lot of similarities, especially with Health IT. There also have been some small-scale implementations of these technologies. Abu Dhabi is building a city of the future that includes smart technology.

Second, we must learn the effect that networks have on cost. Too often, we, cost estimators, wallow in the weeds of systems. We concern ourselves with how many laptops do we need rather than what effect do the laptops working together have on costs. We must ask ourselves repeatedly if the whole is greater than the sum of the parts.

Finally, we must view technology as a service rather than a product. We must evaluate architectures such as SOA, Cloud Computing and Grid Computing. We must analyze how such systems determine requirements and values.

So this is the challenge. The Black Swans have landed. They require estimation to be accurate and thus, proven cost estimating tools must be a part of the equation. Now, we need to shift the way we approach our work and answer the call.

Last week I was asked to participate in Career Day at my son’s elementary school.  I was both honored and humbled.  Honored because the school felt that my career was something the children would be interested in and humbled because I was forced to concoct a story that would make cost estimating and analysis both understandable and interesting to children from kindergarten through grade eight.  Fortunately the format was such that I presented to each grade individually so at least I did not have to come up with one story to address all ages.

The experience turned out to be a lot more fun than I imagined.  It’s amazing how many kindergarteners in my son’s school have parents that are scientists (although to be fair their teacher informed me that thirty minutes earlier, when a policeman visited the classroom, many of their dad’s were also on the police force).  Lots of forensic scientists I suppose! 

And it wasn’t really as hard as I expected, explaining what PRICE Systems does.  I used images of the kinds of hardware and systems that TruePlanning for Products can be used to estimate. While some of the younger ones thought that I actually had flown on the Space Shuttle, the upper grades got it.  The experience actually helped me learn several new things about my job.  First of all, I learned that what I do actually is interesting to kids who are starting to think about what they might want to do with their lives. The little kids were fun but the older kids were attentive and asked good questions.  The fact that my work contains elements of science and technology exploration, with math and a little bit of detective work thrown in was actually appealing to many of them.  I was also reminded of how much I like my job and why.  Not only does my job create lots of new and interesting challenges, it also gives me opportunities daily to help people who do software project estimating, hardware project estimating and system level estimating.  I get to help these people be more successful at their jobs by providing tools and methodologies that make their estimates credible and believable.