Technology projects often fail before the technology is selected

When a technology project disappoints, the supplier or platform receives most of the attention.

Sometimes that is justified.

But many projects are already in difficulty before the technology is selected.

The business may not agree on the problem. Requirements may describe current habits rather than actual needs. Ownership may be unclear. Different departments may expect different outcomes. Data may be assumed to exist in a usable form when it does not.

The procurement process then compares solutions against a requirement that was never stable.

A better sequence

Before selecting technology, establish the business outcome, the operating constraints, the information required and the responsibilities that will exist after implementation.

Then separate requirements into what is essential, what is desirable and what merely reproduces the current way of working.

This does two useful things.

First, it makes suppliers easier to evaluate because the business knows what it is asking for.

Second, it creates permission to discover that a proposed feature, integration or automation is unnecessary.

Keep the project connected to its reason

During implementation, requirements can be buried under configuration decisions, technical dependencies and schedule pressure.

The project needs a continuing reference point: what business requirement justified this work in the first place?

If that answer changes, the project should be allowed to change with it.

Implementation discipline is not about protecting the original plan. It is about protecting the business purpose.