Imagine that, once the initial plan is approved, no adjustments or changes to the scope, schedule, resources, acquisitions, etc, are allowed, regardless of unforeseen circumstances. Would it be possible to successfully deliver the project, or would we simply face a series of failures due to an impediment to making changes? Saving Changes...
Project Manager| AWR Development (BD) Ltd. Cox's Bazer , Bangladesh
Hi Veronica,
Managing a project without the possibility of making changes is likely to result in a series of failures. Flexibility is essential for navigating the complexities of project management, ensuring that teams can respond effectively to challenges and meet stakeholder expectations.
Imagine Scope Creep: While scope creep typically refers to gradual changes in project scope, a rigid approach would not allow for any adjustments, potentially leading to dissatisfaction among stakeholders if their needs evolve during the project.
Golam
...
1 reply by Verónica Elizabeth Pozo Ruiz
Jul 22, 2025 5:54 PM
Verónica Elizabeth Pozo Ruiz
...
Good mention of scope creep, Md. Golam Rob Talukdar. Sometimes we need some project adjustments, but not excessively.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Veronica, in my 22 years of project management experience, I’ve never seen a project succeed without some degree of change along the way. Nearly every project I’ve managed has required adjustments, whether due to evolving requirements, unforeseen risks, or external factors. Imposing complete rigidity on scope, schedule, or resources would likely set the project up for failure. Flexibility and adaptability are not just beneficial, they’re essential for successful delivery. Saving Changes...
Without the possibility of change, there is nothing to manage. It is simply letting whatever pre-determined algorithms already in place run their course to completion. Saving Changes...
projects are by definition unique endeavors so it is not possible to know everything up front such that you can guarantee that nothing important will change. If anything, when I've taught foundational PM courses I always tell the learners that making commitments too prematurely on key success variables will dramatically increase the likelihood of project failure and team member burnout.
Wow. I have never seen a project that I have Managed neither in Construction industry, Telecommunications Industry or Utlities. Mostly all the projects have some kind a change.
For Example in the Telecommunications industry when the stakeholders create the Businsses Develepoment, 50 percent of the time it will change. Sometime the business analyst missed something or any stakeholder. Saving Changes...
Agree with previous comments. No project baseline survives first contact with reality. I like to create awareness with my stakeholders about the triple constraint: scope, schedule, budget. Change one and you will automatically impact at least one of the other 2. When there are circumstances beyond the Project Manager’s control, disallowing a proper response creates avoidable delivery risk. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
If this is the situation then a project manager is not needed because a project does not exists. Think into risk for example, just in case you like to call in this way things that could happened because the fluctuations in the environment. Think about the day to day life and try to apply what you describe to it. Beyond others you can find information about this by searching Barry Boehms' Cone of Uncertainty paper. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Verónica Elizabeth Pozo Ruiz This scenario is more than a theoretical exercise; it offers a diagnostic lens on how project management maturity is understood and practiced.
If change is entirely forbidden once a project begins, what emerges is not true project management, but rather “project determinism”—a construct that only functions in perfectly predictable environments, which rarely exist in reality. In practice, every project acts as a hypothesis that is continuously tested against unfolding events.
Consider the following points:
- Complexity and the Cynefin Framework: Most projects operate within complicated or complex domains, as described by the Cynefin framework, where uncertainty is inherent and initial plans must be provisional by design.
- Learning Loops: Contemporary methodologies such as PMBOK, Agile, and Lean reinforce the need for feedback cycles and adaptation.
When projects are denied this capacity, they become fragile—unable to deliver real value.
- Risk and Opportunity Management: Robust change control mechanisms are not indicators of poor planning, but vital tools for responding to risk, leveraging new information, and ensuring delivery of intended benefits.
A practical illustration: In a recent infrastructure project, a strict “no change” policy led to escalating costs and stakeholder dissatisfaction, as the team was unable to adapt to unanticipated site conditions and regulatory shifts.
Ultimately, the project failed to meet its objectives—not due to a lack of effort, but because the process itself could not engage with reality as it unfolded.
Success in projects is therefore less about rigidly following the initial plan and more about achieving the intended purpose.
Flexibility is not a luxury, but a core competence.
How have others balanced this tension between structural stability and adaptive change in their project environments?
I don't know about you, but I've felt this was the expectation, in past positions. I worked at a company where, once the proposal was approved everything was "locked in place", never mind that we didn't have complete requirements, a solution designed or approved, or a WBS. This wasn't usually an issue with smaller projects, but on larger projects, if we delivered "on time", scope was sometimes incomplete. There was often a "round 2" project.
I worked at another company where they intentionally didn't have complete requirements before they started. They would deliver "something" by a set date and there would be a "round 2" project. Looking back, if I were to boil the major differences down to a single point, I'd say it was mindset. Both companies operated similarly, in effect, with similar outcomes but with different expectations. The latter company was more enjoyable to work at, despite the lack of a false sense of certainty.
Certainty, or the desire for it, drives a lot of behavior and demands. A company that has the expectations outlined in the original question/scenario is likely seeking certainty. Maybe they have a portfolio of projects supporting strategic objectives that they need to plan. There could be a critical Q4 event that is dependent on the outcome of a project. Maybe they have compliance constraints. What would happen if the launch date was missed or scope was not met? Missing out on a strategic opportunity that leads to financial loss? Fines or other penalties? Somebody gets egg on their face? Maybe nothing?
When we are given unreasonable requests, and you can't tell me it doesn't happen, we owe it to ourselves to understand why the request is being made. We don't all have the ability to push back or define the processes that need to be in place that make project management more effective. We can raise concerns and identify risks, but unless we're being tasked with something unethical, illegal, or that will cause harm, our job is to deliver as best we can. Sometimes people listen when there are inefficiencies that can be improved.
Going back to the examples from my past, at both companies, having a round 2 project wasn't considered a failure. Yes, we did not always meet the full combination of scope, cost, or time on round 1, which could be considered a series of failures from a project management perspective. There may have been a lot of textbook failures, but it was a textbook that the business wasn't reading and didn't want to read. We, as project managers, did our part to improve our processes and attempt to achieve the project management definition of success, but we were not the ultimate arbiters of success; the people we were delivering products and services to were defining success.
This is why I asked what would happen, or what has happened. The expectations listed have existed in the past and still do exist in some places. At some point, we will all face unreasonable expectations. Saving Changes...
Alexandre PintoniHead of Customer Satisfaction & Operations| Banco Hyundai Capital BrasilSão Paulo, Sp, Brazil
Hello Veronica.
In my opinion, there is no upside to immutable scope. There are a few reasons behind it, but perhaps the most important is the fact that rarely the project owners or even the clients know exactly what they want. At the end of the day, understanding of the scope evolves during the project life cycle. Therefore if no changes are allowed, you incur in the risk of not delivering the benefits that are expected at the end of the project. Your project result might even be obsolete, because the market characteristics and the customers' needs changed during the project life cycle. Even though we have to be careful about scope creep, we still need to be flexible and have a good change management process to allow those changes that will boost the benefits of the project upon delivery. Saving Changes...
Community Champion
