The public-health immunization registry ART pours budget into a non-bottleneck team’s new IDE while the real constraint—state immunization-information-system reviewers—idles waiting on a monthly slot. What should the RTE apply first?
Select an answer to reveal the explanation.
Short Explanation
Polishing the waiting-room chairs does not speed a clinic if the only nurse is booked once a month. Put the energy on the constraint. Fancy IDEs on a team that is not the bottleneck just fill the lobby faster.
Full Explanation
Focus first on the actual constraint—the idle state immunization-information-system review capacity—not on local tooling wins for a non-bottleneck team. Systems and constraint thinking say efficiency at a non-constraint does not raise ART throughput; it only fills the lobby faster in front of the monthly review slot. Keeping investment in non-bottleneck IDEs because local efficiency "always" lifts flow is a local-optimization fallacy. Ignoring idle interface reviewers while starting more registry screens increases WIP feeding the same gate. Measuring only how many registry stories unconstrained teams start celebrates push and hides the review queue that blocks public-health data exchange. Exam caveat: tooling can matter after the constraint is addressed, or if the map later shows construction as the bottleneck; sequencing still starts at the constraint. Operational check: time how long completed registry work waits for IIS review, pilot more frequent or parallel review capacity with state partners, and only then revisit non-bottleneck tooling ROI. Frame the choice as protecting immunization-record flow for clinics and residents, not as denying developers nicer editors. In municipal and civic service contexts, record the rationale in the ART working agreements or improvement backlog so future PIs preserve the control, and re-validate the same measure or policy after the next Inspect and Adapt against resident-facing outcomes rather than activity theater.