IT as a business partner

The number of resolved tickets, completed projects and delivered features helps monitor IT work. It does not tell us whether that work improves the business.

We can finish a project on time and within budget without achieving the intended outcome. We can also deploy a system that employees do not want to use because it does not solve their problems.

The ITIL 4 principle Focus on Value highlights value for the service recipient. Lean also starts with understanding value from the customer’s perspective.

Instead of opening the conversation with “What solution should we implement?”, I suggest asking “What problem are we trying to solve, and how will we know we have succeeded?”.

If sales requests a new reporting tool, first establish why it is needed. Does the process work? Can the current data be trusted? How long does reporting take, and which decisions will the reports support?

Rather than a new system, the answer may be better integration between existing solutions, improved performance of the current system or automation of one process step. It may also require resolving inconsistent data and agreeing on a single source of information.

Many organisations already work this way, but I still encounter those that judge IT mainly by completed tasks and deployed systems. They pay less attention to the effect on business results. IT remains a cost, although it could help build competitive advantage.

What would I change? For each substantial initiative, agree the intended outcome, a business owner and how to assess the results. Choose measures that fit the problem: employees’ time, costs, revenue, risk or customer experience. Establish a baseline first; do not present estimates as achieved results.

IT becomes a partner when it can explain what has changed in the company because of its work. Other parts of the organisation must also be prepared for that conversation.

Waiting to start work can be the constraint. A task passes through an analyst, architect, security team, project manager and successive approvers. Each considers one part, while responsibility for the whole becomes dispersed. Elsewhere, IT has a ready backlog but is waiting for the business to decide its priorities.

Security, risk and compliance controls are necessary. The problem arises when every decision follows a similarly elaborate approval route, regardless of its significance.

I would examine who should make each decision. For repeatable, low-risk changes, the procedure and its conditions of use can be agreed and authorised in advance. Decisions with substantial business, cost or security implications still need appropriate scrutiny.

PeopleCert describes ITIL 4 Change Enablement as supporting controlled changes, risk reduction and business continuity. Specific decision rights and approval routes must be established for the organisation.

Identify a decision owner, who needs to be consulted and who needs to be informed. Several people sharing responsibility without authority to resolve the issue is a recipe for another queue.

What would I change? Select a few common IT processes and measure working time and waiting for decisions. Remove unnecessary stages and place decision authority as close as practical to those delivering the work, while retaining risk controls and a record of decisions.

In a hypothetical situation where a task takes two hours but approval takes two weeks, I would start looking for improvements in the decision process.

A traditional IT structure reflects technologies or specialisms: infrastructure, networks, applications, databases, security, support and software development. This helps build expertise, manage standards and maintain service quality.

Difficulties arise when one business goal depends on teams with different priorities. Improving order handling may require changes to a sales application, integrations, a database and infrastructure. A small change becomes an organisational undertaking.

One option is to organise some work around products, business capabilities or value streams. A cross-functional team looks after an area such as customer service or billing. IT specialists and business representatives work together, with responsibility for development, maintenance and assessment of outcomes.

Specialist teams do not have to disappear. I often find a hybrid model practical: product teams draw on central expertise and shared platforms. McKinsey’s analysis of 28 February 2020 describes this division and the option for platform experts to join product teams temporarily.

Do two processes needing a network engineer or developer mean two hires? No. If two teams need a Python developer periodically, they can share a specialist, provided priorities and availability are agreed. Dedicated assignment makes more sense when the skill is needed in daily work and waiting for it delays the goal.

Several teams participating in a process does not, by itself, justify restructuring. Compare demand for skills and team costs with the costs of waiting and coordination. Consider how a specialist’s availability affects other people’s work, as well as their individual utilisation.

What would I change? Choose an important process, identify the teams involved in its development and maintenance, and locate delays. Agree a shared goal, priorities and accountability. Then assess whether a permanent cross-functional team is needed or whether better coordination between existing teams is sufficient.

Waste in IT can be difficult to see. It is not limited to unused infrastructure or unnecessary licences. It can include meetings that repeat information in the ticketing system, several versions of the same report, constant task switching or repeated incident handovers.

Starting many initiatives at once can also lengthen queues. A heavier workload does not necessarily mean more completed work.

Value Stream Mapping can help. We examine the entire flow of work and information needed to deliver an outcome, then design improvements. In IT, this might cover the journey from a stated need to using the solution in a business process.

Both working time and the gaps between activities matter. A request waits for clarified requirements, a proposed solution for approval, and a developer for environment access or data from another team. A new system version cannot be deployed because key users have not finished testing and accepting the changes.

We also wait for a supplier’s response, a deployment window or the next team to pick up the task. The task remains open even though nobody is currently working on it.

In a hypothetical example, preparing a change takes one day, testing another, and deployment a few hours. The whole process takes a month because the task spends most of its time in a queue. When mapping it, I would identify which waits are justified by risk controls or operational needs, which can be shortened and which can be removed.

What would I change? Examine one process that causes delays. Mark waiting stages, unnecessary handovers and repeated activities. Agree a limit on concurrent tasks so that teams can finish work already started.

Rather than asking people how they could work faster, I would ask what prevents them from working effectively.

Successive projects introduce new applications and tools. Some emerge outside agreed IT oversight: this is known as shadow IT. After years of growth, a company may have systems with overlapping functions, numerous communication channels and separate knowledge repositories.

This variety is not always driven by business needs. It can result from historical decisions and local preferences, increasing maintenance costs, integration requirements and complexity.

Before buying another tool, check whether an existing solution can achieve the same goal. ITIL 4’s Start Where You Are principle encourages assessing existing resources before choosing changes.

I do not favour automating everything that technology makes possible. Automating a poorly designed process can accelerate errors and entrench inefficient working practices. First put the process in order, then assess automation.

Candidates include repeatable, predictable activities: creating accounts, granting standard access, preparing environments, routine changes and reporting. Automation should retain required approvals and oversight.

AI can be considered for ticket analysis, knowledge retrieval, diagnostics or documentation. Assess its usefulness on selected tasks: output quality, errors, verification time and data access rules can determine the benefit.

Walmart’s own material describes a common technology foundation that allows for local differences. This illustrates a direction for simplification, rather than proving that an identical solution will suit every business unit.

What would I change? Review tools: who uses them, for what purpose, and where do functions overlap? Assess consolidation or retirement of unnecessary solutions. In parallel, prepare a spreadsheet of automation candidates: process owner, prerequisites, frequency, complexity, estimated implementation and maintenance costs, and expected benefits. Record assumptions and compare them with the eventual result.

The AI implementation ROI calculator can support a financial assessment. An estimated return does not replace an assessment of quality and risk.

When a finished application only reaches security or architecture specialists at the end, their findings may require rework, repeat testing or a different design. That creates a risk of delays and additional costs.

Security, architecture and data management requirements should be considered during design. Specialists need to work together, with shared standards and reusable components that meet agreed requirements.

This is consistent with DevSecOps: integrating security into software development and operations. NIST describes incorporating security from the earliest lifecycle stages.

In an interview published by CIO, Jeremy Koppen, identified as Equifax’s CISO, discusses security supporting the pace of development. According to his account, teams supported the secure introduction of more than 180 product innovations in 2025. This is a company representative’s statement, rather than an independent measurement of the operating model’s contribution to that outcome.

I would not assess a security team solely by the number of issues found, or architects solely by their enforcement of standards. Their role also includes helping achieve business goals within an agreed level of risk.

What would I change? Involve these skills in planning important initiatives. Define solution patterns, automate checks where appropriate and agree how exceptions will be assessed. Identifying requirements and risks earlier can reduce rework near the end of a project.

For me, this is the most important change because it concerns how both sides see their roles.

In many companies, the relationship resembles that of customer and supplier. The business prepares requirements; IT estimates, plans and delivers. After deployment, responsibility for using the solution returns to the business unit. That model may suffice for simple services, but limits the joint search for improvements.

I have also encountered several organisations where responsibility for the business’s use of ERP was transferred entirely to IT. IT organised role-specific training and tested changes, while users and their managers did not feel responsible for the tools they used.

Training and support are necessary, but do not replace process owners’ accountability. IT can help implement a solution and prepare users. The business should identify problems and needs, participate in acceptance, and ensure the system is used in daily work. Partnership requires both sides to contribute.

IT should be involved before a specific solution is chosen. If customer service wants to recruit more people because ticket volumes are rising, examine the causes together. Perhaps the problem is missing integrations, an unclear interface or manual data entry. This is an example of a possible diagnosis, not an argument against hiring.

Tungsten Automation provides an example of an operating model change. According to CIO’s interview with Shelley Seewald, published on 4 May 2026, delivery teams were aligned with business areas such as sales, marketing, customer support and finance. This describes an approach; I do not cite measured benefits from that restructuring.

A supplier focuses on fulfilling an order. A partner understands the problem, explores solutions jointly, helps set priorities and shares responsibility for the outcome. The business should also be a partner to IT: explain the goal, identify a process owner and make people available for decisions, testing and adopting the change in daily work.

At the start of an initiative, agree each side’s responsibilities and how benefits will be assessed. Technical acceptance does not end the collaboration. Check adoption and the outcome. A hypothetical target might be to reduce average ticket handling time in customer service by 10% against an agreed baseline, while maintaining service quality. This is an example target, not my result or a forecast.

If a new requirement is urgent, the business must help choose priorities and accept which tasks will be deferred.

What would I change? Establish regular conversations between IT and business leaders about goals, problems, costs, risks and opportunities. Go beyond project status updates. Ensure IT staff understand the processes they support and business colleagues participate in decisions and assessment of outcomes.

Changing a job title or creating a team does not build partnership on its own. Partnership develops when the business sees IT as a participant in decision-making and IT understands business goals and constraints. Both sides set priorities together and share responsibility for outcomes.

I do not believe effective transformation has to start with major restructuring, additional hires or another platform.

It is often better to start with a few small, considered changes. These seven proposals can provide a starting point for organisations of different sizes and structures. Choose one or two that address their actual problems.

I suggest starting with one process: examine the flow of work, clarify accountability, simplify decisions and agree shared measures. Check the outcome before extending the approach. This reflects ITIL 4’s Progress Iteratively with Feedback principle: improving gradually through feedback.

Above all, I want readers to leave with the conviction that IT and the business can work differently, and that a first step is possible in their own organisation. Preserve the expertise, security standards and service stability that already work well.

The table sets out directions for improvement and intended benefits, not measured results or guaranteed gains. Measures must be adapted to the selected process.

Sources and nature of this article

These are my recommendations, based on experience, observations and the material below. Numerical examples are hypothetical; other companies’ accounts are attributed and do not promise similar outcomes. References to ITIL 4 principles do not present ITIL 4 as the latest version of ITIL.

PeopleCert: ITIL 4 Guiding Principles — Roadshow 2024 material, slide labelled 16, listing the seven principles.

PeopleCert: Create, Deliver and Support and Change Enablement — public descriptions of their scope, rather than full manuals.

Lean Enterprise Institute: What is Lean? and Value Stream Mapping — value, flow and mapping current and future states.

McKinsey: Products and platforms, 28 February 2020 — a product-and-platform operating model. I do not use the survey statistics as current market data.

NIST/NCCoE: DevSecOps Practices — Introduction — a live document, September 2026 release, discussing security in the software lifecycle.

CIO: 7 ways to restructure IT for maximum productivity, John Edwards, 22 September 2026 — inspiration and Jeremy Koppen’s statement.

CIO: CIOs rethink IT’s operating model, Mary K. Pratt, 4 May 2026 — Shelley Seewald’s account of Tungsten Automation.

Walmart Global Tech: A Conversation with John Furner and Suresh Kumar, 24 April 2026 — text about a common technology foundation and local differences.

About the author

Rafał Mokrowiecki. I have more than 20 years of IT experience, from ERP programming to serving as an IT director. I am now an independent IT adviser. See my experience and scope of responsibility.

Which process makes collaboration between the business and IT most difficult? Tell me where delays occur and who is involved in decisions. This provides a starting point for discussing the scope of support for businesses.