Dependency Mapping for Bank Integration Workstreams

Dependency Mapping Across Integration Streams

Up to 60% of merger value initiatives rely on IT. Dependency mapping across integration streams shows which late handover will stop the rest.

Alexander Kiel

Business Analyst · Banking & Wealth Management

04.09.2025 · 8 MIN READ · BUSINESS INTEGRATION

ON THIS PAGE

1. List What Each Stream Needs

2. Classify Every Dependency

3. Build One Dependency Matrix

4. Name an Owner for Each Handover

5. Map External Dependencies Too

6. Track the Critical Path Weekly

Sample case: Heathrow Terminal 5

In short

FAQ

Integration streams fail at their joins. McKinsey found that 50 to 60 percent of the initiatives behind a merger's cost and revenue goals are strongly related to IT. So almost every business stream waits on a system, a data extract or a test environment from another stream.

Delays at those joins are expensive. A study of 1,471 IT projects by Flyvbjerg and Budzier found that one in six went badly wrong. Those projects had an average cost overrun of 200% and a schedule overrun of almost 70%. The National Audit Office names managing interdependencies as one of four areas behind problems in major programmes.

Dependency mapping makes the joins visible before they break. Which stream in your integration is waiting on another right now?

Illustrative dependency matrix for a bank merger: six integration streams in rows and columns, marked cells for deliveries between streams and one loop between IT and data and operations highlighted

STEP 1

List What Each Stream Needs

Start by asking every workstream lead two questions. What do you need from other streams and by when? What do other streams need from you? Record each answer as a give-get pair: one stream delivers, another receives. Typical items are product mappings, client data extracts, test environments, legal entity decisions and trained staff. Ask both sides, because each stream sees only half of the link.

The gaps between streams cause the delays. The NAO found instances where one element of the programme being late prevents the entire programme from achieving its objectives. Banks already map in a similar way for operational resilience. The PRA asks firms to identify and document the people, processes, technology, facilities and information behind each important business service. The same five categories make a good checklist for integration handovers.

✓

Ask every stream what it needs and what it delivers

✓

Record each link as a give-get pair with a date

✓

Check each pair with both streams involved

Which workstream in your integration depends on the most deliveries from others?

Keep in mind: Streams rarely list what others need from them. Ask the receiving side as well, or half the dependencies stay hidden.

STEP 2

Classify Every Dependency

Not every dependency carries the same risk. Mark each one by type and by link. A hard dependency cannot be changed: client data must be migrated before clients can be served on the new platform. A soft dependency reflects a preference and can be reordered when time runs short. Also note whether the deliverer sits inside the integration or outside it.

PMI describes three categories. Mandatory dependencies are a physical relationship between elements of work. Discretionary ones are usually based upon experience or a best practice approach. External dependencies rely on work the project manager does not control. The same article warns that overusing finish-to-start links extends the schedule.

✓

Mark each dependency as hard or soft

✓

Note whether the deliverer is inside or outside the integration

✓

Question every finish-to-start link that could overlap

How many of your integration dependencies are truly hard rather than habit?

Keep in mind: Soft dependencies are the room to manoeuvre when the plan slips. Know which ones they are before you need them.

STEP 3

Build One Dependency Matrix

Next, put all streams into one dependency matrix. List the streams down the rows and across the columns in the same order. Each cell shows what the row stream delivers to the column stream and when. Clusters show streams that must plan together. Marks that point backwards in time show loops, where two streams wait for each other.

The method is known as the design structure matrix. A DSM is a square matrix that shows relationships between elements in a system. In a task matrix ordered by time, marks below the diagonal depict information fed back to earlier listed tasks. Those marks are the loops to resolve first, because neither stream can finish alone. One page then shows the whole integration.

✓

Use the same stream order for rows and columns

✓

Enter the deliverable and due date in each cell

✓

Resolve every loop between two streams first

Could your integration office show every stream-to-stream dependency on a single page?

Keep in mind: A matrix with every cell filled is unreadable. Record only deliverables that block work, not every meeting or update.

STEP 4

Name an Owner for Each Handover

Every dependency needs two names: the person who delivers and the person who accepts. Agree the deliverable, the quality criteria and the date in writing. When a date moves, the delivering owner tells the receiving owner first, then the integration office. The receiving side then states the impact on its own plan. In the integrations I have worked on, most dependency problems sat between the business and IT streams, not within IT.

Unclear ownership is a known cause of failure. The NAO found that it is unclear who is accountable for integrating the various elements of a programme. It adds: Encouraging collaboration is not enough: someone with sufficient authority needs to specify its end goal. Its advice is that bodies should clearly define who is responsible for integration. My article on how to build the integration team shows who that is in a bank merger.

✓

Name a delivering and an accepting owner for each link

✓

Agree content, quality and date in writing

✓

Let the integration office own the cross-stream view

Who in your integration decides when two streams disagree on a handover date?

Keep in mind: A dependency owned by a team rather than a person usually has no owner at all.

STEP 5

Map External Dependencies Too

Many critical dependencies sit outside the integration: core banking vendors, custodians, payment schemes, data providers and supervisors. Map them with the same give-get logic. Add contract terms such as notice periods and change windows, because they set the earliest possible date. Ask each provider to confirm its dates in writing.

Banks already hold part of this information. The PRA expects firms to understand how their outsourcing and third party dependencies support important business services. Under DORA, EU financial entities must keep a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers. My article on the operational readiness check shows how to confirm third-party readiness before each wave.

✓

Start from the bank's outsourcing and DORA registers

✓

Record notice periods and change windows for each provider

✓

Get written date confirmations from every key provider

Which external provider could delay your integration without anyone inside noticing?

Keep in mind: External providers plan their own change calendars. A slot booked late can push a migration wave back by months.

STEP 6

Track the Critical Path Weekly

Finally, link the dependencies into one integrated plan and find the critical path. Review it every week with the workstream leads. Check which handovers are due, which are late and which have lost float. Escalate a late critical item to the steering committee within days, not at the next monthly meeting. Record the decision taken.

PMI defines the critical path as the longest (time) sequence of activities in a project plan. The rule follows: if any activity on the CP is delayed, the project end time will be delayed. The NAO adds that sponsors should assure themselves that a programme's critical path identifies all the contributing activities. My article on the decision log shows how to keep escalations traceable.

✓

Review the critical path with all stream leads every week

✓

Track float on every dependency near the critical path

✓

Escalate late critical items within days

When did your steering committee last see the critical path across all integration streams?

Keep in mind: The critical path moves as work progresses. A path checked once at planning time is out of date within weeks.

Simplifying Complexity | Eric Berlow (Founder @ Vibrant Data Labs)

SAMPLE CASE

Heathrow Terminal 5

Heathrow Terminal 5 opened on 27 March 2008 after six years of construction costing £4.3bn, on time and within budget. On the first day, 36,584 passengers were hit by problems with baggage, car parking, security searches and the building. British Airways said 23,205 bags required manual sorting.

The building was finished, but the streams around it were not ready together. The Transport Committee traced most problems to insufficient communication between owner and operator and to poor staff training and system testing. Trials had put 400,000 bags through the system before opening. Yet a staff representative told MPs that for baggage in particular it was still a building site. BA admitted: we should not have absorbed the continuing building delays.

In its lessons learned, BAA listed a joint BA/BAA crisis management team and a direct link between the two baggage teams with early warning indicators. The Committee concluded that several of these inherent risks combined with one another.

Key takeaway: Each part of Terminal 5 was delivered, but the dependencies between building, systems, staff and two organisations were not managed as one plan. A bank integration has the same joins between workstreams, vendors and business teams.

"It is that togetherness that allows you to cope with the issues that arise on the day."

Colin Matthews (Chief Executive @ BAA)

In Short

Dependency mapping across integration streams rests on six moves: list what each stream needs, classify every dependency, build one matrix, name owners on both sides, map external providers and track the critical path weekly.

The result is a plan in which every stream knows what it is waiting for and who is waiting for it.

Frequently Asked Questions

What is dependency mapping?

Dependency mapping is the practice of recording which tasks, deliverables or teams rely on others before they can start or finish. In an integration it shows what each workstream must receive from other streams and external providers, by when and from whom. The result is often a dependency matrix or network that feeds the integrated plan and the critical path.

What is a dependency matrix?

A dependency matrix lists the same items, such as workstreams or tasks, along both its rows and its columns. Each filled cell shows that one item delivers something the other needs. Reading along a row shows what an item gives, while reading down a column shows what it receives. Clusters and loops in the matrix show which teams must plan together.

What are the types of project dependencies?

Project managers usually distinguish mandatory, discretionary and external dependencies. Mandatory ones follow from the nature of the work, such as migrating data before using it. Discretionary ones reflect preferred practice and can be changed when time is short. External ones rely on parties outside the project, such as vendors or supervisors. Each also has a link type, most often finish-to-start.