Lab: an EVM and Monte Carlo notebook in Python

0:00 Build it once, check every tool forever

Here's something that changed how I work. The first time I built an earned value calculation and a Monte Carlo simulation myself, line by line, I stopped treating my tools as black boxes. I could check them. And when a number in a report looked odd, I could reproduce it in minutes. In this lab lecture I'm going to walk you through a small Jupyter notebook that does the analytical core of a monthly controls cycle. Earned value metrics and trends by control account. An EAC range with the to-complete index. A simple anomaly flag. A Monte Carlo schedule risk analysis with a discrete risk and correlation. And finally, a structured status table for review. By the end you'll have a notebook you can adapt to your own project data.

0:57 Why a notebook?

Why a notebook rather than just using Primavera P6, Power BI or a risk tool? You should use those. They do this at scale, with proper data connections, security and audit. But a notebook gives you three things. Transparency: every calculation is visible and readable, which is exactly what you need when someone challenges a number. Repeatability: the same steps run the same way every month, with no copy-paste errors. And validation: you can check that your enterprise tool is doing what you think it is. If your notebook and your scheduling tool disagree about a deterministic finish date on the same network, one of them has a hidden constraint, a calendar issue or a lag that somebody needs to explain.

1:50 The setup

The setup takes five minutes. Create a Python virtual environment, install pandas, NumPy, Jupyter and matplotlib, and open a new notebook. The exact commands are in the lesson text. Now, the most important design decision is the shape of your data. One row per control account per period, with cumulative planned value, earned value and actual cost, plus the budget at completion. In the lab, I type a small illustrative table straight into the first cell: two accounts, civil and pumps, over four months. In real use, that cell becomes a single line that reads a CSV exported from your ERP and scheduling system. Keep the shape identical and everything downstream just works.

2:39 Cell two: earned value, done correctly

Cell two calculates the metrics. For every account and period: CPI is earned value over actual cost, SPI is earned value over planned value, cost and schedule variances are earned value minus actual cost and earned value minus planned value. Then the CPI-method EAC, the composite EAC and the to-complete index to budget. Look at the latest period. Civil has a CPI of about nought point nine seven. Healthy enough. Pumps has a CPI of nought point eight one and an SPI of nought point seven nine. Its CPI-method EAC is about six point one four million against a five million budget, and the TCPI to budget is one point two two. Here's the key idea: a budget-level forecast for pumps is not credible without a specific, evidenced change in how the work is being done.

3:38 Cell three: a simple anomaly flag

Cell three is an anomaly flag, and I want to make a point about AI here. You don't have to start with machine learning. A simple rule, such as 'CPI has fallen for three consecutive periods', catches a surprising share of what matters, and anyone can understand why it fired. In our data, it flags pumps. Later, you might add a statistical test on cost postings, or a trained model that looks for miscoded costs or duplicate invoices. That's worthwhile. But keep the simple rules running alongside, as a baseline. If a sophisticated model can't beat a transparent rule on your historical data, you don't need the model yet.

4:25 Cell four: Monte Carlo schedule risk

Cell four is the Monte Carlo. There are five activities: design, procure, civil, install and commission. Procurement and civil works run in parallel after design, and installation needs both. Each activity has a minimum, most likely and maximum duration, sampled from a PERT distribution, which gives more weight to the most likely value than a triangular does. Then two refinements that make the model realistic. First, correlation: civil and installation share a site productivity factor, so if productivity is poor, both suffer together. Ignore that and your range comes out unrealistically narrow. Second, a discrete risk from the register, R-07, grid approval: a thirty per cent chance of adding ten to twenty-five days to commissioning. We run twenty thousand iterations, and the finish is simply the early finish of commissioning in each run.

5:23 Watch me do it: reading the results

Let me run it and read the output with you. The deterministic plan, adding the most likely durations along the longest path, is one hundred and three days. The simulation says there's only about an eleven per cent chance of finishing by then. P50 is around one hundred and thirteen days, and P80 around one hundred and twenty-five. Why such a gap? Two reasons. The ranges are skewed: things can go much more wrong than right. And the thirty per cent risk on commissioning adds a long tail. Next, criticality. Procurement drives installation in about ninety-six per cent of runs, so it's effectively critical. And the tornado, which ranks each activity's correlation with the finish, puts commissioning first, because it carries the risk, and procurement second. That's exactly where mitigation buys the most confidence.

6:21 Cell six: a structured status table, and AI

The final cell writes a status table: CPI, SPI, cost variance, EAC and TCPI by account, plus the P50 and P80 finish. This becomes the single reviewed source for the monthly narrative. If your organisation allows it, you can give this table, and only this table, to an approved enterprise AI assistant with a prompt that says: draft a short narrative, cite the column for every number, and don't state causes that aren't in the data. It will produce a decent first draft in seconds. Then the controls lead checks every figure against the notebook, confirms causes with the control account managers and records what changed. The AI saves time on drafting. The person owns the forecast.

7:12 Common mistakes and extending the lab

A few mistakes to avoid. Averaging CPIs across accounts: always compute from summed earned value and actual cost, so big accounts carry their proper weight. Running Monte Carlo on a network with missing logic, which produces precise-looking nonsense. Reporting P80 to two decimal places of a day, which implies precision you don't have. And sending an AI-drafted narrative without checking every number. When you're ready to extend the lab, replace the typed data with your real exports, add lags and start-to-start and finish-to-finish links, map more risks from your register, and link time-dependent costs to duration so schedule risk flows into cost risk. And validate: your notebook's deterministic finish should match your scheduling tool's for the same network.

8:03 Recap and try this now

Let's recap. You've built a notebook that loads earned value data by account and period, calculates the metrics correctly, produces an EAC range and TCPI, flags a worrying trend with a simple rule, runs a Monte Carlo schedule risk analysis with PERT ranges, correlation and a discrete risk, identifies the critical drivers, and writes a structured status table for human review. Here's your try-this-now. Build the notebook from the lesson text and run it. Then change one thing: widen the maximum duration for procurement from seventy to ninety days, and run it again. How far does P80 move? And does the plan confidence change? That single experiment will teach you more about schedule risk than any histogram in a report.