In: Root » Business » Management
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
1) E-articles is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringement, please read the terms of service and contact us or use the "Report this article" button on this page to investigate the problem.
2) E-articles is not responsible for inaccuracies, falsehoods, or any other types of misinformation this article may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. |
|||||||||||||
