#15. My Case Against the FinOps Phases

I had a conversation once with a colleague about creating a FinOps advisory offering for a customer. We debated the timing of training and governance for cloud spend policies. According to him, training, governance, and culture belong in the operate phase and should come after we've done the initial work of allocating costs (or achieving cost visibility) and implementing cost-saving optimizations. According to him, that is the sequence of phases in the FinOps Framework. This made me wonder: When you land a new job, don’t they teach you how to do it, and then provide you with rules and guardrails before you are asked to optimizing your work efficiency? So why is that different for FinOps? — Ladies an gentlemen, that is my case against the FinOps phases!

TL;DR

• Organizations follow the FinOps phases sequentially (Inform → Optimize → Operate), which leads them to run workloads in the cloud without first establishing proper governance foundations. In reality, the sequence should be Operate → Inform → Optimize.
• We should view these phases as indicators of our current FinOps activities rather than a rigid sequential checklist!

The Framework has Evolved Well, but there's a Common Misunderstanding

You might remember that until recently, FinOps had all its capabilities listed under 6 domains divided into 3 common phases (see picture below). This has now changed to 4 domains, with the new "Manage the FinOps Practice" domain including many practices needed to establish FinOps in an organization and foster the Cloud Mindset.

Although the contents of the domains appear largely unchanged, the framework is fundamentally different from before. The focus has shifted to why you perform certain capabilities. It's now more goal and outcome-driven, rather than just a series of processes to be performed.

Yet organizations still commonly misunderstand when and in what order they should implement FinOps activities. I believe in iterative cycles of improvement, but not in Inform→Optimize→Operate. In fact, seeing "Operate" at the end of the sequence causes most organizations to start in the wrong order.

Why the Phases of FinOps Don't Make Sense

I believe in early FinOps adoption, which should begin when the Cloud Center of Excellence (CCoE) is established. This means organizations should implement all Operate phase practices right from the start. Consider the following:

• You need to establish a target operating model for FinOps, educate and skill up your stakeholders, and set governance through cloud policy before or in parallel to allocating cloud costs. Thus operate before inform
• You should enable shifting left (which isn't yet a domain, though I hope it becomes one), then use these recommendations to establish governance through policy before you optimize your costs. Hence, Operate before Optimize
• If you have a solid Operating Model including a clear tagging strategy for cost allocation and you enforce it through automations and Infrastructure as Code (IaC), then we avoid the cycles of improving cost allocation. Once again, Operate before Informing.
• Modern organizations start with a DevOps mindset where automation and agile sprints are the foundation of work. Why not apply this to FinOps and make it agile through smaller, parallel improvements driven by automation, rather than following a waterfall-like approach of three phases?

So, obviously it isn’t a straight formula to follow!

Do we Really Need Phases or Small Cycles of Improvements?

Here's my conclusion: We need to improve incrementally to achieve FinOps maturity, but not through three sequential phases. Instead of these phases, I advocate for building a solid foundation first. This means establishing a robust target operating model and implementing an education program so all stakeholders understand their roles in the framework and have clear cost visibility. Next comes cloud spend governance aligned with your business goals. Finally, maximize your business value through optimization—including adopting modern cloud architectures and making refinements beyond your established governance.

Once this foundation is established, focus on cost avoidance through governance, then enhance your cloud spend through small, iterative improvements—whether by extending governance to additional services or optimizing spend through modernization.

Summary

Following three large cycles to improve FinOps resembles an outdated waterfall methodology with flaws in its sequence. Instead, I advocate for establishing a solid foundation upfront, with a strong focus on automation and educational enablement. This foundation allows organizations to run smaller improvement cycles focused on shifting left, governance, cost optimizations, and other essential FinOps capabilities.

Thanks for reading! Share if you found it helpful. Have questions or suggestions for future topics? We'd love to hear from you!

‍