Requirements before preference
Requirements are written as business capability, operational constraint, data need and governance requirement. Preference is allowed, but it is labelled as preference. It does not become evidence by repetition.
Technology advisory starts before preference hardens.
System choices become expensive when requirements are reverse-engineered from a favoured option. The discipline is to separate need, constraint, evidence and recommendation so the decision survives staff turnover.
Shortlist construction
A shortlist is built from fit against written requirements, implementation implications, data responsibilities, integration impact and operational ownership. The list is not a popularity contest and contains no hidden partner incentive.
Recommendation record
The recommendation states the decision, dated, the rejected options, open risks, dependencies and the owner of the next step. A future manager should be able to read it and understand why the choice was made.
Data and integration principles
Data ownership, master records, interface responsibility, reporting definitions and failure handling are considered at principle level. Detailed engineering belongs with the delivery team that will build and run the solution.