For us currently living in the now to which we call reality there are a series of events and outcomes that we are able to accurately predict what the end result will be with consideration for external variables. Time in the context of web development (or any other form of development) is a unique exception when it comes to predictability as it can often be negated and ignored despite it being a constant. To expand on what exactly I meant by it being negated is with how it is usually taken for granted with the hopes of change although most are knowledgeable with it being set in stone. This can be associated most commonly with the act of overestimating and underestimating the length of time needed for a project to be completed from beginning to end, with there being several elements which can contribute towards attaining either result.
Starting off with overestimation (being the less common of the two) this occurs when the amount of time given in comparison to the scope has been unnecessarily distanced from one another, this would mean that the project developers have been provided with a significant extra portion of time that is unneeded for completing to project and planning for said project. Whilst it might seem initially harmless for both parties to have the additional time given despite not requiring that much there are several parallel effects which seep their way in affecting the overall end of the project. The first of which being the possibility of the development team being dragged into a scenario that involves Parkinson’s Law. Being that if the project is given more time than needed the work itself would then become lengthen as to fill up the extra space, in turn resulting in tasks being completed slower than possible from a shorter time frame. The second aspect of overestimation to set back a project is with the coined term Student Syndrome, with it meaning when work of varying amounts is left until or near a deadline. Although this term has been primarily used in project management more frequently than other areas of development, due to it theoretically being able to affect any aspect of development there are crucial after effects which would occur. Some of which being, having the product be rushed and produced with noticeably reduced quality than originally intended, communication between members of the team would be hindered with the goal of finishing before the deadline taking over as the priority, and the scope of the project having to inevitably be reduced significantly in order to allow for the primary areas to be completed.
On the other side of the time-spectrum is with underestimating (the more common of the two estimations) the amount of time needed in order to complete a project. Likewise with the previous form of estimation failure there can also be a disconnect with the scope of the project, with the end result this time being there being less time available for the developers to utilise towards the project. Where it differs slightly is with the involvement of the client in the decision with how much time provided, where with overestimation the common cause can be the client’s lack of knowledge on the subject with them assuming the time frame needed is greater than what is required. With underestimation this varies between two common factors, the first being the same as previously mentioned (lack of knowledge), the other being the inclusion of external factors that have influence over the project. An example of this being a pre-planned due date for the project to be complete such as with Sydney Opera House. Which was estimated to be completed by 1963 when compared to its 1959 beginning of construction costing only 7 million Australian dollars, whereas in the end result it was finished in 1973 at a cost of 102 million Australian dollars. Other points that are present and explained in the overestimation area are also able to be present within this area, for example with the reduction in quality against the scope the event would be similar but the circumstances would of changed. Meaning that with the reduced time given there is still the hindrance to the final result of the product would still be just dreadful. TBC