You know the scenario. The budget is approved, the use case is clear, the team is motivated. Three months later, IT arrives with a list of prerequisites that nobody had on the table: three systems need to be modernised first, data quality is not sufficient, and Security has not yet completed a risk assessment.
Not a one-off failure. A structural pattern.
Two worlds, one approval
Leadership sits between business and IT, usually translating in both directions. Business speaks in use cases, ROI, and time-to-market. IT speaks in technical debt, system dependencies, and architecture requirements. Both are right. Both speak a different language.
The result: projects are approved before the prerequisites are known. IT, security, and legal come to the table too late. By the time they raise their requirements, the architecture is already fixed. What follows are rework cycles.
A recent assessment by IT decision-makers (CIO.com, September 2026) confirms: 32 percent cite IT modernisation as the most important investment driver, ahead of AI innovation. Not because AI is unimportant, but because AI needs a foundation that many organisations do not yet have.
Shift-left as a leadership decision
Software development has a name for this: shift-left. Whoever integrates quality, security, and compliance at the end of a project pays a multiple for every change. Whoever involves them from the start prevents expensive rework.
Applied to business/IT projects: the moment when IT, security, and legal are first involved is a leadership decision. Not a technical one. Not an operational one.
Think-First instead of AI-First means: before a budget is approved, the right voices are already at the table.
🦋 IT knows which system dependencies exist before an architecture is decided.
🦋 Security assesses risks before data flows.
🦋 Legal reviews requirements before a contract is signed.
🦋 Business defines the value before IT estimates the effort.
That slows the start. It accelerates everything after.
What this looks like in practice
A machine manufacturer in eastern Switzerland wants to pre-qualify customer enquiries with AI. Instead of evaluating a tool straight away, the first meeting includes not just the sales director but also IT, data protection, and the head of operations. What follows is not a roadblock: in two hours the group clarifies which data may be processed, which system currently receives the enquiries, and what a realistic pilot scope would be. Six weeks later the pilot is running. No project stop, no rework loop.
No new technology. No additional budget. Just the right people in the room at the right time.
Organisational development as the lever
Shift-left is not a project methodology. It is a question of collaboration structure.
Many SMEs have neither a formal decision body for IT investments nor a clearly defined role that mediates between business requirements and IT possibilities. The result: alignment loops, misunderstandings, budget overruns. Not from lack of will, but from lack of structure.
Organisational development here means clarifying who needs to be involved in which decisions before the first line of a project brief is written. That might be a new format: a monthly architecture board, a shared roadmap session between business and IT, or a temporary role that bridges the gap. Small steps, big impact.
Conclusion
AI projects rarely fail because of the technology. They fail because of missing prerequisites and voices that were invited too late.
The decision about who sits at the table — and when — is not a project specification. It is a leadership responsibility.
👉 Recognise this pattern in your organisation? Happy to talk through how a simple change in the decision process can prevent the next project delay.