The vendor was chosen before the problem was defined.
A careful buying process can still be built around an answer chosen too early.
The buying process was real. But it was working backward from a decision already made.
A familiar vendor had a product. A competitor had made a purchase. An existing relationship made one option seem straightforward. By the time the formal evaluation began, the answer already had momentum.
The requests for proposals, scorecards, and reference calls could all be legitimate. Yet the organization was testing whether it could justify a preferred solution before it had agreed what problem needed solving.
The order of decisions matters.
Vendors can help you see possibilities and constraints you had not considered. Talking to one early does not automatically make the selection wrong.
The problem begins when a preference becomes a commitment too early. The organization has not yet agreed on the outcome it needs, how the work really happens, or what would show that a solution fits.
Once that happens, the requirements can start bending toward the preferred answer. Inconvenient details become exceptions to handle later. Existing licenses or a faster timetable can outweigh information from people who will have to live with the decision.
The Standish Group’s CHAOS 2020: Beyond Infinity puts the sponsor, the team and the working environment at the center of project success. In a procurement decision, those people need the authority to challenge the requirements and change the selection. Their presence on an approval list is not enough.
Listen to the people who know the work.
The person who controls the budget may not be the person who knows the process. A manager can give an honest account of a process without knowing its daily variations, informal handoffs, or workarounds.
Sometimes the right knowledge is missing. A harder problem occurs when people with that knowledge are consulted, give an accurate account, and are overruled. Asking the right people matters only if their answers can change the decision.
Ask which of the two happened: was the knowledge missing from the discussion, or was it available and set aside?
There can also be no single person who knows the whole process. Different people hold different parts of the picture. The documented process may describe the intended sequence while the actual work follows several others. A requirements document cannot replace that full picture.
Reconstruct the order of events.
When was the business problem written down? When did a vendor become the preferred option? Who contributed evidence about the actual work? What information, if discovered, could still change the selection?
If nothing could change the answer, say so. The organization may be implementing a decision already made, rather than evaluating alternatives.
Make the problem specific enough to test.
A broad label such as “improve order processing” leaves too much unresolved. Which part of the process limits the outcome? What variations matter? What must change for the investment to produce value?
Ask those questions while the answers can still change the decision. Speed gained by skipping the discussion can reappear later as configuration work, exceptions, or a mismatch between the system and the work.
The problem may look like technology. But it may have started with how the problem was defined, or with whose experience was heard and whose was ignored. The order of events will tell you more.
Before judging the selection process, ask whether it could still have chosen a different answer.