The Question Every IT Leader Should Ask Before Buying Anything
Before the vendor demo. Before the proof of concept. Before the RFP is drafted and the evaluation committee is assembled and the pricing spreadsheet is built with four vendors compared across twenty-three weighted criteria. Before any of that, there is a question that most IT procurement processes skip, or answer implicitly rather than explicitly, or answer once and never revisit, and the skipping of that question is responsible for a significant portion of the enterprise software that is currently installed in your environment, fully licensed, and being used by fewer people than the renewal contract assumes.
The question is: what will be different when this works?
Not what the tool does. Not what problem category it addresses. Not what capabilities it unlocks in the abstract. What will specifically and observably be different in the organization, for which specific people, in which specific workflows, if this tool is implemented successfully and adopted at the level the business case assumes? The answer to that question is the actual business case, and it is different in kind from the feature comparison matrix that usually substitutes for it, because it requires the IT leader to articulate not just what is being purchased but what is being changed, and change is harder to specify than capability.
The reason this question gets skipped is not laziness and not ignorance. It is that answering it specifically requires doing the harder work of defining the current state with enough precision that the improvement can be measured, which means sitting with the people who do the actual work and understanding their experience of the current process in enough detail to know what better would look like for them. That work is slow, qualitative, and does not produce a slide that fits neatly in a procurement deck. The vendor's ROI calculator is faster and cleaner and tells a story with numbers already attached, and the numbers in vendor ROI calculators are constructed to justify the purchase rather than to predict the actual outcome with any particular accuracy. They are not lying, exactly. They are answering the question in the most favorable light available, which is what you would do in their position.
The organizations that consistently get value from enterprise software purchases are not the ones with the most rigorous evaluation processes. They are the ones that define success before they buy, implement with the success definition visible to everyone involved, and measure against it after go-live with the same rigor they applied before. The tool that was purchased because it was the best-in-class solution in its category and the tool that was purchased because it will reduce the specific manual reconciliation process from three hours to thirty minutes for the six people who do it every Monday morning have the same chance of being adopted. Only one of them has a clear definition of what success looks like. The success definition is not a nice-to-have that gets written after procurement. It is the document that makes the procurement rational rather than aspirational.
What will be different when this works? If you cannot answer that question in one specific, observable sentence per affected workflow, you are not ready to buy anything. You are ready to define the problem. Go do that first. The vendor will still be there when you are done.
