How to Track Multiple Projects Without Complex Software
To see how several projects are progressing, make one shared overview that shows each project’s next milestone, current status, evidence of progress, next action, owner, and any blocker. Update it on a regular schedule and use the same status definitions for every project. A whiteboard, spreadsheet, or plain document is enough when the group can keep it current and find it easily. This guide is for a person coordinating a handful of active projects who needs to spot what is moving, what is at risk, and where a decision or follow-up is needed. It focuses on building a useful cross-project view, rather than tracking every task in detail.
Start with the decisions you need to make
Before choosing a format, write down the questions you want the overview to answer. For example: Which projects are on track for their next milestone? Which need attention this week? Is one person waiting on another project? What needs a decision from me?
These questions keep the overview focused. If you add every task, note, and conversation, the cross-project picture gets buried. Keep detailed task lists where the work already happens; use the overview to show the few facts that help you coordinate across projects.
That distinction is practical, not a rule about project management. Atlassian’s project status report guide recommends reporting progress, upcoming work, and challenges or blockers. For multiple projects, the useful extension is to make those fields consistent enough to scan side by side.
Build a one-page project overview
Create one row or card per project. Use the following fields as a starting point:
Record the project and intended result, its next observable milestone and target date, the current status, evidence of what changed, the next action and owner, any blocker or dependency, and the date the row was last checked. Keep the fields in the same order for every project.
A milestone should describe something another person could recognize as complete, such as “draft shared with reviewers” or “event venue confirmed.” “Make progress” is not a checkpoint. Choose milestones that matter to the project’s next decision or delivery; a long list of minor tasks makes the overview harder to read.
The Kanban University guide to the Kanban Method describes visualizing work and its movement through a workflow as a way to make otherwise invisible work easier to understand. A simple overview applies that idea at the project level: it shows the current state and where work is waiting. It does not require adopting a full Kanban system.
Use status labels people can apply consistently
A colored label is useful only when people understand what it means. Write a short definition beside the overview and apply it to the next milestone, not to a vague impression of the whole project. For example:
On track: The next milestone is expected by its target date, and no unresolved issue currently threatens it.
Watch: There is a specific concern that could affect the milestone, but a next step is identified.
Blocked: Progress cannot continue until a named issue, decision, or dependency is resolved.
These labels are a suggested working convention, not an official standard. Agree on them with the people who will update or use the overview. If a project is marked “watch,” include the reason and the action that would return it to “on track.” If it is “blocked,” name the help needed and who will follow up. A label without an explanation can make a serious problem look the same as a minor uncertainty.
Avoid treating a percentage complete as the main signal across very different projects. “80% complete” may mean something quite different for a design, an event, and a research effort. A dated checkpoint plus observable evidence gives readers something more concrete to interpret. This is a practical comparison choice, not a claim that percentages are never useful; they may help within a project when the work can be measured consistently.
Set a lightweight update routine
An overview works only if people can tell whether its information is current. Pick an update rhythm that matches how quickly projects change. A weekly check is a reasonable starting point for many small groups, but a slower-moving effort may need less frequent updates, while a fast-changing project may need more. Atlassian likewise advises choosing status-report frequency to fit project complexity and stakeholder needs in its status report guide.
At each update, ask each project owner to check four things:
1. Did the next milestone, target date, or owner change?
2. What observable work was completed since the previous check?
3. Is there a blocker, new dependency, or decision needed?
4. What is the next action, and when will it be checked again?
Record the update date. If a row has not been checked recently, mark it “not updated” or ask its owner before treating the status as current. This prevents an old “on track” label from appearing to be a fresh assessment. When a date changes, keep the reason or decision that changed it in a short note; otherwise, repeated date shifts become difficult to interpret.
Keep the update meeting, if you have one, focused on exceptions and coordination. Read the rows in advance, then spend discussion time on blocked work, milestone risks, dependencies, and choices that affect more than one project. Routine progress can be recorded without narrating every task. This is an efficiency suggestion based on the overview’s purpose, not a guarantee that a particular meeting length will work for every team.
Spot dependencies between projects
Projects can look healthy individually while competing for the same person, decision, room, equipment, or review time. Add a dependency when one project needs something from another; note both the provider and receiver, along with the date or condition that matters. For example: “Website launch needs final event details from the event project by 12 May.”
Then scan the overview for shared people and dates. If the same person owns several next actions due at once, or one project’s delayed decision will shift another project’s milestone, make the conflict visible and agree on a priority or revised plan. This is where a single overview is more useful than separate project updates: it lets you compare commitments and dependencies in one place. A Project Management Institute portfolio process likewise records high-level milestones, status and project interdependencies instead of filling its cross-project inventory with every task; the compact version here is an editorial adaptation for a small group.
Do not assume that a dependency is resolved just because it has an owner. Record the expected handoff and confirm it when it happens. When the sequence or date is uncertain, say so; a visible uncertainty is easier to discuss than an implied promise.
Choose the simplest format that stays usable
Use a spreadsheet when you want sortable rows, dates, filters, or a compact view across many projects. Use a whiteboard when the group works together in one place and benefits from moving cards through stages. Use a shared document when updates are mostly short written summaries and the project count is small.
These are format trade-offs, not product recommendations. Pick the simplest option your group can access, understand, and update. Before adding software, ask what is actually failing: Are statuses hard to compare? Are updates late? Are dependencies invisible? A new tool may help with collaboration or reminders, but it will not make unclear milestones or missing ownership clear by itself.
If projects need different specialist details, keep those in their existing working records and link or refer to them from the overview where practical. The cross-project view should stay small enough to scan. If you need to make it much wider, check whether some fields answer the same question or belong in project-level notes instead.
A worked example
Suppose a coordinator is following three projects: a community event, a website refresh, and a monthly newsletter. Their overview might show:
Example: The community event is on Watch because two possible venues remain unbooked; its owner will compare availability by 8 May for a 12 May venue milestone. The website refresh is On track because draft pages have reached reviewers; comments are due by 10 May for a 15 May review. The monthly newsletter is Blocked because final copy needs confirmed event details; its owner will ask for them by 7 May before the 9 May copy milestone.
These are illustrative entries, not reported results. The overview makes a dependency visible: the newsletter depends on event details. It also shows a useful next move: confirm whether the event decision can happen in time for the newsletter, or adjust the newsletter plan. A status color alone would not show either the reason for concern or the coordination needed.
When this approach needs more structure
A one-page overview may stop being enough when many people update the same work, projects have complex schedules or budgets, access must be controlled, or a record of decisions and changes is important. You can still keep a concise cross-project summary, but the detailed information may need a more structured system and clearer ownership.
For a small portfolio, begin with a handful of fields, agree on status definitions, and review the same milestones on a steady rhythm. If the overview helps you see what needs attention and coordinate the next action, it is doing its job. If it becomes another report people fill in without using, simplify it or change the questions it is meant to answer.