monday.com explains PERT for more realistic project timelines

monday.com reported that customers with more than $50,000 in ARR represented 41% of total ARR in Q4 2025. That helps explain why its case for PERT is really a case against pretending complex software work has one clean finish date. For product launches, integrations, and new builds, the Program Evaluation and Review Technique is a practical way to talk honestly about uncertainty when nobody can responsibly promise a single number.

Why this fits monday.com’s own business

The timing matters because monday.com sells the kind of software that lives or dies on planning discipline. The company, founded in 2012 by Roy Mann, Eran Kampf, and Eran Zinman, still lists its principal executive offices at 6 Yitzhak Sadeh Street in Tel Aviv, the city where it launched and held its first board meeting after onboarding its first six customers.

The numbers show that shift. monday.com reported fourth-quarter 2025 revenue of $333.9 million, full-year 2025 revenue growth of 27%, and a 14% non-GAAP operating margin. In the first quarter of 2026, revenue rose to $351.3 million, up 24% year over year, and the company logged record net adds of customers with more than $500,000 in ARR. monday.com crossed $1 billion in annual recurring revenue in August 2024.

How PERT works when one estimate is not enough

PERT, or the Program Evaluation and Review Technique, uses three estimates for each activity: optimistic, most likely, and pessimistic. The familiar formula, (O + 4M + P) / 6, weights the most likely estimate more heavily, which is what makes the method feel more grounded than a single deadline pulled from instinct or wishful thinking.

That weighted average matters because it forces teams to name the range of outcomes instead of hiding it. A task that might take 4 days in the best case, 6 days in the typical case, and 12 if it goes sideways does not really have a “6-day” answer in any honest sense. PERT says the expected duration is closer to 6.7 days, and more importantly, it makes the downside visible before the schedule is locked.

PERT is better for uncertain work such as research or software development, while CPM, the Critical Path Method, is better when the work is routine and durations are predictable. Roadmaps built on stable durations should be treated differently from ones built on dependencies, unknowns, and work that changes shape as it progresses.

Why software teams keep running into the same problem

Software projects are uniquely uncertain because requirements are vague, the end state is hard to visualize, and the work is iterative and complex. That is exactly where a single estimate becomes dangerous. When the team is building something new, or stitching together systems that do not yet behave the way everyone hopes they will, the real risk is not that the estimate is off by a little. It is that the estimate was never capable of reflecting the actual spread of outcomes.

That is why probabilistic planning is more honest than false precision. A single number can create overconfidence, then missed deadlines, then stakeholder frustration when the work inevitably expands or hits a dependency nobody had enough visibility into. PERT gives engineering and product teams a structured way to surface schedule risk earlier, instead of discovering it only after a launch date has already been promised.

For product managers

For PMs, PERT is a useful defense against the pressure to turn every roadmap item into a crisp commitment too early. It makes it easier to justify buffers and sequencing, especially when a launch depends on more than one team or on a feature that is still being shaped.

For engineers

For engineers, the value is in the critical path and the risk hotspots. If an integration, migration, or AI-related workflow has one step with a wide spread between optimistic and pessimistic outcomes, that step deserves attention before it blows up the whole schedule. PERT gives engineering leaders a language for showing which tasks are genuinely brittle and which ones are unlikely to move the date.

For sales teams

Sales has a stake in this too, especially in enterprise conversations. In a market where monday.com increasingly sells into larger organizations, buyers need more than task lists and confidence slides; they need a way to anticipate variability, track dependencies, and see where delays will actually hurt.

From Polaris to software roadmaps

PERT was developed in 1958 for the U.S. Navy’s Polaris missile program, and the original Project PERT began on January 27, 1958. The first phase report came out in July 1958, with the Navy’s Special Projects Office working alongside Booz Allen Hamilton, Lockheed, and Navy personnel.

The method was built for work that was technically ambitious and hard to predict. The old problem was missile development; the modern version is software delivery. First-time builds, migrations, integrations, and AI initiatives all involve work that is hard to predict.