Fair Pricing in Software

One of the biggest conceptions of software development projects is that they run over-time and over-budget.

Certainly, these time and budget are linked, but why the frustration, why can't the IT companies just get it right first time, often large-scale public sector projects will make news headlines - late, over budget and not fit for purpose - there's a triple whammy! Not helpful for our sector!

Fixed vs Flexible

There are two ways of pricing - either a fixed upfront cost, or a flexible 'time and materials' basis - I don't think either of these models are ideal in software development and that's where Blue Squirrel Software take a fairer approach.

A good analogy I find is vehicle mechanics - you don't typically take a car to a mechanic for it's annual service and ask what their hourly rate is - you typically get a fixed price service, in exchange for a set of deliverables, oil change, spark plugs etc. If the mechanic finds other items, then, perhaps you'll pay an hourly rate.

Why can't software be like a car service?

It can, however whereas a car service takes a few hours at the most, and is typically the same for almost every vehicle, software development typically takes days, and is more akin to building a house designed by an architect, an experienced builder has built many houses, but never this particular one - it is brand new, an experienced builder will know of common pitfalls, but what issues is this unique build going to throw up?

As the builder is building the property, the owner, seeing it go up, brick by brick, day by day - may choose to change some aspects, perhaps the windows, or the position of some internal doors, the layout of the kitchen, or squeeze an extra bedroom in, due to an unexpected arrival! 

Software, is more like this - at least at Blue Squirrel Software, however, similar to builders and mechanics, software takes skilled labour and our biggest overhead is time, the problem is, clients want certainty not to sign a blank cheque, but clients also want flexibility.

Waterfall vs Agile

Traditionally software development has been very structured, business analysts, consultants, project managers would scope out every detail of the "project" the client would agree, long before handing over to developers - who would build the solution in detail to the letter of the 'scope' over a period of a few weeks, months or years.

The issue is, business doesn't work like that.

It only takes recent world events to show how business must change and adapt on a week by week, day by day basis - all the work those consultants did 2 years ago, and now the product has been delivered - you'd say but this isn't fit for purpose - the world has moved on, this is not what I need.

This methodology is often referred to as Waterfall, there are circumstances when this is a valid and valuable approach, however this is not often the case for software projects, the very name suggests why - it's soft - malleable, mouldable - adaptable.

This is where Agile comes in, it is a fancy buzzword which really means aligning developers to your business - delivering small chunks as they're ready, allowing the direction to be changed, and tweaked - it's often not until you see the bricks going up - until you touch it, use it, feel it - that the really good ideas come, and the software can stay aligned to your changing business.

So how do you price flexibility?

Clients want a fixed price, secretly hoping it's been underestimated and they're getting a bargain! :-) 

The fairest way to price in our minds, is to scope out an MVP - a Minimum Viable Product - all the basics we will fix our price - of course behind the scenes we're basing this on our costs, time. 

We will set a budget, and if we've overestimated then any left-over can be used for alterations, if we've underestimated then we'll put this down to experience, we always deliver on our promises. 

But what if you want to make changes along the way? This is fine, if we're still within the budget, no problem and no stress, no additional charge.

Wait, there's more

We only count 'reasonable hours' worked - this means if we're making a brew, or installing a software update, we won't count this time. 

With software development, there are often unexpected challenges, much like a builder building a house, problems are encountered, some of which take longer than they should, in these circumstances we apply what we deem a fair time, not the actual time taken.

These are just some of the differences that sets us apart. We want to build a long term relationship, not to maximise revenues in the short term.