The Pain of Corporate Purchasing
Making a significant purchase within the enterprise can be challenging. Justification of new software, infrastructure, or consulting may necessitate many iterations of grueling explanations. Yet it doesn’t need to be this difficult.
In this article, I’ll explain how to get to the finish line faster by way of the deal summary; a template which fosters repeatable processes and eases the pain of repetitive purchase justification. A sample deal summary template is also provided for download here.
Speed Through Repeatability
Corporate purchasing is often painful simply because it isn’t repeatable. Each purchase is a unique, bespoke process with each gatekeeper asking different questions each time. For instance, your boss will have questions. Your boss’s boss will have questions. Your peers will have questions. IT and security will definitely have questions. Finance will inquire if you’ve examined alternatives. Legal will ask about indemnification and privacy compliance. Sounds fun, doesn’t it?
Yet spinning up a new deal should not entail pushing vendor solutions into the procurement pipeline and hoping for the best. The idea is to (literally) get everyone on the same page; that is, a one-page deal summary which standardizes and streamlines the process.
Enter the Deal Summary
A deal summary is a brief synopsis of the problem you’re trying to solve and the resources you need to solve the problem; typically money, but sometimes time, resources, and inter-team collaboration as well. The deal summary also captures requisite approvals from decision makers to unlock the resources.
A deal summary is not a full-blown procure-to-pay process. Nor is it an overly bureaucratic vendor questionnaire. It’s effectively a focused checklist of only relevant artifacts needed to make a documented purchasing decision.
The purpose of the deal summary is not to tactically vet a vendor. (That may come later.) The intent of the deal summary is to unequivocally unlock the funds needed to move forward with this solution via minimal discourse.
Deal Summary Sections
Deal summary sections may be added or removed as needed. Moreover, certain sections may be added only for deals of a specific nature or size.
As a deal summary starting point, see the eight sections below:
- The problem you’re solving – A clear summary of the problem space; not just the solution.
- Urgency – In other words, why now? What are the risks associated with waiting?
- Budget – Both initial and ongoing if necessary
- Sign offs – The official approval section, signed by one and only one decision-maker with signing authority.
- Success Measures – How do we know this was a valid investment? Up-front examples include ROI or NPV. Retrospective / ongoing metrics (such as furthering a specific OKR, KPI, or scorecard) should also be included.
- Vendor – Were alternatives considered? Why was this vendor chosen?
- Business capability: What area of the business improves with this solution?
- Architecture – Is there a solution design? Does this replace an existing solution? Who will support and govern the solution going forward?
Putting Deal Summaries into Practice
The linchpin for deal summary success is getting decision makers to buy-off on the idea itself. That is, vying to adopt the deal summary format and sticking to; versus routinely deviating into random domains inquiry. The idea is to streamline the purchasing process through standardized criteria. In other words, apply standard rules to the game versus making them up as you go.
While every organization is different, I would assert that the deal summary should be completed sometime after initial discussions with the vendor(s), yet before engaging finance, security, legal, and IT.
Finally, there should be criteria for when to use a deal summary versus not. In most cases, this is a spend threshold. (E.g. deals over $150k require a deal summary.) Other considerations are welcome as well; including deviating from a corporate standard or purchasing a cross-functional solution that will impact multiple departments.