As a systems analyst, you will probably be called on to produce a number of estimates for your project. Indeed, you may be solely responsible for producing these estimates in some cases; in other cases, your project manager may ask you to develop estimates for his or her use.

What kind of things need to be estimated in a systems development project? This will vary from project to project, but typically the major things that need to be estimated are:

Keep in mind that you will generally have to make these estimates more than once. A set of estimates will generally be made in the early stages of a project (e.g., during the feasibility study), but they may need to be made many times, as users and management explore the ramifications of different trade-offs. One obvious example of this is the trade-off between time and functionality (e.g., the project manager might say to the user, “I’m pretty sure we can deliver the system to you by January 1st if you leave out functions X, Y, and Z.”); another example is the trade-off between time and people (e.g., the user might say to the project manager, “If you had three more programmers, would you be able to get the system done in time?”). It may take several iterations before the project team, management, and the user community have reached an acceptable compromise. [1]

B.2 ESTIMATING DANGERS

We have a great deal of common experience in the area of estimating; just think of all the situations typified by the question, “How long do you think it will take to drive to your grandmother’s house?” And we are all intuitively familiar with the concept of an optimistic estimate and a pessimistic estimate. But estimating a systems development project is somewhat different, because (1) the scope of work is much larger and more complex, and (2) the consequences of an estimating error are usually much more severe than that of being half an hour late to your grandmother’s house. [2] There are a number of common problems that you should be aware of before you begin calculating estimated budgets, schedules, and resource requirements:

Depending on your seniority in your project, and your clout with management and users, you may be able to prevent some of these problems from becoming serious. But even if you are a junior systems analyst on the project, you should be aware of the estimating problems, for they can ultimately determine the success or failure of your project.

All of these problems — which do lead to faulty estimates in many projects — underscore the need for formally establishing a “triage” approach when the requirements for the project are identified. Even if the initial estimate is reasonably accurate, problems may be encountered in the middle of the project that will make it difficult to implement all of the requirements by the time the deadline arrives. But more commonly, the estimate turns out to have been inaccurate from the very beginning; thus, it’s essential that the end-user and the project team understand which features/requirements are essential (sometimes known as “must-do” requirements), which ones are important (i.e., “should do”), and which ones are optional (i.e., “could do”).

We will discuss each of the problems in more detail next.

B.2.1 The Difference Between Estimating and Negotiating

There is often a great deal of negotiation at the beginning of a project (and often throughout the development phase of the project!). This is normal, because the user community often has little understanding of the amount of work involved in a complex information system and will thus “ask for the moon,” that is, an enormous amount of functionality in an absurdly small amount of time, and for little or no money. Meanwhile, the project manager is faced with limited staff and a limited budget; hence, she or he needs to work with the users to help them see what trade-offs are possible.

But this negotiating process, so necessary and so common in systems development projects, must not be confused with estimating. What you must avoid is the conversation between user and systems analyst (or whoever does the estimating) that goes like this:

without a willingness to discuss other trade-offs in functionality or resources. [3] This is sometimes followed by an appeal by the user to the project team’s sense of devotion, duty, and patriotism, which we will discuss as a separate problem in Section B.1.8. [4]

In some cases, this situation simply reflects a lack of understanding on the part of the user; it can usually be corrected by a careful explanation of the activities involved in developing a system. In other cases, though, it reflects the user’s overall approach, his business “paradigm,” for dealing with people and organizations that provide him with products and services. To the typical user, you see, the internal data processing organization is not that much different from an external vendor; negotiating, in an attempt to squeeze the price down or cut the schedule back a few months, is a very natural thing to do. And it is a reasonable thing to do (from his point of view) if the person or organization providing that service has a profit margin that can be cut down through skillful negotiation.

Even in the case of an internal data processing organization, negotiating (without accepting any trade-offs in functionality, resources, budget or schedule) may be reasonable if your estimates include a margin for error (otherwise known as a cushion or a contingency factor) that the user thinks is unreasonably large. But if you have provided careful, realistic estimates, and the user negotiates you down to a smaller staff, smaller budget, and tighter schedule, then your project has entered the realm of heavy-duty politics for which the techniques and tools discussed in this book probably won't help much. The time may have come to update your résumé.

Alternatively, if you decide to participate in the project despite having been negotiated into an unrealistic deadline, budget, or resource allocation, you should realize that you are probably going to experience what is commonly known as a “death-march” project. As the name implies, such projects often involve large amounts of overtime, leading to a certain degree of stress and exhaustion. However, there are a number of things that the project manager and team can do to maximize their chances of success in such projects; for more details, see [Yourdon, 1997].

B.2.2 The Wide Variation in Technician Skills

It is common to make estimates of the work to be done based on average talent (i.e., the typical programmer or systems analyst, who can write 15 lines of code, or draw four DFD bubbles, in an average day). It’s important to keep in mind that numerous studies over the past 20 years have documented an order of magnitude difference between talented professionals and mediocre professionals in the field. [5] If your project has a group of so-called super programmers, you may drastically overestimate the amount of time and money that will be required to finish the project. Of more concern is the fact that a project team of dullards may cause your project to miss its schedule and exceed its budget by a substantial amount.

One major problem in this area is that the actual performance of experienced practitioners does not correlate strongly with most standard programming aptitude tests. Hence, you must base your estimates on each person’s reputation or previous work experience, or you must simply assume that everyone on the project is average. Since most organizations don’t keep careful, detailed records on the productivity of each person in a systems development environment, it will be very difficult for you to obtain documented evidence that you can trust. All you can do is make your best judgment and then modify the estimates, as appropriate, during the course of the project.

B.2.3 The Danger of Estimating Your Own Work

One of the worst mistakes that you can make is to estimate your own work; it is almost as bad to use the estimate of any one single person, since that person’s judgment may be affected by a number of factors.

If you estimate your own work, you are very likely to fall prey to one or more of the following myths:

For these reasons, it’s very important that estimates be carried out by someone other than the person responsible for the work. It’s also highly desirable if one does not have an estimating database (discussed in Section B.1.4) or a computerized estimating package (discussed in Section B.4) to obtain estimates from more than one person. At the very least, get estimates from three people; this will give you a best case and worst case estimate, along with an in-between estimate.

B.2.4 The Lack of an Estimating Database

When faced with a new project, one would like to use statistics from a hundred similar projects in order to produce accurate estimates. Some consulting firms and software houses are able to do this: when asked to estimate the time and cost for, say, an order entry system, they can say, “Well, this is almost exactly the same as the last 137 order entry systems we’ve built, so it should take X person-months, Y dollars, and Z people.”

Even within your own organization, it’s possible that there have been 137 order entry systems developed over the past decade or two. But this doesn’t necessarily mean that it will be easy to estimate the budget or schedule for the 138th order entry system; if careful records have not been kept, all you can go on is hearsay and rumor. For a typical data processing organization, which acts as an internal service organization, without having to worry about profit/loss figures or cash flow considerations, there is no real incentive to keep such careful records.

Some large data processing organizations are beginning to change this attitude and have begun developing large, detailed databases that can be used to generate much more accurate estimates for future projects. And some consulting firms specializing in this area have developed databases of literally thousands of projects; these are usually used to provide parameters in the computerized estimating models discussed in Section B.4.

In the meantime, there is a significant likelihood that you will be faced with a one-of-a-kind estimate. You should certainly look for other, similar projects in your organization; but be aware that you may be in a situation analogous to the architect who was asked how long it would take build an underground house in a swamp.

B.2.5 Management’s Insistence on Premature Detailed Estimates

As a general rule, it is almost impossible to produce detailed estimates of costs, time, and resource requirements for a project until a considerable amount of detailed systems analysis and design have been done. After all, how can you tell the user how much a system will cost if you don’t know what the user wants? Nevertheless, there is often great pressure from both users and management to produce an estimate, which is presumed by both of those parties to be an accurate, detailed estimate, at a very early stage in the project. Why? Simply because they need to make a go/no-go decision to invest the time, money, and people required to build the system.

Indeed, in the worst case the schedule and deadline are determined before a project manager has been assigned, before anyone has done any thinking about budgets or personnel allocations, and before anyone has a clue about the detailed requirements for the system. You might well ask: how could a rational organization allow such a thing to occur? The answer is quite simple: external pressures. If the government suddenly announces new tax laws, or new reporting requirements for safety codes or employee pension plans, there is likely to be a deadline associated with those laws and requirements. If a competitor suddenly introduces a hot new product that threatens the success of the organization’s existing products, senior management may decree a deadline for creating a competitive response even before they worry about the other details. In other words, situations like this might not seem reasonable, but they do happen, and for very “real” reasons.

This demand for an early estimate is quite understandable; the only thing that is not realistic is the assumption that an early estimate can be detailed or accurate. It’s more appropriate to give management a series of estimates throughout the project, with each one being progressively more detailed and more accurate. Thus, if the project team is developing a system for an application they are fairly familiar with, they might provide the following series of estimates:

B.2.6 An Industry-Wide Difficulty of Measuring the Unit of Work

Many industries have standard ways of measuring the amount of work to be done in a project. Someone building a house, for example, might measure the work in terms of the number of bricks to be laid or the number of rooms to be built. But in the field of systems development, there is still no agreed-upon way of measuring the unit of work to be done.

The most common method is to measure the number of program statements to be written, otherwise known as lines of code. Thus, on some projects, you will see references to KLOC, which stands for kilo lines of code. But there are many problems with lines of code as a measure of the unit of work:

As Capers Jones points out in Applied Software Measurement ([Jones, 1997]) different ways of measuring the unit of work can distort the reported productivity results by two orders of magnitude; perhaps that’s why some programmers can claim to be 10 times or even 100 times more productive than their colleagues! Because of these problems, some organizations are now beginning to use function points as the unit of work; this corresponds roughly to the bottom-level atomic bubbles in a DFD.[7]

B.2.7 Estimates Based on Assumptions of Unpaid Overtime

As mentioned earlier, users and project managers may react to scheduling conflicts by suggesting, implicitly or explicitly, that the project team put in extra hours, work on weekends, skip holidays, and postpone vacations. This is usually accompanied with appeals to the loyalty, professionalism, dedication, devotion, pride, honor, and patriotism of the project participants.

I’ll leave it to you to decide whether a willingness to work extra hours is a necessary attribute of patriotism. In some organizations, this may be the case: every project may be organized in such a way that it will only succeed if the project team regularly puts in an 80-hour week. And some projects (e.g., the NASA Apollo project that put the first men on the moon in the late 1960s) may be so exhilarating that everyone will be more than happy to sign up for the extra work required. And it’s not uncommon to find that a project that appeared to be under control falls behind schedule during the last month, requiring a few weeks of late evenings and weekends.

But you have to remember that working is like running: you can sprint at top speed for a hundred yards, but you can’t sprint at top speed for a 26-mile marathon. Similarly, you can work 14-hour days for a few weeks, but it’s unrealistic, in most cases, to assume that you can work 14-hour days for a 3-year project. People with spouses (spice?), children, or other outside interests will simply refuse to continue working such hours after a few months; if necessary, they’ll quit and find another job. Young, single people may be more willing to devote their entire waking lives (as well as their dreams) to the project, especially if they feel it will help advance their career or their knowledge of the profession.

Even if members of the staff are willing to work 14-hour days, there is no guarantee that they will be effective at their work. This is especially true if the overtime work continues for a period of several months: the long evening hours are often unproductive, and one usually finds that more errors are created as people do their work in an exhausted, frazzled state of mind.

There’s a more subtle version of this problem in many organizations: overtime work on the part of professional staff members throughout the organization (not just IT) is allowed, encouraged, and even expected — but not measured. [8] The rationale is simple: since professional “knowledge workers” are not paid for such work (at least not in most North American and Western European countries), there is no need to measure it. Indeed, to do so is an embarrassing reminder to management that either (a) they created such poor estimates of the project that they had no alternative but to ask their staff to work long hours, or (b) they deliberately created a “slave labor” environment to cut labor costs. Whether or not one agrees with the ethics of such management practices, it’s still a bad idea not to measure the overtime — for it creates a false impression of the “true” productivity (e.g., lines of code per person-day), schedule, and budget.

B.3 ESTIMATING GUIDELINES

There are four important guidelines to keep in mind when you develop estimates for the amount of work to be done in a systems development project:

These are discussed next.

B.3.1 Make the Estimating Units as Small as Possible

This should be an obvious suggestion, but it is not followed as often as you might think; it also has some pitfalls, as we shall see. But, in general, it’s much better to estimate the budget and schedule for a one-week unit of work than it is to estimate a “man-millennium.” [9] Large projects have large complexities; if you try to estimate the amount of work involved, you are almost certain to make major errors. It makes much more sense to base your estimates on small amounts of work.

This implies, of course, that the overall project has been broken down into small units of work. This will normally happen quite naturally as a result of structured analysis, structured design, and structured programming; unfortunately, as discussed in Section B.1.5, you may be required to provide a detailed estimate of budget and resource requirements before this detailed work-breakdown has taken place. There is no magic solution to this problem; all you can do is try to impress upon your managers and the users that a detailed, accurate estimate requires some initial effort to identify the units of work to be done.

But how small should the units of work be? Some organizations measure work in units of one month; however, this seems too large — projects can get seriously out of control in the span of one month. It is perhaps more reasonable to measure work in units of one week; as one veteran project manager said to me, “Nothing useful ever gets done in less than a week.” Perhaps the most common unit of work, though, is a day; this fits nicely with the way we organize our work life. A few organizations actually measure their work in units of an hour; while there are indeed many activities that take an hour or less (e.g., defining a single data element in the data dictionary), it seems too microscopic a unit to work with.

B.3.2 Make the Units of Work as Independent as Possible

A problem that has plagued many attempts at estimating is the interaction, or coupling, between one piece of work and another. If a system is divided into pieces with many, many interactions, then the total amount of work to develop the system will be far more than the linear sum of the work for each piece. If a change is made to piece 13, for example, the change may cause problems in piece 14, and a change to 14 could result in changes being made to 15, and so on. This ripple effect has wreaked havoc in many projects.

The solution is to divide the system into small, independent pieces that are only loosely coupled to other pieces. This requires careful work; we discussed it in Chapter 20 as the major rationale for grouping low-level bubbles in the preliminary behavioral model into higher-level aggregates. The notion of modular independence is also important during the design phase of the project; we discussed this in Chapter 22.

B.3.3 Take into Account the Communication Factor

Even in a project where all the modules are independent of one another, people have to talk to one another. If the project is carried out by one individual, then the only communications required are those that take place with the user (and perhaps some discussions with management). But a typical project has many systems analysts, designers, database specialists, and programmers; even worse, some of these people may work in different companies or even speak different languages.

Thus, your estimates will have to include some time for communication between all the project personnel. This communication will take the form of meetings, memos, telephone conversations, and so forth. Keep in mind also that the amount of communication increases sharply as the size of the project team increases: the number of communication paths between team members increases as the factorial of the number of individuals.

B.3.4 Distinguish Between New Work and Borrowed Work

If the project team is lucky, it will be able to make use of work that was done on previous projects; most often, this takes the form of modules in a common software library. [10] However, you should not assume that the reusable modules are free; it will take some amount of work to (1) find them, (2) investigate them to see if they perform the desired function, and (3) learn enough about them to understand how to use them. It’s more appropriate to estimate that the borrowed modules will require some fraction (perhaps 25%, perhaps as low as 10%) of the work that would have been necessary to develop the modules from the beginning.

B.3.5 Be Aware of Time Delays and Feedback Loops

In Chapter 6, we saw several examples of typical “project life cycles” for systems development; they consist of a network of activities, with the output from one activity becoming input to the next. However, there are two common oversimplifications that project teams make when using these life-cycle models as the basis for their estimates:

They assume that the “transition” from activity N to activity N+1 is instantaneous. But in the “real world,” that may not be true; there are often “hidden” delays that prevent activity N+1 from getting started. For example, activity N might produce a set of data flow diagrams and other documents, which must be sent via “snail-mail” to a different group carrying out the design and implementation. If the post office takes a week to deliver the snail-mail, then activity N+1 has been delayed for a week. Or, equally common: the technical team has finished producing the output for activity N, but is not permitted to send it onward until it has been officially “approved” by the manager of the team that carried out the technical work. Unfortunately, the manager is away on vacation for two weeks, so nothing happens until he or she returns — and, in particular, activity N+1 doesn’t begin.

They assume that work always flows “forward” from activity N to activity N+1 to activity N+2, etc. But sometimes there are feedback loops — i.e., work flows “backward” from activity N+1 back to activity N because of problems, misunderstandings, or changes in the business environment. For example, when the systems analysis activity is finished, the output (dataflow diagrams, etc.) is sent to the design activity; but if the designers discover analysis-related defects, then they must send the materials back to the analysis group for re-work. Re-work (and thus a feedback loop) is also common when the testing activity discovers bugs that require re-programming effort.

Models that emphasize time-delays and feedback looks are often referred to as systems dynamics models; thus, the ideal “estimating model” would be more complex and sophisticated than a simple mathematical formula. Indeed, system dynamics models of the software development process have been developed, though they are not widely used; for more details, see [Abdel-Hamid and Madnick, 1991].

B.4 FORMULAS FOR ESTIMATING

During the past 20 years, the systems development industry has invested an enormous amount of time and effort developing models, or formulas, to help predict the time, resources, and cost of a system. Some of these models are now in widespread use; perhaps the best known model is the COCOMO model developed by Barry Boehm at TRW. [11] But as Tom DeMarco points out in Controlling Software Projects.

There are no transportable cost models. If you wait for someone elsewhere to develop a set of formulas that you can use for cost forecasting in your own shop, you will probably wait forever. Much of our industry concluded, upon realizing this fact, that cost modeling was therefore irrelevant. I think that was the wrong conclusion. If locally developed cost models can be used to improve the precision of the cost-forecasting process, and if the improvement is worth the cost of developing the models, then the concept is viable.

However, it is interesting to see some of the formulas used in other organizations; if nothing else, they will give you a starting point for developing your own formulas. Some of the formulas involve as many as 40 factors or parameters; but, as we will see, some involve only one parameter.

B.4.1 Formulas for Estimating Work Time

Three common formulas for estimating the effort (described in person-months) are based on lines of code. Walston and Felix developed a model at IBM (see [Walston and Felix, 1977]), based on observations of some sixty projects, which is expressed as

where E was measured in person-months, and L was measured in thousands of lines of code.

Similarly, Bailey and Basili developed a formula based on 19 projects; it is expressed as

where effort was measured, once again, in person-months, and DL is thousands of lines of delivered code; see [Bailey and Basili, 1983].

Finally, Barry Boehm’s COCOMO model has an effort formula for three different types of system: organic systems, semidetached systems, and embedded systems:

where KDSI represents Òkilo delivered source instructions; see [Boehm, 1981] for details.

B.4.2 Formulas for Estimating Time

Once you have developed an estimate of the amount of work to be done, you might think that it’s easy to estimate the length of time that the project will take. After all, if you have a project estimated at 10 person-months of work, and 5 people are available, then it should take 2 calendar months to finish the project. But what if only 2 people are available? Does the project then take 5 calendar months?

In general, what we are concerned with here is the trade-off between time and people. Many years of painful experience have taught us that the trade-off is not a simple one: doubling the number of people on a project does not necessarily cut the duration of the project in half. Indeed, Fred Brooks, the architect of the original OS/360 operating system, coined the phrase, “Adding more people to a late software project just makes it later.” There are two reasons for this: (1) adding more people increases the required communication between team members, which reduces productivity, and (2) some work in the project is indivisible; it can only be done by one person and adding more people simply won’t help.

While this is a useful concept, it does not tell us specifically how many people a project will need nor how long it will take. This area has also been the subject of research; Barry Boehm found, for example, that the calendar time for a project could be expressed by the following formula:

where E is the effort of the project measured in person-months; see [Boehm, 1981] for details.

Studies have also been made of the optimal “manpower loading” for a project; the three best known formulas are based on the work of Norden, Putnam, and Parr; see [Norden, 1963], [Putnam and Fitzsimmons, 1979] and [Parr, 1980]. Norden was the first to find that project staffing follows a curve similar to the one shown in Figure B.1.

The chart is often known as a Rayleigh distribution, based on the mathematical formula for the curve. Putnam provided a formula describing the number of people required on the project as a function of calendar time:

where K is the total effort of the project (expressed in people-months), and a is an acceleration factor that establishes the initial slope of the curve. (Note that K represents the total area under the curve.)

An alternative model was developed by Parr [Parr, 1980]; while the overall shape looks similar to Figure B.1, it estimates a higher amount of staffing in the early phases of the project. The Parr model is described by the following formula:

B.5 COMPUTERIZED ESTIMATING MODELS

The idea of using formulas with exponentials and hyperbolic secants is probably not very appealing; you can be sure that most veteran systems analysts have long since forgotten what a hyperbolic secant is and have no idea how to compute an exponential! But it’s not necessary to remember any of the formulas, nor is it necessary to carry out any of the calculations by hand. There are now many computerized project estimating packages available; most run on PCs, and many of them utilize Boehm’s COCOMO model, as well as the Putnam model described above. Some can also incorporate the PERT charts and GANTT charts discussed in Chapter 16. Among the more popular estimating products are CHECKPOINT, from SPR (www.spr.com); SLIM, from Quantitative Systems Management (www.qsm.com); and OnYourMark, from Omni-Vista (www.omni-vista.com).

If you are working on anything other than a trivial system, you should definitely investigate such packages. Not only will they carry out the calculations for you, but they will allow you to play “what-if” simulations to see the effect of adding people to the project or losing people because of sickness or other calamities. In addition, they can help accomplish a more rational form of “negotiation” with the end-user, in order to examine the results of various tradeoffs between schedule, manpower, resources, defects, and risk.

REFERENCES

FOOTNOTES