Scope Creep at Brightpath Software
Brightpath Software is a FinOps team of three whose remit covers only public cloud: $3.1M a year. The CFO has just discovered that SaaS is $1.4M (Salesforce, Datadog, Snowflake, plus 60 smaller tools) and that the on-premises data centre costs $2.2M a year, with a five-year hardware refresh due in 18 months. The team has no visibility into either. Two colo racks house latency-sensitive trading services that product has said cannot move. The CFO wants one FinOps practice, one number, and an answer to 'is the cloud cheaper than on-premises?'. The team is being asked to double its scope without additional headcount.
1. Define the scope boundaries you would propose and what operationally changes as each new technology category comes in.
Read the worked answer
Three scopes, one practice, sequenced - not one scope switched on at once.
- Public cloud ($3.1M) - existing, keep running. Mature the existing practice; it is the source of the methods the other scopes will borrow.
- SaaS ($1.4M) - add next, because the return is fastest. What changes: the unit of cost shifts from hourly usage to contract and entitlement, the data comes from invoices and admin consoles rather than billing exports, the cadence is the renewal calendar rather than the month, and the decision-maker is Procurement plus the business owner rather than Engineering. The whole practice inverts from usage optimisation to licence and entitlement optimisation (provisioned versus active seats, tier right-sizing, duplicate tooling across 60 vendors).
- On-premises ($2.2M) - add last, and with a different question. What changes: the cost is largely fixed and depreciated, so the FinOps question is not 'reduce the bill' but 'utilise the capacity you already bought' and 'get the refresh decision right'. Data comes from asset registers, depreciation schedules, power and colo contracts, and support renewals. It has to be integrated with the existing ITAM/ITFM practice rather than rebuilt - those personas already do this and will not appreciate a parallel process.
With three people, I would not take on all three at once. $1.4M in SaaS with 60 vendors and no visibility is a bigger and quicker win than a $2.2M on-premises estate that is already depreciated.
2. How do you answer 'is the cloud cheaper than on-premises?' without giving a misleading number?
Read the worked answer
I would refuse the question as framed, and explain why the framing produces a wrong answer in either direction.
- The comparison is not like for like. The cloud bill is largely opex and variable; the data centre is capex, depreciated, and sunk until the refresh in 18 months. Comparing a monthly cloud invoice to an annual depreciation charge understates on-premises by excluding the refresh capex, the power and cooling, the colo contracts, the hardware support renewals and - most often omitted - the labour of the team that racks, patches and replaces it. It overstates it if you compare cloud at list price with no commitments against a fully depreciated asset.
- The marginal question is the real one. The useful question is not 'which is cheaper' but 'for this workload, at this scale, over this horizon, what does each option cost per unit delivered?' That is answerable: pick two or three candidate workloads (the two colo trading services and one comparable cloud service), build a total-cost view including labour and refresh, and express it per transaction or per unit of compute.
- State the horizon and the assumptions explicitly. A five-year view including refresh capex with the same labour allocation on both sides is defensible. Anything shorter is a preference dressed as analysis.
The deliverable the CFO actually needs is the refresh decision, made with real numbers 18 months out - not a verdict on cloud versus on-premises in general.
3. Which of the three scopes will strain the three-person team most, and what would you do about the capacity gap?
Read the worked answer
SaaS, and not because of the dollar size.
The strain is structural. Public cloud gives you a machine-readable billing export, daily granularity and a clear technical owner. SaaS gives you 60 separate admin consoles, 60 renewal dates, entitlement data that often has to be exported by hand, and no per-transaction usage at all. For a three-person team, that is 60 small integrations rather than one large one - the worst possible ratio of effort to value per vendor.
What I would do:
- Pareto the vendor list. Twenty of those 60 tools will be under a few thousand dollars each and renew annually. Bucket them into a low-touch 'tail' process - a single consolidated review per quarter, renewal dates in one calendar, no per-vendor analysis - and spend the effort on the five contracts that are 70%+ of the $1.4M.
- Borrow personas rather than hire. Procurement already owns the renewal calendar and the negotiation; Finance already owns the invoice. The FinOps team's contribution is the consumption view that neither has. That is a data contribution, not a new process.
- Buy the scope, not the headcount, where possible - a SaaS management tool is cheaper than an FTE and this is the one category where the tooling is genuinely commoditised.
- Say what will not be done. Explicitly defer on-premises until the refresh business case, and get that accepted in writing. A three-person team that quietly accepts three scopes will deliver a shallow version of all three and lose credibility on the one it was good at.