How I Track 10 Projects at Once: My Project Tracking System

Running one software project is a job. Running around ten at the same time is a different job. The hard part isn't any single project. It's keeping all of them visible, so nothing quietly slips while your attention is somewhere else.

This is the project tracking system I use as a technical project manager to manage multiple projects at once. It isn't tied to one tool, it doesn't need a big process, and you can copy the parts that fit your team. At the end there are free templates you can download.

The short answer

If you only take one thing from this article: every task needs an owner, an expected outcome, and a visible status, and everything important is written down. Most of what follows is how I keep that true across many projects at once.

My setup: a few tools, each with one job

My teams are small, usually three to five people per project. The tools are simple:

• Jira and ClickUp for tasks, sprints, and status. Which one depends on the project.
• Slack and Discord for day-to-day conversation with teams and clients.
• Email for formal updates and anything that needs a clear record.

The rule that matters more than the tools: each kind of information lives in one place. Tasks live in the tracker, not in chat. Decisions are written down, not just discussed in a call. When something is only in someone's head or in a scrolled-away message, it will eventually get lost.

What I track for every task

Owner, expected outcome, and status are the core. On top of that I track a few fields that make tracking many projects much easier:

• Approximate effort. A rough estimate, so I can see when a task is taking much longer than expected.
• QA status. A task isn't done when development finishes. It's done when QA has checked it.
• Blockers. What is stopping the task, and whether the blocker sits with the client or with the team.
• Linked tasks. When a task depends on, or is similar to, another task, I link them. When something changes, I can update all the related tasks at once instead of finding them one by one later.
• Environment. Where the work currently is: development, staging, pre-production, or production.

Two standard practices make these fields more reliable:

• A shared Definition of Done. Agree once, per project, what "done" means: for example, code reviewed, QA passed, deployed to staging, and accepted by the client. Then "done" means the same thing on every board.
• Clear ownership with RACI. For bigger decisions, it helps to note who is Responsible, who is Accountable, who is Consulted, and who is Informed. One accountable person per task or decision, never two.

None of this needs a complicated tool. A well-structured spreadsheet can do all of it, which is why the templates below are spreadsheets.

My daily routine

My day has a simple shape:

1. Check every channel first. Before anything else, I go through client emails and messages across channels. Then I pass on what matters: questions and changes go to the team, answers and updates go to the client.
2. Meet the team. A short check-in to see where people are stuck and help them get moving again.
3. Discovery, when needed. If a project needs more detail from the client, I schedule a discovery meeting rather than letting the team guess.
4. Learning time. I keep some time for learning new things. In software, standing still means falling behind.
5. Evening: updates and follow-ups. I send client updates, request anything the team needs from the client, and follow up on open items.

The order matters. Checking messages first means I hear about problems while there's still time to act.

My weekly rhythm

Across the week, a few things happen for every project:

• Sprint planning for upcoming work, adjusted to how each project runs.
• One progress meeting per project per week with the client. This single habit does a lot of work. The client sees steady progress, questions get answered in one place, and expectations stay aligned instead of drifting apart quietly.
• A weekly status report and short updates in between, by email or message, with a call only when something needs discussion.

A status update works best when it follows the same shape every time. A common standard is a RAG status: Red, Amber, or Green for overall health, followed by what was done, what is next, risks and blockers, and any decisions needed from the client. Sending it in writing before the weekly meeting lets the meeting focus on questions and decisions.

For projects that run in sprints, the standard Scrum cadence fits neatly around this:

• Daily stand-up (10–15 minutes): what moved, what is next, what is blocked.
• Sprint review or demo at the end of each sprint, ideally combined with the weekly client meeting.
• Retrospective with the team: what to keep, what to change. Small fixes here prevent the same problem across every project.

A weekly rhythm turns ten separate projects into one predictable routine, which is the only way to keep them all in your head.

Early warning signs a project is going off track

In my experience, projects rarely fail suddenly. They get blocked, and the block isn't noticed in time. Blockers usually come from one of two places:

• The client side: waiting for feedback, content, access, or a decision.
• The team side: a technical problem, missing information, or someone stuck without asking for help.

So the first thing I look for is anything marked blocked, or anything that should have moved and hasn't. A task that has used much more effort than its estimate is another early sign. Other common warning signs: the same task moving between "in progress" and "in review" repeatedly, client feedback arriving later each week, and decisions being made in calls but not written down.

A simple way to stay ahead of these is a RAID log: a short list per project of Risks, Assumptions, Issues, and Dependencies. It takes a few minutes a week and turns vague worries into items with an owner and a next step.

How I handle blockers

When something is blocked, I review it myself first so I understand what's actually wrong. Then:

• If the blocker is on the client side, I escalate to the client with a clear request and why it matters for the timeline.
• If the team needs technical guidance, I bring in the technical lead.

The goal is speed: a blocker found on Monday and raised on Monday costs a day. The same blocker found on Friday costs a week. A practical rule is no blocker stays unraised for more than 24 hours, and every escalation includes what is blocked, what is needed, from whom, and by when.

How to manage multiple projects with competing deadlines

Sometimes two projects need urgent attention at the same time. When that happens, I assess the impact of each one: what happens if this slips, for the client and for the rest of the project? Then I prioritise by impact, not by who is asking loudest.

Two standard techniques help make this decision clear and explainable to clients:

• MoSCoW prioritisation: sort the work into Must have, Should have, Could have, and Won't have this time. When time is short, protect the musts and agree openly on what moves.
• Impact vs urgency: something urgent but low-impact can often wait a day; something high-impact deserves attention even if nobody is shouting about it yet.

When both genuinely matter and the timeline is at risk, I try to add a temporary resource to one of the projects to keep it on schedule, rather than letting both slip a little. In project management terms this is crashing the schedule: adding resources to the critical work to protect a deadline. It works best when the extra person can pick up well-defined tasks, not when they need weeks to get up to speed.

QA and environments: gates before anything ships

Quality is part of tracking, not something that happens at the end. Two things help:

• QA is involved during development, not only after it, and before anything is shown to the client.
• Each project has separate environments: development, staging, pre-production, and production. Work moves through them in order, so the client only sees what has already been checked.

This is also where user acceptance testing (UAT) belongs: the client tests in pre-production, signs off, and only then does the release go to production. A short release checklist (QA passed, UAT signed off, rollback plan ready, client informed) keeps releases calm.

This means "done" always means the same thing across every project: built, tested, accepted, and ready.

What I stopped doing

The change that made the biggest difference: I stopped relying on verbal agreements. If something was decided in a call, it gets written down: in the tracker, in an email, or in a message. That way everything is traceable, and if a question comes up later, there is an answer instead of two different memories.

The same applies to scope changes. When a client asks for something new, I log it as a change request in writing, with its impact on effort and timeline, before the team starts on it. That protects the client, the team, and the plan.

How to track multiple projects in Jira, ClickUp, or Google Sheets

The system works in any tool:

• Jira or ClickUp: use the standard fields for owner and status, add custom fields for effort, QA status, blocker source, and environment, and use issue links for related tasks. A board per project plus one filtered view across all projects gives you the overview.
• Google Sheets or Excel: one row per task, dropdowns for status and QA status, and a summary sheet that counts open blockers per project. That's exactly what the templates below do.

Free project tracking templates

I made two simple templates based on this system. Both open in Excel, and you can import them into Google Sheets (File → Import).

• Multi-project tracker: a projects overview with RAG health, a task list with owner, outcome, status, effort, QA status, blockers, linked tasks, and environment, a Gantt-style timeline that draws weekly bars from each task's start and due dates (blocked tasks in red), and a RAID log for risks, assumptions, issues, and dependencies.
• Weekly project status report: a print-ready one-page report with an executive summary, overall RAG status and trend, health by area (scope, schedule, budget, quality, resources), key numbers, milestones with planned vs forecast dates, risks and issues, decisions needed from the client, and change requests. Includes a RAG guide so everyone uses the same definitions.

Frequently asked questions

How many projects can one project manager handle?

It depends on project size and team maturity more than on a fixed number. With small teams of three to five people and a clear weekly rhythm, I manage around ten. Without written tracking and regular client updates, even three projects can feel like too many.

What is the best tool for tracking multiple projects?

The one your team will actually keep updated. Jira, ClickUp, and a well-built spreadsheet can all work. Consistency matters more than features: one place for tasks, one for decisions, and the same fields for every project.

How do you prioritise when everything is urgent?

Compare the impact of each deadline slipping, for the client and for the project. Use MoSCoW to agree what must ship and what can move. Work on the higher impact first, and if both are critical, add a temporary resource to the critical work rather than letting both slip.

How often should you update clients?

At least once a week, with one progress meeting per project, plus short written updates when something changes. Regular, predictable updates build more trust than long reports that arrive only when something goes wrong.

Final thoughts

Tracking many projects isn't about a perfect tool. It's about a few habits applied every day: clear ownership, written decisions, checking for blockers early, and talking to clients every week.

If you're new to the role, you might also like Software Engineer to Project Manager: What Actually Changed. And if you'd like to talk about delivery, get in touch.