Building a digital transformation team: which capabilities come first?

Before building a digital transformation team, identify the business decisions the programme needs to make. Which process will change? Who owns the outcome? What must be understood before delivery can begin?

For employers in Ireland planning technology, data or AI programmes, this creates a more useful workforce brief than a list of technical roles. It connects the people required to the work they will enable.

There is no single team sequence for every transformation. The approach below is a planning framework: establish ownership, understand the delivery dependencies and add capability against a clear roadmap.

Give the programme a business owner

Start by naming the person who can explain the intended business outcome and make decisions about priorities. Agree how that person will work with technology leadership and whoever manages delivery.

Write the outcome in operational terms. Examples of planning questions include how users should complete a task, which information a team needs to make a decision, or what a service must support at launch. These are questions to resolve, not promised benefits.

Before scaling the team, agree:

• Who owns the outcome and who controls programme priorities.
• Which measures will be used to judge whether the change is useful.
• Who can make decisions about scope, budget and delivery trade-offs.
• Which functions need to participate in design and approval.
• Who will own the service after the programme ends.

An existing leader may already provide this capability. Identify the gap before assuming that a new leadership role is required.

Establish the foundations for delivery

Assess what the programme needs to know about processes, users, systems and data before expanding delivery capacity. Depending on the work, this may involve business analysis, architecture, data engineering or input from operational teams.

Ask for specific outputs from this early work. These might include a prioritised backlog, a system dependency map, an assessment of available data or agreed requirements for an initial release.

Use the outputs to decide which specialists are needed next. For example, if the first release depends on an unresolved integration, record who will investigate it and how the finding will affect the delivery plan.

Keep assumptions visible. A team brief should distinguish between confirmed requirements and choices that still need to be tested.

Involve security and operations in the planning

Give security, infrastructure and service operations a defined opportunity to shape requirements before delivery decisions are fixed. Their involvement need not mean appointing a large dedicated team immediately.

Instead, agree the decisions they need to inform: system access, environments, deployment arrangements, monitoring, support and incident ownership. Record when their input is required and how it will be obtained.

This is a planning recommendation, not a prescribed delivery sequence. The right level of involvement depends on the systems, risks and internal capabilities of the organisation.

Resource AI governance as part of the work

Where AI is involved, include responsibility for its evaluation and use in the workforce discussion. The NIST AI Risk Management Framework identifies documented responsibilities and communication lines as part of its GOVERN function. It also addresses testing before deployment and assessment during operation under MEASURE.

NIST’s framework is voluntary guidance; it is not a statement of Irish legal compliance. Its value here is as a reference for asking who will carry out these activities and how they will be resourced.

Include business, technical and operational input when deciding how an AI-enabled service will be assessed. Do not assume that adding an AI specialist automatically assigns ownership of every related decision.

Build a capability plan for each milestone

Translate the roadmap into a short workforce plan. For each milestone, identify the output, capabilities needed, available internal capacity and any external support required.

Useful fields include the accountable owner, specialist contribution, start dependency, expected duration and handover recipient. Review these alongside the delivery plan rather than maintaining an unrelated list of open roles.

Consider how the engagement should work. An individual specialist may be appropriate for a defined gap within an established team. A sustained team requirement calls for a discussion about continuity and coordination. A proposed managed service needs explicit scope and acceptance arrangements.

Make the decision against the work being commissioned. Avoid assuming that every capability must be provided through the same model.

A published example: Laya Healthcare

Berkley’s Laya Healthcare case study describes workforce support across AI leadership, digital delivery, infrastructure and security. It records a phased approach, including a Head of AI, specialist delivery roles and infrastructure leadership.

That is an example of one programme’s workforce structure. It should not be read as a requirement to delay security input until a final phase, or as a universal template for other organisations.

Use the example to ask a more useful question: which capabilities does your roadmap require, and at what point do they need to influence decisions?

Plan the transition into ongoing operation

Before a programme team reduces, establish who will own the service, knowledge and remaining work. Agree the documentation, training and access the receiving team needs, along with any period of overlap.

Record ownership of unresolved items. Where specialist support will continue, explain the purpose and review date of that support. Where it will end, confirm that the handover recipient has accepted the agreed responsibilities.

These decisions belong in the workforce plan from the outset, even if the details become clearer as delivery progresses.

Discuss the capability behind your roadmap

Berkley’s Business & Technology practice supports specialist workforce requirements across technology and business functions.

Bring the intended outcome, current team and next delivery milestone to the conversation. Speak to Berkley about building the capability your transformation programme needs.