Lesson
C1ENProject Management
Master the language and thinking behind successful project management. From Agile vs Waterfall and scope creep to stakeholder communication and risk management, this lesson builds the vocabulary and practical skills B2-C1 professionals need to plan, lead, and deliver projects with confidence. A practical B2-C1 Business English lesson on project management, team communication, and workplace planning. Ideal for managers, Business English tutors, and corporate trainers.
Project Management Myths
True or False
- Adding more people to a late project always makes it finish faster.False
- A detailed project plan at the start is more important than the ability to adapt during execution.False
- Scope creep is one of the most common reasons projects run over budget and over time.True
- Agile methodology is always better than Waterfall for any type of project.False
- The project manager's most important skill is technical knowledge of the subject matter.False
- Regular, short status updates are more effective than long monthly reports for keeping stakeholders aligned.True
- A project that delivers on time and on budget is always considered a success.False
- Risk management means trying to eliminate all possible risks before a project begins.False
Project Management Vocabulary
Swipe Battle
Scope creep
The gradual, uncontrolled expansion of a project's requirements beyond its original boundaries
Kickoff meeting
A final review meeting held at the end of a project to evaluate what went well and what to improve
Milestone
A significant point or stage in a project's timeline that marks the completion of a key deliverable
Contingency plan
A legal document signed by all stakeholders before a project can officially begin
Sprint
In Agile, a fixed time period during which a specific set of tasks must be completed
Resource allocation
The process of identifying and eliminating unnecessary costs from a project budget
Agile
An iterative project management approach that delivers work in short cycles and adapts to change
Dependencies
Tasks or deliverables that cannot begin until another task or deliverable is finished
Waterfall
An iterative approach that delivers work in short cycles and adapts to change throughout the project
Project charter
A document that formally authorises a project and outlines its objectives, scope, and key stakeholders
Burndown chart
A visual tool used in Agile that shows how much work remains versus how much time is left in a sprint
Stakeholder
A person responsible for writing the project charter and managing the project budget
Post-mortem
A review conducted after a project ends to identify lessons learned for future projects
Risk register
A document that records identified risks, their likelihood, impact, and planned responses
Critical path
The shortest possible route through a project that avoids all high-risk tasks
Why Projects Fail — and How to Stop It
Jigsaw Reading
Fragment A: The Scope Problem
Research consistently shows that scope creep is the single most common cause of project failure. It rarely happens dramatically — it accumulates gradually, through small additions that each seem reasonable at the time. A new feature here, an extra requirement there, a "quick change" that turns out not to be quick. The antidote is not rigidity but clarity: a well-defined project charter, a formal change request process, and a project manager willing to say "yes, we can add that — and here is what it costs in time and budget."
Fragment B: The Communication Gap
A study by PMI found that ineffective communication is the primary contributor to project failure one third of the time. The problem is rarely that teams don't communicate — it's that they communicate the wrong things to the wrong people at the wrong frequency. Stakeholders who need high-level updates receive detailed technical reports. Delivery teams who need quick decisions wait days for approvals. The most effective project managers design their communication plan as carefully as their project plan — defining who needs what information, in what format, and how often.
Fragment C: The Optimism Bias
Most project failures are predicted long before they happen — by people who don't feel safe saying so. Research into project psychology consistently shows that teams and leaders systematically underestimate how long tasks will take, how much they will cost, and how many things can go wrong. This optimism bias is reinforced by organisational pressure to promise aggressive timelines and budgets. The most reliable corrective is reference class forecasting: instead of estimating from scratch, look at how long similar projects actually took in the past.
Fragment D: Agile Is Not a Silver Bullet
Agile project management has transformed software development and spread rapidly into other industries. But the enthusiasm has sometimes outpaced the understanding. Agile works best for projects with unclear or evolving requirements, fast feedback loops, and empowered, co-located teams. Applied to infrastructure projects, regulatory compliance work, or large-scale procurement, it can create ambiguity rather than flexibility. The most effective project managers choose their methodology based on the nature of the project — not on what is currently fashionable.
Comprehension questions
- Have you ever experienced scope creep in a project you were involved in? How did it start, and how was it handled?
- The second fragment says teams often communicate the wrong things to the wrong people. What does good stakeholder communication look like in your organisation — and where does it break down?
- The last fragment says Agile is not always the right choice. Do you agree — or do you think Agile principles can be applied to any type of project?
Project Management Language
Word Choice
- We need to finaliseclarifyreduceexpand the scope before we go any further — the requirements keep changing and the team doesn't know what they're building anymore.
- The project is at serious risk of scopebudgetresourcetime creep — we've had fourteen new feature requests in the last three weeks alone.
- Can we schedule a statusreviewplanningkickoff meeting next week to align everyone on objectives before we formally begin?
- I'd like to add this to the changeissueprojectrisk register — it's a low probability risk but the impact would be significant if it happens.
- We're running two weeks behind on the critical resourcemilestonepathdependency — if we don't recover this time, the whole launch date moves.
- The client has submitted a formal changeriskprojectscope request — we need to assess the time and budget impact before we agree to anything.
- Let's do a proper post-mortemauditdebriefreview once the project closes — I want to understand what slowed us down in phase two.
PM Jargon Buster
Taboo
Scope creep
- forbidden: expand
- grow
- add
- change
Milestone
- forbidden: goal
- deadline
- date
- target
Stakeholder
- forbidden: person
- team
- manager
- client
Sprint
- forbidden: fast
- run
- time
- week
Dependencies
- forbidden: wait
- need
- before
- after
Agile
- forbidden: flexible
- fast
- method
- software
Risk register
- forbidden: list
- document
- risks
- problems
Critical path
- forbidden: important
- sequence
- time
- longest
Kickoff meeting
- forbidden: start
- first
- begin
- meeting
The Project Crisis
Drama Event
Scenario
You are the project manager. Your team is six weeks into a twelve-week product launch project. The timeline is already slipping, the client is asking for additions that weren't in the original scope, and two key team members are at capacity. Respond to each situation as it unfolds — make decisions, communicate with your team and client, and keep the project on track.
- 🎲
wordlist
This is outside our agreed scope... We need to escalate this to the steering committee... I'd like to formally log this as a risk... Can we agree on a change request process? What's the impact on the critical path?
- 🔄
Twist
The client has just sent a list of twelve new requirements and says they were "always part of the brief."
- ⏱
Pressure
The CEO asks for a project status update in 30 minutes — and the news is not good.
- ⚖️
Conflict
Two senior team members disagree on the technical approach and both refuse to compromise.
- 🧠
Revelation
A dependency you assumed was on track is actually three weeks behind — and no one flagged it.
- 🚧
Constraint
The project budget has been cut by 20% effective immediately due to a company-wide cost review.
- 🎯
Decision
The client offers to extend the deadline by four weeks — but only if you add a feature that will require significant rework.
- 🧨
Crisis
A key deliverable that was signed off two weeks ago has been rejected by the client's legal team.
- 🧭
Opportunity
A new team member with exactly the right skills has just become available — but only for the next two weeks.
- 🎲
settings
- 🎲
settings
- 🎲
settings
- 🎲
settings
The Steering Committee
Mission Briefing
Scenario
The steering committee for a major digital transformation project is meeting to decide whether to continue, restructure, or cancel a project that is 40% over budget and eight weeks behind schedule.
Project Sponsor
You approved this project and your reputation is partly tied to its success. You believe the problems are recoverable with the right intervention — but you need the committee to agree to an increased budget and a revised timeline.
Must use: Make the strongest possible case for continuing. Present a credible recovery plan. Do not let sunk cost fallacy drive the decision — focus on future value, not past investment.
CFO
The project is already €400,000 over budget. Approving more funding without a clear explanation of what went wrong and concrete controls going forward is not something you can justify to the board.
Must use: Push for a full explanation of the overrun before agreeing to anything. Propose financial controls and milestone-based release of any additional budget. Do not approve a blank cheque.
Head of Operations
Your team is the end user of whatever this project delivers. The delays are already causing operational problems, and a poorly delivered system would be worse than no system at all.
Must use: Focus on delivery quality and realistic timelines, not just cost. Push for a revised scope if necessary — a smaller, well-delivered solution is better than a large, broken one.
Independent Board Member
You have no stake in the outcome. Your job is to ask the questions no one else wants to ask and ensure the committee makes a decision based on evidence, not hope.
Must use: Challenge every assumption. Ask for evidence behind every claim. If the case for continuing isn't strong enough, say so clearly — even if it's uncomfortable.
Project Dilemmas
Speed Debate
Useful phrases
- In my experience, the projects that succeed most often...
- The problem with that approach is...
- That depends entirely on the type of project...
- From a stakeholder perspective...
- The research on project failure consistently shows...
- You could argue the opposite — that flexibility...
- In practice, most project managers would...
- Should project managers always stick to the original plan, or is the ability to adapt more valuable than consistency?
- Is Agile always better than Waterfall — or does it depend entirely on the type of project?
- Should a project ever be cancelled once it has started, even if significant money has already been spent?
- Is it the project manager's job to say no to the client — or to find a way to say yes?
- Should project teams always be co-located, or has remote work made physical proximity irrelevant?
- Is a project that delivers on time and on budget but fails to achieve its business objectives a success or a failure?