Project Control
One of the dangers of the popular project control methodologies is that they are so elaborate they become ends in themselves. There are two basic problems to solve — scheduling and control. The Structured System Development methodology assists in both areas:
• It identifies in detail the tasks to be done, and gives a good indication of their complexity;
• It provides deliverables right through the development stage. Once deadlines are set for each of these, progress against schedule can be measured.
Of course, it is not really quite that simple. Since the system did come in on time and under budget, it seems worth looking forany contributing factors and any problems encountered along the way:
• Estimates were done in great detail and always by at least two people working independently. This participation increases commitment to the resulting estimates, which are made more accurate by the detailed and independent assessments.
• Almost all our analysis and design estimates were exceeded while coding and testing underran, indicating that we are still influenced by the traditional breakdown of time. Fortunately, our clients had less confidence in our structured techniques than we did and increased the system testing budget substantially. This meant that the under-run in the code and test stage more than compensated for the previous overruns.
• When analysis and design effort exceeded estimates, it was not curtailed. Instead, areas of the system which could be deferred for later implementation were identified and placed "on hold". These were released as satisfactory progress was made in the later stages.
• Despite some pressure from the client, a team member who left three months before the original deadline was not replaced. Delays in the smelter construction had made the original deadline an
|
artificial one, and so the deadline was simply moved to a more appropriate date and the main constraint became total man hours. We believe, with Fred Brooks, that a new team member at that stage was more likely to decrease productivity than increase it.
Realistic Budget
IMPAC had some advantages in this area. The person responsible for project control from the client side is an experienced data processing consultant, Mike Dorahy of CSA, who had an accurate view of the time which the system development required. IMPAC also had a deadline which could be moved without cost. However, the fact that this project had a realistic budget from the outset cannot be dismissed as mere good fortune. A realistic budget is not a sufficient condition to bring a system in on time, but it is a necessary one.
If the budget and deadline are fixed, data processing personnel must be prepared to stand their ground and negotiate to reduce the scope of the project until it is feasible, if they want to retain any credibility. This is not a once-off exercise, but a continuing process throughout the system life cycle. The tendency of projects to grow in scope is often a contributing factor to budget over-runs and missed deadlines.
One solution is to "freeze'' the specification, but a better one is to re-assess priorities continually. Thus, when an additional feature is identified which really should be "in", some other process is found which can be omitted or deferred.
With good negotiating skills, one can defer those areas where requirements remain ill-defined, thus further reducing potential for cost over-runs. In our case, we eased out processes that had to communicate with other computers or receive data from special devices, problems renowned as difficult to solve. Instead, we wrote relatively simple data entry programs, which were, of course, required for back-up anyway.
|
