Estimation/SWAG is possible....but it's hard (Score 1)

I've been developing reasonably large software projects for over 15 years. It is possible to deliver software on time/budget, but there are key concepts to keep in mind: 1. You can't develop time estimation based on large work units. Take a big work unit - design/develop an XML parser (example). Figure out what the 300 hundred individual things your parser must do (from a development perspective, not user requirements perspective). This level of functional decomposition will allow you to give a reasonable swag (scientific wild ass guess) on the larger work unit. 2. Manage risk properly. This is not easy. Think of everything you know of that can go wrong (experience helps). Take into account the things that you don't know of that can go wrong (experience is irrelevant). Detail the risk indicators (how do you know if one of your risks is happening?). Come up with contingency plans for each risk. Follow your risk plan throughout the project lifecycle. 3. Implement a change management system. Requirements do change, that's life. However, allowing this to affect your project is unacceptable. If the powers that be request a change, go through the entire estimation process again with the new data. Give them the new date, if they accept it ok. btw: a changed deadline due to changed requirement is *not* the same as a slipped deadline. 4. Careful management of minor and major deadlines. Most pople manage major deadlines only (alpha, beta, RC# etc). If you don't manage minor deadlines, how do you expect the major deadlines to be reached? (if you take care of the nickels and dimes....you know the rest). Most developers (people in general) work more efficiently under pressure. Keep the pressure on by managing the minor deadlines, and the project momentum will be maintained. As others have metnionned, R&D of new technology is the ultimate risk to a project, however the vast majority of projects are implementation derivitatives, not ground breaking stuff.