Unpopular opinion for B2B SaaS – how about redirecting your next £100k to fixing implementation delays rather than building the next shiny feature?
Why?
Because looking into different studies of project performance – the most conservative one is claiming that about 20% of projects experience overruns (time and/or budget), while other sources claim that up to 75% of projects experience implementation delays of more than 50% on average. (No consistent data exists, which is probably a topic for a different post. Sources below*).
Let’s do some maths using a hypothetical situation:
- a small(ish) saas company with projects averaging 9 months
- 10 implementations per year
- 4 people per implementation team at a blended rate of £90k
- 20% of projects are late or cost more than budgeted for
- and for these 20% that are running late the average delay is 30% (not recoverable from the customer)
What this means – the delay is pushing 2 of the 10 projects to 12 months. If my secondary school math does not betray me, this results in a loss of £180k p.a
In B2B SaaS we love a nice new shiny thingy, and we invest a lot of money in it. Mostly with an excellent reason – I think that product-led is the right business model for most companies, and the product is what makes us money.
Having said this – priorities, priorities, priorities…
We need to make some value-based priorities.
Deserving investment:
- A budgeted time and focus to step back, with a mandate to assess and change (and no, it will not work if you try to fit this in between meetings)
- Tools and repositories selected and implemented, or if these exist – cleaned up and refreshed keeping only the relevant information (and this is where AI fits in nicely)
- Product documentation, API documentation, training materials, demo env.
- Cross-company adoption (Sales and everyone – delete your old downloaded documents, make sure you use only the new ones)
And after this, the budget of the next shiny toy can (should) be redirected to developing Operations tools such as self service setups/configs, etc.
PS is a cost centre in most cases, aiming to cover costs with the fees the customers pay for implementations. But to avoid losing money, reduce customer churn, and most importantly – be able to scale, it requires some external investment from time to time.
*Studies vary widely on this — Standish’s 2012 CHAOS data found 37% of projects fully successful, 42% challenged, and 21% failed; IDC’s 2024 study found 75% of enterprises experienced SaaS implementation delays, with average timeline overruns of 57%; SPI’s PS benchmark, measuring delivery organisations directly, puts typical portfolio overrun closer to 8-10%.