DevOps Life Skills: Understanding and Managing the Procurement Process
In a previous blog, I talked about why it’s important to bring a ‘systems thinking’ approach to application delivery, operating more like a well-tuned factory optimized for efficient value delivery. Getting there means assessing the tools you rely on as well as the process by which you select and procure them. Efficiency requires prioritizing reusable patterns where possible, as well as selecting tools and processes that are consistent across teams and environments. That makes sense in theory to most people, especially when the tools in question are infrastructure or security related—with minimal impact on application function. However, an underappreciated barrier to building such patterns often stands in the way: The vendor and procurement process.
At present, it’s not unusual for DevOps engineers to use cloud-native tools, open source solutions, or other types of inexpensive (or free) resources that don’t require significant investment or interaction with the procurement team. But what if you need to advocate for a richer IT investment to drive needed efficiencies as well as to ensure better security and performance for your apps?
Making the Case for IT Investment
Here are a few things for DevOps professionals to keep in mind as they navigate unknown waters of the procurement process.
- Focus on value
If you’re reading this blog, you’re likely to prefer to focus on the technological capabilities of what’s needed, can talk APIs all day, and are obsessed with optimization. But guess what—your colleagues who are responsible for signing the big checks probably don’t give a hoot about any of that. Which is why the single biggest thing you can do to support purchasing a new tool or resource is to articulate—in their terms—the business value it will bring.
Often times, this starts with identifying what is currently missing or lacking. Asking to purchase a new tool simply because it’s now available is nowhere near as compelling as highlighting a significant flaw or liability, outlining the ways in which that flaw creates problems (slows production, exposes vulnerabilities, etc.), and then proposing a new tool that will solve it all.
The three key elements to focus on are cost, value, and risk. It’s important to talk about these in business terms—how a specific solution solves the problem identified by:
- Reducing costs over a short, medium, or long-term period
- How the business may increase agility, speed time to market, or attract new customers
- How business risk is reduced with improved regulatory compliance, reduced risk of attack or even something which reduces competitive exposure
In all of these, it’s very important to quantify each as best as can be achieved. No one wants purely qualitative opinions. Hard data matters.
For your colleagues in Procurement (and more broadly in Finance teams), everything has a cost and a value. This includes the cost of doing nothing (in the face of known problems), as well as the value of liberating workers from dealing with those problems. Just be aware that, while NetOps might find value in eliminating mundane tasks simply because it makes the job less tedious, Finance teams see value in freeing up those same engineers to focus on strategic, revenue-generating initiatives.
Will Marken, technical solutions manager at F5, suggests you “position yourself as a problem-solver; as you focus on delivering value, link the proposed solution back to corporate aspirations—this shows you can interact with management on their terms and speak to their needs.”
- Know the lingo: CapEx vs. subscription
- Be persistent
- Break it into chunks
- Team up
Your team might be all in on purchasing a solution through a subscription model and then discover your organization is aligned around large, CapEx expenditures and lacks a process for funding IT investments on a subscription basis. In that case, you have some additional work to do. You might find it easier to switch to a capex budget request (e.g., a single large purchase that will be amortized over time). On the other hand, even companies that have been slow to embrace subscription models are figuring out how to support them. You might just need to allow some extra time as your Finance colleagues work through their own organizational process challenges.
As cliché as it may sound, this really is one of those instances when it is about the journey, not the destination. Justifying large purchases often takes multiple attempts. In fact, your request may well be competing with others that have been making the rounds through two or three budget cycles, refining focus and gathering support along the way. Don’t give up when you hear “No.” Instead, plan for it, accept it when it comes, and move forward with adjustments from there.
Tackle procurement as you would take on any other task in your Agile workflow. Identify problems; solve them one by one; and iterate, iterate, iterate.
For large budgetary requests, it is often helpful to divide your project into more digestible pieces. This can be useful for two reasons: a) It is easier to create a plausible POC (proof of concept) and identify real-world value when there is tighter focus; and b) it is simply easier for those in charge to sign-off on smaller requests.
There are all kinds of reasons why it is a good idea to elicit help from others in the organization. For starters, your direct or cross-team peers may be more familiar with the procurement process in general—and with the value of F5 solutions in particular—and can therefore help you frame the request (and avoid known hazards). You can also reduce perceived risk by showing how your proposed solution will positively impact multiple departments. Finally, it is not uncommon (especially in very large organizations) to discover that another group has already attempted a request similar to yours (in which case you can learn from them) or may even have begun to implement a similar solution (in which case you can partner with them).
A Note on Structure
As you take on the creation of a budgetary request, you can rely on many of the same tactics you would use to create more typical documents for your field, such as white papers and datasheets. This starts with finding the appropriate template so that you know your request will look and read like other requests the manager is familiar with. It also includes running it past multiple colleagues for input and feedback throughout the process. Jon Gross, product development manager at F5, adds that “as with datasheets and white papers, success often hinges on the description or opening paragraph.” He suggests you “look for existing reference architectures and use cases that can shore up your implementation roadmap with real-world data points.”