ITIL 4 Problem Mgmt study materials
ITIL 4 Problem Mgmt study resources

Who Owns a Cross-Product Onboarding Failure?

ITIL 4 Problem Mgmt · Put your knowledge to work in context.

All case studies

Who Owns a Cross-Product Onboarding Failure?

A financial services firm has adopted product teams. Each product team owns a service and its incidents, but there is no dedicated problem management role. A new problem manager is appointed into the service management office. A high-impact problem affects the mobile app, the identity platform, and a third-party SMS provider: customers cannot complete onboarding about 1 in 5 attempts. Each product team says its metrics are within threshold. The SMS provider says its delivery rate is normal. The mobile team says the identity platform times out. The identity team says the mobile app retries too aggressively. The problem manager has no line authority over any team. The incident is being worked around by asking customers to retry after 10 minutes, which works about half the time. The executive sponsor wants a single accountable owner and a date.

1. Define the problem owner, problem manager, and technical resolver accountabilities in this situation. Who should be accountable for the end-to-end problem and why?

Read the worked answer

The problem manager owns the problem management practice: the record, method, cadence, evidence quality, and escalation. The problem owner is accountable for end-to-end resolution and benefits, and must have authority across the services involved. Technical resolver groups are responsible for investigation and actions in their domain. In this case, the accountable problem owner should be the service owner for customer onboarding, not the mobile, identity, or SMS team alone, because the outcome crosses all three. The problem manager supports that owner and should not be forced to be the technical decision-maker. Publish a RACI: one accountable owner, named technical leads, one problem record, and one decision log. This removes the 'my metrics are fine' loop without creating a new hierarchy.

2. Design a lightweight governance mechanism to break the deadlock without creating a new bureaucracy.

Read the worked answer

Use one problem record and one cross-functional bridge with fixed membership: mobile, identity, SMS provider, service desk, and the problem manager. Set a 30-minute daily stand-up, a shared timeline with synchronized timestamps, and a decision log. Agree three joint measures: onboarding success rate, retry success rate, and time to complete onboarding. Run time-boxed experiments rather than open debate: for example, reduce mobile retry aggressiveness for a small cohort while capturing identity timeout data. Escalate unresolved decisions to the sponsor within 48 hours. Keep the workaround visible and improve it, but do not count it as resolution. This is lightweight governance: one forum, one record, clear decisions, and a short escalation path.

3. The sponsor asks for a fixed date. What should the problem manager say?

Read the worked answer

Say that a fixed resolution date would be a guess until the cause is narrowed, and a guess would damage credibility. Offer milestone dates instead: by day 3, a shared timeline; by day 7, a tested hypothesis; by day 10, a decision on permanent fix or further investigation. Explain the dependencies: the SMS provider's data access and the identity team's test window. Commit to a communication cadence and an interim workaround target, such as improving retry guidance. If the sponsor needs a date for planning, give a range with the assumptions stated. This is not refusing accountability; it is making uncertainty explicit and giving the sponsor decision points.