Accuracy of estimates of time necessary to implement a functionality

By June 20, 2015


Software is never completely free of errors. Even for the well-known packages that
are used by many (e.g. Word, Excel, Explorer, OSX, PHP, Flash), there are lists of
known bugs available on the Internet. New releases regularly appear on the market,
in which software errors have been removed. Customers sometimes expect errorfree
software. In practice, however, such a goal would make it impossible to
complete a piece of software. Moreover, software errors are often not inherent in the
software itself.
An educational game was made in Flash. It was agreed that the game would be
delivered as a file and that the customer would install it himself on his own server.
During the project, the customer requested that a high score feature be included in
the game to increase competition between players. This would require a piece of
script code in PHP. The game builders made and tested the script code on their own
server, which worked in Linux. It worked. The game and script code were delivered
to the customer. The customer, however, had a Windows server and, for some
reason, the script no longer worked well. The high scores were not saved. The
programmer eventually needed a week to resolve the problem. As it turned out, the
combination of PHP and Windows does not always work well. The script itself

contained absolutely no errors! By using a hack, he was able to get it to work, and
everyone was satisfied – but who should pay for that extra week of work?
Another software-development project also involved educational software. The
problem was that the software worked for the programmers, but it did not work well
for the customer. After trying nearly everything, the programmer decided to pay a
visit to the customer. As it turned out, the customer was using an old Pentium III
system. The slowness of the computer caused the poor performance of the software.
The programmers had also tested the software on a Pentium III, but it had worked
fine. Further investigation revealed that the customer’s computer was so slow
because it was full of viruses and spyware.
The uncertainty that is illustrated by the examples above does not simplify the
writing of project plans. It also complicates agreements between the parties
involved. Someone must assume the risks for extra work that must be done. If
payment is on an hourly basis, the customer assumes the risk. If a fixed price has
been agreed (as in grant-funded projects), the software builder assumes the risk.
When more than two parties are involved, it becomes even more complicated. In
such a case, who should pay for the extra hours in the project?
Discussions often arise concerning who should be responsible for delays. In
many cases, the guilty party is difficult to identify. It is quite possible that none of
the parties involved is at fault, as the ‘delay’ is actually the result of a faulty initial
estimate of the number of hours that would be needed. Exceeding the number of
project hours and the question of who should pay are frequent sources of conflict in
the IT world.
It should be possible for all intermediate results to be tested by
users throughout the entire trajectory of the project
In the definition phase and the design phase, customers are asked to formulate their
requirements as well as possible. This is difficult for two reasons. First, customers
have only a limited conception of the possibilities or impossibilities of IT. They do not
have a good idea of what is or should be possible or what they should or should not
want. Second, customers often have only limited knowledge of their own business
processes. Many IT projects involve the computerisation of a customer’s existing
business practices. Even though customers may have worked with the processes for
many years, they are often not able to define their own business processes. They
can work fine in their own way, but cannot say exactly what that way is. The precise
definition of processes is a precondition for making software that will drive
computerisation. The complexity for customers thus increases if they must describe
existing processes.
The list of requirements that is developed in the definition phase is often
incomplete. In the implementation phase, programmers make software according to
this incomplete list. When users are confronted with the initial versions of the new
software, additional requirements are identified. ‘It looks good, but now can you
make it so that I don’t have to keep entering my password?’ Programmers often
complain that customers do not know what they want. Customers appeal to the ‘fact’
that, because software developers are professionals, they should have determined
earlier in the process what the customers wanted.
In a software project that involved the automatic processing of applications for a
web-based service, an extensive functional design was made. Long lists of
requirements from the customer were compiled. A number of screen designs and
flow charts were added, after which the programmers could get started.
Probably because the project was under extreme time pressure or perhaps because
the customer’s organisation was rather chaotic, the designers had neglected to
include one important component: manual administration. The applications were
processed by the software. Because the processing of the applications was to be
automatic, the programmers thought that no manual administration would be
desired. This requirement also did not appear in the functional design. When the
software was delivered for testing, the customer realised that there were exceptions
in some of the applications. These applications could not be processed automatically,
but would have to be handled manually. The software, however, worked only
In the waterfall method, the actual project result is tested at the end of the
implementation phase. This is late in the development process. The time between
the definition phase, design phase and implementation phase sometimes amounts to
months or even more than a year. If design errors are discovered in a late stage of
the project, it can be expensive or sometimes even impossible to adapt software
without beginning an entirely new project. Because we have seen that it is practically
impossible to specify all requirements beforehand, a working method that allows the
possibility of testing (intermediate) results earlier is desirable.
Comparing a number of prospective software houses, a customer asked the
competing parties what was possible. One party was somewhat reserved and
doubted whether some of the customer’s requests would be feasible. The other party
had an aggressive sales representative. When the customer asked the sales
representative if a particular request would be possible, the sales representative
telephoned his programmers. ‘Can we build a functionality that can do X?’ The
programmer, who thought primarily in technical terms, answered that, in principal,
anything was possible. Neither the programmer nor the sales representative worried
about feasibility in terms of project management (e.g. time, money, complexity,
The sales representative’s enthusiasm was more effective than the other party’s
reserved attitude had been. The customer chose the aggressive sales
representative’s offer. The newly acquired project subsequently came into the hands
of a project leader and a group of programmers. After a time, it became apparent
that the project did not fulfil the customer’s expectations. This had partially to do
with the fact that the processes were much more complicated for the customer than
they had originally appeared. During a heated discussion between the two parties,
the customer referred to the fact that the sales representative ‘had said that
functionality X would not be a problem’.
Cyclical methods of project management
Because of the issues that have been sketched above, a number of other methods of
project management have emerged in recent years. These methods are particularly
suited for IT-development projects. Examples of these relatively new streams within
project management include DSDM, RUP, eXtreme Programming (XP), RAD and agile
project management (McConnell, 1996; Kroll, 2004; Chromatic, 2003; Stapleton,
2002, [ii], [iii])
Although the above-mentioned methods of project management differ according
to a number of aspects, they are essentially the same. Because the path toward the
final goal of IT projects has proved so uncertain, these methods assume that the
goal will be achieved in a number of short cycles. This is the background for the term
‘cyclical’ project management for these methods