Can your team actually deliver this project?

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

What does your team look like?

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:

μ = (O + 4·M + P) / 6
σ = (P − O) / 6

The weighting of four on the likely estimate reflects the assumption that it is the most probable outcome, while still letting the optimistic and conservative values pull the result toward reality. The standard deviation σ captures how uncertain the estimate is: a wide spread between O and P means low confidence, a narrow spread means high confidence.

The likely scenario shows the expected effort (μ). The conservative scenario adds one standard deviation (μ + σ) — the point where things start to go wrong. Both are compared against your team's available hours to produce the gap.

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 →