The waterfall technique is divided into stages. Project leaders must include estimates for the amount of time (and therefore money) required for each step in their project plans. We have previously established that time estimates are inherently problematic for any project, much more so when they must be set early in the project’s life. It is just not feasible for software projects. Consider the possibility that a qualitatively acceptable list of capabilities might be compiled during the defining phase. In principle, this should enable the project team to give a realistic estimate of the time required to develop each feature. However, in reality, there are too many uncertainties to provide a fair approximation:
However, in reality, there are too many uncertainties to provide a fair approximation:
- Frequently, after a feature is developed, it is found that the client does not need it. Thus, the hours spent developing this feature may be considered in vain.
- Throughout the course of the project, requirements may change.
- Should the capability be provided at a high cost or at a low cost? There are many implementation and realization techniques.
- How will the functionality be technically designed? The design greatly influences the amount of time required to create it.
- To what extent must the functioning be of a high standard? For instance, should a web application be fully accessible at all times, or should it be allowed to be down for a few hours per year?
- The time required to detect and correct software problems varies from minutes to weeks.
- How long will the new software take to install and integrate with the customer’s current systems?
- Lack of information about potential solutions further affects time estimates. Additionally, estimating the time required to acquire the requisite expertise is challenging.
The list above demonstrates that a variety of variables may influence the length of time required to develop a new piece of software. Estimations of the time required to develop a feature at the start of a project are often four times too low or four times too high. This implies that the time required may be four times more or four times less than an erroneous estimate. As the project develops, these estimates become more precise. After completing the functional design, the margin is decreased to 25% too much or too little. Only when the feature has been developed is it possible to give an estimate with a high degree of confidence.
Software Risks #
Project management software will never be fully error-free. Even for well-known programmes that are widely used (e.g., Word, Excel, Explorer, OS X, PHP, and Flash), the Internet has lists of known flaws. On a regular basis, new versions are made available on the market that fix software bugs. Customers sometimes demand software to be error-free. In reality, though, such a goal would make completing a piece of software unfeasible. Additionally, software faults are often not inherent in the programme.
Flash was used to create an instructional game. The client agreed to get the game as a file and install it on his own server. During the course of the project, the client asked that a high score feature be added to the game to enhance player competitiveness. This would need some PHP script code. The game developers developed and tested the script code on their own server running Linux. It was successful. The client received the game and script code. However, the client used a Windows server, and for some reason, the script stopped working properly. The best grades were not retained. The programmer ultimately needs a week to fix the issue. As it turns out, PHP and Windows do not always function well together. The script in its entirety had no mistakes at all! He was able to make it function via the use of a hack, and everyone was pleased — but who should pay for that additional week of labour?
Another software development project included the creation of instructional applications as well. The issue was that the software worked great for the developers but not good for the client. After exhausting all other possibilities, the programmer decided to pay the client a visit. As it turned out, the client was running a Pentium III machine from the early 1990s. The computer’s slowness contributed to the software’s poor performance. Additionally, the programmers tried the software on a Pentium III, and it worked well. Further examination showed that the customer’s PC was running slowly due to a virus and spyware infection.
Managing Uncertainties In Project Development #
The uncertainty shown by the instances above complicates the process of developing project plans. Additionally, it complicates negotiations between the parties. Someone must bear the risks associated with the additional labour that must be performed. If payment is made hourly, the client bears all risk. When a set fee is agreed upon (as is the case with grant-funded projects), the software developer bears the risk. When there are more than two people involved, the situation gets more complex. In this scenario, who should bear the cost of the additional hours worked on the project?
Disputes often emerge about who should be held accountable for delays. Often, the responsible person is difficult to identify. It is quite conceivable that none of the parties involved are at blame, since the ‘delay’ was caused by an incorrect initial estimate of the number of hours required. Excessive project hours and the issue of who should pay are common causes of contention in the information technology industry.
