Project Management

The project workspace holds the information needed to plan and deliver a piece of work. It can be generated from a brief or start as an empty draft project.

Project header

The header shows the project name, job number, colour, status, client, and key dates. Depending on your access, you can update the name, job number, colour, and client from here.

If you can delete projects, the header also shows a ⋮ menu on the far right. Deleting lives inside that menu rather than as a standalone button so it cannot be pressed by accident while working with tasks. Choose Delete project…, then type “delete” in the confirmation dialog to enable the Delete Project button. Deleting removes the project’s tasks, schedule entries, and assets, and cannot be undone.

Links in Ru conversations, activity, and job results can remain after a project is deleted. Opening one of these links takes you to a clear replacement when Runnit can identify exactly one safely. If there is no safe replacement, the page tells you that the project was deleted instead of showing a generic not-found error.

The Budget, Planned, and Actual cost chips only appear if you have financial-report access (managers and above by default). Planned is the cost of the assigned work (estimated hours priced at each assignee’s rate) and Actual is the billable value of logged time, so both are treated as financial data along with the budget itself. People without that access see the rest of the header as normal, and the API leaves the financial figures out of what their browser receives.

Set or change the client

Project owners and administrators can select the client chip in the header to link the project to a client, switch it to a different client, or make it an internal project again. The chip reads Internal project while the project has no client, and hovering it shows Set client. The list offers your organisation’s active clients in alphabetical order. Your own organisation is not in the list: work you own is an internal project, which is the Internal project option.

Changing the client resets any client rate card pinned to the project, and future task assignments follow the new client’s staffing eligibility. Existing assignments are not changed. The change is recorded in the History tab with the previous and new client.

Change the project status

If you can update project statuses, the status chip in the header is a dropdown. It lists your organisation’s workflow stages, grouped by lifecycle category, so the header and the Kanban board always agree. Selecting a stage moves the project immediately, updates the board, and records the change in the History tab.

Moving a project to a done, completed, or cancelled stage while it still has incomplete tasks opens a confirmation. You can leave the tasks as they are, mark them all complete, or cancel them. Your organisation can change this behaviour in its project lifecycle settings, including requiring the tasks to be resolved before the project can close.

Archive a project

Archiving tidies away finished work. An archived project disappears from the projects board, lists, and pickers, and becomes fully read only until it’s unarchived. Archiving needs the archive permission (organisation admins and owners by default) and is only available once a project is done, completed, or cancelled.

Open the status dropdown in the project header.
Select Archive project at the bottom of the menu.
Confirm in the dialog. If incomplete tasks remain, choose what happens to them first.

An archived project shows a banner with when and who archived it. Select Unarchive in the banner to restore the project exactly where it left off, including its previous workflow stage.

Project owners and administrators can click the project name or job number in the header to edit it in place. The change saves automatically when you press Enter or click away. Press Escape to cancel without saving. An empty value is not saved.

Every project gets a rounded-square colour identifier. Select the colour beside the project name to change it. The same colour appears in the sidebar, project cards, Kanban cards, and master-project hierarchy.

Project tabs

Tab	Use it for
Tasks	Gantt, task table, and capacity views for tasks, dates, milestones, dependencies, assignments, and conflicts
Team	Members, roles, workload, project access, and rates (rates show only with financial-report access)
Brief	The live project brief in a full-height Markdown editor
Files	Project assets and linked delivery files
History	Status, task, comment, file, and project activity over time

Project owners can edit the brief. Changes save when the editor loses focus, so click outside the editor and confirm the updated content before leaving the page.

Work with tasks

The Tasks tab has three views over the same tasks and milestones:

Gantt groups tasks beneath read-only assignee headers and shows task spans, milestones, and finish-to-start dependency links. The assignee header shows the person’s role and task count. Select its chevron to collapse or expand that person’s tasks. The header is not a task and cannot be opened, renamed, moved, or deleted. Select a task row to edit the task itself. Tasks without dates sit in a separate Unscheduled backlog group. They can still be opened, but have no timeline bar to drag.
Table supports inline task creation and editing, grouping, search, filters, multi-column sorting, column visibility, bulk changes, dependency editing, and CSV export.
Capacity shows the scheduled load for the project team and lets authorised users move work while checking availability. If a resource planning run suggested alternative candidates, they appear too, marked with their AI fit score; other organisation members do not. Tentative bookings from draft projects appear with a hatched amber pattern so you can tell proposed work from confirmed work. Use the Include tentative checkbox (on by default) to keep or remove tentative hours from the daily load and overload totals. Tentative work stays visible with its hatched pattern either way.

Create a task with only a name when you want to capture work before planning it. Assignment, effort, and dates are optional and can be added independently. Table and Gantt keep these backlog tasks visible. Capacity and the global Schedule show only work with real schedule entries, so an undated task does not consume anyone’s availability.

Table opens by default when you have not chosen another view. If you switch to Gantt or Capacity, Runnit remembers that choice for your next visit. A link with an explicit view also opens that view directly. A project with no tasks always opens on Table so you can start adding work straight away, unless the link asks for a specific view.

In the Table view, each group ends with a + new task row. Type a name and press Enter, or simply click away, to create the task. Press Escape to discard what you typed instead.

In Capacity, each person’s scheduled task rows are open by default. Drag a task bar to move its work. The view includes work from other projects so you can see the person’s real load. If you have permission to schedule that task, you can move it here without opening its project first. Runnit checks your access against the task’s own project when you drop it.

Use the horizontal scrollbar at the bottom of the Capacity timeline to move backward or forward through dates. On a long task list, the scrollbar stays at the bottom of the browser window while the Capacity timeline remains visible.

Select Allow weekend assignments before a Capacity move when Saturdays and Sundays can carry the work. That choice is saved with the task and is reflected in its daily breakdown, Table, Gantt, and Capacity views. You can also drag that task onto Saturday or Sunday in Gantt after the task’s weekend setting is enabled. Organisation closure dates and days the assignee has blocked out as unavailable remain unavailable, and partially blocked days hold fewer hours.

Task and project changes update the open planning views automatically. You do not need to refresh the browser after moving a task, changing its hours, editing the project, or changing its lifecycle state.

Table layouts can be saved as personal or shared views. Personal views belong to you. Shared views require project management access and are visible to the project team.

The columns the table opens with come from your organisation’s defaults. An administrator can set them in the organisation settings, and a kanban board can set its own columns for the projects on that board (the board setting wins). Your own column changes are kept per project and always take precedence, as do saved views. Reset to default columns in the Columns menu returns the table to the configured default.

Project managers can add text, number, dropdown, date, checkbox, link, and rating columns. Client and organisation administrators can define shared columns that flow into related projects. An inherited column can be overridden or hidden for one project without changing its shared definition.

Most custom column types can be filled by AI from selected task fields. The column editor’s Fill with AI section explains what the AI reads and what it can’t: expand What it can and can’t do to see that it reads the task name, description, status, priority, tags, planned dates, estimated hours, progress, and any source columns you pick, and that it cannot read comments, files, time logs, other projects, or the internet. Every generated value is checked against the column’s type exactly like manual input, and the AI leaves a cell empty when it is unsure. AI-filled cells keep generation provenance, but remain normal project data after they are saved.

Before saving, select Test on sample tasks in the editor to try your instruction on a few real tasks from the project. The sample values appear in the dialog so you can refine the instruction. Preview values are not saved.

Saving an AI column is immediate. The fill runs in the background: the column header shows a progress count (for example, 30 of 88) while values appear in the table as they are generated, and a notice reports how many tasks were filled when the run completes. You can keep working, or even leave the page, and the remaining cells are picked up the next time the table loads.

Runnit refreshes an AI column after any task field changes, including a direct edit to a custom value. Rapid edits are grouped briefly so they don’t start repeated runs. Runnit also checks the AI columns when the task table is first opened each day and refreshes values generated before that day. Current values are skipped, so opening the table again does not repeat the same AI work. If a run fails, the last saved value stays in place and a later automatic or manual run can retry. Editing a shared (client or organisation) column refreshes the project you are in; other projects catch up when their tables next load.

Users with financial-report access can also show Rate, Actual hours, Planned billable, Actual billable, and Billable variance. These columns show the billable value of planned and logged time (they are not internal cost figures) and are hidden completely from people without that access.

Select any task in the Timeline views to open the shared task editor over the project. On desktop it uses a wider two-column layout, with the description and work status given more space and planning details grouped into clear sections. Authorised assignees can update their own task details, status, and progress without needing project-management access. If every selected task is one you can update, the Table bulk toolbar also lets you change their status or priority. A mixed selection that includes a task you can’t update keeps those actions unavailable. Assignment, scheduling, and deletion still require their specific permissions.

Dependencies and schedule changes

Task dependencies are finish-to-start. A blocked badge means at least one predecessor is not complete or cancelled. When a predecessor or dependency changes, Runnit can move dependant work forward through working days, closure dates, each assignee’s blocked-out dates, and the real capacity scheduler. Completed, cancelled, and undated dependant tasks do not move automatically.

Successful timeline changes update the views without a confirmation toast. If a date, hours, allocation, assignee, or dependency change creates a conflict or other issue, the timeline notice explains it and identifies dependant tasks that were rescheduled.

Keep project dates and milestones aligned

The project start and target dates are linked to kickoff and delivery milestones. Editing the project window moves the matching milestones. If a kickoff or delivery milestone is firm, Runnit asks you to confirm before moving it.

Editing milestones works in the other direction: the earliest kickoff becomes the project start and the latest delivery becomes the target date. Use the firm flag for dates that should never move without an explicit confirmation.

Mark milestones achieved

Each milestone shows a status pill based on its date and whether the team has reached it: Upcoming, Due today, Overdue, Achieved, Achieved late (reached after its target date), or Closed (the project itself has finished, so the date is no longer tracked).

To record that a milestone has been reached, tick the Achieved checkbox on its row in the Key dates section of the Table view, or use the tick button next to the milestone in the Edit key dates dialog. Marking a milestone achieved:

changes its status to Achieved (or Achieved late);
stops any further due or overdue notifications for it, including the overdue email; and
records who marked it and when in the project history.

If you marked the wrong milestone, clear the same checkbox to reopen it. The milestone returns to its date-based status and becomes eligible for due and overdue notifications again.

When a milestone passes its target date without being achieved, the project team and owner receive an overdue notification and email. Selecting the email’s button opens the project with that milestone highlighted and asks Has this milestone been reached?. Select Mark achieved to record it in one click, or Dismiss if the milestone is genuinely still outstanding.

Marking milestones achieved requires the project owner, a project admin, or an organisation admin or owner, and never moves any dates.

Finishing the project closes its key dates

You do not have to tick every milestone by hand before you close a project. When you move a project to Done or Completed, Runnit marks any key date that is still open as achieved and records it in the project history. No extra notification is sent, because the project completion notification already tells the team.

More generally, a finished project never sends overdue alerts. Once a project is Done, Completed, Cancelled, or Archived, Runnit stops sending overdue milestone and overdue task notifications for it, and its remaining key dates show as Closed instead of Overdue. If you reopen the project, alerting for any genuinely missed dates resumes.

Build an empty project

If the project was created without Brief Builder, start with these actions:

Add the project brief.
Add key dates and milestones.
Add team members with the right project access.
Create tasks with assignees, estimates, priorities, and dates.
Check the Gantt timeline and resolve schedule conflicts.
Set the budget and confirm rates if cost tracking is required.

Any schedules created while the project remains Draft are tentative. Choose Activate project when the plan is ready to confirm them. A generated draft may require a budget or project rate-card confirmation first.

The timeline fills as dated tasks and milestones are added.

On a client project, the client staffing list supplies the default team. A project owner or project admin can still add another active staff member from the organisation. Runnit labels that person Project only and allows them to work on this project without adding them to every project for the client.

Access and responsibility

Project owners and administrators can manage more settings than normal project members. Task creation, editing, assignment, scheduling, and deletion each use their own organisation capability. Those capabilities apply across projects the person can access, whether or not they are listed on the project team. Project owners and project admins retain a local override. Client staffing rules still control who can be assigned.

Runnit exposes the same permitted controls in the task table, Gantt and capacity views, the task editor, and global task creation. See Updating Tasks for the field-level rules.

For connected work, see Master Projects, Task Management, and Project History.