I am working on estimating my first project, where I am participating in the architecture and performing nearly 100% of the coding work. I have some (what I consider) to be "accurate" guesses, based on my last set of changes to the application (which was estimated by the original developer who no longer works here).
The firm I used to work for used a proprietary development system named SPECTRUM (I don't know whether it's still around, or if it's connected to various companies with the word in their names). I never got to use it much (I was a programmer, not so much an analyst), and "waterfall" development systems are not entirely appropriate in these days of quick prototyping (http://en.wikipedia.org/wiki/Waterfall_model
--this introduced me to the neat term "sashimi model") , but I remember that some of the principles seem to me to be applicable still:
--Realizing that you can estimate some parts of the development process only after you have done some of the earlier work. You have to do the User Requirements before you can estimate preparing the Design, and that has to be done before you can really estimate the programming. These days there's much more feedback and iteration, but, having given more than a few back-of-an-envelope estimates before truly realizing the scope of a project, I think that it's more important than ever to get an idea of the scope of a project, or better still the scope of the parts of the project, before committing to an estimate.
--Getting a good idea of just how much work is involved. In SPECTRUM, one of the phases involved creating an inventory of the various screens and reports that will be required. There are often more of these than one might expect at first blush, and each one will take a certain minimum time to complete. When clients would cavil at some of the Programming estimates, we'd be able to say something like, "Well, there are twenty reports to program, and each one will take at least an hour, maybe two. If you don't like the estimate for the reports, which reports would you like to do away with?"
--There are factors that make development harder. SPECTRUM had a bunch of factors for many of these: if the development team has more than three members, multiply the estimated hours by 1.3 (or whatever) for coordination; if the client contact/"chief customer" changes, multiply by 1.x; and so on. There was a big list of these, most of which, of course, I've completely forgotten.
--Minimize changes during the development process: SPECTRUM had a very hard line on this: each phase had to be signed off by a client committee, the estimate for the next phase was based on this, and no changes were permitted without a very heavy penalty. (Requested changes were put on a post-project to-do list.) As I say, these days we wouldn't be that hard-line, but there are some changes that are so big that they change the rules completely. I was on an RPG project where we casually assented to the client's request that dates be displayed a certain way; this required about six lines of code every time a date was input or displayed, in every program, and for every screen field or report line, a huge job. I also remember reading about a large project in which the hardware was changed about half-way through--"Well, all Unix is the same, right?" Not really--it put the project a year or more behind.
--Leave room for implementation, testing, documentation, and training; these are all non-trivial, and they tend to be overlooked.
Using SPECTRUM and common sense, and with a few exceptions like the RPG project in which we took a big bath, my former firm was able to have an excellent record of on-time on-or-below-budget projects. (When we came in below budged, we were able to start working on the wish lists.)
Software development has changed a lot since those days (I'd look now at a couple of Steve McConnell books, Code Complete
and Rapid Development
; I haven't read his Software Estimation
), but I bet it's a winner), but I think that many of these SPECTRUM principles still apply.
There's a lot of stuff out there on what is generally known as System Development Life Cycle models, of which programming estimation is just a small but essential part. Just randomly Googling, I found thousands of thousands of hits, including http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx
, and so on.
Hope that some of this helps. Cheers, --Howard[/list]