Technology should wait for the problem

Technology is easier to buy than a problem is to name. That is why so many programmes start with a platform and spend the following months searching for a use that will justify it. The search is then called implementation. It is not. It is archaeology in reverse: trying to find a past that will make the purchase look inevitable.

This pattern is older than the current tools. Enterprise resource planning, customer platforms, data lakes, and now models have all been bought as answers in search of a sentence. Each wave produces a few genuine fits and a large number of organisations that now have an extra layer to feed, join, and explain. The extra layer is not free. It consumes the same people who were already keeping the unofficial path alive.

Constrange’s view is simple, and we will keep repeating it until it is boring: understand the situation, define the problem, then look at technology — including the option that no new technology is required. Sequence is not a personality. It is how you avoid spending a year on the wrong object.

A sequence that holds

The method we use in the work is five stages. They are not a waterfall costume. They are a way of making sure each artefact can be challenged before the next one pretends to be certain. Understand produces a picture of the work, the systems, the people, and the constraints as they actually are. Define produces a named problem and non-goals. Explore holds more than one credible path, including doing less. Structure produces architecture, owners, and sequence. Move produces a first action small enough to be real, and a rhythm to review it.

1. Understand the situation — work, systems, people, constraints.
2. Define the problem, including non-goals.
3. Explore approaches, including the option that no new technology is required.
4. Structure a path that can be implemented.
5. Move: owners, first actions, a way to tell if it worked.

Notice where the purchase sits. Not at the front. Not as a given. If a vendor meeting happens in week one, it should be treated as research into a possible tool, not as the start of a programme. The programme starts when the problem can be said in a sentence that operations recognise.

Why the reverse sequence is so common

Buying first is socially easier than naming a problem. A purchase has a date, a budget line, and a senior sponsor who can be seen to have acted. A named problem has arguments. It threatens someone’s current tool. It admits that the unofficial path is the real one. It might conclude that the bottleneck is a rule, a join, or a person who is doing three jobs. None of that photographs well in an annual report.

There is also a genuine fear of falling behind. Categories move. Boards ask what you are doing about the category. The safest-looking answer is a platform. The honest answer is often: we are still establishing whether this category is the constraint. That sentence feels like weakness in a culture that rewards motion. It is frequently the most expensive sentence you failed to say.

Vendors are not the villains of this story. They sell what they have. Your job is to know what you need. If you do not know yet, you are not a sophisticated buyer. You are a budget. Sophisticated buying starts with a problem that could, in principle, be solved without the product in the room.

Sometimes the process is the product

If a competent person would still be slow given complete information, you may have a capacity or rules problem. If they would be fast, you likely have an intake, join, or data problem. In the second case a model will sound helpful and remain beside the point. It will generate text about the missing fact without producing the fact. It will sit on top of a broken join and make the join harder to see.

IF the delay survives complete inputs
  THEN consider automation or capacity
ELSE
  fix the missing fact, the join, or the owner
  do not buy a layer that hides the gap

This test is deliberately blunt. It is meant to be used in a room, not in a laboratory. You do not need a six-month diagnostic to ask: if we handed a capable person every input tomorrow morning, would the work still stall? If the answer is no, your technology conversation is premature. You have an information, ownership, or joining problem. Those are cheaper to fix when they are not wrapped in a platform.

If the answer is yes — the work still stalls with complete inputs — then technology, automation, or capacity may be the right class of move. Even then, you have not yet chosen a product. You have chosen a class. Classes are not vendors. Collapsing the two too early is how you inherit someone else’s architecture.

The join is usually the problem

Work rarely fails in the middle of a well-owned box. It fails where one system hands to another, where one team’s definition of done is another team’s intake, where the customer has to repeat a fact that the organisation already holds in three places. Joins are unglamorous. They do not have category conferences. They are where money and patience go to die.

A new platform that does not redesign the join becomes another box with the same handshake. Sometimes it makes the handshake worse, because now there is a canonical object that is almost right. Almost right is a special kind of wrong: it looks like progress in a demo and fails in the exception, which is where live work lives.

What waiting looks like in practice

Waiting does not mean freeze. It means do the work that makes a purchase honest. Map the unofficial path. Write the problem and the non-goals. List three paths, including one that changes process only. Put a cost on being wrong. Then, if a tool is still the right class of move, go and buy it with a spine: owners, sequence, and a first step that does not require the entire estate to move on day one.

• A sentence for the problem that includes a constraint
• A sketch of the join, as done, not as drawn
• Non-goals, so the purchase cannot quietly expand
• A first slice that can fail without taking the organisation with it
• A named owner who will still be there when the first exception appears

If you cannot produce that list, you are not ready to sign. You are ready to look. Looking is legitimate work. Signing is a different act. Mixing them up is how “discovery” becomes a paid implementation that nobody can stop.

Already bought

Many conversations begin after the platform is already in the building. That is not a reason to pretend the sequence still starts at zero. It is a reason to be stricter. The work is then to see which problem the thing can honestly serve — and which work should stop so it has a chance. A platform that is asked to justify itself by becoming the home of every idea will justify itself as shelfware, or worse, as a new unofficial path on top of the old one.

Stopping work is the unfashionable half of implementation. Without it, the new system competes with the old habits and loses, because the old habits are how Friday afternoon actually happens. If you will not stop anything, do not add anything. That rule would retire a surprising number of programmes.

Implementation is not a later department

A strategy is valuable only when it can become action. The last artefact is not a recommendation. It is a first move with a name next to it. Constrange will not leave a path that cannot be built. Direction is always in scope. Build can sit with your team, a partner, or a mix. Either way, the joins, owners, and first slice have to be designed as if someone were going to do them on a Tuesday — because they are.

This is why we resist the split between “strategy” and “delivery” as two cultures that throw documents over a wall. A point of view that cannot survive contact with the unofficial path is not a point of view. It is a brochure. The method’s last stage exists to prevent that split: move, review, and be willing to name a different problem if the first step taught you something.

“If the path cannot be started without a new operating model, it is not yet a path. It is a wish with architecture.”Constrange

A closing discipline

Before the next tool conversation, write one page. Not a deck. A page. What is under pressure. What constraint will not move. What the unofficial path does today. What you will not do. What first step would tell you if you are right. If you cannot fill the page, you do not need a vendor. You need a reading. If you can fill it, you will buy better, or you will discover that you should not buy at all.

That page is the cheapest artefact in the whole landscape, and the one most often skipped. Constrange’s practice is, in large part, the discipline of not skipping it — and of staying until the page has become a move.