Project Bottlenecks: Find the Queue Holding Up the Work

A late task is a clue, not a diagnosis

A project plan might show that technical approval is late. That tells you where the date slipped, not why. The packet may lack a drawing, a ready packet may be waiting for the only qualified reviewer, or the review may be finished while the decision waits for a meeting.

A critical path identifies dependencies that determine the planned project duration. A queue bottleneck identifies a limiting resource or rule in the flow of work. They can interact, but are not interchangeable. A specialist shared across projects may create waiting that a separate plan for each project hides.

Follow one approval workflow first. Use the portfolio guide when deciding which projects to start; use bottleneck analysis for the broader capacity logic.

Collect arrival, readiness, work and decision separately

In this fictional example, times are hours from the beginning of the same working week. The clock advances only during declared working hours, excluding weekends and breaks. Two packets use the same approval route. No time zone or calendar conversion is involved.

Can the shared reviewer keep up?

Suppose ten ready packets arrive each week. Each needs two hours of qualified review, but the specialist has only 12 hours available after other duties. Demand is 20 review hours and capacity is six packets per week. Under these stable assumptions, the ready backlog grows by about four packets per week.

Check the measured distribution, not just this average. Rework, varying packet complexity and interruptions can make the queue worse. If the reviewer often has no ready packets, the limiting problem may be upstream readiness rather than the nominal six-packet capacity.

Limit release without hiding the waiting

A team might trial a limit of two ready packets released to this review queue at once, with a visible upstream waiting list. Two is a starting experiment, not a universal rule. Publish the complete waiting list, its age and priority so an attractive local board cannot hide delayed projects.

A limit does not turn six packets of capacity into ten. The team must also reduce avoidable review demand, improve the handoff, change commitments or add genuinely qualified capacity. Never bypass a required safety or quality approval to make a queue look shorter.

1. Agree readiness

   Define the drawing, evidence and decision required before a packet enters review.

2. Set a short trial

   Name the owner, release limit, upstream visibility and urgent-work rule.

3. Record every return

   Keep correction work linked to the original packet, with time and reason.

4. Review the whole route

   Compare accepted decisions, total elapsed time, oldest open packet and quality before keeping the rule.

Check whether the bottleneck moved or the work improved

Observe several comparable cycles. If review is faster but packets now wait longer for the decision meeting, the constraint may have moved. If fewer packets arrive because teams stopped logging difficult work, the apparent improvement is a reporting problem.

A useful result has more accepted decisions or shorter complete journeys without unacceptable rework, missed commitments or overload elsewhere. Keep capacity and priority decisions visible to the people making project promises.

When the cause remains disputed, use an A3 investigation to connect the symptom, evidence, proposed change and follow-up. The point is a decision people can test, not another color on the project status slide.

A 5C label needs an author and a purpose

There is no single 5Cs definition for every project-management task. A concrete example is Gupta and Rao’s 2007 PMI conference paper about knowledge use in Infosys projects. Its five areas are a compulsory mindset shift, creation of reusable repositories, a clear knowledge-management organization, consistent communication and career-driven knowledge management. That case-specific model is not a five-stage project lifecycle.

When a review stalls, check whether the next person has the information, authority and time to act. If a past lesson applies, make it available at that handoff. A team still needs to check the dependency even when it follows a named management method.