Skip to content

Common Problems with IT Project Cost Estimation

July 25, 2008

Size: Economies of Scale may not exist

People naturally assume that a system that is 10 times as large as another system will require something like 10 times as much effort to build. But the effort for a 1,000,000-LOC system is more than 10 times as large as the effort for a 100,000-LOC system, as is the effort for a 100,000-LOC system compared to the effort for a 10,000-LOC system.

The basic issue is that, in software, larger projects require coordination among larger groups of people, which requires more communication. As project size increases, the number of communication paths among different people increases as a squared function of the number of people on the project.

Type of IT Project being developed

After project size, the kind of software you’re developing is the next biggest influence on the estimate. If you’re working on life-critical software, you can expect your project to require far more effort than a similarly sized business-systems project

You can account for the industry in which you’re working in one of three ways:

  • Use the results from previous projects or industy reference as a starting point. If you do that, notice that the ranges in the table are large—typically a factor of 10 difference between the high and the low ends of the ranges.

  • Use an estimating model , and adjust the estimating parameters to match the kind of software you develop. If you do that, remember the cautions from the above sizing comment.

  • Use historical data from your own organization, which will automatically incorporate the development factors specific to the industry you work in. This is by far the best approach, and we’ll discuss the use of historical data in more detail in the next few posts

Type of IT Human Resources

Personnel factors also exert significant influence on project outcomes. According to project estimates, on a 100,000-LOC project the combined effect of personnel factors can swing a project estimate by as much as a factor of 22! In other words, if your project ranked worst in each category , it would require 22 times as much total effort as a project that ranked best in each category.

One implication of these variations among individuals is that you can’t accurately estimate a project if you don’t have some idea of who will be doing the work—because individual performance varies by a factor of 10 or more. Within any particular organization, however, your estimates probably won’t need to account for that much variation because both top-tier and bottom-tier developers tend to migrate toward organizations that employ other people with similar skill levels. Another implication is that the most accurate estimation approach will depend on whether you know who specifically will be doing the work that’s being estimated.

Type of Programming Language

The specific programming language a project uses will affect your estimates in at least four ways.

First, as the table suggested, the project team’s experience with the specific language and tools that will be used on the project has about a 40% impact on the overall productivity rate of the project.

Second, some languages generate more functionality per line of code than others. Table shows the amount of functionality that several languages produce relative to the C programming language.


Level Relative to C


1 to 1


1 to 2.5


1 to 2.5


1 to 1.5

Fortran 95

1 to 2


1 to 2.5

Macro Assembly

2 to 1


1 to 6


1 to 6


1 to 10

Visual Basic

1 to 4.5

Type of Project influences




Applications (Business Area) Experience


Teams that aren’t familiar with the project’s business area need significantly more time. This shouldn’t be a surprise.

Architecture and Risk Resolution


The more actively the project attacks risks, the lower the effort and cost will be. This is one of the few Cocomo II factors that is controllable by the project manager.

Database Size


Large, complex databases require more effort project-wide. Total influence is moderate.

Developed for Reuse


Software that is developed with the goal of later reuse can increase costs as much as 31%. This doesn’t say whether the initiative actually succeeds. Industry experience has been that forward-looking reuse programs often fail.

Extent of Documentation Required


Too much documentation can negatively affect the whole project. Impact is moderately high.

Language and Tools Experience


Teams that have experience with the programming language and/or tool set work moderately more productively than teams that are climbing a learning curve. This is not a surprise.

Multi-Site Development


Projects conducted by a team spread across multiple sites around the globe will take 56% more effort than projects that are conducted by a team co-located at one facility. Projects that are conducted at multiple sites, including out-sourced or offshore projects, need to take this effect seriously.

Personnel Continuity (turnover)


Project turnover is expensive—in the top one-third of influential factors.

Platform Experience


Experience with the underlying technology platform affects overall project performance moderately.

Platform Volatility


If the platform is unstable, development can take moderately longer. Projects should weigh this factor in their decision about when to adopt a new technology. This is one reason that systems projects tend to take longer than applications projects.



Refers to how “precedented” (we usually say “unprecedented”) the application is. Familiar systems are easier to create than unfamiliar systems.

Process Maturity


Projects that use more sophisticated development processes take less effort than projects that use unsophisticated processes. Cocomo II uses an adaptation of the CMM process maturity model to apply this criterion to a specific project.

Product Complexity


Product complexity (software complexity) is the single most significant adjustment factor in the Cocomo II model. Product complexity is largely determined by the type of software you’re building.

Programmer Capability (general)


The skill of the programmers has an impact of a factor of almost 2 on overall project results.

Required Reliability


More reliable systems take longer. This is one reason (though not the only reason) that embedded systems and life-critical systems tend to take more effort than other projects of similar sizes. In most cases, your marketplace determines how reliable your software must be. You don’t usually have much latitude to change this.

Requirements Analyst Capability


The single largest personnel factor—good requirements capability—makes a factor of 2 difference in the effort for the entire project. Competency in this area has the potential to reduce a project’s overall effort from nominal more than any other factor.

Requirements Flexibility


Projects that allow the development team latitude in how they interpret requirements take less effort than projects that insist on rigid, literal interpretations of all requirements.

Storage Constraint


Working on a platform on which you’re butting up against storage limitations moderately increases project effort.

Team Cohesion


Teams with highly cooperative interactions develop software more efficiently than teams with more contentious interactions.

Time Constraint


Minimizing response time increases effort across the board. This is one reason that systems projects and real-time projects tend to consume more effort than other projects of similar sizes.

Use of Software Tools


Advanced tool sets can reduce effort significantly.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: