NEW: Learn OnDemand in Arabic, French, Chinese & Spanish – Explore Courses or Book Free Consultation

header-bar
hamburger__close

When Good Project Decisions Lead to Bad Outcomes 

This article explains how project managers can look beyond handover and judge decisions by their long-term value, not just delivery.

When Good Project Decisions Lead to Bad Outcomes 
Back

Introduction 

Some of the most expensive mistakes in projects begin with decisions that look perfectly reasonable. A material is replaced with a less expensive alternative, a design is simplified to recover lost time, or a technical solution is approved because it meets the specification and removes an immediate obstacle. The decision is reviewed, approved and implemented. The project moves forward, and by the measures available at the time, nothing appears to have gone wrong. 

Months or years later, the picture may look different. Maintenance costs increase, operational flexibility decreases, replacement is needed earlier than expected, or the asset simply doesn’t perform as well as intended. This raises a question that has become increasingly important to me through years of working in construction projects: Can a decision be successfully implemented and still be a poor project decision? 

I believe the answer lies in the difference between delivery performance and decision quality. Project teams are generally good at assessing whether a decision helps the project move forward. We are less consistent at asking where that decision ultimately leads. Projects are temporary; many of their consequences are not. 

When the Project Boundary Becomes the Decision Boundary 

Construction projects operate within unavoidable constraints. Budgets are limited, schedules must be protected, technical requirements must be satisfied, contractual obligations must be managed, and stakeholders expect progress. Making trade-offs under these conditions is not a failure of project management; it is part of the job. 

The problem begins when the boundary of the project becomes the boundary of the decision. 

Consider a project under cost pressure where an alternative material or system is proposed. It satisfies the required performance criteria, can be procured faster and reduces construction cost. Within the immediate project environment, approving it may be entirely rational. If that alternative later requires more maintenance, has a shorter service life or restricts future modification, however, part of the saving may simply have moved from CAPEX to OPEX, from the project team to the operator, or from today’s budget to tomorrow’s obligation. 

This does not automatically make the original decision wrong. It means that its quality depends on how broadly its consequences were considered. A decision can improve delivery performance within one boundary while reducing value within another. 

Delivery Performance Is Not the Same as Value 

Scope, schedule and cost remain fundamental to disciplined project delivery. The mistake is not using these measures; it is allowing them to become the complete definition of success. 

A building may be completed on schedule, within budget and in accordance with its requirements, yet prove expensive to operate or difficult to adapt. An infrastructure project may achieve its contractual milestones without generating the expected benefit for its users. A design decision may resolve today’s technical problem while limiting tomorrow’s options. 

The question, therefore, is not whether traditional project controls matter. It is whether they are sufficient to judge important decisions. 

One way I have come to frame this is through a simple chain: 

Decision → Deliverable → Outcome → Benefit → Sustainable Value 

A decision shapes what the project delivers. The deliverable then produces outcomes in its operating environment; those outcomes should generate benefits, and those benefits should ultimately contribute to value that remains meaningful over time. 

The framework is deliberately simple. Its purpose is not to create another layer of project governance, but to extend the line of sight of a decision. Handover is an important milestone, but it is not the end of the consequences created by the project. 

Cost Reduction and Value Creation Are Not the Same Thing 

Value engineering provides a useful example. Properly applied, it challenges assumptions, eliminates unnecessary expenditure and seeks better ways to achieve required functions. Under intense cost pressure, however, the distinction between value engineering and cost reduction can become blurred. 

A specification is changed, a system simplified or a component substituted, and the immediate saving is easy to calculate. The value potentially lost is often harder to capture in the same analysis. Construction cost is visible today; maintenance expenditure may emerge years later. Schedule savings can be measured in days, while reduced adaptability may remain invisible until the asset needs to change. A component has a clear purchase price, whereas the disruption caused by replacing it several times during its service life is less obvious at the point of procurement. 

This does not mean that the more expensive alternative is better. Nor does every decision require a detailed lifecycle study. It means that price is an input to a value decision, not a substitute for one. 

The distinction becomes particularly important in construction because the time horizon of the project and the time horizon of the asset are fundamentally different. A project team may manage an asset for two or three years while making decisions that influence its performance for decades. Some of those decisions are made in meetings lasting less than an hour. 

The longer the consequence, the more carefully the decision boundary deserves to be considered. 

Widening the Decision Without Slowing the Project 

Better decision-making does not necessarily require more process. In many cases, it requires better questions at the right moment. 

For decisions with significant downstream consequences, five questions can widen the frame: 

  • What problem are we actually solving? A technically effective solution can still address the symptom rather than the underlying issue.  
  • Are we eliminating a cost or transferring it? Savings during delivery may return through operation, maintenance, replacement or future modification.  
  • Who receives the benefit and who carries the consequence? The contractor, client, operator and users may experience the same decision differently.  
  • What happens after handover? A brief examination of operation, maintainability and adaptability can materially change the assessment of an alternative.  
  • If we execute this decision perfectly, will it still create the outcome we want? Successful execution cannot compensate for a poorly framed decision.  

These questions are not intended to eliminate uncertainty. Their purpose is to prevent immediate delivery pressure from defining the entire decision. 

Sustainability as Part of Decision Quality 

This perspective also offers a practical way to integrate sustainability into project management. Sustainability is often treated as a separate objective, addressed through environmental requirements, certification systems or dedicated initiatives. Those mechanisms are useful, but sustainability becomes more powerful when it influences routine decision-making. 

When alternatives are considered in terms of lifecycle cost, resource use, maintainability, adaptability, resilience and stakeholder consequences, sustainability becomes part of decision quality rather than an additional layer imposed on the project. 

This is particularly relevant to the project manager’s position. Designers may focus primarily on technical performance, contractors on constructability, commercial teams on cost and contractual exposure, and operators on reliability and maintenance. None of these perspectives is wrong, but each is necessarily partial. 

The project manager does not need to replace these specialists. The more valuable role is to connect their perspectives early enough to prevent an optimisation in one part of the project from creating an unintended problem somewhere else. 

Experience helps here, but not because it provides certainty. Experience improves our ability to recognise where consequences may emerge, where assumptions deserve challenge, and when one more question should be asked before a decision becomes expensive to reverse. 

Good Decisions Under Uncertainty 

No project team can predict the future. Technologies evolve, economic assumptions change, user requirements shift, and unforeseen conditions emerge. A decision that appears sound today may look different years later. 

For that reason, decision quality should not be judged solely by the eventual outcome. A poor outcome does not necessarily prove that a poor decision was made, just as a favourable outcome does not prove that the decision process was sound. 

A more useful test is whether the decision was made with a reasonable understanding of the information available at the time: whether meaningful alternatives were considered, assumptions were made visible, relevant stakeholders and consequences were recognised, and the team looked sufficiently far downstream for the significance of the decision. 

This distinction matters because project management is not the elimination of uncertainty. It is the disciplined management of decisions within uncertainty. 

Beyond Handover 

Projects still need realistic schedules, controlled budgets, clear requirements, competent teams and disciplined execution. A broader view of value does not replace these fundamentals. It gives them context. 

The decisions made during delivery remain long after the project team has left. They remain in the building that must be maintained, the system that must be operated, the infrastructure that must adapt and the resources that will continue to be consumed. 

Thinking in terms of Decision → Deliverable → Outcome → Benefit → Sustainable Value keeps that longer chain visible without making project management unnecessarily complicated. 

For an important project decision, “Will this help us deliver the project?” is therefore necessary, but incomplete. A second question should follow: 

“Will this decision still make sense after the project team has gone?” 

That small extension of the decision horizon can make the difference between delivering a project successfully and creating value that survives beyond delivery.