Chapter 6: Estimating

The Art

Of Estimating

Introduction

Often the estimating of software looks much like this:

1. Examine system structure charts

2. Consider othograhic vectors

3. Define interface beta factor

4. Plug values into Estimating Model

5. Multiply result by 2.5 fudge factor

6. Add a week for luck!

Life would be much easier for IS project managers if all the computer scientists and systems professionals who have worked on it for years had designed a foolproof way to estimate systems. We are getting closer, but we're not there yet. There are many different models and methods for estimating, but none of them are entirely accurate. The chief reason for this is that projects vary greatly. Even though a project may look like another one that our organization has done, there may be great differences in organizational culture, technology or user needs. What estimating can do for us is:

Help us define the project scope, schedule and costs.

Give us a basis for comparing alternative solutions and alternative costs for the project.

Provide the basis for measurement and control of the project.

Provide the basis for definition of resource requirements and cash flow needs.

Provide general answers to Top Management's questions:

What will it cost?

When will we see the benefits?

What are our risks?

How can we control them?

Can we get it done cheaper or better some other way, or using some other service?

Help answer the project manager's questions:

Can we do it?

Is it economically feasible?

What are our alternatives? Packages? Consultants? Build?

How long will it take?

Standard Estimating Techniques

There are several elements that need to be considered in estimating a project. The next section discusses some common issues that should be taken into account for any type of project. This first section is then followed by a discussion of software project estimating techniques.

Benefits, Resources And Costs

In every project there is a relationship between benefits, resources and costs which needs to be understood. The project manager and project sponsors need to understand what they are going to get out of the project, what resources are going to be needed and what the cost will be.

Benefits are highly specific to the client's business. The client may be able to cut costs due to greater efficiencies, or gain strategic market share. Or the benefits may be less tangible, such as improving corporate image or increasing customer satisfaction. In any case, the benefits must be quantified so that they can be compared with the cost of creating the system.

In an information system project, much of the cost comes from resources - people costs. There are often other costs such as hardware, consultants, and ancillary packages, but the primary costs come from the people who will build the software. A great deal of estimating effort goes toward estimating their time.

Understanding A Project

In order to prepare an estimate for a project there are elements you must understand. These include:

SIZE

COMPLEXITY

RISK

EXPERIENCE

ENVIRONMENT

SIZE

The size of a system can be measured in several different ways. The two most common ways are to estimate the lines of code or the function points for a software system. No matter which method is used, the size must be clearly defined. Size of the software system is the primary estimation driver for systems built from the ground up.

Complexity

As important -or perhaps more important - than size is complexity. The project team must understand the complexity of the software they are going to build. This includes an understanding of the requirements and how inherently difficult it is to build.

Risk

Risk refers to the likelihood that the project will not be built, not be used, or come in over budget or not on time. The project manager should look carefully at the risk factors of size, structure and technology before beginning to estimate the project.

Experience

The experience of the clients with the proposed system, the IS team with the hardware, software and techniques all have an effect on the project estimate. Experienced groups will be able to complete projects with less risk, less cost, and in less time than inexperienced groups. The differences between experienced and inexperienced programmers proves the point. An experienced programmer can put the same coded structure many orders of magnitude faster than an inexperienced programmer.

Environment

The project team must also take into account the environment in which the system will be built and operated. What tools are available, what methodology is used, and the methods of testing all have an effect on the project.

Estimating Methods

There are many different models for estimating systems. We will focus on just three of the methods, but others are available. Which method a person uses depends on many things, including:

Previous experience: which methods the organization has used before ... and which ones worked.

Starting point: where you are in the project lifecycle. For example, function point analysis gives better early estimates than lines of code.

Risk level: Projects with higher risk will cause people to use a more detailed approach or multiple methods.

Project Size: Smaller projects require less planning, measurement and control.

Time: How much time you have to pick an estimating method and use it correctly.

There are two primary types of estimating techniques; sizing techniques, and techniques based on the work breakdown structure. The following section lists some possible methods.

The Fuzzy Logic Technique

The Fuzzy Logic technique, or guesstimate, is perhaps the most widely used sizing estimate method. This involves asking someone who has done a project similar to the one proposed to estimate how long it will take. It is useful to ask the expert (or experts) to look at the optimistic, pessimistic and likely times for the project, and then use this information to arrive at both a range of estimates as well as a mean estimated time. This can be useful very early in the project when different solutions are being examined in the early stages. It relies heavily on rules of thumb.

For the fuzzy logic method to work, the project manager must gather information on previous projects in the organization. Data should be gathered on small, medium and large projects. The characteristics of the projects should be similar - risk levels, client involvement and applications.

As information is gathered, it can be categorized and organized by project type and size. Projects which are similar is size and type should be grouped together to provide basic estimating information on future projects. The likely, optimistic and pessimistic times for projects of similar size and type should be gathered. These then can be plugged into the standard curve, using the formula for the mean. Unfortunately, often the organization has not taken the time to calculate these averages. As an alternative, the project manager can ask people he or she knows about projects they have worked on which are similar to the current project. Averaging the results from several people will give the project manager a range of possible values for the project, as well as the mean average estimate for the project.

Task Based Estimating

This bottom-up method of defining the lifecycle steps, milestones and tasks can be used for any type of project - build your own or package. When using this method the estimator must keep in mind the overall system perspective and not get bogged down in the details. The method can begin giving estimates at the end of the initial planning stage of the lifecycle.

The basis of the task based method is the work breakdown structure. Once the structure has been defined, the project manger should look at each task and estimate the time it will take to do that task. First, the project manager should apply the fuzzy logic concept listed above for each task. Ask yourself and your team members what the likely, optimistic and pessimistic times are for the task. The likely time is the amount of time you would expect the project to take under normal conditions. Pessimistic is the amount of time the project would take under the worst case. Optimistic is the amount of time the project would take if every thing went absolutely right. Then apply the formula for the mean to get the time estimate for the task. This places the estimates along a standardized statistical bell curve as shown in figure 4. By doing this you have established a range of times for the project which will capture the time for the project with 95% accuracy. A project with an optimistic time of 500 hours and a pessimistic time of 950 hours will fall within that range 95% of the time. This range is a much better way of expressing to the client how long the project will take. There are several other considerations as well:

The impact of part-time resources

The impact of team size

The impact of team efficiency

The impact of delay

Part Time Resources

When the project is going to have people working on it part time, the project manager will need to plan extra time for them. For example, if a task is estimated to take three days time, someone working on it half-time will take more than six days to complete it. This is because people need time to "ramp-up" to the task; taking time to put away whatever they are working on, gather the resources necessary to work on the new task, and begin that work. They also need time to "ramp-down," putting resources away and preparing things so that the task can be picked up the next day. The project manager should add up to ten percent extra time for part-time resources.

Team Size

Team size can have unusual effects on a project. Research in organizational behavior shows that the optimal team size is between 5 and 12. Groups smaller than this may not be able to create the synergy and interchange of ideas necessary to provide creative approaches to problems. Groups larger than this tend to waste too much time communicating and solving group process problems.

Large teams (more than 20) are literally too large. Each person added to a group over this size actually cause the overall group productivity to fall. This is because of the need for communication and interfacing needed to make sure that tasks are coordinated.

If at all possible, avoid team size problems by making sure that project teams have between 5 and 12 people in them.

Team Efficiency

It may seem obvious, but some groups of people are more efficient than other groups. Some groups work well together, some do not. Project managers should try to assess the effect of team efficiency, or the lack of it, on task time.

Delay Effects

One final area for analysis is the effect of delay. Most delays need to be taken into account when scheduling the project, not when estimating tasks. Waiting for the return of a RFP, for example, is a scheduling delay, not a task delay. In the case where a technician has to wait idle for tests to run on a machine, the delay is a task delay.

Besides these task level estimates, it is also wise to look at other impacts. The use of structured methodologies, Computer Aided Software Engineering tools, or experience with specific hardware of software can help or hinder a project. The project manager should try to take these impacts into account as well.

Software Estimating

Beyond these common methods of estimating a project, there are also specific techniques used to estimate software projects. This next section takes a look at some of those methods.

Lines of Code

The sizing method of estimating the lines of code for software modules is one of the more frequently used estimating methods. It requires that the project being estimated be similar to others which have been previously completed. It is also not useful until the analysis phase of the lifecycle is reached.

The LINES OF CODE method can be used to define cost estimates for projects once the requirements phase is completed and the modules for the system are defined. Once this is complete, the following steps need to be taken:

Estimate the number of files and their size.

Estimate the number of input and output formats.

Estimate the types of programs required, including subprograms and subroutines.

Estimate the number of programs required.

Estimate the number of LOC for each program, utility, and test generators (not including comments, debug statements and continuations).

Estimate the complexity of the programs, taking into account the function, size and technology of the programs.

Once these initial estimations have been made, then various estimating models, such as the COCOMO model by Boehm or the Jensen or Putnam models can be used. The most accepted of these models is the COCOMO model. The basic COCOMO model is used for estimating relatively small, simple projects. These are what Boehm calls organic projects. Semi-detached projects are intermediate in size while embedded projects are ones with tight hardware, software and operational constraints. The equations for estimating project time are:

E= a b (KLOC) EXP (b b )

D= c b (E) EXP (d b )

where E is the effort applied in person-months, D is the development time in chronological months, and KLOC is the number of delivered lines of code for the project (expressed in thousands). The coefficients are shown below:

Thus, if an intermediate level project had been estimated to have 33,000 lines of code the calculation would look something like this:

E = 3.0(33.3) 1.12

E = 152 person months

D = 2.5(152) 0.35

D = 14.5 months

This allows the project manager to estimate the number of people (N) needed to complete the project:

N = E/D

N = 11 people

The basic model has been extended to consider "cost-driver attributes" for intermediate and larger projects. The following attributes are considered:

These effort adjustment factors (EAF) are rated on a six point scale that ranges from very low to very high. Based on the rating, an effort multiplier is determined using the following formula and table:

E = a i (LOC) EXP (b i ) X EAF

where E is the effort applied in person-months and LOC is the estimated lines of code. The coefficients are shown in the following table:

Boehm considered the model to be effective if it could estimated correctly within 20% of actual time on 70% of the projects.

The Lines of Code method is an accepted method for measuring the success of projects, but is considered to be a less effective tool for estimating. Function point analysis, laid out in greater detail later, is less subject to error and mis-interpretation.

Function Point Analysis

The function point model is a more subjective sizing model for estimating the functionality of the software to be built. It is based on the number of inputs, outputs, files and interfaces, their complexity and various adjusting factors. It can be used earlier in the project lifecycle than LOC, but is not effective until the requirements are fairly well known.

Function points are computed by looking at five specific elements. The software project is analyzed to define which elements are present.

Function Point Elements

Each of those elements is rated on a three level complexity scale:

Function Point Complexity

Once each element is defined, another analysis is done to define the degree of influence of 14 general application characteristics. Each characteristic is rated for its degree of influence based on a weight of 0 to 5.

Application Influencing Characteristics

The function point calculation is made by first computing the raw function point score by adding up the values for each of the software application elements. This raw score is then multiplied by the sum of the influencing factors to arrive at the total function point score.

A sample case will illustrate this computation. Imagine that we have a project reporting system which will provide information to both the information systems team and the client reporting system. The system will have a total of six different on-line transactions which update two different master files. It will output six different batch reports run on a daily basis, and support three different on-line inquiries. As the project manger has begun preparation for building the system, the following complexity scores have been established for the system.

The figures are plugged into the formula

Raw function points X ((.65 + ( influence factors X .01)) = Total Function Points

111 X ((.65 + ( 34 X .01)) = 110

Recent research has shown the following:

Computing function points is fairly simple, taking only a few hours for a one-year project. It is critical, however, to apply a consistent set of definitions to function point analysis.

The U.S. information systems application development average is five function points per month. This is also the average for COBOL

Fourth generation languages average 10 function points per month, assembly language 3 function points per month.

Recent C.A.S.E. projects have averaged between 15 and 20 function points per month.

Expert Estimator Tools

More and more organizations are beginning to establish the use of software estimating packages run by experts. This gives the organization a person who, with every project becomes more expert in estimating and using the software. There are several different packages on the market - each of which has strengths and weaknesses.

An expert estimator or team using an expert estimating tool such as CA-ESTIMACS® or CHECKPOINT® can make the process of estimating a project much easier. The bias of the estimator and the tools used must be carefully controlled. To be effective the estimator must be aware of the environment and experience of the organization. This method can be used early in the lifecycle, but becomes more effective during and after the initial planning stage.

CA-Estimacs by Computer Associates. This product is the most comprehensive tool. It can be teamed with PLAN-MAX and Super Project Expert for a complete set of project management tools. It is based on the function point analysis method and includes tools for effort estimating, staffing, financial analysis, strategic planning and function point estimating. It is fairly accurate for early estimating.

PMS/BRIDGE . This tool from Applied Business Technology includes tools for effort and cost estimating, financial estimating, and risk assessment. It is built around the WBS methodology and can be linked to the Project Management Workbench.

CHECKPOINT. This tool was developed by T. Capers Jones and is built around the function point methodology. It supports effort and cost estimating as well as function point analysis. It is very useful after the requirements phase has been completed.

Project Size Considerations

The size of systems can have a significant effect on the estimating of those systems.

Small Systems: Less than 15,000 LOC or 150 FP.

The management level is minimal. Can perhaps be handled by one person working part time.

Systems interfaces are straight forward and minimal.

Systems integration is fairly simple.

Documentation is easy.

Communications remains important, but can be managed without a great deal of effort.

Overhead costs are low.

Requirements tend to be stable.

Usually at a single site with a small number of users.

Testing effort is small.

Maintenance is limited.

Medium Systems: 15K to 75K LOC or 150 to 750 FP

Management effort can no longer be part time. Project managers must pay close attention to lifecycle and details.

Systems interfaces are more complex.

Systems integration efforts increase with the number of modules.

Documentation is more difficult.

Communications becomes more important and must be consciously managed.

Overhead costs are moderate.

Requirements tend to be less stable due to longer project time.

May be at multiple sites with several users using the system in different ways.

Testing effort becomes significant.

Maintenance becomes more likely and more significant.

Large Systems: More than 75K LOC or 700 FP

The systems life expectancy is much greater.

Management effort is a significant portion of the cost. Project managers must pay very close attention to lifecycle and details.

Systems interfaces are more complex and more numerous.

Systems integration is very complex.

Documentation is more difficult. It must be closely monitored at each phase of the project.

Communications are critical and consume large amounts of time.

Overhead costs are large.

Requirements changes are inevitable.

Often at multiple sites with several users using the system in different ways.

Testing effort becomes critical.

Maintenance is inevitable.

Very Large Systems: Over 200K LOC or 1000 FP

These systems are an order of magnitude more difficult to manage and implement.

Rules Of Thumb

Productivity for systems programming ranges from 3 to 15 lines of debugged lines of code or 1 to 3 function points per month.

Productivity for applications programming ranges between 15 and 60 debugged lines of code or 3 to 5 function points per month.

Cost runs between $5.00 and $225 per line of code with the average between $70 and $125.

The most difficult projects to estimate are ones which run in excess of 100K lines of code or 1000 function points. Since the systems are so complex, small changes in requirements or cost drivers can create severe interactions and cause wide cost variations.

Projects which are undertaken with too many people, too few people, or with a timeline which is shorter than the shortest feasible timeline have a success probability of less than 25%.

The advantages of tools such as CASE and 4GL's are not realized unless a structured methodology and lifecycle are accepted and used. If they are used correctly, ratios of as much as 10:1 can be realized over the productivity of programmers writing assembly code programs.

Responsibilities

Estimating a project is a difficult, time-consuming process. The project manager who believes he or she can "do it alone" will fail. In order to make an effective estimate the project manager, users, and project team members must be involved.

Users

Define the functional requirements, user organization costs, system and organizational constraints, and acceptance criteria.

Project Leader

Coordinates the cost estimating effort. Estimates the resource constraints and opportunities. Defines the complexity factors and adjusting factors for the project. Presents the estimation efforts of the team to users and top management.

Project Team

Clarify Requirements

Develop WBS

Determine Software Requirements

LOC or FP

Complexity levels

Resources needed for each task

Compute expected values for each task

Define relationships and dependencies

Estimate duration for each use of each resource

Estimating Steps

The basic steps for estimating a project are as follows:

Select an estimating method. The following are recommended at different steps in the project:

At project start-up use an EXPERT ESTIMATOR and (if possible) an expert estimating tool, to help you get a rough estimate of the project size.

At the early planning stage, use the TIME -BASED APPROACH to estimate the time and cost involved in the phases, milestones, and tasks which need to be accomplished.

Once the basic parameters of the software design are known, use the FUNCTION POINT ANALYSIS technique to estimate the time needed to complete work on the software. The LINES OF CODE method may be substituted later in the project lifecycle.

Assign the appropriate responsibilities to staff members and users. Manage the process of estimating through them. One important part of the process is to have several people estimate the same part of the project. They will give you slightly different answers, but you can take the weighted average of those estimates.

While others are preparing their estimates, define the adjusting factors (such as distributed data processing, hardware and software issues) that will positively or negatively impact the estimates.

Remember that estimating does not come easily. Your organization will get better at it each time as you gather and maintain historical data on your estimates and their accuracy. The use of a tool such as CA-ESTIMACS will greatly aid this process. To be effective, you should set up an estimating database. To make this database work, an organization would have to:

Use a consistent set of estimating methods used for all projects.

Develop a tool for tracking:

Effort expended per phase

Elapsed time and tasks - estimated and actual

Total FP for the project by module and language

Use the attached tools to help you in your estimating process. The time based ESTIMATING WORKSHEET can be used to get a handle on the phases, milestones and tasks. It is broken down by level 3 key results. The second function point ESTIMATING WORKSHEET is designed to help you establish the function points for clearly identified software packages.

Take the time and the care needed to develop a good estimate.