(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.

4 thoughts on “(Re)Estimation: A brave man’s task”

  1. Points of Agreement:
    *I agree with the fact that a project manager has to take
    decisions that abides by companies policy and upper
    * I agree with the fact that adding new programmers
    later on in the process of software lifecycle increases the
    complexity and timing.
    * I agree with the fact that the project managers should
    be realistic in estimating the timeframe for the work to be
    done and meeting deadlines.
    *I agree with the fact that the project manager plays a
    very crucial role in resource allocation, time frame and
    completion of the project.
    Points of Disagreement:
    *I disagree with the fact that if more programmers
    are involved in a task total time increases
    exponentially and they don’t always have common
    point. My opinion on this statement is that on
    involving more programmers on a task the work
    gets split and its easy to finish tasks on time. New
    ideas can emerge from any programmer in the team
    which might help in finishing the tasks quickly.
    For eg consider that an application has 100
    functions and we have 10 programmers. Each
    programmer has to do only 10 functions. Work gets
    split and happens quickly.
    * If programmers are working towards a common
    goal then any argument being raised will only be for
    the betterment of the project and not creating
    ambiguity. So arguments raised by the
    programmers during the project discussion should
    be viewed as a positive strategy and not as time
    wasting process.

    1. Hey,

      Concerning your points of disagreement:

      Firstly, the author of the blog post does not say that more developers need more time for the development, but that the communication gets more complicated. Do you disagree on that also?

      Secondly, especially when the project end is near, arguments can be a waste of time, as every resource needs to be productive, instead of arguing about fundamental things. What do you think?


  2. Eshwar: You are making some assumptions in your first disagreement, which does not necessarily have to hold true. You are not considering that programmers are not equally experienced or, most importantly, equally productive. It’s misleading to look at it only in terms of numbers of programmers capable of doing the same amount of work in the same time, and I believe that there is more to it than that.

    Furthermore, adding more people to a project might change the dynamics of the group, making the communication less efficient, as Panos and Aimo highlighted.

    As for the arguments, yes, arguments can be constructive. Not all arguments are constructive though, and some of them might even derive from false or inaccurate assumptions, in which case they can be a waste of time. There is certainly a “soft” element to this, with regard to how to actually choose the discussions that will most likely be of benefit for the team.


  3. Thanks everyone for reading the article 🙂


    You brought as an example that 10 programmers can split the work of 100 functions and finish earlier. But what if these functions depend on each other (some functions may use others as sub-routines) ? What if these functions must have some common characteristics such as the same output format (e.g. serialization of output in XML) ? In your argument you make the assumption that programmers can work independently on these functions which is not the case in the majority of industry projects.

    These 10 programmers will need to communicate with each other in order to create a quality product. Imagine that programmer P1 writes a function F1 which takes 2 arguments. Imagine now that a programmer P2 uses the F1 function inside an F2 function. If, for any reason, P1 desides that the F1 function should take 3 arguments instead of 2 he must communicate with programmer P2 in order to change the code of F2. Imagine this happening in a large-scale scenario….

    I agree with you that disagreements can be usefull. What I am saying is that these disagreements come with a cost.


    You are right in your second claim especially when the deadline is near. But, if close to deadline there are still dissagreements about the overall strategy, then the problem is much bigger… 😉


    Apart from choosing the “right” discussion (which I think is very hard because there is the element of prediction) another important aspect is to have mechanisms of organizing effectivelly these discussions in order to reduce their length and remove any ambiguities.


Comments are closed.