Quantifying the price for source code and software product

Question

I'm about to undertake a project. This requires me to write code, and tons of it. The client's requirement is to hand in all source code at the end of the project.

My question is: How do I quantify the price for source code and the software product? Is there any metric that one follows to determine pricing? How would I quantify the software product?

Extra info: The application must run anywhere, in any OS, including tablets (iPad, Galaxy tabs, etc.), Smartphones (iPhone, Android phones, etc.) and also on the web. (Now, imagine how much code this will be).

Answer 1

You can never know an exact or nearly exact price, since it depends on many factors. Example:

Case study

You got a request for a small website based on WordPress. The only thing you have to do: work with your designer to create attractive graphics, then create the website itself (nothing highly technical, just a set of plugins to add to WordPress), and then deploy it. The work being really easy, you quoted it $600.

Your designer created the first draft. The customer explained that he finds it not attractive at all. The same went with the second, third and fourth draft. Finally, after two weeks of hard work, the designer finally got the draft which was accepted by the customer.

But sadly the designer was hit by a bus and the only thing you got was the JPEGs he sent you, but not the original PSDs, so you had to start over with a new designer. Finally, you got the graphics and started your job.

Surprise: you've discovered that the plugin A is incompatible with the plugin B, that the plugin C is not working as expected, and that the plugin D cannot be installed on the newest version of WordPress, while the plugin A can be installed only on this newest version. Now you have to do a lot of PHP coding by hand, and since you're a Python developer and never wrote a single line of code in PHP, it's not the easiest task.

Meanwhile, the customer starts to send you scary e-mails, asking why the work is not already done, while the deadline was a week ago. You finally finish the PHP coding, and everything works perfectly well on your machine. The customer is happy.

Then you start deploying the website to the hosting server to discover that not only the website fails with some cryptic error, but also the hosting company doesn't support a feature of PHP you've used a lot in your code.

Finally, after spending more than $3,000 on this project, you have the website up and running. The customer is angry because of the deadlines and because "nothing works as expected with you". Would you ask $600? $3,000?

Why does it happen?

What I illustrated in this example happens much more often than you may believe. Why? Because there are too many variables that you can't predict and which increase the risk. Here, the risk was increased by:

• The unclear specifications related to visual design,
• The death of the designer,
• The incompatibility of the plugins you've selected,
• The bad support of the plugins you've selected,
• The fact that you haven't used PHP before,
• The difference between the development environment and the production environment and the absence of staging.

One could solve those issues with specific approaches:

• Clear and precise functional and non-functional requirements,
• Hit-by-a-bus scenario management (i.e. the designer had to share every document with you so that he could be dead at any moment without compromising the project),
• Prior knowledge of tools and languages you have to use (which requires a lot of work),
• Staging, intensive testing, etc.

The only problem is that with this approach, you have to tell your customer that he would pay at least $5,000 in the first place, since it is actually the price of requirements, specification, design, testing, etc. Chances for this customer to accept your quote are extremely low.

So there is nothing to do?

If you can't give a very precise price, you can still give an approximation, which takes in account every part of the work to do separately, with a risk index being affected to every part. Higher is the predictable risk, higher is the price.

You have two ways to do that:

1. Watefally way

If you work on projects which fit Waterfall/V-Model, this may work:

1. List the functional and non-functional requirements of a project. Get the document signed by the customer, the same way he signs the contract.

2. Once you got this document, you already have:

   • The price you already spent gathering the requirements and creating this document. This may represent an important amount of money, since those documents may vary from twenty to a hundred of pages for an ordinary project, and be hundreds or thousands of pages for large projects.

   • The clear, precise and complete understanding of the product you're requested to do.

3. Go with your team step by step, analyzing each requirement and evaluating:

   • An average price of this part of the project,

   • A maximum price without taking in account the risk,

   • A risk index.

   All three will be taken in account to determine the price you will give to the customer.

4. Asset the risk which doesn't depend on a specific requirement, but rather on the compatibility between the requirements or on the system in general.

Pros of waterfally approach: the customer gets a price which is quite precise, considering that you have a very clear vision of the work to do and the risks which may arise.

Cons of waterfally approach: you have to write a 200 pages document before giving the price. What if the customer cancels the project meanwhile, or goes to your concurrent? The whole process is also extremely heavy and the requirements cannot change later.

2. Agile way

If you work on projects which fit Scrum or other agile models:

• either don't give the overall price of the project, but rather the prices of every component,
• or you may indicate a very approximate overall price at the beginning, and then give the more and more precise one.

In both cases, you should have either a strong trust between you and the customer, or have excellent people in sales department. Otherwise,

• in the first case, the person would believe that you're just stealing her money asking for small amounts again and again, and this will never end,

• in the second case, the person would not understand why you're changing your price all the time, especially if the price is rising most of the time.

Pros of Agile approach: the customer can cancel at any moment. Also, if she cancels at early stages, she still has some source code which works.

Cons of Agile approach: the price is too imprecise or not even given. Most customers would be unwilling to do business with you if you don't tell them how much they will have to pay.

Answer 2

Do not accept a project when its not clear both the outcome and the money the client need to pay. I just do the following:

• Come up with steps and payments the client need to do.
• When the previous step is done and fully paid and the client is happy move to the next.

For the payment method, chose the payment based on the features. So if the client has the opportunity to drop the features if he/she cant not pay the whole project.

Getting paid based on lines of code (LOC) is a stupid thing. Because LOC does not mean anything!. Be smart write a good code and charge based on the feature!.

Good luck,

Answer 3

Do not accept a fixed price for an open ended commitment. You'll be screwed every time if you do.