Projects

Portfolio management, delivery and governance in one application - and every surface in it reads from one process instead of from a stack of tools that have to be kept in agreement.

The hierarchy is yours, not a fixed ladder

Portfolio → project → stage → task → subtask, with goals, events, risks and issues as record types of the same process.

That is deliberately deeper and more flexible than the fixed epic-story-task-subtask ladder most tools impose - and because it is a process model and not a product's internal structure, the levels, the statuses and the transitions are yours to change.

Drill-down, not two lists. Selecting a portfolio reveals its projects in place, instead of showing a portfolio grid and a separately filterable project grid stacked on the same screen. One level at a time, so you always know where you are.

And every tab looks like what it is. Tasks are a real kanban board, stages are a real timeline, and the four registers are real tables, instead of one card-grid shape repeated regardless of what the tab represents.

Two kinds of Gantt, because they answer different questions

• A stage roadmap at project level - how the project lands in time.
• Task-level dependency scheduling - what actually blocks what.

Both carry classical dependency types - finish-to-start, start-to-start and the rest - and milestone markers. Clicking a bar on the roadmap opens that stage's edit panel, so reading the plan and changing it are the same activity.

Three registers, and the distinction between them is the point

Most tools give you one "issues" list. Governance needs three, and they behave differently:

A risk with no active mitigation is a different object from an open issue, and treating them as one list is how projects quietly stop managing risk at all.

The issue log your stakeholders already use

A customer or stakeholder maintains issues in a spreadsheet - the thing they were going to use anyway, whatever you built. Here that spreadsheet is part of the system:

• Saving a row creates or updates the governed issue in the project - a real record with a status, an owner and a history.
• The other direction holds too: the issue's live status always shows back in the sheet.

So the stakeholder never leaves their sheet, the PM never retypes anything, and there is exactly one truth about whether an issue is open. That is the shape of integration that usually costs a project its own middleware.

Budgeting from the bottom up

Two sheets, kept separate from the stage-level plan and actual figures:

• A resource plan - who, at what rate, for how many hours
• Other costs - the non-labour spend

That produces an estimate built from what the work consists of, not a number typed into a field.

On the project overview, a live budget summary sums planned against actual across the project's own stages - reading the current records and not a snapshot somebody refreshed.

Capacity, across projects rather than inside one

A workload grid as an editable sheet: one row per person, a weekly capacity column, and planned hours per week - with the allocation percentage colour-coded automatically to flag who is over and who is under.

Crucially it spans every project and portfolio, because the person who is overcommitted is rarely overcommitted within a single project. That view is one of the two things this application added deliberately after comparing the entity set against the established tools - the other being a portfolio-level budget and progress rollup instead of only a stage-level one.

What a PM opens in the morning

• A project overview with KPI tiles - health, budget, risks, goals - each carrying a status badge and not only a number, and each clicking through to its own tab.
• A risk heatmap of likelihood against impact.
• A cross-project task board - every task across every project on one kanban, so finding work does not mean opening projects one by one.
• A portfolio analytics page - project count by health and by status, stage budget totals planned against actual, and risk exposure by likelihood and impact - all reading live records instead of a static extract, through the engine.

Automations that run without anybody remembering

• A goal flipped to "at risk" notifies a configured recipient the moment it happens, not at the next status meeting.
• Actual start dates are stamped when work really begins, so the baseline comparison is against reality.
• The issue log stays in sync in both directions.
• A weekly project review is produced on schedule.

A digital employee on the team

That weekly review is not an anonymous background job. It is written by a named digital employee holding a PMO-analyst position in your org structure - with its own bounded rights, and permitted to write only into the two project fields reserved for it.

So the review has an author, a mandate, a budget and an audit trail, exactly like a person's work. See AI harness.

It does two things:

• The weekly review - computing a fresh health verdict for the project and for a representative stage, instead of repeating last week's.
• Structure from a brief - ask it in chat, and it turns a project brief into a stage, task and risk structure and creates it. The first day of a project stops being an afternoon of typing.

What it is made of

All of it is artifacts you can open and change - see Applications - which is the difference between a project tool you configure and a project system you own.