|
Project managers are under a lot of pressure to produce estimates of time and cost
for systems development very early in a project, typically in the first two weeks.
However, estimating a development project from outline requirements and not from
a physical design is like a home buyer saying, “Quote me a price for building a house,
but I am not sure where I want the house located, or about the number of rooms, or
whether it should be of brick or wood.” It is not surprising that project estimates are
as bad as they are, but that they can be made and met at all. Three approaches can
be taken to estimating:
1. Using industry experience
2. Using the experience of one’s own organization
3. Rolling up more or less detailed estimates of the project effort
Using Industry Experience: Function Points
Perhaps the most useful form of recorded industry experience comes in function
point counts. Many people measure software efforts based on the number of lines of
code. The trouble with this measure is that the same function involves many more
lines in a low-level language than in a high-level language. Often, an algorithm
coded in one language requires more lines to be coded in another language.
A function point count is a more stable measure of software size than lines of code,
because it is based on the number of inputs, outputs, files, and other measures of
complexity. The International Function Point Users Group (IFPUG) has put
considerable effort into devising and maintaining standard methods for sizing
software.
The Function Point Method Briefly, one counts the files, inputs, outputs, and
queries involved in an application. Each is rated as simple, average, or complex.
Each rating is weighted to yield the unadjusted function point count. For example, if
five files in an application are of average complexity (for which the IFPUG method
specifies a weighting of 10), they add 50 function points to the total.
The whole application is rated on 14 measures of overall complexity, which include
the degree of distributed processing and the proportion of transactions that involve
online data entry. Each complexity measure is rated on a five-point scale (i.e., 70 is
the highest score possible). The complexity rating is divided by 100 and 0.65 is
added to yield a factor ranging from 0.65 to 1.35. The unadjusted function point
count is multiplied by this factor to obtain the adjusted function point count.
For example, the counting and weighting of files and other items produces an
unadjusted function point count of 1000. The application is of significant complexity
and the rating of the 14 complexity measures gives a total of 60 points. As 60/100 +
0.65 is 1.25, the adjusted function point count would be 1250.
Measuring Productivity in Function Points Many thousands of projects have
been analyzed to build up function point databases, which can be used to compare
the effort that went into each project with the number of function points created.
Wide ranges of productivity exist. For example, with inexperienced staff,
unstructured methods, ordinary tools, and low-level languages, productivity ranges
from 0.25 to 5 function points per staff month. At the other end of the range, with
experienced staff, structured methods, power tools, and high-level languages,
productivity ranges from 20 to 100 function points per staff month. IS projects
generally range from 3 to 50 function points per staff month, and the average is 8
function points.
If a project team can achieve ten function points per staff month, then a 1250-
function-point project takes 125 staff-months or ten people a little longer than a year.
If productivity is 20 function points per staff month, then the work can be done in
half the time.
Although function points are a reasonable sizing measure, they are not much use in
estimating effort unless productivity can be estimated. To do that requires a track
record of the project productivity of the staff.
The Value of Project Experience
Despite its importance in estimating, very few organizations have a database of
project experience. Instead, experience on a project is in the heads of project team
members and is not easy for the manager of the next project to access. Indeed, very
few organizations keep reliable figures on the actual hours taken in project
development. As automated process management tools become more widely used, it
becomes less expensive and easier to use past project history.
A process management tool should help in answering the following questions:
>> Which past projects are similar to the current one?
>> What was the effort on similar projects overall and by task?
>> How do the skills of the people on similar projects compare with those of the
current project staff?
Finding Similar Projects A similar project may be one that has the same tasks that
were done by the same people, used the same programming language, or met other
criteria. A project history database must enable the search for similar projects. This
implies that all projects must be performed using a standard set of tasks, just as
accounting costs must be analyzed using a standard chart of accounts. If each
project manager makes up the names of the tasks on each project, how can projects
be compared with one another?
Determining Past Effort and Skills Once the similar projects are chosen, the
manager of the new project needs to know the effort on similar projects, overall and
by task, and the skills of those who worked on these projects. The manager can find
this information if the time and cost spent has been recorded in a standard way and
if data is reasonably complete. To quote productivity expert Capers Jones, “The
historical data for projects used internally by corporations is close to worthless for
economic studies. Direct user costs are essentially never tracked, unpaid overtime is
seldom tracked, and carelessness in charging time to the correct set of project
accounts is rampant in the MIS domain.”
Automated process management tools must make the recording of actual effort
against standard categories inexpensive and easy for everyone putting in time on a
project; then project history can become a meaningful aid to estimating.
Roll-Up of Estimates
Using experience to size a project from the top down has value because it can be
done early in the project when only general knowledge about the physical design is
available. Function point counting, however, is based on physical information about
files, inputs, and outputs.
The most reliable method of estimating, although the most time -consuming, is to
make an estimate for each piece of work jointly with the team member who is
responsible for it and to combine the estimates from the bottom up. Bottom-up
estimating involves answering three questions:
>> What tasks have to be done?
>> Who is going to do them?
>> How long will they take to complete? (Detailed estimates can be imposed on
or negotiated with employees.)
A project leader talented in informal project management can negotiate tight but
achievable estimates as well as obtain personal commitment from the staff members.
Firm commitment can only be made once the design is known at least in outline form.
Top-down estimates are made early in a project, done cheaply, and often changed.
Bottom-up estimates are set, costly to produce, and established later in a project. | 
Disclaimer
