Estimation is one of the hardest parts in software projects due to many misconceptions, the inability of humans to estimate, and the risk and fear of losing your margin. A systematic approach and the knowledge of typical mistakes will drastically improve your estimations and allow for win-win-projects.
To make a proposal you have to provide a number that not only reflects the real effort involved but also sounds reasonable in contrast to the desired product or service.
For your quotation, you have to find the optimum between too low and too high. This ‘sweet spot’ can be moved depending on your value proposition and your customer’s value perception. The more common the thing you are selling is (e. g., tool training), the harder it will be to move the sweet spot.
[image with lines ‘effort’ and ‘margin’ and marks ‘too low – ruining yourself’, ‘too high – not competitive’, ‘sweet spot’]
– market-based pricing
– effort-based pricing
– value-based pricing
– experience-based pricing
[Table: Pricing approach, When to use, What to do]
market-based pricing, you know your client and her budget,
effort-based pricing, you know what needs to be done, calculate
Effort-based Pricing: Estimation of
Effort-based pricing needs an estimation of the effort involved in producing the software or rendering the service. Determine the effort by breaking down the big tasks into smaller tasks until you can come up with an estimation.
Besides effort, you need to provide a project duration and you have to know how many people you should staff in a project.
Rule of thumb: Optimal Team Members Count = Square root (Effort in months)
In Scrum projects, the effort of stories is estimated before each sprint. A pricing approach would be on a per-sprint-basis for X consecutive sprints and an extension depending on the features delivered. This, of course, needs stakeholders that are familiar with the basic premises of agile development (potentially shippable products, sprint reviews etc.). — Otherwise, you’ll get a ‘waterscrumfall’ (link).
The effort-based price is not necessarily the minimum, e. g. if you have a good reason to believe to get a follow-up project or other benefits. But be careful: ‘Underselling’ is generally a bad option as your clients get used to an unrealistic perception of costs. Also, it encourages bad engineering practices and hence low product quality. (And you might already know that low software quality costs more than it saves.)
If you’re providing a service (training, consulting, coaching…), you’ll have an hourly or daily fee, that also takes into account the value of your expertise (s. value-based pricing below).
Experience-based Pricing: Comparing Apples With Oranges
In experience-based pricing, you compare your project with similar (finished) projects. The data can be (preferably) your own or of competitors. Have a look at white papers of similar-sized companies and technology consultancies to get an idea of what it takes to migrate from system [OLD] to system [NEW], to implement [FASTNOW] technology or to build a custom [UNICORN] system. Take the data with a grain of salt as nobody will (want to) tell you about failures (‘file drawer problem’).
The more stable the environment (people, technology, industry etc.) the more comparable the projects are and the more precise your estimation will be.
The value the client gets off of your product or service informs the value-based pricing. How many new leads will your client generate with your data analysis? How much money is your client saving due to the implementation of your quality assurance method? These numbers will be an orientation of.
The more realistically you can show the prospective savings or earnings, the more convincing your pricing will be. At least, this number should be in your buyer’s head as an additional argument.
Also, your client’s perception defines your value as a professional or organization. Some of the factors contributing to this perception are:
- Authority (products, books, articles)
- Originality: entertaining, fun
Software Pricing and Effort Estimation
With a structured approach, it’s still hard to estimate and adequately price a software project. Yet, the results will be much closer to reality.The key is to find a good
Latest posts by André Nitze (see all)
- 7 Reasons Why Low-Quality Software Actually Costs More Than It Saves - June 22, 2017
- Pricing Software Projects Without Leaving Money On The Table - June 22, 2017
- “Quick-and-Dirty” is Fake News - June 21, 2017