Eight Ball in the Side Pocket
Poor scheduling has been the bane of several projects with which I have had involvement. Ever since the one-month estimate that I gave for my first independent software development project, a shopping cart, a statement by Fred Brooks resonates continually in my mind. In The Mythical Man-Month, Brooks states, “More software projects have gone awry for lack of calendar time than for all other causes combined.” There are many things that are detrimental to projects, and Brooks suggests that the lack of time is the most significant factor that hampers a project and overshadows the total damage inflicted by all others.
Having learned and relearned the importance of good reality-based scheduling, I become squeamish when receiving a seemingly groundless estimate on project duration. In particular, I am very pessimistic about schedules that call for an entire project to be completed within a month. Conceptualization of a nontrivial system can easily exceed two weeks. Design will most likely require more than a week. This leaves implementation and testing with less than a week in a one-month schedule.
Two approximations to a feasible solution for the software procurement problem with a constraint of one month are the minimization of the product feature set and the minimization of system quality. These have served as candidates, though with strong resistance from project members, in the past. Betting against optimistic or baseless schedules is betting with the house.