by Ethar Alali
For decades, pricing software development projects has presented a problem. Follow traditional Time and Materials or Fixed Price contract models ubiquitous in other industries created friction between these two methods for both the client and supplier and still does to this day.
As agile methods arrived at the turn of the century, neither model provides sufficient scope for software projects, due to the strange mix of IP, intangible assets, evolutionary delivery and merciless refactoring. Charging hourly or daily rates wasted money and fixed-price contracts didn’t provide enough space for refactoring and technical debt. The solution to both appeared to regress operating models back towards traditional waterfall development. A methodology the industry fought hard to escape.
Many movements in the tech industry have tried to deal with this, including #NoEstimates and BDD and DDD advocates, who considered the mix of capped T&M as the model that would work best. Yet, they all had their problems and to this day, no mainstream group can lay claim to have cracked it yet.
At Axelisys, we’re about ready to place our stake in the ground. Thanks in no small part to the clients and suppliers that have raved about it over the past few years. Each determined that this was the right approach to use. Yet, to many it will be the most controversial thing they’ll read today.
Tl;dr
The secret: Remove time from pricing and supply altogether and align payments and costs. Much like cloud computing costs follow usage.
We evolved within our own business and it’s been really good for us. Allows us to make best use of the way we operate.
To Assets not an Asset?
Time and Materials contracts charge for both parts and labour. In software, labour forms the majority of such costs and is easy to do for projects without fixed cost components. While this model can adapt, any time a quotation is requested, it immediately removes that adaptability. Not because of the cost of the staff, but because the encasing project has a cap. A major limitation encouraging behaviour that results in technical debt or meaning contract staff may have to be dismissed to bring costs down at a time in the project which is critical.
Fixed Price contracts on the other hand, set a limit on the amount of work done and quote price set. Because of this, requirements are set in stone from the outset and while agile development can deliver incrementally within that, the requirements encased in the contract are fixed and unwavering. Except for costly change requests. Preventing the partnership from adequately respond to change. In longer projects, with fast changing markets, delivering absolutely the wrong thing, just because it legally must.
Previously attempts to change fixed-price models nurtured poor behaviour from both parties. Suppliers pushing code that isn’t ready, just to meet temporal milestones or clients unreasonably withholding large swathes of revenue for arbitrary, undefined changes, well beyond their client credit limit. Some unscrupulous, yet experienced clients of naive freelancers or digital firms may not pay final invoices at all, for no apparent reason. Safe in the assumption that chasing via a small claims process that is not fit for purpose likely costs suppliers more than small invoices are worth.
In the UK, this leads to many software firms becoming the victims of late payment. An epidemic that plagues a third of firms across the country in any year. 45% of those never receive payment for works done. Leaving them no choice but to offset costs elsewhere, including other client work, and internal jobs, or go out of business.
The process is legal-heavy and presents both bills and risks to both parties. With the ever faster adaptation of companies, their markets and requirements, software development contracts and operations must provide methods to both increase valuable throughput, reduce risk, limit exposure and align costs with revenue. Preventing situations which pay for resources in a different phase to the firm getting paid for that work.
So how did we do it? I’m not going to lie. It’s a long road which you must be prepared for. But if I had to pick a top 5, they would be.
1. Ticket-based Pricing
A ticket is a story, bug, improvement, tech task etc. It’s simply a more abstract name for them. All costs are included in these tickets. Including development, infrastructure, coding, testing and QA, BA, desk-space, utilities etc. The ticket becomes a segmentation of the total cost of the work, including all overheads. This isn’t any different to a traditional contract. Which must account for operating costs.
2. Invoice by Iteration
At the end of every iteration, there is typically:
- A retrospective to determine what went well, badly and what should change
- A demo of the software, which the client accepts
These fulfil review and acceptance stages of development and are naturally ideal times to invoice. As long as the customer doesn’t breach their credit limit, invoice at the end of the sprint. If they are at their credit limit, make sure you are able to pause until the credit line is paid. Together, these two limit your exposure to large invoice debts but similarly are small enough batch sizes to be covered within many enterprise departmental thresholds. Only one sprint is ever able to land in arrears. Reducing the amount of risk and the sensitivity to that risk, that your firm takes.
Does this mean more invoice paperwork? Absolutely! But where you use longer payment terms, it also means smoothing payments where the client has longer payment terms than you do. Since you get paid more frequently once the very first payment finally comes in.
3. Arrears Invoicing makes you a Credit provider!
Often forgotten by many creative technologists. Especially ex-contractors. Until the client (or agent) has paid you for the work, the client has received it for free. They have taken a line of credit and instead of going into overdraft to pay your company, they promise payment, as an IOU, for you to pay yourself. Interest free no less! Better than 6%+ with the bank, right?
There is reason banks credit check customers is to ensure debts are paid. There is also a reason banks reject people. Because they haven’t demonstrated an ability to managing debt (even if they’re filthy rich. But in such a case, they are just transferring risk on to you). You must also maintain the ability to do the same. If you don’t, you are letting creditworthy and non-worthy customers use your bank account, as their overdraft.
4. Align your costs and revenue payments
We are quite lucky. As a chaordic organisation, this is a really natural model for us. We basically pay our teams per ticket, in the same phase of the month as we get paid for that ticket. That means several payments per month for our workers, but also means that we ourselves never run into arrears against the work. In the event we hit a late payer, the work stops, we pay the workers from the float of the revenue gained so far, and chase through every means at our disposal. Including credit control and debt recovery agencies, sale of the outstanding work and the courts.
5. Late Copyright Transfer
Under no circumstances transfer copyright until you have been paid for the works. Keep title until invoices are paid so you can sell the production to another firm, including their competition where appropriate. You might find that you make much more than the original work cost and can use the funds to continue to chase for any irreclaimable costs. This doesn’t mean you have to hold on to all the work. Simply the portion that you have not been paid for. That naturally gets smaller and smaller the more product has been built.
6. Contracts: Standard Light, Schedule Heavy
The nature of jobs and agile development means you could find yourself doing anything. So your contracts must let you do anything.
We spent a lot of time developing agile contracts that allowed us to place a standard set of legal protections around our work, but provided us with the freedom to place anything in one or more schedules. We found we had to negotiate enough of our old contract proforma to make it viable to create a streamlined process that’s incredibly flexibility for our customers, while of course, protecting us too.
Rationale
A couple of clients compared our costs to local Contract Software development costs. It is not an exact comparison, since our clients get a firm not a freelancer or IT contractor. Plus, comparing IT contractors must include costs normally borne by the client.
- Desks
- PC or Mac
- Infrastructure costs (e.g. Cloud costs)
- Software licences for Dev, QA & UAT systems
- CI/CD server licensing
- Employment agency costs of 15 to 20% which are undiscounted
- Project management
The IT contractor pays for none of those and the client doesn’t get a discount on payment. Furthermore, the contractor can’t work effectively without all of the above and obviously, it’s not just software development either, as we draw on skills and resources required by tickets. Something further contractors must be recruited for.
#NoDeterminism
Story points should not assume a time-based unit. It’s not a direct match. A story point is stochastic and the varying type and nature of projects mean there may be more or less infrastructure, with more or less overhead and more or less client or commercial delays. This in turn, means points can totally vary in length under a time metric.
By comparison, a story point has a fixed cost associated with it, but no fixed time. So takes as long as it takes for that fixed cost to manifest. This may seem different, but in reality, traditional projects yield more significant variation, as famously covered in the Standish report.
In reality, the actual budget spent, including any waste, is what you get your value from. Until it’s realised, it’s just a hypothetical case on piece. For illustration of a comparable software development project.
£425 contractor, plus £75 agency fees, plus £57 infrastructure and desk, plus 1 hr of PM time (at £60), plus £7 of licensing is £632 per day +VAT undiscounted.
Enough Waffle: The Money
Axelisys' story point is currently £493+VAT minus discount. To use an anonymous case study, on average, two stories are completed in just over a man-day, including infrastructure, PM, architecture, video where appropriate, desks etc etc. So that’s £986+VAT, minus any discount for early payment. So, with, say, a 31% discount that’s £680.34+VAT on average. Compare this to a project with a single contractor, the difference is less than 10%, for a much faster delivery cycle and an adaptive process.
However, this effect gets compounded when considering iteration length assignments. Our typical iterations is 2 weeks long. 10 working days. An IT contractor+agent fee alone, is paid over £5,000+VAT. Regardless of delivery and they usually need at least a month of full-time work minimum. All this without having paid for infrastructure, project management time, architecture time, licenses, desk etc etc. In contrast, we rarely charge clients a £5,000 invoice per person in any sprint to date and they have certainly not paid £5,000 once our invoice has been discounted. Most come out at less than half.
This way, projects are naturally cheaper and must deliver a valuable story for payment. It also means payment is automatically performance linked. Costs follow revenue exactly. Something that doesn’t happen in either T&M or Fixed-Price contracts which must hold a safety buffer to pay before they’re paid.
Sound good? Everyone should be working this way.
Epilogue: In light of tax changes
For a very long time, UK IT contractors have been spoilt by the industry. I say this as someone who was a contractor for over 15 years in the past. The latest round of changes from the UK’s tax office is the greatest threat to contractor income stability there has ever been.
Our model doesn’t subject anyone to that. It is not one client and they can choose to do tickets even if they also work for someone else, as long as they respect the NDAs and contracts they are asked to sign and of course, if their other clients don’t mind [Ed: This control is one reason contracting is regarded as disguised employment]. Our team works the same way around the world and in the same office. We have no set hours and people can work from anywhere they like. However, what we didn’t figure was tickets being seen as “gig work” by people unfamiliar with our organisation, the stochastics or how it works (take a look inside).
Many true freelancers like this flexibility. It has perhaps done more for the diversity of our team than any other initiative we’ve tried. Team members have chosen to work this way entirely for the past 4 years, having introduced it 6 years ago. Nowadays, nobody who joins us requests a salary. So we don’t carry a regular payroll bar 1.5 Full-time Equivalent staff.
However, this model has concerned some IT contractors and even sometimes TechForGood advocates because it sounds like “gig work”. Yet, this is very distinct from concepts like zero hour contracts or much worse, low paid exclusive zero hour contracts, which provides absolutely no protection for workers at all and indeed, is totally harmful.
Axelisys’ client projects are equivalent to a few months long, 7 to 11 sprints, as a minimum. Freelancers can be contracted on several different projects, with different terms and the choice is up to them. The choice of whether to earn more in one day than many locally earn in a week, or globally earn in a year, with the flexibility to do this around caring commitments, or even simply waiting for a package, whether in clusters with us, or on a beach in Bali, is often regarded as a trade-off worth taking. We’ve even been surprised by people who felt guilty for earning so “easily”.
Why does this happen? Little management overhead and super teams. But that’s for another day.
