Why Unbounded 'Yes' Can Derail Your Project 2

If you are an ambitious manager, you already know the pressure. You want to help. You want to keep the project moving. You want your stakeholders to feel supported. And sometimes, in the moment, saying “yes” feels easier than pushing back. 

A small extra feature. A quick change in workflow. One more request to keep everyone happy. It rarely feels dangerous at the time. But this is exactly how good projects start to slide. What begins as flexibility can quickly become confusion, delay, and frustration for everyone involved — including you. 

If you look at the recent data from the Project Management Institute, the reality is sobering. Over half of all projects (52 percent) experience scope creep, and those that do are 50 percent more likely to miss their budgets and deadlines. Their overall success rate drops to 64 percent. Furthermore, in the United States alone, poor requirements, scope expansion, and related software quality problems cost $2.41 trillion in 2022. 

So let’s be very clear: saying “yes” may feel generous in the short term, but an unmanaged “yes” is one of the fastest ways to drain a project's value. 

A £170 Million Lesson: The Birmingham ERP Migration 

A useful example is the migration at Birmingham City Council. The goal looked straightforward: move from a legacy SAP system to a modern Oracle Cloud ERP platform and improve finance, HR, and procurement processes. On paper, that sounds like a sensible upgrade. 

But the problem was not the software. 

The problem was that different departments wanted the new system to behave exactly like the old one. Instead of changing old habits and adapting their internal business processes to align with standardized cloud software, leaders pushed for extensive customization to preserve familiar ways of working. The project team did not hold the line on scope, and the system became increasingly tailored to old problems rather than helping the organization move past them. 

This unbounded 'yes' led to the creation of a completely bespoke Banking Reconciliation System. Upon launch, the system generated tens of thousands of manual errors and failed to recognize 60 percent of municipal income. The initial budget of £19.9 million was violently expanded to £170 million, driving the local authority into effective bankruptcy. 

That is what an unbounded “yes” looks like in practice. 

Not kindness. Not collaboration. Just delayed conflict, multiplied cost, and a much larger mess later. 

The Cost of Being Too Helpful: My Early Days at Shell 

I know this lesson because I lived it. Early in my career at Shell, I wanted badly to prove myself. I wanted to be seen as dependable, capable, and helpful. If someone needed support, I leaned in. If extra work appeared, I took it on. If the scope moved, I adjusted. 

Part of that came from ambition. Part of it came from personality. I genuinely like helping people, and for a long time, I confused that instinct with good project leadership. So I kept saying yes. 

Yes to additional work. Yes to shifting expectations. Yes to demands that were clearly bigger than the time and energy I actually had. The result was predictable. Long evenings. Lost weekends. A constant feeling that I was carrying more than I should. 

I remember one year very clearly. I had delivered a huge amount of work, and the stakeholders were pleased. From the outside, it looked like a successful year. But when my year-end review came, the rating was not what I had hoped for. My manager acknowledged the technical work, then gave me a lesson I never forgot. He told me I had accepted too much — far beyond normal capacity — and then he said something simple that stayed with me: 

“Mohamed, you have to learn to say no.” 

That lesson was painful, but it was necessary. 

Saying “no” is not the problem. 

Saying “yes” to something you cannot properly deliver — that is the problem. 

Beyond the Hype: AI Will Not Rescue Weak Requirements 

This is where many teams are getting misled today. 

They are overwhelmed by requirements work, stakeholder requests, meeting notes, and endless cycles of clarification, so they turn to AI, hoping it will bring order to the chaos. 

Figure 1. An operational comparison matrix illustrating the trajectory of AI in requirements engineering, contrasting the documentation bloat of passive Generative AI utilities against the strict constraint mapping of autonomous Agentic AI governance models. 

The Trend: Project Management Offices are aggressively deploying generative AI tools to process stakeholder interviews and quickly generate large numbers of user stories and functional specification documents. This can reduce manual drafting time by 30 to 60 percent. 

And that is exactly why the trend is appealing. It feels fast. It looks productive. It creates the impression that the project is becoming more organized. 

The Illusion: But speed is not clarity. If your stakeholder brief contains vague, open-ended language, AI does not magically fix that. It simply turns weak thinking into faster output. Generic AI will confidently hallucinate edge cases and expand requirements beyond what was originally asked for. 

A vague brief goes in. A larger, more polished mess comes out. 

This creates a 200-page specification document that no human being fully reads, fostering a highly dangerous "false consensus" among stakeholders. Everyone assumes alignment because the document appears complete, even when the underlying thinking remains weak. 

That is the real risk. Not that AI has no value, but that teams will use it to make a broken process look more advanced than it really is. 

The Tangible Future  

The stronger future is not one where AI writes more. It is the one that AI helps teams hold boundaries. 

This is agentic requirements orchestration: a more disciplined use of AI where new requests are autonomously cross-referenced against fixed budgets, existing enterprise architecture, and compliance constraints before anyone casually agrees to them. The value is not in producing more pages. The value is in forcing a quantifiable tradeoff matrix so leaders can see the real cost before scope expands again. 

If the foundation is broken, AI will not rescue the work. It will only make the confusion travel faster. 

Taking Control: Learn to Protect the Work 

If you want to grow in your career, you have to stop seeing yourself as the person who says yes to everything. 

Your job is not to absorb unlimited demand. Your job is to protect the delivery. 

Saying “no” gets easier when you stop relying on willpower and start relying on a system. To earn genuine respect from your leadership team, you must implement a rigorous, operational framework that defends your project's boundaries. 

Here is the exact, four-step playbook you must use to stop the "yes" trap and take control of your scope. 

Step 1: Enforce a Rigid Change Control Mechanism  

The most dangerous scope changes happen casually—in hallway conversations, post-meeting chats, or quick emails. You must eliminate these informal requests immediately by implementing a strict, centralized change control mechanism. Require every stakeholder to submit a formal Change Request (CR) that documents the specific business value and explains why the project will fail without it. This simple point of friction will instantly filter out frivolous, low-value demands before they ever reach your team. 

Step 2: Conduct a Rigorous Impact Analysis  

When a formal Change Request does pass the intake gate, you still do not simply say "no." Instead, you say, "Yes, but here is the exact cost." For every new requirement, your team must conduct a formal impact analysis against your established project baselines. Map out exactly how this single change will impact the "Iron Triangle" of your schedule, budget, and scope, as well as how much it will increase your underlying technical debt. This allows you to bring a quantifiable trade-off matrix to the table instead of emotion. 

Step 3: Escalate to the Change Control Board (CCB)  

Never absorb the consequences of a scope change yourself. Take the formal Change Request and your impact analysis directly to your project's Change Control Board (CCB) or your executive sponsor. Present the data clearly: "We can add this feature, but it will delay the core launch by three weeks and cost an extra $45,000." Force the CCB to formally approve, reject, or defer the change. This shifts the burden of the decision off your shoulders and places it exactly where it belongs—with the executives governing the project funding. 

Step 4: Protect the Scope Baseline and the 'Clean Core'  

If the CCB approves the change, formally update your scope baseline to document your new targets. However, you must still fiercely protect the “clean core” of your enterprise software. Institute a project mandate that your organization must adapt its internal business processes to fit the standard software, not the other way around. Treat every single bespoke customization as a future payment on technical debt that will accrue massive interest. Require specialized, secondary executive approval for any request that attempts to alter the foundational system solely to copy an outdated legacy habit. 

Good managers do not win respect by accommodating every request. They win respect by building operational gates, setting healthy boundaries, and forcing data-driven decisions that protect the team from avoidable chaos. 

Holding that line is not selfish. It is one of the most generous things you can do for your project, your team, and your own credibility. 

References 

1. Project Management Institute (PMI). Pulse of the Profession In-Depth Report: The Essential Role of Communications. (Source for the statistic that 52% of projects experience scope creep and related budget/timeline overruns). 
2. Consortium for Information & Software Quality (CISQ). The Cost of Poor Software Quality in the US. (Source for the $2.41 trillion macroeconomic toll in 2022). 
3. Audit Reform Lab / Grant Thornton. Value for money and accountability: a report on the Birmingham City Council section 114 bankruptcy. August 2024. (Source for the independent audit details of the BCC Oracle ERP migration failure). 
4. CIO.com. "How Birmingham's $48M Oracle ERP project turned into an epic failure." (Source for the £19.9M to £170M budget expansion and the 60% unrecorded municipal income statistics). 
5. Boston Consulting Group (BCG). GenAI Can Revolutionize ERP Transformations. (Source for the statistic that generative AI can reduce manual requirements drafting time by 30% to 60%).