(Re)Estimation: A brave man’s task

So the deal is closed, the client has just ordered a large-scaled software package and the company directors summon the project manager asking him for an estimation over the time and human resources required for the project’s successful implementation. In addition to the numerous variables that must be taken into account for the estimation, the manager must come with an answer which abides by the resource constraints imposed by the upper-level management and have to do with the company’s policy and/or specific commitments to the client. Based on the work of Frederick P. Brooks JR. [1], in this article we present a fundamental misconception of managers regarding cost estimation and we argue that there are two circumstances where a good manager should be brave enough to dispute the imposed constraints. Finally, we discuss the advances in software engineering research concerning resource estimation which can aid the manager in supporting his opinion.

Being pressurized by their superiors, many managers fall into the trap of treating manpower and time as interchangeable components (hence the title of [1]: “The Mythical Man-Month”). In software development process there is not necessarily a one-to-one proportional relationship between human resources and development time due to sequential bottlenecks. No matter how many programmers are assigned to a project, possible dependencies between sub-tasks could act as an inhibitory factor for reducing the development time (at least by a percentage analogous to manpower). One could argue that, with proper planning, the workforce could initially concentrate its efforts towards the core components of the system and then work on extensions that are independent. This is wrong because of another factor that affects productivity: coordination. The number of communications among programmers working on the same task increases exponentially as more people are added to the group and a large amount of time is wasted in trying to resolve disagreements and ensure that all members follow the same strategy when developing. So a good manager should have the courage to present an initial time estimation that violates the one imposed by the board if he envisages that the development process is infeasible within the time restriction, regardless of the manpower available. By doing so, he ensures that there will be no future changes in the schedule.

But what if the manager hesitated to disagree with his superiors and accepted the requirements? What is he supposed to do now when the first landmark has not been achieved and the irrationality of the initial estimation is becoming more and more apparent? This is another chance for him to show off his mentality and propose a radically altered estimation. Ideally, the new estimation should vary a lot from the initial for two reasons: Firstly, there must be enough time for all the development stages including possible implementation changes in case of future test failures. Secondly, it is essential that no other rescheduling takes place. Making continuous changes in the schedule is frustrating for the board, the customer and, more importantly, the developers. This re-estimation can be effectively combined with a reduction of the task where the developing team will only focus on the essential functionality of the system and postpone any extra stuff for later releases. The easy solution of adding programmers to the project can be disastrous for the same reasons as before plus one more: the newcomers would need time get into things and understand the concepts of the project. Not only these newcomers are not going to be productive for some time (typically weeks) but the remaining staff will bear the burden of their training. As the writer states in [1]: “adding manpower to a late software project makes it later” (this is known as the Brook’s law).

In the early days of professional software engineering, project managers were in a far worse position than today when it comes to resource estimation debate. Back then, there were no standard cost estimation methods and a manager had only his experience and intuition to protest against the non-technical and purely managerial-oriented arguments of his superiors. The year 1981 is considered a landmark for software project estimation because of the introduction of the COCOMO (COnstructive COst MOdel) in the book “Software Engineering Economics” by Barry Boehm [2]. It was the first time that software engineering was approached systematically from an economic perspective. Since then, a range of models have been developed for the resource estimation including COCOMO II [3] , an updated version of COCOMO designed to operate on state-of-the-art projects. Despite the progress that has been made in the field, these models are not a panacea when it comes to resource estimation. There are powerful tools in the manager’s archery but, given the peculiarities of each individual project, human judgment is still a crucial factor for estimation. The project manager still needs to be brave.

In this article we demonstrated how irrational requirements from non-technical personnel combined with a fundamental misconception of the project manager are able to affect software’s development cycle. We presented the reasons why a manager should be realistic regarding his resource estimation even if that means a conflict with his superiors and that nowadays he is able to partially support his opinion with commonly accepted tools.

[1]: Brooks, Frederick P. The mythical man-month. Vol. 1995. Reading: Addison-Wesley, 1975.
[2]: Boehm, Barry W. “Software engineering economics.” Software Engineering, IEEE Transactions on 1 (1984): 4-21.
[3]: Boehm, Barry W., Ray Madachy, and Bert Steece. Software Cost Estimation with Cocomo II with Cdrom. Prentice Hall PTR, 2000.
[4]: Pyster, Arthur B., and Richard H. Thayer. “Guest Editors’ Introduction: Software Engineering Project Management 20 Years Later.” Software, IEEE 22.5 (2005): 18-21.