Project pricing: bugs and fixes

adrian.png
Adrian Keindl 3 min read
Project-pricing.jpg

Pricing in general

If you work in a project-based line of business, this issue is something you must have encountered multiple times. Project pricing is obviously a huge topic, so we’ll cover just a fraction of it. In general, there are multiple approaches on how to price a project, while some of the industry leading ones in the world of software development would include value-based pricing, cost-plus pricing, competitive pricing and billing around agile cycles.

Whatever your pricing strategy may be, there is always a possibility that your competition won’t follow a truthful path toward forming their price. There is nothing wrong with a competitor being cheaper, faster or more skilled, but dishonest pricing and hiding the full potential scope of the project, along with the possible hurdles from your customers is definitively a problem one can easily find in the industry.

1-58.jpg

What we all deal with

One recent situation we’ve lived through a few months ago illustrates this point perfectly. A company we met up with had a need to develop an ERP system to manage their employees and equipment. Prior to meeting us, they already gave the project to a group of developers, who came to them with an estimate of 32 man-days that will be needed to develop everything.

The project was signed at that moment and so began the investigation phase. It took the dev team 2 full months into to project to realize they were wrong and needed to do a re-estimate. The new figure they communicated was 650 days! After being burnt like this, the client still found our 62 days estimate to be too high and the deal didn’t go through.

The point of this article isn’t to bash on any competitors nor the clients for wanting to believe in shiny figures, its purpose is rather to warn both parties of the dangers of not approaching project estimation more meticulously. Some do it for the lack of knowledge, whereas some count on the fact that the client won’t mind the additional costs that come up in the later stages of development.

A Small Q Tip

Not to end things on a negative note, we’re happy to share one strategy we started using recently, which helped us increase our success rate in winning new projects. When we are drafting quotes for really large projects, most often we’ll go with a hybrid quote, combining a fixed-price estimate with a dedicated team arrangement.

This means that we will attach a final amount of man-days to the first few project phases, like database & project architecture, UX & UI design and parts of the Frontend and Backend development. After this stage is completed, a team of dedicated experts will take the project to its completion.

The issue this approach solves is that we don’t have to charge the client any “buffer” (the price for the time that will be spent to cover possible unexpected problems that may occur) and the risk factor is eliminated for both sides.

We will provide the client with a rough estimate, e.g. a team of 2 Frontend devs and 1 Backend dev will take 2–4 months to complete the project. This way, everyone is incentivized to deliver the project sooner and productivity was shown to rise by considerable amounts.