Pre-sales estimation of project costs and durations has been a software dilemma thatstarted with the profession itself. Despite all good intentions, MurphyÂ's Law seemsto leave everyone room to be unhappy about something. Customers expect accuracy andoften are disappointed even by what software companies consider minor post-salesadjustments. IT project managers dread giving pre-sales estimates because they knowthat just about every project has hidden work.
The burning question has been, Â Is it possible to make an accurate estimation beforethe project architecture is built?Â
The dream answer of  YES is all the more desirable for outsourcing software firms,such as TechnoPark Corp., because accuracy is also related to trust and reputation,the cornerstone qualities of any outsourcing company.
Since the 1970s, there have been many attempts to attain this dream of accuratepre-sales estimations of projects. None however have stood up to the rigors of realworld challenges and client expectations.
Today, TechnoPark Corp. shares its successful experience in the fine art ofpre-sales estimation.
First, letÂ's review the basis of the estimation process. There are some commonmistakes and some important issues ignored by many estimators.
A common initial mistake by software development companies is that they estimate theproject as if everything will go  just right. However, it shall not. It is best toestimate the reality of the process, and not some Pollyannaish scenario. Risks oughtto be the first things analyzed. Any estimation not based on analysis of allprobable risks, in conjunction with a companyÂ's true capabilities, inevitably willresult in an estimation of oneÂ's hopes and wishes and not probability.
According to the new model by TechnoPark Corp. a requirements-based model is themost suitable for pre-sales estimation. The source lines of code (SLOC) model,popular in the 1980s-90s, proves to not be effective any longer as coding issignificantly more complex and interactive than the number of lines of a program.The SLOC model admittedly still helps with measuring the efforts of a completedproject, but that doesnÂ't help much with estimating before the coding begins.
Requirements-based estimation, on the other hand, accounts in advance for aprojectÂ's features, risks and complexity. Analysis of the requirements provides anestimator with a more abstract but accurate vision, as the estimator views the wholeproject.
Requirements-b ased estimation however is not the solution either according to thenew model by TechnoPark Corp. Pre-sales estimation needs a general understanding ofthe project but also needs to account for the details, an area whererequirements-based modeling comes up short.
Another golden rule of estimating reads: Estimate the diapason or range, not theprecise figure. It usually is impossible to count the precise size of efforts andget a correct estimation at the pre-sales phase. It is better to estimate thespectrum of possibilities and set aside more precise estimation for detailedexamination of the project.
In order to get the diapason, three figures for each task are needed: Worst Case(WC) is the maximum amount of person-hours needed to implement the feature anddepicts the situation when everything is going wrong; Best Case (BC) is anoptimistic estimation providing minimum amount of person-hours; and Most Likely (ML)depicts the situation which is the most probable in an estimatorsÂ' assessment, whichmay be close to either the worst or best case.
 At TechnoPark Corp., we involve three developers each time estimation isfacilitated. Two of them provide their versions of WC, BC and ML estimations, andthe third one estimates complexity and function points. When counting the diapasonof person-hours, we use a number of additional coefficients such as maturity ofprocess, required software reliability, programming language experience, etcetera.After all necessary data are entered, automated counting is implemented by thesystem based on COCOMO II , explains Victoria Malinovskaya, the estimationfacilitator at TechnoPark Corp.
COCOMO II, or the Constructive Cost Model, is growing in popularity as an estimationmodel. Its first version, COCOMO 81, was introduced in 1981 by Barry Boehm. Themodel is used for estimating the number of person-hours and person-months it willtake to develop a software product. The first version was based on SLOC counting.COCOMO II appeared in the 1990s.
The power behind COCOMO II is that it is based on function points instead of SLOC. Afunction point is a rough estimate of a unit of delivered functionality of asoftware project. To calculate the number of function points for a software project,one counts all of the user inputs, user outputs, user inquiries, number of files andnumber of external interfaces, dividing them all into simple, average and complexcategories.
COCOMO II coefficients and formulas are clear and useful for software developmentcompanies, both big and small. The model offered by TechnoPark Corp. is based onCOCOMO II with only small fluctuations making it more suitable for outsourcingsoftware development companies.
TechnoPark Corp. has adapted the COCOMO II approach to client costing with greatsuccess.
 With COCOMO II, we have helped the company reduce losses caused by understatedestimations by almost 70%, Malinovskaya said.
About the company
TechnoPark Corp. is an outsourcing software development firm headquartered inNaples, Florida, USA. Its software development center is based in the Ukraine,Eastern Europe. TechnoPark Corp.'s areas of expertise are Online Payments, VoIPTechnologies, Enterprise Application Integration (EAI), and Data Warehousing. Thecompany develops in Microsoft .Net, Java, Ajax, Flex/Flash, C++ and LAMP, amongothers. For more information, visit www.technoparkcorp.com.
You are welcome to include these headlines in your own pages. If you want to find out how to parse this RSS file please read our tutorial How to parse RSS feeds with PHP.