As has long been accepted, can get good estimates of time and cost for software project A if it is quite similar to and done by the same team as successful projects B, C, D, E, F, ....<p>IMHO, for software project A, break the work down into relatively small pieces and attack those. Make each piece small enough so that if that the work on that piece takes too long or even just fails, then the loss there is not too big.<p>Some of the most important pieces are about the <i>experience</i> of the team -- have they successfully done just such a thing before?<p>So, for such <i>experience</i>, start with the <i>skills</i> and, in particular, the documentation. So, start with the skills and experience with the operating system, the text editor, the e-mail program, the file system, the command lines, and the programming languages. Then move on to other related software, e.g., TCP/IP, HTML, CSS, JavaScript, SQL, AJAX, Web site security, collection classes, APIs, etc. So, for each of these, get the documentation, the <i>skills</i>, the <i>experience</i>, etc. E.g., have people write test programs that illustrate and test the tools, and some of the more important limitations on the tools, being learned.<p>Then start in, say, outline form, the <i>waterfall</i> development process by coming up with a <i>requirements document</i>, that is, what the heck the software is to do.<p>On writing this document, e.g., what level of detail to include, get some good consulting help.<p>Then move on to the <i>architecture</i> document. This document is an example of the standard project approach of <i>divide and conquer</i>. So, that division results in <i>pieces</i>, e.g., <i>components</i> of some kind. So, get started on some of the components. And have write some code to test those. Do these pieces one at a time so that a failure is not to expensive.<p>As long as the project is not struggling at some obstacle, is making good progress, each of the small steps looks okay, then continue on.<p>Soon begin to get some data on how fast the work is going, at least for each of the stages.<p>When are well into writing the code for version 1.0, then soon should have some okay estimates of the time to complete version 1.0.<p>Here see part of the truth: Much of the work is getting relevant <i>skills</i> and <i>experience</i>. Next much of the work, especially the risky part, is getting a clean description of what the heck the system is to do. With those parts done well, we should be talking mostly a nice road downhill from there to a good finish line.<p>Gee, in the middle ages in Rome there was a big project to move a huge stone obelisk some yards to one side. Big obelisk. Big project. Lots of timbers, ropes, horses, workers. It was successful.<p>Impressive until ask how the heck the obelisk got there in the first place? Sure, ballpark 1000 years before some of Caligula's slaves went to the upper Nile, cut the obelisk from solid stone, floated it down the Nile, across the Mediterranean, and to Rome, and erected it.<p>So, Caligula's slaves did some <i>project planning</i>, for a project they were likely mostly doing for the first time. And they got it done.<p>And now we are struggling with some software project for some Web based order entry and inventory system or some such? Ah, come on, guys!