MetroRail: Fourteen Approvals for a Standard Workstation
MetroRail's IT organization has 22 fulfillment groups. A request for a standard analyst workstation passes through 14 approval gates; median end-to-end time is 19 days, of which 6.2 days is waiting for approvals. There are 900 open requests. Password resets are 38% of volume and software installs 22%. The service desk has no authority to approve anything, so every request is escalated. No single person is accountable for the end-to-end request process; the service desk manager, HR shared services, and security each claim part of it. New agents take 11 weeks to become productive and turnover is 24%. An audit found 140 requests approved by a manager who was not authorized to approve that access. The service desk uses 11 tools, and the catalog is a spreadsheet. The CIO wants a leaner value stream and one accountable owner within 90 days.
1. Map the current request value stream and identify waste, controls that add value, and handoffs. Propose a target-state design with clear decision rights for the standard workstation request.
Read the worked answer
Current flow: demand arrives by portal, email, phone, or walk-up → service desk classifies → 14 sequential approvals → fulfillment group picks up → user confirms or ticket is closed → reporting. The 6.2 days of approval wait is waiting waste; 22 groups create handoffs; 11 tools create motion and data re-entry; 900 open requests are inventory; the 140 unauthorized approvals are defects. Not every approval is waste: a finance check for a non-standard spend or a security check for privileged access can be a value-adding control. The test is whether the control changes a decision or only records it.
Target state: segment requests by risk and value. Standard workstations for entitled roles become pre-approved against a role matrix, with budget checked against a pool rather than per request. One approval remains only where a real decision exists, such as an exception above threshold. The service desk gets authority to fulfill and close low-risk standard requests. The process owner is accountable for end-to-end design, performance, and improvement; fulfillment groups own technical execution; HR owns starter data; security owns access policy.
Design the end-to-end target around the user outcome - a working workstation on day one - not around departmental queues. Publish a service level for the whole flow, not just each step. Before changing the tooling, remove duplicate approvals and define the authority matrix; automating a 14-step process only makes it faster to be wrong.
2. Design the roles and competencies needed for the target state. How should MetroRail address the 140 unauthorized approvals without treating the problem as purely a training issue?
Read the worked answer
Roles should be defined by decision rights, not job titles. The service request management process owner is accountable for the value stream, catalog, policies, and measurement. A process manager runs daily performance and improvement. Request approvers are named by authority matrix - for example, line managers for budget within a threshold, role owners for entitlements, and security for privileged access. Fulfillment teams own technical completion and knowledge articles. The service desk owns intake quality, triage, and low-risk fulfillment.
Competencies include catalog and service knowledge, decision-right literacy ('what may I approve?'), triage and diagnostic questioning, clear communication, data quality, risk awareness, and the ability to say no and route to the right authority. Approvers need specific training on the authority matrix; agents need practice with real cases and a safe escalation path.
The 140 unauthorized approvals are a control design failure. If the tool allows any manager to approve any access, training alone will not fix it. Embed the authority matrix in the workflow, validate approver eligibility, block self-approval, and require the role owner for access decisions. Review the 140 retrospectively, revoke inappropriate access, and report to risk or audit. Add sampling and exception reporting. Then train people on the corrected process - training after the control fix, not instead of it.
3. Propose a 90-day plan that establishes a single accountable owner and reduces new-agent time-to-proficiency. What milestones and evidence would show real progress?
Read the worked answer
Days 1–15: baseline and mandate. Confirm the CIO sponsor, publish the process owner role and decision rights, map the top 12 request types, and quantify approval wait and rework. Do not start with a tool purchase.
Days 16–30: establish governance. Create a request process board with service desk, fulfillment leads, HR, and security; agree the authority matrix and service-level definitions; freeze new catalog items until duplicates are removed.
Days 31–60: redesign and pilot. Pre-approve standard workstation requests, automate password resets, collapse the 14 approvals to exception-based checks, and create end-to-end knowledge articles. Pilot with one business unit and measure cycle time, first-time-right, and approval wait.
Days 61–90: scale and embed. Extend to the top request types, publish a single catalog view, and begin role-based training for approvers and agents.
For time-to-proficiency, replace shadowing-only onboarding with a structured pathway: week 1 service and catalog fundamentals; week 2 supervised triage; week 3–4 fulfillment practice in a sandbox; certification gates before independent handling; a buddy and a knowledge checklist. Measure time to independent handling, first-time-right during onboarding, and 30-day reopen rate. Progress evidence: approval wait down, end-to-end cycle time down, backlog aged, unauthorized approvals zero in sampling, and new agents productive in under eight weeks.