More software projects have gone awry for lack of calendar time than for all other causes combined.
Work happens slowly. Why get impatient? No matter how much you water the trees, the fruits will come only at the right time.
To cook well requires a certain amount of time. If you must wait it is only to serve you better and please you more.
Take time for all things: great haste makes great waste.
Unreasonable haste is the direct road to error.
INTRODUCTION
Software estimation is an activity that is done often during a software project's life cycle. It is done often because it is expected to help in predicting how much will the project cost and when will the project get completed. As it is difficult to predict, especially the future, a lot of people are not comfortable with software estimation work. But since it is so important, especially at the time of bidding for project and later on, while looking for light at the end of the tunnel during development, software estimation can not be wished away. In this paper, we will try to elaborate on some of the issues linked to software estimation and put forward the point that a little different outlook can take away much of the discomfort surrounding software estimation work and, in turn, lead to projects that are less turbulent, easier to manage and eventually provide software closer to stakeholder's expectations in terms of functionality, quality, and the cost and time taken to build the software.
SOFTWARE ESTIMATION
Software estimation involves working out the effort required for completing the software development work. The effort is usually worked out in terms of man-months [sic]. Depending upon the number of people available, the maximum number of possible parallel threads of development and other constraints, and keeping a margin for unforeseen contingencies, the calendar time for the project is worked out. During this process, estimation of lines of code of the software to be developed is done, which helps in working out the corresponding development effort.
There are quite a few analytical models for estimating the software size and the corresponding time required to develop it. In practice, however, what is done is to break the overall software into into smaller modules. The size of smaller modules and the associated time to develop is estimated based on past experience. Then the time to develop of individual modules is laid out on a timeline chart, to arrive at the total calendar time required to complete the project.
PROJECT TIMELINE
Project timeline is a chart showing progress on different project activities on calendar time scale.
PROJECT DEADLINE
Project deadline is the date the project is to be completed. A project may have multiple deadlines, each corresponding to a project milestone.
PROBLEMS
THE LEARNING CURVE
In any project, various technologies are applied to solve the problem at hand. In general, the developers would have varying levels of expertise in these technologies. More so, some of the developers would not be knowing some of the technologies to be used. The learning curve, which gives one's expertise as one learns a subject with time, tells us, initially the rate of learning is slow, then there is very fast learning and finally as expertise has been gained, the rate of (new) learning drops.
Figure 1: The Learning Curve
Surprisingly, the software development life cycle models are silent about the learning of new technologies to be used in a project. There is a natural tendency to not to speak about something not known, especially if it happens to be in the domain of software technology. The best we are willing to do is to talk about is difficulty in knowing about requirements, which is in the application domain.
Nevertheless, in almost all projects, some new technology is to be used and some new concepts need to be mastered. As is seen in the learning curve, the initial learning part is difficult. A tight deadline makes it worse. The initial learning part becomes longer. In some cases, learning is put aside and all efforts are put towards getting some visible output. What happens is that the programmers never get past the initial part of the learning curve. This results in lack of creation of fundamental concepts and a poor quality of basic building blocks. This is like making a skyscraper without adequate foundation. The result may vary from a total project failure to an overall lack of quality of the developed software product.
MISSED DEADLINES
Although software engineering has matured during the last forty years and the software crisis is presumed to have been eradicated, software managers still seem to have problems with project schedules and deadlines. A lot many projects take much more time then planned. As someone has quipped, A badly managed project takes thrice the time planned, a well managed one takes only twice
. Software development teams take a lot of time planning schedules, re-working and re-negotiating schedules and analyzing why development did not happen as per schedule. Project teams may be spending about 15-20% of the time in project estimation and scheduling, which is actually a project overhead. It does not contribute to the software code that does the job.
The human aspect of project deadlines is that missing a deadline is considered some sort of a failure, resulting in disappointment and, sometimes, financial loss. More often than not, missing a deadline appears to have been beyond a team control. The reasons for missing may be external factors like some input not received from customer, or some bug not resolved till date or simply the development taking more time than planned.
PROJECT DEADLINES VERSUS OVERALL TIMELINE
A project's timeline is made up of individual deadlines linked to project's milestones. A project milestone and associated deadline indicates the work planned for that deadline. However if one looks at the work done during the project's timeline and the work planned for various deadlines, the difference between plan and achievement become apparent. In most projects, the progress achieved is a lot less than progress planned. For example, a project with a planned timeline of 18 months, may find that only 25% work has been done by the twelfth month. Yet, the balance 75% work might be planned for the final deadline of last six months, which could include the most difficult system testing. The software managers seem to think that if challenging milestones are put for a team, at least a fraction of work planned would be done and overall rate of progress would be better than before. Unfortunately, unrealistic milestones lead to wastage of precious resources and, quite often, the software developed is of poor quality and not useful for the end-product.
THE ANATOMY OF A DEADLINE
A deadline is the estimated date of completion of a project milestone. It is the date by which all the work involved in the current milestone should be completed, resulting in a deliverable software version which can be independently tested and released to the customer. So a project milestone along with its associated deadline is a mini-project in itself. There may be contractual obligations on the part of both supplier and customer associated with the deadline. Meeting the deadline by the supplier might result in release of payment and generation of goodwill for the supplier. However, if a deadline is not meet, dreadful things like straining of supplier-customer relations and, in extreme cases, premature termination of the project might happen.
Is it fair to treat a project deadline in such a sacrosanct manner? The answer to this question normally depends on which side of fence one is sitting. Software developers, obviously, would not want the deadline to be treated in such a final manner. They would normally say that a lot of progress had been achieved till date and the target milestone was only a short time away. A customer might think that missing the deadline was a serious default on planned project performance on the part of developers. Those in management might take a view somewhere in between, depending upon whether they were a part of developers' management or customer's management.
There is a case that our views of project deadlines are clouded by short-term goals and prejudices and while thinking of a project's deadlines we often forget about the bigger picture, the overall success of the project. The only reason project management exists, both on the customer's side and at the developer's side, is for the overall success of the project so that it meets the requirements of project's stakeholders. So we need to take a holistic view in this regard. The first step in this direction is to ask the questions,
How is the deadline arrived at?
What are the factors involved in meeting the deadline?
Is it correct to regard, meeting of a deadline as success and missing it a failure?
The answers to these questions are known to all. Deadlines are either estimated or set. Estimating is not an exact science; it is a heuristic aimed to arrive at a likely date of completion of task. Quite often, deadlines are set by managements based on their feel of the work involved, which can be quite off the mark. Software development depends on a lot of factors like the problem at hand, working environment, development environment – its stability and ease of use, quality of documentation, software process model followed for development, the clarity of requirements, inter-personal relationship between the developers and the customer and also between members of the development team, etc. A many of the factors may be beyond the control of a development team. In fact, a development team may really be trying to do the work in spite of some unfavorable factors.
Realizing the importance of meeting deadlines to the longevity of projects, many developers just claim meeting the deadline without completion of work. What follows is a protracted round of discussions during which the work done and not done is discovered. The storm of deadline weathered, what come at the end of work review is a list of errors or missing items, which can be taken up in the next milestone. Regarding missing a deadline as failure, consider a team which has done an exceptional quality work, taken pains to find a lot of hidden requirements and is only a few days away from completing a milestone when the deadline passes. Technically, it has missed a deadline and a short-sighted management may consider it a failure. It is not as rare as one may think; ask any software expert, it does happen. The situation is similar to that of a policeman who chased a robber for a kilometer, almost caught him and then heard the siren announcing the end of his duty for the day. He let the robber go.
DEADLINE AS ESTIMATED DATE OF COMPLETION (EDC)
The solution lies in realizing that a deadline is nothing more that an estimate which has a probability of happening sometime in future. A more helpful term for deadline is Estimated Date of Completion (EDC). When project managers estimate a deadline for a milestone, they are actually estimating a date for completion of a project milestone, the EDC. Taking a cue from Program Evaluation and Review Technique (PERT) model for project management, there are three estimates for EDC, viz.,
- optimistic time, O
- most likely time, M
- pessimistic time, P
Figure 2: The Optimistic, Most Likely, Pessimistic and Expected Times for Project Completion
As per PERT, the expected time for work completion, E is (O + 4M + P) / 6. It is biased towards the most likely time. This would be fine for engineering projects where specifications are in the form of engineering drawings and manufacturing and construction processes well understood using work study and time study techniques. In software development, we have a lot of uncertainties, the biggest being unknown or miss-understood requirements. Also, since programmers have a sense of pride and over-confidence, given a work, they feel
that they would be able to do it fast
. The problem is compounded by the management desire to play a major role in project execution and to drive
the project with close supervision
. Alas, neither the management nor the programmers can undo the delays caused by missing and miss-understood requirements and also poor software engineering. The urge to do the project faster creates a tense environment where programmers make more and more design and programming errors. The more a team tries to do the project faster, the more the delays as the errors keep on accumulating. The team gets into a vicious circle of poor software quality and project delays, from where, as time progresses, it becomes more and more difficult to come out.
THE CASE FOR A RELAXED INITIAL EDC
Since the project managers and programmers err in underestimating the work which has a detrimental effect on the entire project, it is best to add a margin to estimated optimistic, most likely and pessimistic times and then calculate the expected date of project completion. The margin should compensate for the uncertainties like gaps in understanding of requirements and other unanticipated problems that come up during the project [1].
Figure 3: The expected time for project with provision of error in estimation
E' is the EDC for the project, taking into account the errors in estimation for software development work.
POST EDC
Once we appreciate the probabilistic nature of EDC and have estimated it, we have taken the first necessary step towards ensuring success of our software project. But it is only the first step. It is necessary to follow it up with other equally necessary software project management steps to ensure that the project becomes successful. Some of these steps are to empowering developers to take and implement decisions regarding project infrastructure, encouraging good communication and inter-personal relationship between the customer and the developers and between the developers themselves, taking care of training required to do the project work, and providing leadership so that the developers are motivated. Once the basics of development environment are in place, the software process would become more and more predictable and the variation between estimates and actual time taken would gradually decrease.
Will a relaxed initial deadline result in programmers taking it easy and the project getting delayed right at the onset? A lot many managers would definitely think so and that is precisely the reason for a lot of turbulence in software projects. A lot many software projects get delayed right at the beginning, but for different reasons. The reasons, often, are – lack of adequate number of people, hazy requirements and lack of computing resources. Quite often, resources available are not matching with the resources required. In all this confusion, when there is an attempt to get fast progress with micro-management, the result is disastrous. On the other hand, if we create a positive environment with adequate resources and provide the required time for initial development, we would have contributed in creating a solid foundation on which a successful project can be built.
The remaining risk of programmers going to sleep because of relaxed deadline is managed by having meaningful project reviews. Unfortunately, most reviews tend to focus on what is not done rather than what is done. Such reviews achieve nothing and, in fact, do more harm than good to the project. The key to successful software project management , or for that matter any management, is to create a positive dynamic environment, where people go the extra mile on their own initiative. The reviews should focus on what had been done during the time period being reviewed and what might be the impediments coming in the path of the project team. A positive attitude on the part of reviewers coupled with a genuine interest in solving project problems should be adequate in managing this risk.
CONCLUSION
Many software projects end up as failures because of unreasonably tight deadlines. A deadline is an estimate for completion of development work. An alternative term for deadline is the estimated date of completion (EDC) of a project. Since it is an estimate made before starting the work, there is an associated probability that the work will actually get completed by the estimated deadline. For a given project, we can estimate the optimistic, most-likely and pessimistic times and apply a margin for uncertainty for software projects and then arrive at the expected or estimated date of completion (EDC) of a project. The EDC can be used as the deadline for the project. Having a relaxed initial deadline for a project improves the chances of project success significantly.
REFERENCE
1. Frederick P. Brooks, The Mythical Man-month, Essays on Software Engineering, Anniversary Edition
, Addison-Wesley Professional, August 1995.
