Building IT Value for the Business
Transformation – from waterfall to agile business partner
In many organizations, IT still operates in the logic of several years ago: a centrally managed department, large projects in the waterfall model, extensive paths of acceptance and decision-making. In the reality of 2026 – with high dynamics of change, pressure on digitization and the use of AI – such a model is increasingly becoming a bottleneck instead of being a lever for development.
In the article you will learn:
- Why the traditional IT model stops working
- What does “IT as an agile business partner” mean
- How to carry out organizational transformation of IT step by step
- What KPIs to measure during changes
- How to consciously set the proportions: central vs local IT
Why the traditional IT model stops working
A classic, central IT model based on waterfall usually looks similar:
- Large, rarely delivered projects dominate,
- Most investment and architectural decisions are made at the level of the centre,
- IT acts as a “supplier” to which the business submits requirements.
In a stable environment, this way of acting was acceptable. Today, however, it generates several repetitive problems:
First of all
Too slow to respond to business needs. Long cycles of analysis, budgeting and project implementation mean that many months pass from the decision to the first effect. In the meantime, priorities, the market, and often the strategy itself change.
Secondly
Not fitting into constant change. Waterfall assumes relatively stable requirements. In practice, requirements change during the work, which leads to scope scrambles, protracted testing and post-implementation disappointment.
Thirdly
There is a lack of a mature mechanism for investment decisions. A portfolio of IT initiatives is sometimes a collection of “orders” rather than a consciously managed portfolio of value-oriented investments. There is a lack of simple, common criteria that help justify decisions to the management and business.
As a result, IT – instead of being a partner – is perceived as an expensive, inflexible cost that “does not keep up” with the pace of change.
IT as an Agile Business Partner
IT organizational transformation is not simply about implementing Agile or DevOps. It means moving towards a model in which business and IT jointly define the direction of technology solutions and share responsibility for the business outcomes they deliver. IT is no longer assessed solely on delivering solutions within scope, time, and budget – increasing emphasis is placed on the value those solutions bring to the business.
Key elements of this approach:
- A product model complementing the project-based approach
IT increasingly organizes its work around products and services – such as digital channels, CRM, or e-commerce platforms – owned by stable, cross-functional teams. The product approach does not replace project management but complements it in areas where solutions evolve continuously and require long-term accountability for business value. - Continuous value delivery vs. focus on a single implementation
Teams work in shorter iterations, deliver changes more frequently, and validate their impact faster. This makes it possible to continuously test assumptions against user needs and business outcomes and adjust the direction of solution development accordingly. - Shared business and IT goals and joint accountability for outcomes
Business and IT jointly define initiative objectives and expected outcomes. Success is no longer measured solely in terms of scope, time, and budget. Increasing importance is placed on the actual impact of IT solutions on business metrics – such as revenue growth, cost reduction, improved customer experience, or greater operational efficiency.
In this model, the objective is to continuously build business value through shared accountability between business and IT – from defining needs and priorities, through delivery, to evaluating the outcomes achieved.
How to carry out organizational transformation of IT – the logic of steps
Every organization has its own specifics, but in practice, successful IT transformations have several common stages.
1. Diagnosis of the current state
The first step is to name a spade:
- What does the current IT structure look like (division of responsibilities, role of architecture, PMO, etc.)?
- How does the decision-making process for new initiatives and budgets work?
- How does IT work with key business units?
This includes workshops, interviews, a portfolio review of initiatives and value stream mapping, among m.in others. The goal is to understand why IT works the way it does today, and not just to say “we operate in a waterfall”.
Note: Workshops and interviews and their mutual synchronization are key here. There are often divergent opinions about how IT works – depending on the level of the organization from which a person looks at the problem.
2. Define the target operating model
Based on the diagnosis, the target image is created:
- What roles are needed (e.g., Product Owner, Business Owner, Domain Architects)?
- What should teams (product, domain, mixed) look like?
- How to divide responsibilities between IT and business – who decides on priorities, budget, direction of product development?
This is the stage at which the organization answers the question of what “IT as a business partner” should look like in its reality, and not in general models.
3. Establishing the rules of IT-business cooperation
Even the best organizational chart will not work without clear rules of cooperation. Key issues are:
- The method of submitting and evaluating new initiatives,
- The frequency and format of planning (e.g. quarterly portfolio reviews),
- Common KPIs that are reported and discussed.
At this stage, rules are created to replace the current, often ad hoc way of operating.
4. Pilot – testing the new model in practice
Instead of immediately covering the entire organization, it is wise to choose 1-2 areas where:
- Business sees the value of change,
- There are leaders ready to take responsibility for the pilot,
- It is possible to show the first effects relatively quickly.
In the pilot, new roles, the way of planning, the rhythm of work of teams and the way of cooperation with business are tested. It’s about “learning by doing”, not just on slides.
5. Scaling to new areas
Only based on the conclusions from the pilot is it worth planning further wave implementations:
- Expanding the product model to other domains
- Strengthening roles (e.g. Product Owners) and supporting structures (e.g. architecture, HR, finance),
- Adaptation of tools (systems for portfolio management, team work).
6. Stabilization period after implementation
This is a moment that is often overlooked. After the formal “implementation” of the new model, a conscious stabilization period is needed, in which:
- Observe how the new model works in practice,
- Adjustments are made to the responsibilities, processes and interfaces between teams,
- The competencies of leaders and key roles (e.g. Product Owners) are strengthened.
Changing the organizational model is just the beginning – it takes months to change behavior and habits. Equally important is the attitude of IT towards business: just changing roles, structures and teams is not enough if the mindset of IT leaders – but also of each employee – is not “switched” from completing projects to consistently building value for the business. Therefore, at the beginning of the transformation, it is crucial to honestly assess whether such a change in the way of thinking is realistically possible in the organization and what development or personnel activities will be necessary to support it.
7. Continuous improvement
IT transformation does not have an “expiration date”. Successful organizations treat it as a process of continuous learning – with regular model reviews, adjustments, and investments in people development.
What to Measure in Transformation – Simple KPIs That Make a Difference
One of the key challenges is the lack of tools and processes for efficient investment and project decision-making. An effective way to organize these decisions is to introduce a simple set of common KPIs that IT and business accept and regularly discuss as the basis for managing their portfolio of initiatives Part of the answer is simple, common KPIs that IT and business accept and discuss regularly.
For example:
- Time-to-market – the time from the decision on the initiative to the implementation of the first version of the solution.
- The degree of achievement of the business objectives of the initiatives – not only “whether the assumed effect has been achieved”, but whether the assumed effect has been achieved (e.g. increase in sales, decrease in service time).
- Business satisfaction with IT services – simple surveys after initiatives or recurring NPS.
- The degree of utilization of the implemented functions – how many of the introduced functionalities are actually used, and what remains a “redundant” range.
It’s not about creating dozens of indicators, but about a few well-chosen ones that help talk about value, not just tasks.
Central vs local IT – how to consciously “loosen” cohesion
The final key tension in the transition is the balance between central cohesion and local flexibility. Modern models are increasingly using federated governance – an approach that clearly distinguishes which decisions and processes should remain central and which can be consciously communicated closer to the business.
The central ones usually remain:
- Safety and compliance standards,
- Data and integration architecture,
- A selection of strategic platforms and technologies.
On-premises (on the product teams and business unit side):
- Decisions on the priorities of the development of a given product,
- Detailed organization of the team’s work,
- Testing and deploying smaller, iterative changes.
In practice, this means a conscious, controlled “degradation of cohesion”: the organization accepts that not everything will be identical across all units if it delivers value faster and better responds to local needs. It is crucial that this decision is deliberate and conscious, and not resulting from chaos.
Summary and next steps
Organizational transformation of IT – from a central, waterfall department to an agile business partner – is primarily about change, responsibility, cooperation with business and ways of acting, in this order. Only the combination of these dimensions allows us to build a model in which IT really supports the organization’s strategy, and not just delivers projects.
- The current model copes worse and worse with the dynamics of the environment,
- IT needs to change its operating model to continuously build value,
- Change requires cooperation with business and time for stabilization,
- It is necessary to consciously balance between central and local management.
A well-designed process – with a reliable diagnosis, a clearly described target model, pilots, a stabilization period and a simple set of KPIs – significantly increases the chances that the transformation will not end with slides, but will actually change the way the organization operates.
Sources:
- McKinsey & Company – The big product and platform transformation
- McKinsey & Company – A new operating model for a new world
- VTI – IT Operating Model: Essential Guide for CIOs & IT Leader
100+
Satisfied Clients
1k+
Completed Projects
Would you like to assess how ready your IT organization is for this transformation?
Contact us for an initial assessment of your IT operating model and portfolio of initiatives.
