That’s a question that members of the cost estimating community will try to answer at next week’s  43^rd Annual DoDCAS symposium. The conference is centered around the “theory and implementation” of the WSARA 2009 (Weapons System Acquisition Reform Act). Simply put, the cost estimating community needs to first and foremost understand what the real life implications of the WSARA will be. At least in theory that is.  

According to GAO, nearly 70% of the Pentagon’s 96 biggest weapons programs were over budget in 2008 and another government report found $295 billion in waste and cost overruns in defense contracts. Clearly things need to change.

As the Deputy Secretary of Defense, William Lynn, correctly states, overly optimistic estimating is at the root of cost overruns.

“We rely on overoptimistic cost estimates. These estimates are success oriented…they assume every step in the development process will go as planned. To produce weapon systems efficiently, it is critical to have budget stability. But it is impossible to attain stability in our modernization budgets if we underestimate the cost of our weapons systems from the start.”

Lynn also states the need to bolster personnel by 20,000 positions over the next five years with a heavy focus on cost estimators, systems engineers, and acquisition managers. 

Naturally, PRICE Systems, is eager to support the acquisition community as it attempts to implement the key initiatives of the WSARA. We will have our some of our cost research experts on hand to present and discuss best practices in cost estimating and they will be reporting back on what they learned and observed at the conference.

Stay tuned.

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.

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.
 

 

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. 
 

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.

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.

                     
Like many others, I was astonished last Thursday by the images on my browser of those 155 extremely lucky people standing in the Hudson River.  And they certainly were very lucky last Thursday.  If you’re destined to fly on a flight bound for collision with birds, you want it to be piloted by a hero like Captain Sullenberger.  The incident made me think about what a hero is and how we all have the opportunities to be heroic in our chosen professions.

According to Wikipedia, a hero refers to a character that, in the face of danger and adversity or from a position of weakness, displays courage and the will for self sacrifice.  As a project manager you may not encounter danger daily, at least of a physical nature, but you certainly deal with adversity on many levels.  And courage is essential!

An heroic project manager is one who makes project decisions based on facts and who stands behind those decisions.  He or she defends the project team from those who wish to impose unrealistic deadlines and stands up to those who want to abuse or ignore the Project Management Triangle.  In order to be heroic, a project manager needs to have the tools necessary to plan a project right the first time as well as manage it with agility as situations change.  TruePlanning from PRICE Systems is just such a tool.  TruePlanning is the worlds leading solution for software cost estimation and IT Project Planning.  It gives project mangers the cost estimates they need to plan projects successfully and the courage necessary to defend those numbers to the naysayers.

Although the use of TruePlanning is unlikely to lead to instant fame or enable people to walk on water, a project manager who uses it regularly will be a hero to the team!
 

Dude, Where’s my Stimulus?

If you turn on the news or open the newspaper, you will definitely come across an item about the stimulus package. Obviously, there will be much debate to come over the price tag for the initiative. But I wanted to take a moment to discuss where resources will be directed and how they will be dispersed. I also would like to talk about how this bill might affect us in the "Land of Estimation."

High-tech is the theme for this stimulus. Most projects will involve technology upgrades of one sort or the other. Even shovel type projects will have a futuristic spin to them. For example, school repairs are geared toward energy efficiency. Health IT, alternative energy and high-tech manufacturing are at the top of this agenda.

An even more important point is that not a lot of new bureaucracy will be created. Instead, existing federal bureaucracy will be expanded. For example, the Manufacturing Extension Program, a Clinton-era initiative, will receive more funds. The Office of the National Coordinator, a Bush-era Health IT office, also will receive more funds.

So what does this mean for business, in general, and estimators, specifically?First, partnerships will be essential. Estimators should partner with federal agencies and programs on the dispersal side. These groups will be focused on accountability and affordability. Their goal is that no dollar is wasted. On the reception side, partnerships should be formed with states and industry-leaders. These groups will be interested in developing accurate business-cases. Their goal is to demonstrate that their projects create value.

So, the stimulus will indeed be controversial. But it also may create a golden opportunity for the estimation world.

Today, change is in the air.  As I write this, Barack Obama is about to be sworn in as our new U.S. President and the space community, among others, should be braced for change.  A recent LA times article reported that of the 74 questions asked of NASA by the Obama transition team, over half were on basic spending issues, including cost overruns.

The Obama team and the NASA Administrator Michael Griffin clearly do not see eye-to-eye.  Monday, it was announced that Mr. Griffin will step down from the post.  Griffin characterizes himself as an engineer and states that NASA shouldn't be evaluated by how well it estimated the cost of projects.

"We start these things out, and we admit up front we don't completely know how to do them. That is what makes them interesting," Griffin said recently.

"If we are to judge the worth of our work by our ability to estimate, then that is a standard I am not ready to apply or to accept," Griffin said.

Others are more realistic about NASA's obligation to create credible expectations for spending taxpayer money.

"Our space program is running inefficiently, and without sufficient regard to cost performance," wrote Alan Stern, a former NASA associate administrator who has been mentioned as a possible replacement for Michael Griffin, the current NASA administrator.

In a recent op-ed piece in the New York Times, Stern called the cost overruns a "cancer" that has cost the agency's science program about $5 billion over five years.

Agency officials said they had improved financial controls -- including forcing managers to better estimate costs.

Considering NASA's great technical achievements, one must wonder, "Is accurate estimating harder than rocket science?" 

I don't think so.  I believe the clue to accurately estimating the cost, uncertainty and risk associated with large, complex space projects can be found in a recent Defense AT&L article by Col. Brian Shimel, USAF.  Col. Shimel states,

"We cannot relieve ourselves of the need to plan for the future just because the future is uncertain. For our plans to be reasonably accurate and reliable, it is prudent we base them on rational analysis and not on wishful thinking.", and...

"We must think clearly about uncertainty and risk, and we must fight the temptation to discount those factors when communicating the real conditions of our management situation. We don't get in trouble because of risk and uncertainty. We get in trouble for not admitting to ourselves - and those who rely on us - all of the risk and uncertainty that inherently exist in everything we plan to do."

Our TruePlanning estimating and cost management software gives managers metrics and benchmarks of previous projects, and methods to realistically quantify uncertainty and risks.  TruePlanning's reports and charts expose over-optimism and show managers the real conditions of the situation.  I routinely recommend that government agencies quantify all the risks and uncertainties of each project in their portfolio and budget to the sum of the 70% confidence levels of each project, yielding 80% confidence that the projects can meet taxpayer expectations for the budget.

President Barack Obama just finished his acceptance speech.  He called upon us all to increase our service to the country.  Government managers can help by stepping up to the estimating challenge.

Accurate estimating is not rocket science.  There are sophisticated cost estimating models to accurate estimate software development costs, hardware development costs, IT project costs, and operation and support costs - we just need to be realistic, responsible and courageous about presenting the results for our analysis. Contact us and we'll help you get started today.

A recent Gartner report indicates that industry enthusiasm for SOA is waning.  The reasons cited are the lack of enough people with the proper skill sets to perform SOA deployments and the lack of a good business case for SOA.  It’s an interesting but not really unexpected direction.  SOA has been surrounded by significant hype, ensuring that organizations surveyed would be anxious to profess their desire to start a SOA project.  But as the rubber hits the road, these organizations are realizing that SOA may not be the answer to all of their organizational woes.

Many will argue that SOA is nothing new – but rather a repackaging of an object oriented approach to software reuse.  They insist that the reason for this repackaging is motivated by a strong marketing push to sell a new generation of tools to folks that were not successful achieving reuse with earlier versions of tools.  Although I agree that the notion of SOA is not new, I do believe that technology has been advanced to a level where enough abstraction can be applied to the process to make reuse a possibility.  I do agree with the cynics that the heavy marketing push for SOA has not helped businesses make thoughtful decisions about whether it is right for them.

Now that enthusiasm has been tempered, organizations are starting to look at the costs, benefits and ROI of SOA.  This is a good thing.  A more thoughtful approach across the industry will balance the effects of aggressive marketing and ensure that the right SOA projects are attempted.  Of course, the challenge of determining ROI is daunting, particularly without a lot of data. Determining the benefits of a relatively untested paradigm is problematic.  If the SOA vendors are to be believed the benefits are tremendous.  Experience of course tells us that this is optimistic.  But common sense indicates that there is a great deal of potential for benefit for businesses that meet one or more of the criteria listed in the article “Your SOA needs a business case” – in other words if your business must respond to frequent changes in the marketplace or with business rules and relationships.

Understanding, or predicting, the benefits SOA will bring to the organization is only half the challenge.  The costs associated with a deployment of capabilities in a service based framework are also an important consideration.  The TruePlanning Suite, available from PRICE Systems, can help in this area.  TruePlanning allows for IT Project cost estimation that will help address costs associated with deploying the right infrastructure for SOA, the costs associated with development of services, and the costs associated with the composition of applications using services.

Software cost estimation is hard.  I have learned this the hard way – as a software developer and later as the manager of software development projects. Today, as a builder of cost estimating software, I learn something everyday about software development that reinforces the fact that software cost estimation is hard.

I attend a lot of trade shows and I talk to a lot of software people about how they estimate software costs.  Many of them have no formal process, many don’t collect data as projects progress, many of them perform estimates off the cuff, and many of them, not surprisingly, are unhappy about the outcome of their software development projects.

Many of these same people are quick to point out, when presented with possible help in the form of TruePlanning for Software, why it will never work for them.  Nine times out of ten, the reason they give me has to do with the uniqueness of their product, their customer base, their market or their software development process.  They question the data behind the model and suggest that this data can not be successfully translated to properly model their specific situation.

And I can’t fight the uniqueness argument – it’s most likely true.  Every software project has factors that make it different from all the other software projects that have occurred in the past.  No two software projects are the same.  I can however argue about the suitability of the data behind my model. The majority of software projects are not defined by their uniqueness.  There is much more about most projects that is similar to other projects than is different.  A good software estimation tool like TruePlanning for Software capitalizes on this fact by allowing the user to take advantage of industry or organizational data for those many places where a project is not unique.  Further, it offers expert systems like guidance to transcend those areas where a software project veers from commonplace to extraordinary.

In software, as in life, we tend to put the most focus on the parts of a project that are challenging and interesting with much less focus on the parts that are ordinary.  If, in doing this, we are discounting the lessons we can learn from history, we are doing ourselves and our software projects a disservice.

Jacob has a great comment to my recent post on getting it "right the first time".  He notes that requirements are often fuzzy and that estimates rely on peoples' opinion of cost and duration - and that the are often wrong.  He asked what silver bullet we have. Our silver bullet is a proven discipline that makes people better estimators and sheds light on fuzzy requirements.

It starts with the people. Becoming an accurate estimator requires the same step-by-step approach as any learned skill such as golf or tennis or swimming (things I am currently struggling to do well). First you need the right tools, then you need to learn the right way, then you need to be mentored by experts as you practice what you learned until it becomes second nature. Recently, I was struggling with my breathing while attempting to swim. Lap-after-lap I was breathing hard, swallowing water - it was a miserable sight.  Then I consulted an expert that got my head turning the right way and got me into an rhythm of breathing every third stroke.  My swimming quickly improved by 40% - more laps in less time.

We do the same for our clients.  First we arm them with the right tools.  Our TruePlanning software provides a proven step-by-step discipline to do an estimate the right way,  TruePlanning asks the right questions and covers all the bases, including risks.  Then we train people not just how to use our software but how to be great estimators.  Sizing methods, interview techniques, and requirements elicitation are part of our training.  Then our experts are by their side as they hone their skills through email, live-meetings, a 24/7 hot-line, and on-site visits.  Throughout we provide people with benchmark measurements of other similar efforts and tips to guide them. Suddenly fuzzy requirements become clearer. People are doing more accurate estimates in less time. Typically our clients improve their estimating accuracy by 50% within three months and several of our clients now produce estimates that average within 5% of actual scope, cost, and schedule.  Our clients leverage our cost estimating software and cost management software to estimate software costs and schedules, IT infrastructure costs, and custom hardware to improve their overall project and portfolio management.  By the way, I just finished a mile in the pool and improved by another 10% - practice makes perfect.

According to Gartner, Service Oriented Architectures (SOAs) will be used in more than eighty percent of mission critical operational applications and business processes by the year 2010.  Perusal of the literature on SOAs leads to visions of ease of implementation and cost savings of epic proportions.  And it is likely that not only will service oriented implementations results in cost savings, but that without them many currently envisioned capabilities in the corporate world and the Department of Defense (DoD) will be impossible to deploy, maintain, and evolve as technology explodes and requirements and priorities shift.

As with all technology shifts, the cost savings are neither automatic nor are they immediate.  Up front investment is necessary before the cost savings start to roll in.  Businesses are anxious to begin deploying SOA capabilities but are wary as to what the transition may cost them. 

This is an area that we at PRICE are very interested in, not only because we want to help our clients overcome this software cost estimation challenge, but also because we are investigating ways that SOA concepts will help us better serve clients of the TruePlanning Software Cost Estimation capabilities. 

For purposes of understanding cost implications, a SOA deployment can be segmented into three general areas.  The implementation of the infrastructure necessary to host service based capabilities is a significant investment for a company.  This generally requires a search for the right set of commercial off the shelf middleware components to meet the business’s requirements for security, performance, etc.  The deployment of the infrastructure is a one-time investment with costs being driven by the specific requirements of the organization and the level of technical maturity with respect to SOA.

Once an infrastructure is in place, services need to be developed and existing capabilities need to be migrated from traditional applications to services.  As services are really just software implementations,  drivers in this category are similar to typical drivers for software development costs.

Finally there is an integration and test effort associated with getting services working within the context of the infrastructure to deliver value to end users.  In many ways this effort will be similar to other software integration and test efforts but additional factors will come into play. It's important to understand how the rigor put into developing the infrastructure will impact the cost and effort of actually using that infrastructure to deliver capability. Read more about on-going research into the costs and benefits of Service Oriented Architecture.