2. Software Project Estimating Obstacles
System analysts and project managers have always been challenged with determining a well-defined project scope. This difficulty in determining user or system requirements has led to cancellation, cost overruns, or protracted delivery dates for software projects, applications, and maintenance (Smith 2000). In this section the focus will be on what are the obstacles to successfully determining user requirements.
According to a study done by the Standish Group International, their 1995 Chaos Report on information technology (IT) project failures indicated that 40 percent of all application development projects were canceled before completion. Further U.S. companies lost $145 billion annually due to project failures or overruns (Gordon 1999). Notwithstanding these statistics, a more recent study on 100 companies concluded that 37 percent of major IT projects were completed as scheduled. However only 42 percent of all projects were completed on budget (Gordon 1999). These findings illustrate that there is an opportunity for IT managers to accurately determine what the application should do and what resources to make it happen.
There is a cliché: you can't manage what you can't measure. The IT manager must be able to foresee the potential size and cost of a project for he or she to have success in managing it. Grupe and Clevenger cite seven critical objectives for managers to plan successful projects, these are 1) ascertain programmers' productivity, 2) reduce costs, 3) increase throughput, 4) create run-time efficiency, 5) timeliness of delivery, 6) increased service to end-users, and 7) operational efficiency of staff. Of these seven managerial objectives, understanding programmers' productivity and timeliness of software delivery are the most difficult to manage and estimate (Grupe 1991). Managers have measured programmers' productivity by determining the number of source line code that has been entered. The inherent problem with this method is the inability to compare applications using different programming languages. An anecdote to this method was the time a mid-size company determined the productivity of its programmers by measuring the number of times the programmer hit the return key. Naturally the programmers quickly figured this out and were much too obliging to hit the return key. The second managerial problem is to accurately schedule the software deliverable times. In order to create budgets and plan for expenses, senior management required IT managers to accurately estimate the cost and completion of projects. For end-users, their productivity often hinged on how well the systems were functioning. And the most important user of the business, the customer, has expectations built upon competitive market forces on how well the systems deliver the product or service to them (Grupe 1991). This is a tall order of responsibility on the shoulders of the IT manager. Furthermore this demonstrates the importance of discerning the programmers' productivity and required resources to keep development or maintenance costs to a minimum and deliver applications in a timely manner.
Coupled with the problem of discerning productivity and scheduling is the process of understanding the user requirements. Even though the manager knows the productivity of the resources involved and how to allocate them, unknowingly the requirements gathering fails and so does estimating costs and scheduling deliverables for the software application. As the project moves through the software development life cycle, requirement changes become increasingly more expensive and deliverable times become more protracted. Thus this leads to project failure or cost overruns. In essence this is the tragedy of "scope creep."
Gary Anthes argues seven facets of scope creep:
Studies on scope creep have revealed that 44 percent of projects have poor initial requirements definitions. An additional 22 percent in the research has revealed management failing to properly maintain expectations of senior management and end-users. These statistics help support the communication problem between end-users and system analysts or project managers, who gather project requirements. Consequently this undermines the manager's budgeting and scheduling, in conjunction with diminished productivity of the software development or maintenance group (Anthes 1994).
So far the discussion on consequences of poor project planning has hurt businesses' competitiveness in the U.S., organizations profitability, and the IT development staff's reliability. The inability to accurately gather requirements and communicate cost and deliverable times to end-users can have a profound affect on the project manager's job. The following describes a highly common scenario in the business world.
For over ten years, Jill Thomas has been a very successful programmer and project manager for Smith Enterprises, Inc. Recently she was asked by senior management to develop cost and scheduling estimates for a new licensing fees billing system. According to the request, Jill had developed a similar system months earlier and began on putting together the estimates. After review from senior management, the estimates were quickly approved and Jill began developing the new billing system. After several months into the project (the project was estimated to take five months), senior management wanted to see a demonstration of what she had completed thus far. Jill, who always was on ready for such requests, demonstrated the application to the senior management. Several of the senior managers were surprised that Jill was failing to produce the new billing system that would handle accounts receivable, cash outlays, the general ledger, etc. for Smith Enterprise, Inc. Much to Jill's astonishment and disappointment in the directives that she received by senior management, she embarked on developing a new corporate accounting system.
The resulting affect from this "miscommunication" was the following: 1) the new accounting system was months behind schedule; 2) the system was three times over budget; and 3) Jill suffers with the damage to her reputation. William Marks refers to a scenario like this as "qualification amnesia" (1992). This is the tendency of the users to only remember the estimate but forget or fail to disclose the qualifications or definition of the system. Nevertheless there are ways to avoid such miscommunication and demonstrate the need for function point analysis.
2.4 Communication and Measurement
In Jill's situation, too much was assumed from the standpoint of the project analyst and the senior management. However there are methods to minimize the communication errors. In addition function points are introduced here to present a quantitative measure to provide feedback on the project's scope for the end-user. There are six ways listed below to assist the system analyst or project manager to control expectations.
In order to discern the costs involved with a project, a metric needs to be used to determine the resources and time to complete the development of the application. Before using any metric to quantify the budget and schedule for developing or maintaining a software project, the project manager should meet following criteria: 1) if the metric's methods are not accepted by upper management, then support for the project my not be easy; 2) if programmers or managers have no goal with the metrics, then the metrics provide no value; and 3) the project manager should market the success of the project to upper management and end-users, stemming from the decisions based on the metrics used (Ray 1993). When the manager provides feedback on the success of the project, then upper management, programmers, and end-users find value in the metrics and confidence in the manager's decisions.