NORDHAVEN PERSPECTIVES / 2 NOVEMBER 2026
The shortlist is rarely the starting point
A business often begins a digital project by comparing products. That feels concrete: features can be scored, demonstrations can be arranged and budgets can be estimated. But a shortlist does not establish what the organisation needs to change. Without that clarity, a procurement process can make an uncertain requirement look more precise than it is.
Describe the work that needs to improve
Start with a specific situation. A handover takes too long. Teams reconcile conflicting versions of the same information. A manager cannot see which exceptions need attention. Describe who is affected, what happens today and why it matters. Avoid naming a preferred tool while the problem is still being defined.
Separate the requirement from the habit
Some difficulties are technical. Others are unclear responsibilities, inconsistent inputs or decisions that wait for the wrong meeting. Reproducing an awkward process in new software can preserve the very friction a project is meant to remove. Map the work before deciding which parts need a system.
Write the decision in plain language
A useful decision brief identifies the business problem, the people involved, the change being sought and the constraints that matter. It also states what is outside scope. Turn these points into evaluation criteria that a business owner can explain without a vendor presentation.
Keep adoption inside the decision
Implementation is not only configuration. Someone must own the process, decide how exceptions are handled and support people as their work changes. A credible software choice includes these responsibilities from the start. The better question is not which tool has the most features, but which approach the organisation can use well.