Project risks and estimate vs. actual hours

Current tracks two different kinds of "are we going to be OK?" on a project. The risk register captures what could go wrong — the vendor that might be late, the firewall you might not get access to — with a likelihood, an impact, an owner, and a mitigation plan. Estimated hours capture how long the work should take, so that when it's done you can compare plan against reality. Both live on the project page, and neither one is ever visible to a partner.

Open a project from Portfolio (or My Day) and scroll to the Risk register panel near the bottom of the project page. Project managers and tenant admins see an Add risk button; engineers can read the register but not change it.

1. 1
   Click Add risk

   The inline form opens above the list.
2. 2
   Give it a short title

   This is the only required field — e.g. "Vendor lead time may slip." Everything else is optional.
3. 3
   Set likelihood and impact

   Each is Low, Med, or High. Both default to Med.
4. 4
   Pick an owner (optional)

   Any workspace member. Defaults to Unassigned.
5. 5
   Write the mitigation plan (optional)

   What you'll do about it. It shows under the risk title in the list.
6. 6
   Click Add risk to save

   The risk lands with status Open. Change the status any time from the coloured chip on the row.

Every risk gets a score: likelihood × impact, where Low = 1, Med = 2 and High = 3. That gives 1 through 9, and the colour follows the number.

The 3×3 matrix to the right of the list plots the same thing — impact down the side, likelihood across the bottom — with a count in each cell. Closed risks drop out of the matrix.

1. 1
   Open the task

   From the project page, the Kanban board, or the Timeline — they all open the same task drawer.
2. 2
   Find Estimated hours in the Details section

   The field steps in quarter-hours and accepts 0 to 9,999. Anything higher is clamped down to 9,999 when it saves. Leave it empty and the task reads "Not estimated."
3. 3
   Click Save

   On a PSA-synced task the footer button reads Save & sync, and the estimate is written to the PSA task's estimated hours at the same time.

Estimate at the task level, not the project level — that's what makes the rest of the numbers work. The Schedule board puts each task's whole estimated-hours figure on its due date (end date) as a single chip — it does not spread the hours across the days the task spans. Daily capacity is the person's weekly target divided by 5 (a 40-hour target = 8 hours a day), and PTO, holiday and blocked days are zeroed. A task with no estimate still shows as a chip but adds zero hours to the bar, which is why a fully-booked engineer can look free; a task with no assignee or no due date isn't on the grid at all — it sits in the unscheduled tray.

The Estimate vs actual panel sits on the project page beside Budget & actuals. It lists every task that has an estimate or has logged time, with four columns: Task, Est., Actual and Variance.

• ＋Variance = actual − estimate. A red +6h chip means the task ran six hours over; a green −2h chip means it came in under. Hover the chip for the percentage.
• ＋Actual hours follow Current's source-of-truth rule: if your PSA reports worked hours for the task, that's what's shown; otherwise it's the time logged in Current. So a synced project where techs log time in the PSA still reads correctly here.
• ＋Where the figure comes from Current's own time entries, time a manager rejected and time your PSA voided are both left out, so a task can read fewer actual hours than it did before 26 July 2026 and a variance chip can turn from red to green. Where the figure is your PSA's own worked hours, it is your PSA's number: it already leaves out anything the PSA voided, but time a manager rejected can still be inside it, because Current does not re-cut a figure the PSA reported. The same is true of the totals in a project's close-out pack.
• ＋The Total row's variance only counts tasks that actually carry an estimate — a task nobody estimated but everybody worked on can't fake an over-run.
• ＋Inside a task, the time section shows the same story live: "4h logged of 6h estimated," with the bar turning amber at 80% of the estimate and red once you pass it.

These two panels sit side by side and get confused constantly. They measure different things and only one of them moves a project's health score.

A single over-run is noise; the same task running 40% long on five projects is a quoting problem. On the Playbooks page, managers see a Hours learning panel — "N suggestions across your templates" — comparing each template task's estimate against how long it really ran on completed projects cloned from that template.

• ＋A suggestion appears only once at least 3 completed, hours-bearing instances of that task exist across clones of the template — normally 3 completed projects, but same-named tasks inside one project each count as an instance.
• ＋It only surfaces when reality is off by 15% or more, or when the template task has no estimate at all.
• ＋The suggested figure is the average actual, rounded to the nearest quarter-hour and clamped to the range Apply accepts (0.25h to 999h); the row also shows the median so you can judge the spread.
• ＋Apply writes it onto the template task, so the next clone starts with an honest estimate. Dismiss hides it until the numbers change.
• ＋Only projects cloned after Current began stamping template lineage count as evidence — suggestions build up as new projects complete.
• ＋On a task whose actual hours come from Current's own time entries, rejected and voided time no longer counts toward the average, so a suggestion can read slightly lower than it did before 26 July 2026. On a task your PSA reported worked hours for, the suggestion uses the PSA's figure and is unchanged.

For the wider view, the Reports cockpit has a Risk lens that keeps two sources separate: risks flagged by Current's AI analysis (severity only — not register entries) and the risks your PMs logged by hand, as a heatmap, a status breakdown and a full register. Portfolio can also sort by Open risks or filter to projects that have any. See "Reports: the reports cockpit and its lenses" and "Project templates and PMI playbooks."