ProjectMetrix

Project · Program · Portfolio management for enterprise IT

Agentic project control for enterprise IT.

ProjectMetrix continuously monitors schedules, risks, dependencies and commitments, detects emerging problems from current and historical delivery data, and recommends the actions that keep projects on plan, while automating the chasing and reporting that consumes a PM's week.

Built on a real deterministic scheduling engine — not an AI-generated task list.

Test Drive Beta Try the live demo How it works What exists today
ProjectMetrix Gantt view showing a data center migration plan with critical path highlighted, dependency links, and an editable schedule grid

From project activity to project control

Most tools record what teams say happened. ProjectMetrix continuously compares what is happening against what was supposed to happen, identifies where execution is diverging, and helps the PM decide what to do about it, early enough that it still matters.

Status arrives too late

Slippage surfaces in a status meeting weeks after the float quietly ran out. By the time it is visible, the recovery options that were cheap have expired.

PMs spend their week chasing

Collecting updates, reconciling spreadsheets and assembling reports crowds out the judgment work that only an experienced PM can do.

Plans repeat the same optimism

Every new project is estimated from scratch and from hope, while the organization's own record of how this work actually goes sits unused in closed projects.

A closed loop, not a dashboard

ProjectMetrix runs the delivery control cycle continuously. Each pass produces evidence for the next one, and every change to the plan passes through a human.

Step 1 · Plan

Build a real schedule

Tasks, dependencies, constraints, calendars and baselines. A deterministic critical-path engine computes every date, so the plan is a model that can be reasoned about, not a list.

Step 2 · Monitor & detect

Watch for divergence

Progress, float erosion, milestone trends, open risks and outstanding commitments are compared against baseline continuously, and deviations are flagged as they emerge.

Step 3 · Predict & recommend

Model the impact

The engine simulates what a delay actually costs and what each recovery option would buy. Agents propose the corrective action, with the evidence they reasoned from attached.

Step 4 · Decide & learn

The PM decides

A human approves, edits or rejects. The plan is re-computed, the decision and its outcome are recorded, and that record informs the next project's estimates and risks.

Agents do the monitoring. PMs make the decisions.

Propose, don't impose

Assistants write proposals, not changes. A human reviews and approves in an inbox. Where auto-execution is genuinely safe (a reminder email, a metrics snapshot) it's explicit and configurable, not assumed.

Evidence or it doesn't ship

Every proposal cites what it reasoned from: the meeting note and the exact quote, the risks that materialized on similar past projects, the float that's been eroding for three weeks. No citation, no proposal.

The engine does the arithmetic

Dates, float, impact and metrics are computed deterministically. The language model explains, extracts and drafts. It never does the math. Ask twice, get the same numbers.

Agent inbox showing proposals from the action item, risk and reporting assistants, each with supporting evidence and approve or reject actions

The agents, and what each one is for

Each agent exists to close one gap between what a PM should notice and what a PM has time to notice. These are designed and specified. See the roadmap for what is running today.

Project Control Agent

Monitors schedule performance, float erosion and milestone trends. Detects slippage while it is still emerging. Recommends modeled recovery options. So that the committed date is defended before it is missed.

Risk Agent

Monitors the live risk register and leading indicators across the portfolio. Detects conditions that preceded failures on similar past projects. Recommends mitigations with the precedent attached. So that risk management is evidence-led rather than a quarterly ritual.

Planning Agent

Monitors how comparable projects actually ran: durations, sequencing, what went wrong. Detects estimates that history says are optimistic. Drafts a plan grounded in that record. So that new work starts from evidence instead of hope.

Task Agent

Monitors owners, due dates and open commitments. Detects what is drifting or unanswered. Acts by chasing owners and keeping status current. So that the PM stops spending their week collecting updates.

Reporting Agent

Monitors the plan, the risks and the narrative teams are telling. Detects divergence between reported status and computed reality. Drafts the status report for review. So that reporting takes minutes and says something true.

Meeting Agent

Monitors meeting notes and delivery conversations. Detects the schedule changes buried in them: new dates, new blockers, new commitments. Proposes a batch of plan updates for approval. So that what was agreed in the room reaches the plan.

Real scheduling underneath

Agents can only perform genuine project control if the project data is trustworthy. That is why the scheduling engine came first: it is what turns a task list into something an agent can reason about, simulate against, and be held to.

Critical path, on the web

Plans of a thousand tasks and more, with an editable grid beside an interactive Gantt. Durations, dates, predecessors, constraints and resources are all editable inline; the engine recomputes the entire network on every edit and the chart redraws immediately.

Filter to the critical path and the plan collapses to the chain that actually drives your finish date. These are the tasks where a day lost is a day lost on the project.

The same plan filtered to critical path only, showing just the zero-float chain in green

Ask for what you want

"How are we doing?" · "Push the DB migration out three days" · "What does this task block?" The assistant understands your plan, and any request that would change the schedule is simulated first.

The preview is the point: before anything is written, you see exactly which tasks move, which milestones slip, and what it does to the finish date. Then you confirm, or you don't.

Chat panel showing a requested three-day delay, with a table of affected tasks, milestone slips, and Confirm or Cancel buttons

Portfolio and program rollups

Programs roll up from their projects and portfolios from their programs — health, progress, finish dates, slip against baseline, open risks and overdue actions. All computed bottom-up from the schedules underneath, never hand-entered into a status spreadsheet.

Portfolio view listing programs with their projects, showing rolled-up health, progress, finish dates and slip

Health that explains itself

Every status color comes with the reasons behind it: how far the finish date has slipped, how delivery compares with the plan, which risks are live, and what's overdue. Baselines make plan-versus-actual visible instead of anecdotal.

Status view showing computed project health with a why-this-RAG explanation, milestone variance against baseline, and top risks

Delivery measured against outcomes

Objectives and key results, with programs linked to the results they're meant to move. Each key result shows two numbers side by side: the business outcome, and the delivery progress rolled up from the schedule.

When delivery reads 100% and the outcome reads 40%, that's the conversation worth having. We shipped it, and it didn't move the needle.

OKR view with executive and org-level objectives, each key result showing outcome progress next to delivery progress rolled up from linked programs

It gets better with every project you deliver

Every plan, every baseline change, every risk that materialized and every date that moved is recorded against the organization that delivered it. That record of planned versus actual, over and over, is what the agents reason from. It is specific to a company and cannot be bought in.

Project 1

Observe

Planned versus actual durations, dependency failures, risks that materialized, decisions taken and what followed them.

Project 10

Recognize

Patterns that preceded slippage here start to be identifiable: the vendor lead time that is always understated, the environment handover that always slips.

Project 50

Anticipate

Planning and risk recommendations reflect how this organization actually delivers, rather than generic project-management assumptions.

Always

Stay accountable

Every recommendation carries the history it came from, so a PM can judge the reasoning instead of trusting a score.

This is how the product is designed to work as delivery history accumulates. ProjectMetrix is pre-launch, so there is no customer corpus yet.

What exists today, and what doesn't

The scheduling and data foundation came first on purpose: agents that reason about a portfolio are only as good as the schedule underneath them. What's here today is honest, and so is what isn't.

Built

  • Critical-path scheduling engine with all four dependency types, lead and lag, float, part-day durations, working-time calendars with holidays and exceptions, and the full set of task constraints
  • Interactive Gantt and editable plan grid, 1,000+ task plans, recomputed in milliseconds
  • Baselines, plan-versus-actual variance, program and portfolio rollups
  • Computed project health with explained reasoning, and OKR linkage
  • Multi-tenant data platform with row-level isolation, append-only audit history
  • Enterprise single sign-on via OIDC with directory federation and joiner/leaver sync

Live in the beta

  • The web application, running for invited accounts
  • Chase agent: chases the people who own overdue or at-risk tasks over Slack and email, and turns their replies into schedule changes the PM approves
  • Slack and email nudges, with one-click confirmations and an approval queue where nothing changes the plan without a person
  • Every project carries an owning project manager; escalation copies them when a task slips
  • Jira importer: connect a Jira Cloud site and bring a project in through the same engine a customer would use
  • Change tracked against baselines, with rebaselining as an approved decision rather than an automatic side effect, so pre-existing drift is never quietly absorbed

Designed

  • Conversational assistant: plain-language querying and editing, with every write simulated and previewed before it is applied
  • Access control: teams granted access at portfolio, program or project level and inherited downward, with confidential projects kept out of inherited access
  • Project Control Agent: keeps the PM ahead of trends before they become slips
  • Risk Agent: predicts emerging risk from what actually materialized on similar past projects
  • Planning Agent: drafts plans for new work from how similar projects really ran
  • Reporting Agent: drafts the status report, with sentiment and divergence flags
  • Meeting Agent: turns meeting notes into a proposed batch of schedule updates for approval

Planned

  • Capacity Agent: forecasts resource crunches before they hit delivery dates
  • Cross-Project Dependency Agent: warns when one project's slip breaks another's assumptions
  • Benefits Agent: tracks whether delivered projects moved the business outcome
  • Advanced scheduling: resource levelling and effort-driven tasks
  • Jira two-way sync: scheduled status, progress and velocity, feeding the metrics the agents read
  • Confluence: meeting notes and decision records as evidence for extraction

Get in touch

ProjectMetrix is built and delivered as a tailored deployment for each customer rather than a self-serve signup. If you run a PMO and the problems above sound familiar, or you'd like a walkthrough of the product, I'd like to hear from you.

Get in touch Try the demo How it's built