How do you bill for software development?

[shifty_uk]

It would be good to pick some brains on this as I'm sure there must be a few of you that are familiar with software development either through your own contracts or your employer.

I run a growing development company, we have a combination of projects of varying sizes, retainer contracts and ad hoc work from our existing base which is continually being serviced.

Retainers and ad hoc work are easy, what's challenging is managing and billing the projects.

I've made huge mistakes in the past with fixed cost builds(albeit well scoped) that have cost me dearly as things go wrong out with our control or extras are thrown into the mix and expected - "I know you're at a loss over the project because of my bad data but you gave me a fixed price"

Now we're at a stage where granular scopes are provided with estimates which are split on key milestones, typically billed at 50/25/25 or 25/25/25/25 depending on how large the project is.

The problem with the latter is of course the agile nature of development and how long it takes on sign off/waiting on various components from the customers. There are also frequent delays with invoices being paid, more so throughout the pandemic.

My question is, how do others operate their billing periods for professional services?

I haven't yet tested the waters with a small upfront deposit followed by monthly/more frequent invoices for hours used - to me, this would ensure complete buy in from the customer and cover our time allowing flexibility of my team to move onto other work if there are customers who are dragging their heels.

Thoughts?

 

[Dwarfy]

Not my department as in I know nothing
But in my mind, you would draw up a contract based on their initial request and take a deposit, any changes they decide to impliment against the original design incurs a new contract and change of pricing as you go.
This would help you to get started knowing your goal, but gives them the freedom at their cost to make changes.
Initial deposit (non returnable unless stipulated in the contract) can vary due to project size and complication, and charges for changes can vary due to implemetation difficulty.
You could also charge admin fees for drawing up new contracts. But these can be waived on the first or second instance, you know for customer friendlyness

This system would encourage them to get the idea right first and also to limit the changes they might want to make.
Business payments though I have dealt with and can be a pain, but on your invoice clearly mark expected payment dates, I.E. within 30 days yadda yadda, failure to pay within the alotted time allows you to charge interest. And don't be affraid to employ a debt collection agency (I have to great effect) who will then chase for you and do the court paperwork if it gets that far you can then charge the customer for the debt collection too.

 

[HangTime]

There are a couple approaches you can take here in addition to what you've described:

• T&M based contract with initial estimates. This protects the supplier a bit in terms of not being left trying to finish something that has overrun for no benefit, although the client will likely want a fairly robust plan with milestones etc to ensure they aren't getting taken for a ride.
• Small scoping/pilot SOW to really understand what is required which then leads to a more well defined fixed price contract (i.e. once you have a better idea of the work involved so can give a more informed estimate). I guess to use your nomenclature above this is more like a 10/30/30/30 sort of milestone basis with the 10 being the initial scoping work

 

[OspreyO]

The larger projects I've worked on. Any change of spec raises a change request quotation which has to be signed off before starting it. Also staged payments. All work stops if there is any delay in payment. If the delay is long enough the resources working in it are reassigned and it can be some time before the project gets back on track when the resources become available again.

 

[mid_gen]

The larger projects I've worked on. Any change of spec raises a change request quotation which has to be signed off before starting it. Also staged payments. All work stops if there is any delay in payment. If the delay is long enough the resources working in it are reassigned and it can be some time before the project gets back on track when the resources become available again.

Doesn't work with agile methodologies does it? Not unless you bastardise it to the point of being useless.

If you do truly work agile, then I would aim for T&M with a loose upfront estimate. Everybody wins really....suddenly everyone is motivated to get things done promptly.

 

[OspreyO]

These are projects we've outsourced to development companies. I'm not privy to how they are developed. I assume they don't use agile. I don't know though.

We don't use agile internally for our own development that we do. We have a big issue with scope creep though.

I thought it was interesting how the dev companies billed change requests though and how quickly they walk away from a project if payment is delayed. We spent a lot of time juggling the schedule or features to fit within the current payment window. Project would stop until next tranche of payments were approved.

 

[shifty_uk]

Thanks for the input here guys, some valuable advice; you've pretty much validated what I'm moving to but some good points.

Doesn't work with agile methodologies does it? Not unless you bastardise it to the point of being useless.


If you do truly work agile, then I would aim for T&M with a loose upfront estimate. Everybody wins really....suddenly everyone is motivated to get things done promptly.

The problem with this is sign off. From small businesses to enterprise level customers, they all require what they perceive as bullet proof estimates but things change, issues arise.

My takeaway from some of the points here is to simply be stricter on the milestone payment terms and scope creep.

And don't be affraid to employ a debt collection agency (I have to great effect) who will then chase for you and do the court paperwork if it gets that far you can then charge the customer for the debt collection too.

I'm thinking about adopting a soft suspension of services(for example application access) or full on project delays. Haven't had to take it a step further yet but noted, thanks.

• T&M based contract with initial estimates. This protects the supplier a bit in terms of not being left trying to finish something that has overrun for no benefit, although the client will likely want a fairly robust plan with milestones etc to ensure they aren't getting taken for a ride.
• Small scoping/pilot SOW to really understand what is required which then leads to a more well defined fixed price contract (i.e. once you have a better idea of the work involved so can give a more informed estimate). I guess to use your nomenclature above this is more like a 10/30/30/30 sort of milestone basis with the 10 being the initial scoping work

I'm leaning more towards your first point. Fixed pricing has near killed me in the past. The estimation element is key.

 

[HangTime]

The larger projects I've worked on. Any change of spec raises a change request quotation which has to be signed off before starting it.

Sometimes it's not about change of scope however, the OP is citing things like bad data which can be hard to mitigate from a scoping perspective when you haven't spent enough time with the client to fully understand data quality, coverage, volatility etc. You can try to protect yourself a bit with assumptions, contingency etc but ultimately code (and test) complexity can be heavily influenced by such factors on some types of project.

Even internally I've seen big problems with such overruns where a programme is expecting a bill of say £300k from a given team based on their original estimates but it then runs a lot higher due to edge cases, overheads preparing 'real world' test data etc.

 

[NickK]

So internally the organisation will have a budget - typically yearly allocated they draw down. It's up to them to define the required business case to justify. The drawdown can then be defined in many ways and that can be done specific to the programme/project or the 'standard' of the organisation.

The framework for the payments would be defined up front - it manages their expectation and yours.

Now I'm assuming there's no operational services or product licensing as part of this - just pure professional services as part of a service provider contract.

A true agile delivery would, idealistically, have a set budget then draw down as business value is delivered. The project (fixed) stops when the budget is exhausted or additional features in the pipeline to use up the remaining budget are not worth the ROI.
A customer would prefer business value delivery invoicing - so you pick up the delays caused by your staff.
A service provider would prefer monthly charging for cashflow-salary reasons and offer a form of points to redeem against delivery delays.

Agile projects still have deadlines - specifically ROI inflection points rather than simple delivery deadlines. A contract can essentially attempt to recover the missing ROI from the service provider. Ye-olde project managers look at penalties because you committed to that date you missed - which isn't flexible for the customer either (as it ends up in contractual minefield).

The bad agile delivery is where the customer re-designs repeatedly after the product demonstration. Insisting that the feature is not complete due the engineers and thus the payment milestone zooms off into the distance leaving you our of pocket for salaries..

If your customer is really out of pocket until the feature is delivered, they may favour business value delivery style milestones. For large orgs that budget yearly, they know in Jan after the budget haircuts that they have money and if they don't spend it by year end they will lose it - but - they will be expected for the business case ROI by the year end they used to justify the spend.

In reality it's really up to your relationship management to find a good mid ground between the organisations. My preference is to run monthly for internal devs. For external agile service deivery I prefer the option of having sub-phases. That is where a sub-set of features are placed within the phase with a set budget, this allows monthly draw down from that phase's budget but allows a hard conversation about delivery performance ahead of the next phase prep with the next feature subset. A trade off between risk, overheads and trust for both sides.
I've seen agile deliveries from other teams resulting in budget runaway due to the service provider simply burning all the budget then saying 'we can't finish this unless you provide more budget' without really delivering the full ROI.

TL;DR .. If I was in your shoes I would be very specific about the format of payment milestones to ensure monthly cashflow. If they suggest pay-on-feature then I would suggest the approach for monthly payments within a sub-phasing of the budget/feature set scoped ahead of the phase. This limits the liability and allows you to have a tough conversation - assuming that they are playing games it gives the option of walking away.

 

[NickK]

Sometimes it's not about change of scope however, the OP is citing things like bad data which can be hard to mitigate from a scoping perspective when you haven't spent enough time with the client to fully understand data quality, coverage, volatility etc. You can try to protect yourself a bit with assumptions, contingency etc but ultimately code (and test) complexity can be heavily influenced by such factors on some types of project.

Even internally I've seen big problems with such overruns where a programme is expecting a bill of say £300k from a given team based on their original estimates but it then runs a lot higher due to edge cases, overheads preparing 'real world' test data etc.

Indeed - break down your liability and risk exposure into smaller bite sized portions.

It's all good to have a massive year contract but if the customer has massively underestimated the costs for an ROI business case, you do not want to be in the position of making up the short fall (unless you're a massive service provider that can spread the cost). You will go out of business and they won't care.

 

[jsmoke]

Set up micro transactions, £0.99 for this feature or buy a bundle for £4.99 sort of thing.

 

[OspreyO]

Sometimes it's not about change of scope however, the OP is citing things like bad data which can be hard to mitigate from a scoping perspective when you haven't spent enough time with the client to fully understand data quality, coverage, volatility etc. You can try to protect yourself a bit with assumptions, contingency etc but ultimately code (and test) complexity can be heavily influenced by such factors on some types of project.

Even internally I've seen big problems with such overruns where a programme is expecting a bill of say £300k from a given team based on their original estimates but it then runs a lot higher due to edge cases, overheads preparing 'real world' test data etc.

We wouldn't have those kind of issues. Since we (Internal IT) would be preparing the metrics on the data and the interfaces with other systems. If there was a problem we would fix it not the development company since its our data and our interfaces.

Where we would have a frequent problem is when one if the specific business units not not having a complete understanding of their own business processes. You might a library of hundreds of rules, workflows or process that turn out to be complete garbage and contradictory. Requiring a lengthy review and the specification would ultimately change and timelines would be pushed out. In some cases this would be branched out into a seperate mini project and a seperate funding stream, so as not to divert resources from the main project. I thought that was smart way to handle these.

If the developer had a fixed cost contract they would have been stuffed. Projects usually ended up costing 2 or 3 time their original budget. TBH though I think they were only breaking even. The gravy was in the support contracts. So if a project was to derail or not go live, it would end up not being that profitable. It would however allow them to keep the resources on staff to take on other projects. Since their goal was to grow to a much larger size to take on even bigger projects.

 

[OspreyO]

I think there is a conflict between IT people who are quite happy to deliver a version 1.0 and push other features to 2.0 or bolt on functionality in associated services or API, etc.

The business user however, wants an all inclusive version AND price. So they throw everything including the kitchen sink in the spec, or try to add it in as they go. Making it unmanageable and unwieldy.

 

[NickK]

Set up micro transactions, £0.99 for this feature or buy a bundle for £4.99 sort of thing.

That becomes difficult for a large org, both in terms of £6 for a feature (a bank is more like £10,000+/feature and depends on country/language etc). Additionally a large org has larger overhead for contracts - that can includes costs charged to the charge centre of the project. So you want to break it down but not too fine.

 

[OspreyO]

Our funding would be released in large blocks from the board, only during specific times of the year. We had to work around that. Cut the cloth to suit etc.

 

[NickK]

We wouldn't have those kind of issues. Since we (Internal IT) would be preparing the metrics on the data and the interfaces with other systems. If there was a problem we would fix it not the development company since its our data and our interfaces.

Where we would have a frequent problem is when one if the specific business units not not having a complete understanding of their own business processes. You might a library of hundreds of rules, workflows or process that turn out to be complete garbage and contradictory. Requiring a lengthy review and the specification would ultimately change and timelines would be pushed out. In some cases this would be branched out into a seperate mini project and a seperate funding stream, so as not to divert resources from the main project. I thought that was smart way to handle these.

If the developer had a fixed cost contract they would have been stuffed. Projects usually ended up costing 2 or 3 time their original budget. TBH though I think they were only breaking even. The gravy was in the support contracts. So if a project was to derail or not go live, it would end up not being that profitable. It would however allow them to keep the resources on staff to take on other projects. Since their goal was to grow to a much larger size to take on even bigger projects.

Ahh the joy of the aspiring enterprise business information model.. and the legacy APIs that have data models and operations that cannot support customer UI flows. Did I say the fun with packing fields with data parameters making the same field different for each application..

Technically it can be nightmare. My favourite is rejecting a feature for the customer BU budget owner due to the existing owning BU (in a few countries) licensing 'deal' held a global pricing model made it unviable to roll out globally. Turns out the guy signed it on the golf course.. smart moves.

The joys of 320,000+ employee organisations and 350 C-level execs (yes a bank)

 

[gpuerrilla]

I think there is a conflict between IT people who are quite happy to deliver a version 1.0 and push other features to 2.0 or bolt on functionality in associated services or API, etc.

The business user however, wants an all inclusive version AND price. So they throw everything including the kitchen sink in the spec, or try to add it in as they go. Making it unmanageable and unwieldy.

Kind of how I have seen projects go especially if the leaders are either not tech savvy or they do not understand their own needs/requirements.

 

[OspreyO]

In our case,

Kind of how I have seen projects go especially if the leaders are either not tech savvy or they do not understand their own needs/requirements.

In some cases there a power struggle between IT vs Business. IT not listening to the Business and the Business thinking they can bypass IT by outsourcing their own IT project. Great fun being in the crossfire.

As these projects can fail despite large budges, I think some zero tolerance on stage payments is required to keep your sanity.

One vendor said they wouldn't talk to us unless we had proof of budget approval in place, and people assigned to the project. Otherwise we weren't serious. Many would require funds in Escrow .

 

[gpuerrilla]

Just going through one of our orgs introducing a new CMS and the contractor has flaked just before the hyper care period, and from our own org side the projects being forced to use it have fell way short in cleaning up their own data (clueless is only word to describe how to store info and people treating partial data not serious enough) and wanting more features than should occur in the first phase.

I can see from the contractors perspective (hence this thread) and the customers. Can agree it must be hot/cold and frustrating without clear malleable people involved. Probably critical is a decent people person just to organise the two parties, likely best a neutral freelance project manager just to deal with the awkward stuff and keep people on time deadlines.

 

[HangTime]

We wouldn't have those kind of issues. Since we (Internal IT) would be preparing the metrics on the data and the interfaces with other systems. If there was a problem we would fix it not the development company since its our data and our interfaces.

That's great for you, but it often won't be the case in other organisations. I've never worked for/with a company either directly or via a consultancy that could simply 'fix' all their [relevant] data in a fashion that was quick, safe, accepted by stakeholders and [perceived to be] cost-effective.

I think there is a conflict between IT people who are quite happy to deliver a version 1.0 and push other features to 2.0 or bolt on functionality in associated services or API, etc.

The business user however, wants an all inclusive version AND price. So they throw everything including the kitchen sink in the spec, or try to add it in as they go. Making it unmanageable and unwieldy.

The conflict is real but it's not always the same protagonists on each side. I've seen plenty of projects where IT want to do more work (sometimes not even beyond the original budget) but the Business want to get it live. In other words, it's the time piece of the equation as well, not just spec and price of delivery.

Probably critical is a decent people person just to organise the two parties, likely best a neutral freelance project manager just to deal with the awkward stuff and keep people on time deadlines.

One of the challenges is freelance project managers have to get paid from somewhere and hence may not be completely neutral. In my experience I would say all else being equal (skills, experience etc) the ideal scenario is to have PMs that have worked with a given org for a decent period of time so understands the culture, ways of working, business and IT context, has wide-ranging relationships established etc. Realistically that means they will be closer to the customer than the supplier, but if they are a good PM, I don't think that is a problem.