AI is changing a lot. Including how we structure and prioritize the delivery phases of IT projects. Where the development phase used to consume most of the time and budget, we are now moving into a new reality: the analysis phase is taking up more space, and a concluding test phase is becoming a more significant part of the process.

From project to product – and from predictive to adaptive 

AI has triggered a shift in IT project delivery phases that is largely about mindset. Whereas we used to work within fixed project frameworks such as scope, time, budget — based on a set prediction from the start, we now need to move toward a more flexible, product-oriented approach. In this model, we evaluate, adapt, and learn continuously with a strong focus on user involvement. 

This means that, as leaders and professionals, we must dare to say: “We shouldn’t move forward.” We must be willing to shut down initiatives that don’t create value and instead invest our time where we can make an impact. That takes courage, curiosity, and not least an organization ready to work in new ways. 

A new structure for delivery phases: analysis and testing take on a new role 

In practice, this changes the way we structure projects. Previously, the phases of a public IT project (simplified) typically looked like the graphic below illustrates: 

Classic delivery model:

 We have been used to the initial analysis phase taking the least amount of time. This phase has been particularly short if we forgot to include critical considerations such as governance, role and responsibility distribution, operating models, and documentation to ensure successful implementation — something that has caused issues in several projects. These considerations naturally extend the analysis phase but also secure a smoother and more successful development phase: a phase that, regardless of analysis, traditionally consumed the most time and investment. 

Now, with AI accelerating the actual development work, the balance shifts, allowing for a more efficient development phase. However, this demands a far more precise analysis and documentation of business needs. With AI, the scope of the delivery phases shifts, as illustrated below: 

AI-based delivery model:

With AI, we can quickly generate code and solutions. But we must be extremely precise in analysis and in understanding users, core processes, and objectives—otherwise, we simply end up building faster in the wrong direction. That is why the analysis phase is now the one that should take up more space—and in some cases, the most. 

At the same time, the need for a concluding test phase has increased, where IT projects are tested more thoroughly: technically, organizationally, and from a user-experience perspective. 

The effective use of AI also makes it possible to move faster through the phases from idea, to analysis, to development and testing. The innovative model thereby becomes iterative (as the symbol to the left illustrates), enabling organizations to test different options—where AI makes it possible to try out multiple directions and solutions without launching large, failed projects. 

In other words, we are shifting from a project mindset to a product mindset in how we develop IT projects, as illustrated below: 

Embedding a product mindset in the AI-based delivery model:

With an iterative product development approach, the organization can work step by step through the process, continuously evaluating whether the initiative should continue (as the “stop” or “go” sign in the dark orange triangle shows). By incorporating this product mindset into our delivery model, we test multiple solutions in their simplest versions — but only continue with the ones we are confident actually create value. 

How can a product mindset fit into procurement processes? 

In many public IT projects, the rules are set early: scope, budget, and timeline are locked through the procurement process. This creates security and overview—but can also make it difficult to work in the more flexible and experimental way that a product mindset and AI encourage. 

But it does not have to be an either/or. Many tenders are now designed with elements of agility: room for iterations, testing, and adjustments along the way. This means that collaboration between customer and supplier can include user feedback and market changes—even when the project spans months or years. 

In this way, it is not enough to have dialogue early in the process. What is crucial is that procurement allows for continuous learning and adaptation within the collaboration itself. 

The new way of delivering requires an innovative mindset 

Kickstarting an innovative mindset can be difficult—especially in large organizations where mentality is often locked into classical frameworks. 

For us to succeed with innovation and AI-driven processes, we must dare to work differently—and like everything else, it starts with leadership. I recommend bringing the following into play: 

(New) Leadership Formats: 

• Put diversity and cross-disciplinary collaboration into play by creating spaces for teams with different skills and perspectives 

• Build psychological safety by allowing the “crazy idea” and accepting that mistakes are a natural part of innovation 

• Budget for experiments and learning. Innovation requires both resources and structure 

• Prioritize continuous learning and feedback—innovation is also education and knowledge-sharing 

• Lead by example by being a curious and open leader who drives change 
  

Conclusion: AI is changing not just what we do – but how we think 

AI is not just a new technology—it is a catalyst for rethinking how we develop and deliver digital solutions. It demands rethinking procurement and delivery models, a bold innovation mindset, and new leadership formats. 

Future digital organizations must take the lead—not by simply executing faster, but by analyzing smarter, strengthening teams, and making braver decisions. 

Would you like me to also make this translation more like a polished LinkedIn-style article in English (shorter sentences, catchier section headers), or do you prefer it stays close to the Danish structure and tone?