Project Forecasting, Capacity and Financial Control
Product development and service company · Digital Product Delivery & PMO · 2025–2026
The challenge
Project information was distributed across Jira tickets, worklogs, supplier references, purchase orders, and financial classifications. Traditional status reporting could describe what had already happened, but managers also needed to understand what a scope change meant for remaining effort, available capacity, financial exposure, and the forecast deadline. The real requirement was not another static dashboard; it was a traceable model that connected delivery progress with the decisions required next.
My role
I worked across business analysis, data-model design, Power BI development, forecasting logic, financial-control rules, PMO reporting, and stakeholder coordination to turn fragmented delivery data into a usable portfolio decision model.
Delivery approach
- 1Defined the management questions first: project status, estimates versus actual effort, remaining work, capacity, supplier exposure, risks, ownership, and upcoming decisions.
- 2Structured Jira ticket and epic data through a shared issue dimension, connected worklogs to actual effort, and integrated supplier and financial references into the reporting model.
- 3Created CAPEX/OPEX control logic covering project and supplier cost calculation, monthly financial grouping, budget utilisation, and traceable exception handling.
- 4Added measures for variance, burn, remaining work, burndown, delivery pace, and forecast completion.
- 5Extended the model with scenario calculations: when scope changes, it can show the capacity adjustment required to preserve the deadline or the revised deadline required when capacity remains fixed.
- 6Developed the wider portfolio-data architecture around SharePoint Lists, Power Automate, structured data exchange, authentication considerations, and Power BI integration.
Business value
- Created a working forecasting model under active development rather than a retrospective status report
- Connected project progress, estimates, actual effort, capacity, financial exposure, risks, dependencies, ownership, and actions
- Turned scope changes into explicit capacity-or-deadline management decisions
- Provided project, supplier, CAPEX/OPEX, monthly, and budget-utilisation views from traceable source data
- Made missing data, conflicting references, and financial exceptions visible for correction
- Established a stronger foundation for portfolio review, resource planning, and executive delivery governance
Project delivery forecast
Ticket completion can look healthy while the larger pieces of work, delivery pace, or resource forecast tell a different story. Change the synthetic project and filters to see how the management signal changes.
Project
Workstream
Cost class
Issue type
Current scenario
Northstar Release
Healthy delivery: effort, progress and pace remain broadly aligned with the target date.
- Snapshot
- 10 Apr 2026
- Target
- 30 Apr 2026
Effort-weighted progress
78%
64% by ticket count · 7/11 closed
Budget utilisation
82%
626 h actual · 760 h budget
Forecast variance
-11%
-84 h vs budget · 676 h forecast
Deadline status
On track
30 Apr 2026 target · 12 working days buffer
Delivery forecast
The forecast estimates when the currently estimated scope would finish if the recent delivery pace continues. It is a schedule projection based on remaining effort and observed delivery evidence, not a promise or a percentage-complete calculation.
Remaining work
50 h
Recent pace
15 h / working day
Required pace
3.3 h / working day
Working days remaining
15
Forecast completion
16 Apr 2026
Schedule buffer
+12 working days
Management signal
Recent delivery pace supports the estimated work with buffer remaining; one or more open items are not yet included in the forecast.
1 open item is not fully represented in the current estimate, so the forecast should be treated as incomplete.
How the delivery forecast is measured
The calculation combines the amount of work still expected with the rate at which estimated work has recently been completed. The demo currently uses the previous 10 working days as the recent-pace window.
1. Remaining work
Add the current remaining estimates of all open issues in the selected scope. This is the amount of effort the team currently believes is still needed.
2. Recent delivery pace
Add the estimated effort of issues completed during the previous 10 working days and divide by 10. In this demo, the original estimate represents completed effort where it is available; actual effort is used as a fallback.
3. Working days required
Divide remaining work by recent delivery pace. This answers: at the recent observed rate, how many working days would the current estimated scope still require?
4. Forecast completion date
Add the calculated working days required to the snapshot date. That produces the forecast completion date for the current scope and pace.
5. Required pace
Divide remaining work by the working days available until the baseline deadline. This is the average pace now required to finish on the baseline date.
6. Schedule buffer
Compare working days available until the baseline deadline with working days required at the recent pace. A positive value is margin; a negative value means the projected finish is after the baseline date.
How to read the forecast
Recent pace vs required pace
If recent pace is comfortably above required pace, the current delivery evidence supports the deadline. If recent pace is below required pace, the team would need a change in pace, scope, capacity or date to recover the plan.
Forecast date vs baseline deadline
Compare the forecast completion date with the baseline deadline of 30 Apr 2026. Earlier means positive schedule margin; later means the current trajectory does not support the baseline date.
Schedule buffer
Buffer shows how much tolerance remains if the current pace continues. A forecast that technically finishes before the deadline but has almost no buffer is still vulnerable to normal delivery variation.
Data completeness
Missing remaining estimates weaken the forecast because some open work is not included in the projected effort. A precise date based on incomplete scope should not be treated as precise evidence.
Baseline deadline check
The current forecast is 16 Apr 2026, before the 30 Apr 2026 baseline deadline. The current delivery evidence supports the baseline date with positive schedule margin.
In a production dashboard, the forecast completion date is a useful indicator of whether the baseline deadline was realistic. The strongest evidence comes from its trend over time: if forecast dates repeatedly remain later than the baseline while scope, estimates and delivery conditions are reasonably stable, the baseline was probably too optimistic or its original assumptions are no longer valid. Repeated forecasts substantially before the baseline can indicate conservative planning or improved delivery conditions.
A single forecast should not be used to declare a baseline date correct or incorrect. Scope changes, temporary capacity changes and estimate revisions can all move the forecast.
Data that must be maintained
A working dashboard needs relatively simple source data, but it has to be maintained consistently. The forecast is only as reliable as the remaining estimates, completion history and working calendar behind it.
| Data point | Why it is needed |
|---|---|
| Baseline deadline | Provides the planned finish date against which required pace, buffer and forecast completion are compared. |
| Snapshot / as-of date | Anchors the calculation in time and defines when the forecast is being evaluated. |
| Working calendar | Defines which days count as available delivery days. This demo excludes weekends; a production model should use the actual working calendar and relevant holidays. |
| Issue status | Separates open work from completed work so remaining scope can be calculated. |
| Original estimate | Provides an effort measure for completed work and a reference against which estimate movement can be understood. |
| Current remaining estimate | Provides the current effort still expected for every open issue. This is the main input to Remaining Work. |
| Completion date | Identifies which issues were completed inside the recent delivery window used to calculate pace. |
| Actual effort | Supports delivery and forecast analysis and provides a fallback effort measure when completed work has no original estimate. |
| Forecast history | Recommended for production use. Retaining forecast completion, remaining work and pace at each snapshot makes it possible to judge whether the baseline deadline remains plausible over time. |
Remaining work
Compares the baseline-estimated scope still open over time with an ideal linear trajectory toward the target date.
Burndown position
Evaluated as of 10 Apr 2026: 150 h actual remaining versus 152 h ideal remaining.
2 fewer baseline-estimated hours remain than the ideal trajectory would suggest. The project is ahead of the ideal burn trajectory.
How to read this chart
Actual remaining
The solid line tracks the original estimated effort attached to items that were still open on each date. It shows how much baseline-estimated scope had not yet been completed.
Ideal remaining
The dashed line is a linear reference trajectory from the original baseline at the project start to zero remaining at the target date.
The distance between the lines shows whether baseline-estimated scope is being completed faster or slower than the ideal trajectory. If the actual line is above the ideal line, more work remains than the reference trajectory would suggest. If it is below the ideal line, less work remains than expected at that point.
Important distinction
Burndown remaining and Remaining Work are related but different concepts. The burndown uses original estimates to show the historical delivery trajectory. Remaining Work in the forecast uses the current remaining estimates on open items to describe how much effort is now expected to be needed to finish the work.
Scope growth
Counts issues when they are created and accumulates them over time by type. This shows how the number and composition of scope changed during the project.
Scope at the latest point
11 issues created by 6 Apr 2026.
Feature 5 · Enabler 3 · Defect 2 · Research 1
How to read this chart
The upper edge of the stacked area is the total number of issues created up to each date. Each coloured band is the cumulative number of issues of that type. A step upward means new scope was recorded on that date; a flat section means no new issues were added in the selected view.
Scope growth
A steep rise means several issues were added in a short period. If the top line keeps rising late in the project, scope is still expanding rather than settling.
Type mix
The band that grows tells you what is driving the change. Late defect growth can indicate newly discovered corrective work; feature growth shows additional product scope; enabler or research growth shows supporting or discovery work entering the plan.
Delivery pressure
Read this together with burndown and the forecast. If created scope keeps rising while remaining work is not falling fast enough, pressure is coming from both incoming scope and delivery pace.
What this chart does not show
Every issue counts as one regardless of size. Ten small tickets and ten large tickets produce the same count. Use the burnup to understand scope growth and composition, then use effort-weighted progress and Remaining Work to understand the size of that work.
Financial control
CAPEX/OPEX classification is attached to the people doing the work. Their estimates are compared with logged effort and the current remaining estimate so the project can see where forecast effort is moving above or below what each resource originally estimated.
Resources
5
3 CAPEX · 2 OPEX
Estimated
695 h
Resource estimate for selected scope
Logged
626 h
Effort already recorded
Remaining estimate
50 h
Current expected effort still required
Forecast at completion
676 h
-19 h variance · -3%
CAPEX resources
3
-13 hforecast variance
- Estimated
- 490 h
- Logged
- 459 h
- Forecast
- 477 h
OPEX resources
2
-6 hforecast variance
- Estimated
- 205 h
- Logged
- 167 h
- Forecast
- 199 h
Financial control signal
The selected resource forecast is -19 h (-3%) below the aggregated estimate.
The largest positive resource variance is currently Evan Cole (Developer) at +1 h.
1 resource forecast is incomplete because estimate or remaining-estimate data is missing.
| Resource | Role | Class | Issues | Estimated | Logged | Remaining | Forecast | Variance | Signal |
|---|---|---|---|---|---|---|---|---|---|
| Leah Sutton | UI/UX Specialist | CAPEX | 2 | 175 h | 148 h | 18 h | 166 h | -9 h(-5%) | Within estimate |
| Mara Quinn | Developer | CAPEX | 3 | 170 h | 165 h | 0 h | 165 h | -5 h(-3%) | Forecast incomplete 1 item estimate missing. |
| Evan Cole | Developer | CAPEX | 2 | 145 h | 146 h | 0 h | 146 h | +1 h(+1%) | Forecast above estimate |
| Noah Byrne | Tester | OPEX | 2 | 110 h | 90 h | 14 h | 104 h | -6 h(-5%) | Within estimate |
| Theo Marin | Consultant | OPEX | 2 | 95 h | 77 h | 18 h | 95 h | 0 h(0%) | Within estimate |
How to read this financial control
Resource, role and class
The row is the individual person doing the work. Role describes what that person does—developer, tester, UI/UX specialist or consultant. CAPEX/OPEX is a separate financial classification attached to the resource; it is not inferred from the role itself.
Estimated and logged
Estimated is the effort the resource has estimated for the selected project scope. Logged is the effort already recorded against that work. Logged hours therefore show consumed effort, not a plan or allocation.
Remaining and forecast
Remaining Estimate is the resource's current view of the effort still needed. Forecast at Completion is Logged + Remaining. This means the forecast can change before all of the effort has actually been consumed.
Variance
Variance is Forecast at Completion − Estimated. A positive variance means the resource is currently expected to need more effort than estimated; a negative variance means the forecast remains below the estimate. Missing estimates make the forecast incomplete rather than artificially favourable.
What this helps you conclude
The class summaries show whether forecast pressure is concentrated in CAPEX or OPEX resources. The resource table shows who is driving that variance and whether it comes from effort already logged or from a higher remaining estimate. A rising remaining estimate is an early warning: the forecast can deteriorate before the logged-hours total alone looks problematic. Missing resource classifications or missing estimates are governance exceptions because they prevent a complete view of the project's financial effort profile.
This control is expressed in effort hours. Its financial relevance comes from classifying resource effort as CAPEX or OPEX; it is not presenting synthetic hours as currency or as an approved project budget.
Delivery quality
Classifies each issue from estimate completeness and forecast movement so the review list below can focus on items where the current delivery signal needs attention.
- Healthy
- 10
- Enough data is present and the issue stays within the expected forecast range.
- Attention needed
- 0
- A review flag or material forecast overrun means the issue should be checked.
- Critical
- 0
- An open issue combines a review flag with a larger forecast overrun.
- Not evaluable
- 1
- Required estimate data is missing, so the issue cannot be assessed reliably.
How issue health is measured
For open issues, the working forecast is calculated as actual effort already spent plus the current remaining estimate. That forecast is compared with the original estimate.
Open issue forecast
Actual effort + current remaining estimate
Healthy
Open issues have both estimates, no explicit review reason, and a forecast no more than 115% of the original estimate. Completed issues are healthy when actual effort is no more than 130% of the original estimate.
Attention needed
An open issue is flagged when it has an explicit review reason or its forecast exceeds 115% of the original estimate, unless it meets the critical rule. A completed issue is flagged when actual effort exceeds 130% of its original estimate.
Critical
Applies to open issues when there is an explicit review reason and the forecast also exceeds 120% of the original estimate.
Not evaluable
The original estimate is missing, or an open issue has no current remaining estimate. Without those values, the forecast comparison cannot be calculated consistently.
These are management exception rules, not a quality score. They are intended to show where forecast movement or missing data deserves review.
Management attention
The dashboard does not stop at a warning signal; it identifies the records behind it.
| Item | Workstream | Status | Estimate | Remaining | Why review it |
|---|---|---|---|---|---|
DEMO-N11 Post-launch telemetry check | Data Services | Backlog | Missing | Missing | Not evaluable New scope is awaiting an estimate before it can be included in the forecast. |
All project names, resource names, issue data, dates, estimates and effort values shown in this demonstration are fictional and were created solely to explain the reporting approach.