A 20-person AI agency in Chicago was running seven active projects simultaneously with a delivery team of 12 engineers. On paper, the math worked โ total estimated hours across all projects fit within the team's capacity at 75% utilization. In practice, it was chaos. Engineers were context-switching between three projects in a single day. Project managers were competing for the same senior ML engineer's time. A critical deployment on one project conflicted with a client demo on another. Two projects fell behind schedule, which cascaded into resource conflicts with three other projects. By the end of the quarter, four of the seven projects were over budget, two clients had escalated complaints to the founder, and three engineers were showing signs of burnout.
The problem was not capacity โ it was coordination. The agency had enough total hours to complete all seven projects. What they lacked was a system for managing the interactions between projects โ shared resources, competing timelines, conflicting priorities, and cascading dependencies.
Managing one project well requires discipline. Managing five or ten simultaneously requires systems. The agencies that thrive at multi-project management do not have better project managers โ they have better coordination infrastructure.
The Multi-Project Management Challenge
Single-project management is about executing a plan. Multi-project management is about optimizing across plans. The challenges are fundamentally different.
Resource Contention
Your best engineers are in demand across multiple projects. Without a system for allocating shared resources, project managers compete for the same people, and the loudest voice or the most urgent deadline wins โ not necessarily the most important project.
Context Switching Costs
Research from the American Psychological Association shows that context switching can consume 20-40% of productive time. An engineer switching between three projects in a day is not 33% productive on each โ they are roughly 60% productive in total. The switching cost is lost time that does not show up on any project's time tracking.
Cascading Delays
When one project falls behind, it consumes resources that were scheduled for other projects. This creates a domino effect โ one late project makes two other projects late, which makes three more late. In a multi-project environment, delays are contagious.
Priority Conflicts
Different projects have different priorities, and those priorities change over time. Without a clear priority framework, every project manager believes their project is the most important, and resource allocation becomes a political negotiation rather than a rational decision.
Aggregate Risk
Each individual project has a manageable level of risk. But across ten projects, the probability that at least one will hit a significant issue is very high. Multi-project management requires aggregate risk visibility, not just project-by-project risk assessment.
The Multi-Project Management Framework
Layer 1 โ Portfolio Visibility
You cannot manage what you cannot see. The first requirement is a single view that shows all active projects and their status.
The project portfolio dashboard should show:
- All active projects with their current phase, health status (red/yellow/green), and key metrics
- Timeline view: A Gantt chart or timeline showing all projects, their phases, and milestones. Overlapping timelines and conflicting milestones are immediately visible.
- Resource allocation view: Who is assigned to which projects, at what percentage, for what time period. Conflicts and gaps are highlighted.
- Financial summary: Budget vs. actual for each project. Revenue recognition and billing status.
- Risk register: Top risks across the portfolio, not just per project.
Update frequency: Weekly. The portfolio dashboard should be reviewed in a weekly operations meeting.
Layer 2 โ Resource Orchestration
Resource allocation across multiple projects is the hardest operational challenge in an AI agency. Here is the system.
Allocation principles:
- Minimize context switching: Where possible, assign engineers to one or two projects maximum. Three projects for one person is the absolute ceiling. Beyond three, productivity drops precipitously.
- Protect focus time: Block dedicated focus time for each project assignment. An engineer who is 60% on Project A and 40% on Project B should have three full days on A and two full days on B โ not 60% of every day on A and 40% on B.
- Plan for transitions: When an engineer moves from one project to another, plan a transition period. Knowledge transfer, documentation, and ramp-up on the new project take time.
- Maintain a small buffer: Keep 5-10% of total capacity unallocated as a buffer for urgent issues, estimation surprises, and unplanned client needs. Allocating 100% of capacity leaves no room for reality.
Resource allocation process:
- Monthly allocation planning: At the beginning of each month, the delivery director (or whoever manages resource allocation) reviews all project needs for the coming month and creates an allocation plan.
- Weekly adjustment: Each week, review actual utilization against the plan and make adjustments based on project progress, scope changes, and emerging needs.
- Conflict resolution: When two projects need the same resource at the same time, escalate to the delivery director for resolution using the priority framework (discussed below).
Layer 3 โ Priority Framework
You need a clear, agreed-upon system for prioritizing projects when resources are scarce.
Priority criteria:
- Strategic importance: Is this project with a strategic client? Does it open a new market or service line? Is it a reference-able engagement?
- Financial impact: What is the margin on this project? What is the revenue impact of a delay?
- Contractual obligations: Are there contractual deadlines with penalties for missing them?
- Client relationship risk: Is the client relationship at risk if this project is deprioritized? How important is this client to the agency's future?
- Dependency impact: Will delaying this project cascade into delays on other projects?
Scoring: Rate each project 1-5 on each criterion. Sum the scores. Use the total score to create a priority stack rank. When resource conflicts arise, the higher-priority project gets preference.
Review frequency: Re-score priorities monthly. Project priorities change as business conditions change.
The critical rule: The priority framework must be agreed upon by leadership (founder, delivery director, sales director) and communicated to all project managers. If project managers do not know the priority stack, they cannot make trade-offs.
Layer 4 โ Cross-Project Coordination
Individual projects have project managers. The portfolio needs a coordination function.
Weekly portfolio review meeting (30-45 minutes):
- Attendees: Delivery director, all project managers, and the resource planner (if separate from the delivery director)
- Agenda:
- Portfolio dashboard review: Quick status on every project (30 seconds per project โ red/yellow/green and one-line explanation)
- Resource conflicts: Any conflicts that need resolution this week
- Cross-project dependencies: Any project waiting on another project or shared deliverable
- Upcoming milestones: What milestones are due in the next two weeks? Are they on track?
- Risk escalations: Any project-level risks that have portfolio-level implications
This meeting is not a deep dive into any individual project โ it is a coordination checkpoint. Individual project issues are handled in individual project meetings.
Monthly portfolio review meeting (60-90 minutes):
- Attendees: Founder/CEO, delivery director, sales director, and project managers
- Agenda:
- Financial review: Budget vs. actual across the portfolio. Margin analysis.
- Resource planning: Upcoming resource needs, hiring decisions, contractor needs
- Priority re-scoring: Review and update project priorities
- Pipeline impact: What new projects are coming? How will they affect current allocations?
- Strategic discussions: Are we taking on the right mix of projects? Are we over-committed?
Layer 5 โ Standardized Project Management
Multi-project management only works if individual projects are managed consistently. Standardization reduces cognitive load, makes cross-project coordination easier, and enables meaningful portfolio-level reporting.
Standardize:
- Status reporting format: Every project uses the same status report template. Same sections, same metrics, same health rating definitions.
- Risk management: Every project uses the same risk register format. Same risk categories, same probability and impact ratings.
- Milestone definitions: Standardize what "milestone complete" means โ deliverable submitted, client reviewed, client approved, or deployed?
- Time tracking: Everyone uses the same time tracking system with the same project codes and task categories.
- Communication cadence: All projects follow the same communication rhythm โ weekly status meetings, monthly client reviews, milestone demos.
Managing Shared Resources
Certain roles in an AI agency are frequently shared across projects โ DevOps engineers, data engineers, QA specialists, and project managers. Managing shared resources requires specific techniques.
The Shared Resource Model
Dedicated resources: Assigned full-time to one project. Simplest to manage. Use for senior technical roles where continuity and deep context are essential.
Fractional resources: Assigned to multiple projects at defined percentages. Common for roles like DevOps (30% on three projects) or data engineering (50/50 on two projects). Requires careful scheduling to minimize context switching.
Pool resources: Available to any project as needed, drawn from a shared pool. Common for QA, technical writing, and infrastructure support. Managed through a queue or request system rather than fixed allocation.
Scheduling Shared Resources
Day-based scheduling: Assign specific days to specific projects. "Maya is on Project Alpha Monday-Wednesday and Project Beta Thursday-Friday." This creates focused blocks and minimizes daily context switching.
Phase-based scheduling: Assign resources to projects during specific phases. "Chen handles data pipeline setup for each new project (2-3 week engagement) then rotates to the next project." This works for roles that have intense, time-limited involvement in each project.
On-call scheduling: For pool resources, establish a request and scheduling process. Project managers submit requests with scope, priority, and timeline. The pool manager schedules the work based on priority and availability.
Managing Client Expectations Across Projects
When you are running multiple projects for different clients, you need to manage expectations consistently and honestly.
Transparency About Capacity
Never tell a client they have your "full attention" when their engineer is also on two other projects. Set honest expectations about team allocation and availability. Most clients accept fractional allocation if you are transparent about it and deliver results.
Consistent Service Levels
Every client should receive the same quality of communication, reporting, and responsiveness โ regardless of project size or priority level. A $50,000 project client should get the same quality status report and response time as a $500,000 project client, even if the depth of the work differs.
Managing Competing Deadlines
When two clients both need something urgently, do not try to do both simultaneously at lower quality. Communicate with both clients, explain the situation honestly, and negotiate timelines. Most clients are understanding when you are transparent. What they cannot accept is finding out after the fact that their deadline was missed because of another client.
Common Multi-Project Management Mistakes
Over-Commitment
The most common mistake is accepting more projects than your team can handle. The pressure to grow revenue leads agencies to say yes to every opportunity without evaluating the portfolio impact. Before accepting a new project, model its resource requirements against your current portfolio. If it pushes utilization above 80% or requires resources that are already fully allocated, you either need to hire, subcontract, or decline.
Equal Priority
Treating all projects as equally important is the same as having no priorities. When everything is critical, nothing is. Establish a clear priority stack and make trade-off decisions based on it.
Ignoring Cross-Project Dependencies
Projects that share data sources, infrastructure, team members, or client relationships have dependencies that must be managed. A change in one project can affect another. Identify and track cross-project dependencies explicitly.
Hero Culture
Relying on individual heroics โ one engineer working 70 hours to cover for poor coordination โ is not management. It is dysfunction masquerading as dedication. If projects consistently require heroic effort to stay on track, the portfolio is over-committed and the systems are inadequate.
No Learning Across Projects
When Project A solves a technical challenge that is relevant to Project C, that knowledge should transfer. Without cross-project knowledge sharing mechanisms (shared code repositories, internal tech talks, documented solutions), you lose efficiency and repeat mistakes.
Your Next Step
Start with visibility. Create a simple portfolio dashboard โ even a spreadsheet โ that shows all active projects, their status, their resource allocation, and their timelines. Review it weekly with your delivery team. The first time you see all your projects in one view, you will identify conflicts and coordination opportunities that were invisible when each project was managed independently. Then implement the weekly portfolio review meeting. Twenty minutes of coordination each week prevents hours of fire-fighting. From there, build out the priority framework, standardize your project management practices, and implement day-based scheduling for shared resources. Multi-project management is not about working harder โ it is about coordinating smarter.