As a developer it would be lovely to live in a world where clients have infinite budgets and patience, and the only thing that mattered was building the most beautiful, technically impressive piece of software that you can envisage. However, we must, alas, realise that we live in the real world, along with our clients, who most likely do not have infinite budgets and resources.
And so we find ourselves faced with the same question, “this all sounds great, but how much is it going to cost?”
This is never a simple question, and the specifics of the project, and what deliverables have been defined must of course be taken into consideration, but having recently read the fantastic book “How big things get done” by Bent Flyvbjerg, I’ve come to realise that his approach to cost forecasting, which he titles ‘Reference Class Forecasting’ is well suited to estimating costs for Software Development projects. I will use the term ‘costs’ to collectively reference to both time and billables here as they tend to amount to the same thing, unless you’re a proponent of value based pricing, which is a whole other kettle of fish, and we could get into on another post.
Reference Class Forecasting basically states that the best way to give a realistic estimate is find the mean average value of projects in the same ‘Class’, apply some variation to that mean based on any specific requirements which your projects may have, and then simply use that value as your estimate. The painful process of trying to map out each individual deliverable and the costs associated simply doesn’t produce estimates of sufficient accuracy to be much use.
Let’s look at a real world example:
Customer X wants a piece of software to manage customer interactions, quotes, orders, and invoices, for 5 members of staff. This is almost boilerplate stuff, and having done a dozen or so of these types of projects in the past 3 years or so, we know that on average it usually takes about £10 - £12K to deliver this kind of thing at a standard that we consider fit for purpose. However, we also know that the customer additionally wants to be able to sync financial data with QuickBooks, and we know that we’ve done this before enough times to warrant a rough estimate of an additional £1K.
I always prefer to aim for under promising and over-delivering rather than the rather less palatable opposite, so I’m simply going to say this project is estimated to cost £12+1 = £13K.
That’s it. No more detail is provided.
Sure we can refine this based upon adding spec in and out of the brief, but the point here is that we are making an estimate based on data we’ve collected ourselves that takes into account the “unknown unknowns” of these projects - misunderstood specifications, uncontrollable delays, increase in costs of materials etc.
Some customers may baulk at the idea of not being given a detailed breakdown of where costs lie, and in the past I’ve been guilty of trying to provide these in order to pacify, but in reality, it’s up to use as developers and project managers to explain that interconnected nature of the parts of a system, and the general nature of software development mean providing an estimate based actual experience will be more accurate than trying to pinpoint exact costs for every micro element of a projects and just adding them all up.
By being clear about the rationale for using this estimating model, along with providing more concrete costs for the things we can accurately predict, we can deliver and estimate that gives the customer an overview of projected costs that they can then decide what to do with:
Filemaker Licensing: £810/yr based on 5 users. We can secure this pricing for up to 5 years in advance.
Filemaker Hosting: £900/yr based on current GBP/USD exchange rate. This is unlikely to change, but is obviously subject to currency fluctuations.
Development Costs: Initial Build £13K, see above, based on experience.
Ongoing Support: Some agreed day / hourly rate, this can be secured for a fixed term as required.
But what about the outliers?
“This won’t work for me, all of my Filemaker development work is custom, every job is different!”
This is, of course, absolutely true. Part of the value that we provide as Filemaker developers is delivering solutions that match business processes and don’t require force fitting off the shelf solutions into spaces they don’t quite fit. But - after a while we can start to see patterns in this too.
Someone wants their solution to be available on a mobile device? We can start to estimate the costs of doing that once we’ve done this a few times. We know how to build a mobile friendly navigation system, and how long it will take to deploy.
Another customer needs to track some sort of industry specific metric that we’ve never worked with before? That’s ok too - based on a rough estimate of the numbers of tables, fields, and records that we we’re going to need, we can work out how long it will take to build the required list/detail/picker/development layouts, and associated scripts required for managing tables of data more generally, to again provide us with a mean estimate of these additional components.
One final point here, which should be clear to anyone with a rudimentary grasp of mathematics, is that the accuracy of these kind of estimates is based on the size, and accuracy of the sample data. If you only have 2 or 3 the specific class you’re trying to estimate for, your data is not going to be particularly accurate, compared to what you might find if you have several dozen similar class projects to draw history from.
In Summary
I feel that the benefits of kind of approach to estimating are too great to be ignored any longer, as providing an accurate estimate serves both customer and supplier so greatly. What are your thoughts?…
