Adding an architect to a queueing value stream
A retail bank is reviewing its idea-to-funding value stream. A project proposal takes an average of 38 days from submission to funding decision. The flow includes nine handoffs and four committees; enterprise architecture review is mandatory for 70 percent of proposals, and the same chief architect reviews every one. Projects are approved without a check on delivery capacity, and the portfolio currently runs at about 130 percent of available engineering capacity. The PMO's improvement proposal is to add a second architect to halve the architecture review time. A value-stream map shows that 60 percent of proposals wait in a queue before architecture review, while most architecture reviews take under two hours. Business units have started bypassing the process by labelling work as 'continuous improvement'. The CIO wants faster funding but is worried about losing control and audit evidence.
1. Using value stream and process thinking, assess the PMO's proposal to add a second architect.
Read the worked answer
The proposal attacks a step, not the flow. The map shows that most architecture reviews take under two hours, while 60 percent of proposals wait in a queue before review and total lead time is 38 days. Flow efficiency is therefore very low: value-adding review time is a tiny fraction of elapsed time. Adding a second architect may reduce queue time if architecture is the true capacity constraint, but the evidence points first to batch size, handoffs, decision rights and demand segmentation.
A better diagnosis asks why 70 percent of proposals need the same architect, why work arrives in batches that create queues, and whether low-risk proposals could use a pre-approved pattern or delegated decision. If the chief architect is reviewing work that could be standardised, a second architect simply doubles the over-processing. If all proposals must queue for four committees, the constraint may be decision latency rather than review capacity.
The PMO should measure waiting time, touch time, rework and handoffs before and after any change. Adding capacity is not wrong in principle, but it should be the last experiment after reducing unnecessary demand and batch size. Otherwise the bank pays for more capacity while preserving the system that creates the queue.
2. Identify waste and failure demand in this value stream, and explain how bypassing the process as 'continuous improvement' affects risk and data.
Read the worked answer
The visible waste includes waiting in queues, excess handoffs, over-processing from mandatory architecture review applied to 70 percent of proposals regardless of risk, batch approvals and rework when proposals arrive without capacity checks. There is also failure demand: if proposals are incomplete or criteria are unclear, they return for more information, consuming review capacity and increasing lead time. Approving work at 130 percent of engineering capacity creates a further queue downstream that the funding process does not see.
Labelling work as 'continuous improvement' to bypass funding is a serious information problem. Some of that work may genuinely be small continual improvement; some is likely disguised project demand. Bypassing creates a shadow portfolio: no consistent risk assessment, no capacity visibility, no audit trail and no clear benefit case. It also distorts the data used to manage the value stream, because demand and lead time disappear from the official system. The bank then makes portfolio decisions on incomplete information.
The response should not be simply to close the bypass. The bank needs proportionate paths: clear criteria for continuous improvement versus project work, a lightweight route for low-risk change, and visible capacity accounting for all demand. This preserves control through transparent rules rather than forcing every item through the same queue.
3. Recommend a redesigned value stream with controls that satisfy the CIO's audit concern.
Read the worked answer
Redesign around risk-tiered flow and visible capacity. First, segment demand: small continual improvement, low-risk standard change, and projects requiring funding. Define objective entry criteria so labelling is not a choice made to avoid scrutiny. Second, create tiered decision rights: delegated funding thresholds, pre-approved architecture patterns, and a design authority that reviews exceptions rather than every proposal. Third, introduce a capacity check before funding, with work-in-progress limits and a portfolio Kanban so approved work matches engineering capacity. Fourth, reduce handoffs and batch size: one intake, one decision forum with named delegates, and parallel rather than sequential checks where possible. Fifth, set flow measures: lead time, queue time, flow efficiency, percentage of proposals returned for rework, and capacity utilisation.
Audit control should come from transparent criteria, decision records and exception handling, not from queueing everything. Each decision should record who decided, against which criteria, with what evidence and what risk acceptance. Delegated decisions remain auditable if the rules and records are consistent. Architecture review by exception needs a published pattern catalogue and periodic sampling.
The CIO should also separate governance from committee count. Four committees are not inherently more controlled than one accountable forum with clear thresholds and escalation. The test is whether the bank can show end-to-end traceability from proposal to funding decision and whether capacity promises are kept.