Can your team deliver this project?
Five numbers. Thirty seconds. Honest answer.
How many hours of engineering work will this project take?
Estimates should go from lowest to highest.
Estimates should go from lowest to highest
What does your team look like?
Team size, weekly pace, and weeks until the deadline.
→ 0 hours available in total
How the calculator works
The tool uses the classical PERT (Program Evaluation and Review Technique) three-point estimation method, originally developed for the U.S. Navy's Polaris programme in 1958 and still used as a standard reference in project management today. It takes three estimates — optimistic (O), likely (M), and conservative (P) — and combines them into an expected effort μ and a measure of uncertainty σ:
The four-times weighting on M reflects that the likely estimate is the most probable outcome, while the optimistic and conservative values still pull the mean toward reality. The standard deviation σ captures how uncertain the estimate is, with a wide difference between O and P reflecting the low confidence on project scope.
A probabilistic approach is then taken to estimate the likelihood of being overworked. The equations describing the situation are:
Where P(X ≤ x) is the probability that the effort (measured in team hours) is less than the available hours. It must be noted that this approach assumes effort is normally distributed, which is not always the case and particularly deviates from reality on large projects. Nevertheless, it still serves as a general-purpose metric to identify overload.
What the result means
Your team is well-positioned. The buffer above the likely estimate is real breathing room, even accounting for uncertainty.
You're covered on paper, but only if everything goes to plan. One task running over, one person pulled elsewhere, and you're short. Worth having a contingency.
The maths don't work. Not as a prediction of failure, but as a clear signal: the project needs more resource, more time, or a tighter scope — before you commit.
Why estimation is hard
Most engineering teams say yes before they know the answer — not because they're reckless, but because predicting effort isn't easy. Many times a project arrives, someone senior does a quick mental calculation, and the team commits. Three months later the deadline is missed, the scope has grown, and two engineers are working weekends. Essentially, effort estimation is genuinely hard.
The two numbers that matter
Every project comes down to a simple comparison: needed hours against available hours. If demand exceeds capacity, the project is in trouble before it starts. If capacity exceeds demand, you're fine. If the numbers are close, it matters how close.
Both numbers are harder to get honestly than they look. We are human, and we carry bias. On the demand side, engineers tend to estimate the best case. On the capacity side, managers tend to overestimate the team's available hours. Both errors push in the same direction — the scenario looks better than it actually is, and the team eventually becomes overloaded.
Parkinson's Law and the R&D problem
There is a third problem, particular to R&D: in research environments, work expands to fill whatever time and budget exists. If you allocate six months and a fixed budget, you can be sure all of it will be spent — not because the work required it, but because there is always another test to run, another variable to explore, another result to validate. If you don't define what done looks like before you start, the finish line moves and the budget is consumed.
When the numbers don't add up
That's where C2E comes in. We work with research teams and engineering companies that have a project in front of them and not quite enough capacity to deliver it. We come in, deliver the engineering work, and step back. No full-time hire, no long onboarding — just the hours you need, when you need them.
Tell us about your project.
One conversation to assess fit. We'll tell you directly whether we can help and what that looks like.
Email C2E →