Nothing is free. Either dollars matter more than time, or vice versa. In either case, time is a unit of measure that can be converted to dollars fairly easily by multiplying by the cost of paying someone to spend that time. So, lets talk about time.

I produce a bid by first reviewing the functional specifications for completeness. If they are incomplete I might only be able to bid on the existing parts.

I create a spreadsheet and list all the things the software must do or that I must do in creating the software. This can be a long list. I group rows where possible, sometimes multiple levels of grouping.

Then I assign an optimistic time and a pessimistic time for each one of the lowest level todos. I use the groupings to accumulate the sum of their members. When I’m done, I have one optimistic and one pessimistic estimate for the entire project, or at least, the part on which I am bidding.

These two numbers are extremes. I expect the project to fall somewhere between them. But where?

As I am estimating time for each item, I check whether I feel like each item is well defined or whether I have lingering questions or uncertainties. The more uncertainties, the more I move my bid toward the pessimistic side. I usually imagine that the difference between the two extremes is a range of time. I divide that range into three sections. My default is to start at the lower end of that middle third, and if I have concerns about the project I slide it as far as the end of that range of the middle third.

I need a good reason to choose an estimate outside the middle third of the range.

With so many assessments, we are bound to be wrong. We’ll underestimate some and overestimate others. Which means the errors tend to cancel each other out and as the size of the estimates gets smaller, the overall accuracy can actually increase! There is, of course, a point of diminishing returns. Avoid too many significant digits and remember that these estimates of project duration are intrinsically inaccurate.

With a bid value selected I may augment the bid to cover additional services such as:
* the cost of the software design process itself
* maintenance after the release
* deployment costs
* SQA costs
* management overhead
* material or incidental costs
* costs for producing documentation or service manuals
* costs for training users
* costs for supporting users

The software bid should not be confused with the project’s entire cost. But, the software bid is usually the most important because it is what determines when the engineering will be completed (or at least, when it can be submitted to SQA).

if you have the luxury of producing the software design, the above bidding process will be far more accurate.

Rather than wrestle with a client over whether software design is included in a project’s costs or not, offer to create the design (for a fee) as a small, initial service. Whatever investment in design is made will yield a good return on investment up to about 10% of the overall cost of development, in my opinion. Yes, it is possible to do too much design, or at least to include things in a design that should not be there:
  • disambiguates nothing
  • provides only information that is trivial to infer or anticipate
  • is redundant
  • fairly belongs in a different section of the document (such as implementation details)
  • isn’t needed or important for the developers, SQA or support specialists to be able to complete their work or do their job
  • information that isn’t specific to the project or related to how it will be executed (such as philosophy or personal comments that aren’t on-topic)