An active project limit matters when a team looks fully occupied but has little to show for its work. Consider this illustrative case. Several projects are open, employees move between them, and every new request becomes another priority. The owner sees activity, while customers wait for finished work.
An active project limit gives a team a clear rule for deciding when to start another commitment and when to finish or pause work already underway. It does not set a universal number of projects. It makes the trade-off visible, then gives the owner evidence to adjust the workload.
Separate the backlog from work in progress
A backlog is work the business may do later. Work in progress is work the team has started but has not finished. Keep those lists separate. If a customer has asked for a proposal but no one has begun it, the request belongs in the backlog. If someone is gathering data, waiting for approval, configuring a system, or reviewing a draft, that item is already in progress.
Write down when work counts as started and what “done” means. A project might count as active once a named person has committed time and taken the first delivery step. It might count as finished only when the client has reviewed the agreed deliverable and the team has closed any included corrections. Choose definitions that fit the work. Without them, a project can disappear from the active list simply because it is waiting.
Do not count every task as a separate project. Pick a useful unit, such as one client implementation, one improvement initiative, or one recurring service change. If units differ greatly, record the stage or size as well. A two-day analysis and a six-month system change should not look interchangeable in a simple count.
Use the queue to ask a better timing question
Operations research offers a useful relationship between average items in a system, the rate new work arrives, and how long each item stays there. John Little’s proof expresses it as L = λW under stated conditions. Here, L is the average number of items in the system, λ is the average arrival rate, and W is the average time in the system. The formula relates long-run averages. It does not predict when any individual project will finish.
For example, suppose a team averages twelve comparable projects in progress and completes four each month. Assume new projects enter at the same average rate that other projects finish, and both figures describe the same work and period. Under those assumptions, the equation gives an average flow time of about three months. This is an illustrative calculation, not a forecast for a real company. It does not prove that reducing the count will raise output. Demand, project mix, blocked work, staffing and rework can all change the result.
Still, the calculation points to a useful owner question. If customers need work finished sooner, should the team start less at once, remove a bottleneck, change the work mix, or add capacity? An active project limit makes that choice explicit instead of letting each person accept another task on top of existing promises.
Measure the current pattern before choosing a limit
Track one team or work type for a few weeks. Record four things: the number of active items, each item’s start date, its finish date, and time spent waiting. Note the main reason for a delay, such as missing customer information, a review queue, unavailable staff, or a decision held by the owner.
Look at completed work as well as open work. A long list can hide different problems. If items wait for approval, a staffing increase may not help. If one specialist is assigned to too many projects, the handoffs may be the constraint. If projects repeatedly return for corrections, the completion test or customer agreement may need attention.
Interruption research offers a reason to pay attention to constant switching, while keeping the evidence in proportion. One field study examined operators who indexed customer telephone-line records. Calls increased the time needed for the task in progress. A separate laboratory experiment found that time pressure affected performance and errors at the start of a second task. Those findings describe particular settings. They do not establish a universal productivity penalty for every business or prove an ideal number of projects.
Set a first active project limit as a test
Choose one team and one kind of work. Agree on a starting limit based on its current load and available skills. Do not copy a number from another company or turn the limit into an employee quota. The point is to create a manageable flow and learn what blocks completion.
Suppose a small implementation team has eight open client projects. The team agrees that only four may receive active delivery work at once. The other four remain visible in the backlog with an owner, a next review date, and any customer commitment. This example is illustrative. Four is not a recommended limit for other teams.
When a new request arrives, first check whether an active item has finished or can safely pause. If none can move, ask who has authority to approve an exception and what existing work will wait. Before accepting a new promise, return to the active project limit and name which open item will move. A genuine safety, legal, or customer-critical issue may need to go first. The team should name the displaced item, update the affected people, and review the exception afterward. Otherwise every request can become “urgent” and the limit loses meaning.
Review the limit without turning it into a target
Review the active list at a regular operating meeting. For each item, confirm its owner, next action, expected completion test, customer date, and any blocker. Ask whether the item should continue, pause, or be closed. Then check whether the limit still fits the team’s work.
Track completion time, the number of finished items, time spent blocked, rework, and missed customer commitments. A lower active count is not a success by itself. If fewer projects start but the same number of commitments remain overdue, the business may have moved the queue without fixing it. If output slows, check whether the team has a scarce skill or approval bottleneck before raising the limit.
Run the first version for four weeks, then compare it with the baseline. Keep the rule if it helps the team finish work more predictably without creating unacceptable waits. Adjust it if the work mix or capacity changes. Record why the limit changed so the next review can distinguish a deliberate decision from gradual overload.
Make the next commitment a conscious choice
An active project limit works best when owners use it to protect commitments, not to make a dashboard look tidy. Start with one team, define what counts as active, measure current flow, and agree who can authorize a trade-off. The team’s own evidence should determine whether the limit changes.
DBG360 can help owners trace delays across people, approvals and systems, then prioritize an operating change that fits the business. If projects keep starting faster than they finish, a discovery call can help identify where work is waiting and what to test first. Book a discovery call.
Sources
John D. C. Little, “A Proof for the Queuing Formula: L = λW,” Operations Research, 1961. The paper states the conditions for the queueing relationship used in the illustrative calculation above.
H. Eyrolle and J. M. Cellier, “The effects of interruptions in work activity: field and laboratory results,” Applied Ergonomics, 2000. The field component concerned customer-call interruptions during telephone-line data indexing; the laboratory findings are not treated as a universal business benchmark.
