Projects: Interactive Gantt, Capacity & Portfolio

Open a project and choose Timeline. Every task with both a start and a due date is a bar; a task that is done is drawn as done, a task on the critical path is marked as such, and a thin line under the bar shows its baseline once one has been set with Set baseline. Milestones are diamonds on their dates, dependencies are arrows from a task to the ones that wait for it, non-working days on your working calendar are shaded, and a Today line marks where you are. Day, Week and Month change the zoom, and the Today button scrolls back to the present.

Hovering over a bar shows its dates and length, assignee, estimate and slack and, when there is a baseline, how many days late or early it is against it. Below the chart a Table view lists the same tasks with start, due, assignee and whether they are on the critical path, which is the accessible way to read the plan and the quickest way to check exact dates. Tasks without both dates are listed under Unscheduled rather than guessed onto the chart, and a very large project shows the first 600 tasks by start date and says so.

In practice: a Nairobi construction firm’s site office opens the timeline of a 14-week fit-out every Monday. On Week zoom the critical path runs through electrical first fix and plastering; the baseline lines show plastering already four days behind the plan agreed at kickoff. Three snag tasks have a due date but no start, so they sit under Unscheduled; the site manager gives them start dates so they appear on the chart and in the critical-path calculation.

Drag a bar to move a task — its start and due date move together and its length is kept. Drag the bar’s right edge to change only the due date. The keyboard does the same: Tab to a bar, Left or Right moves it a day, Shift with Left or Right changes its due date, and Enter opens the task. Each move is saved straight away. Moving a task bar is editing the task, so it needs the permission to edit tasks as well as access to project planning; moving a milestone needs project planning. Someone who can see the timeline but not re-plan it is told so under the chart, and the mobile app shows the timeline read-only.

Dependencies are finish-to-start: a task may start no earlier than the day after the task it depends on is due. A move that breaks that rule is not refused — planners often move one task first and its neighbours second — so it is saved and flagged in both directions. If the moved task now starts before something it depends on has finished, only you can resolve it, by moving one or the other. If tasks that depend on the moved one now start too early, the warning offers Push successors later.

Push successors later moves each affected open successor later by exactly the days needed, keeping its duration, and repeats down the chain. Successors are never pulled earlier, and done or cancelled tasks are never moved — they are reported instead. In practice: a Kigali software team’s API build slips three days. The project lead drags it right; the Gantt warns that two tasks depending on it now start too early. She clicks Push successors later, and integration testing and the client demo each move three days, while a documentation task that already had four days of slack is left alone.

Projects → Resource Capacity shows people down the side and weeks (or days) across the top, and each cell compares the hours of work planned for that person with the hours they have. Capacity is your standard day length — the hours in a working day from HR settings, 8 to start with — multiplied by the working days on your working calendar, minus public holidays for the employee’s work country and minus approved leave. Leave is spread over the days it covers, so a half-day request removes half a day. There is no per-person contract-hours setting: everyone is counted at the standard day, including part-timers.

Allocation depends on whether a day is past or still ahead. For days before today the cell shows hours actually logged on tasks. From today on it takes each open, assigned task’s remaining estimate — the estimate minus hours already logged — and spreads it evenly over the assignee’s available working days between the task’s start and due date. A task with only a due date is scheduled backwards from it, one with only a start is scheduled forwards, and work already past due lands on the next available day, which is why an overdue backlog shows as today’s overload. Tasks with no dates are shown beside the person as undated hours, and tasks with no estimate plan nothing and are counted separately.

In practice: a Kampala design studio’s designer has a 40-hour week with one public holiday and half a day of approved leave, so her capacity is 28 hours. She has a 30-hour task spread over that week and the next, plus 6 remaining hours on a task due Wednesday. The cell shows roughly 21 of 28 hours — healthy — until the Wednesday task slips past due, when its hours pile onto the next available day and her week turns over.

Each cell is coloured by utilisation, hours planned ÷ hours available: Under below 70%, Healthy from 70% to 100%, Over up to 125%, and Far over beyond that; a cell with work on a day with no capacity at all is marked No capacity, and past days are styled as hours logged. Filter by project, department and date range, switch between Weeks and Days, and step through time with Earlier, Now and Later. The heatmap needs the project analytics permission, and the mobile app shows it read-only.

Select a cell to see the tasks behind it — which projects and tasks make up those hours — and open any of them to reassign it, move its dates or correct its estimate. Because the heatmap reads the same tasks as the Gantt and the task pages, fixing the plan there fixes the heatmap; there is nothing to update on the heatmap itself. A person with work but no estimates will look under-allocated, so the count of tasks with no estimate is a prompt to ask for one before trusting a pale row.

In practice: a Lagos consultancy filters Resource Capacity to its Delivery department for the next six weeks. One analyst is Far over in week 2. Selecting the cell shows three client reports due the same Friday. The engagement manager moves one report’s due date a week on the Gantt and reassigns another to a colleague who is Under that week; when the heatmap reloads, both cells are Healthy.

Projects → Portfolio lists every project with its health, % complete, due date, open and overdue tasks, hours logged against plan, budget burn, owner and next (or missed) milestone, under a KPI row you can click to filter by health and two charts: effort logged against plan, and budget burn against progress. Filter by health, status, owner and department, or search by name or code. Viewing it needs the permission to view projects; budget figures appear only for people with the project analytics permission. The mobile app has a read-only portfolio screen.

Health is the worst of three checks. Schedule is off track when the project or an open milestone is past due, and at risk when any open task is overdue, an open milestone is due within 7 days, or the project is due within 14 days and is under 80% complete. Effort applies when the project has an hours budget or task estimates: off track when hours logged exceed that baseline, at risk when hours run more than 15 points ahead of task progress. Budget applies only to projects with a money budget: off track when actual cost exceeds it, at risk when 90% is spent or spend runs more than 15 points ahead of progress. Completed and cancelled projects are shown as closed rather than judged.

In practice: an Accra NGO’s programme director opens the portfolio before the monthly board meeting. Eleven projects are on track, three at risk and one off track. The off-track one has a missed milestone. One at-risk project is 62% complete but has spent 81% of its budget — 19 points ahead of progress — so the budget dot is amber while schedule and effort are green. She takes those two to the board with the reason already stated, instead of a list of fifteen projects.