We’ve already discussed the importance of predictability in project execution, especially when it comes to the commitments made by project team members to key stakeholders (we’ll use this term to refer to all interested parties for simplicity).
This topic ties directly into the broader questions: “What constitutes a project failure? Why do projects fail?”
According to the foundational principles of project management, a project is considered successful if it meets three core constraints: scope, time, and budget. In other words, a project is successful if:
- Upon completion, stakeholders receive exactly the planned deliverables—no more and no less;
- The project is delivered on the agreed timeline;
- The project stays within the allocated budget.
“Overdelivering” Isn’t Always a Virtue
When I cover these principles in my project management courses, a common question arises:
“If we have the opportunity, shouldn’t we exceed stakeholder expectations by delivering more than originally planned?”
For example, let’s say the project involves installing 25 personal computers. Partway through execution, a new generation of PCs becomes available—cheaper, faster, and better than the agreed-upon models. Should we upgrade?
The answer is: no—at least not without a discussion.
No changes should be made until the potential consequences have been fully evaluated and agreed upon by all stakeholders.
In some cases, your project may be a subcomponent of a larger customer initiative. The new equipment might create compatibility issues, involve a different operating system, or interfere with existing infrastructure. Even if the new models seem technically superior, they may not be fully tested or certified for critical business use.
A well-known example illustrates this risk: several years ago, users discovered that certain processors performed arithmetic operations incorrectly. Such rare but impactful defects remind us that untested “improvements” can backfire.
Bottom line: Commitments matter—stick to them unless all parties agree on a justified change.
On Deadlines and Budgets
Let’s talk about promises related to timelines and budgets.
In many organizations, project deadlines are dictated by management or clients, often without input from the project team. These dates—planned, target, or final—can feel imposed.
However, what stakeholders really want isn’t aggressive acceleration; it’s reliability. Most would rather have the project completed on the date you committed to, not necessarily the earliest possible date.
The same goes for budgets. Many clients and internal managers believe that without tight constraints, project teams will overextend on both time and cost. This lack of trust leads to systematic reductions of the proposed schedule and budget.
Anticipating this, project managers may intentionally inflate their estimates, expecting inevitable cuts. But this back-and-forth results in a destructive cycle: unrealistic plans based on adjusted, rather than actual, expectations—making true project control impossible.
When Unrealistic Projects Succeed—But at What Cost?
Interestingly, many projects that undergo such imposed cuts still seem to succeed—delivered faster and cheaper than initially planned. This reinforces the belief among executives that original estimates were inflated.
But how does this happen?
Usually, these “successful” projects have reduced scopes or compromised quality. Essential tests may be skipped. High-risk decisions might be made without proper analysis. In other words, the project isn’t really the same as originally envisioned.
These shortcuts can have hidden costs down the line—costs that are often invisible at project closeout.
Breaking the Vicious Cycle
As responsible project managers, we must break this cycle of inflation and arbitrary reduction.
The only way to restore trust—both from stakeholders and upper management—is to consistently deliver what we promise. That means making reliable and well-founded forecasts for cost and duration.
In the next article, we’ll explore why using the most likely value as the default forecast for project time or cost is a flawed approach—and what you should do instead.
