Quantitfying a cost for a software project

Question

Disclaimer: I didn't know exactly where to put this question. If you feel that this question is not suitable for Programmers @ StackExchange, feel free to migrate it.

Background: Broadening my last question, there is a request for tender for a software system that's open and I have decided to take it on. I am a software developer & engineer by profession and, in this tender process, I have to put on the pricing for my bid. I have been provided a documentation consisting of functional and non-functional requirements only.

I have to put a project manager's cap on and think of all aspects, e.g. cost for implementation for the project, resources needed, etc.

My question is: Is there a project framework that I can follow that breaks the project cycle into steps and corresponding cost aspect or how would I go about best calculating/approximating the cost for the project?

Answer 1

I'll try to help solve your problem more than answer your question.

There are many systems for estimating software costs in advance. Why isn't there only one? Because there isn't one that actually works. A comment mentioned COCOMO-II, which I believe claims to be accurate within a factor of 7 times either way! (that's from memory, I can't find a reference, so take it with a grain of salt).

You won't be able to give a client an estimate with a multiply/divide factor of 7.

So, what do people really do?

1. Bid conservatively and usually lose the contract.
2. Bid aggressively and lose money most of the time.
3. Talk the client into not doing fixed-price bidding.
4. Bid aggressively then make up the money later.

Item 4 bears explanation. The most common tactics are:

1. Do nothing not in the requirements. For example, code quality is rarely a requirement. Training is frequently not a requirement. To be fully complete, a spec would be a working program, so vital things not in the spec can almost always be found.
2. If asked to do anything not in the requirements then that gets billed hourly, usually at a high rate.
3. Usually bugs have to be fixed. So every bug gets classified as "by design".

This is why many fixed price projects are an unending battle between the parties. How bad it gets tends to be based on how much money the contractor is losing, how greedy the contractor is, how greedy the customer is, and how far behind estimate the project is.

If the process goes well (which can happen, even if I'm not making it sound that way), items in the spec that are difficult to implement can be traded for items that were forgotten, the ultimate price (initial fixed price spec plus all the stuff nobody thought of) is fair, and everyone is happy.

If the process goes badly, what is actually implemented is based on what is on the original spec plus the result of political battles over money, and somebody loses money (probably everybody).

In managing a project, if you won't bend on price, time, or features, but you can't control quality, guess what usually suffers? The fixed price bidding process eliminates at the start the possibility of bending on price or features, and is generally strongly against bending on time. You sound like you would like to be fair and do a good job, but understand it's a tough model to work under.

Answer 2

You are being asked to turn requirements into hours, and then hours into $'s. There is no magic wand for doing this. All your competitors will be trying to make the same calculations. The more experience you have the better your estimates will be.

Each requirement will take time to design, code and test; plus time for all the other parts of the project.

There is no easy way to turn lines of requirements into lines of code, and then into hours.

The risks are that the customer may chew up weeks of time approving small changes, or in a 30 minute meeting cause the entire project to be trashed (I heard that language X is the wave of the future, just rename the files...). Depending on the structure of the contract all the money risk is on you. Underbid and you will win, but go broke in the end. Overbid, and you will not get the contract.

Answer 3

First rule of estimating is you will lose money on fixed price projects always.

---

Second rule of estimating is you will never be able to provide a comprehensive estimate within a margin of error that will be acceptable to a customer because they will always argue that you mis-interpreted a requirement, which will cost you money.

---

Software has soft requirements, fluid expectations by the customer, and un-predictable risks.

This is why Agile Methodologies become so popular for building software.

1. They allow for you to plan for the change and risk and budget it in.

2. They allow for your customer to be in charge of priority and direction.

3. They allow the customer to have transparent view of what is costing what, for good and bad. The customer gains trust and rapport rapidly if you deliver on time the first few iterations, and feels like it is a team effort, not you charging them money.

4. Protect you by setting short term expectations that the customer can expect to see and the team can meet.

There are many other benefits, if you research some of the methodologies.

Answer 4

Take the requirements and break them down into the smallest possible tasks. Estimate how long to do each task. The smaller the task, the more accurate the estimate. Then factor in things like bathroom breaks, lunch breaks, sick time (yours, wifes, kids, dog etc) and anything else that will keep you from working.

Use the task list as your statement of work. Anything not on the list, you charge extra for.

I personally add 30-50% onto the first estimate as insurance.