The 5 Most Annoying Things You Can Say to a Project Manager
Project managers are supposed to be calm, diplomatic and relentlessly professional. We smile through impossible deadlines, vague requirements and actions that were apparently going to be completed three meetings ago.
But there are a few comments that test even the most experienced project manager. They tend to arrive as if the speaker has spotted an obvious solution that somehow escaped the people who have spent months planning the work.
Here are five of the worst.
1. “Can any of the tasks run in parallel?”
No. We never considered that.
Despite being qualified project managers, building a detailed schedule and spending hours examining dependencies, it simply did not occur to us that two activities might happen at the same time.
Thank goodness you arrived.
Yes, we have looked at which tasks can run in parallel. It is one of the basic things you do when creating and optimising a project schedule.
The snag is that activities cannot run in parallel just because somebody wants the project to finish sooner. Some tasks depend on the output of others. Some need the same people, equipment, supplier or environment. Some can overlap, but doing so adds risk. Others can overlap if the organisation is prepared to pay for more resources, which it often is not.
Reality check: Crossrail
Crossrail is a good warning against treating schedule compression as free. The National Audit Office found that the fixed December 2018 date led to multiple activities running in parallel. It said the compressed schedule, lack of a realistic plan and an atmosphere where “can do” became unrealistic all contributed to cost and progress problems.
Crossrail did eventually become the Elizabeth line, but the lesson is useful: overlapping work does not remove dependencies. It can simply allow unfinished construction, testing, integration and assurance work to collide later.
So “Can these tasks run in parallel?” is not a bad question. The annoying part is the assumption that doing so carries no extra cost, resource requirement or risk.
What you may actually be asking is: “Can we accept more cost or risk to finish sooner?” That is a perfectly reasonable discussion. Let us just call it what it is.
2. “I used to work in project management.”
This normally comes from somebody who now works in sales, marketing, operations or senior management and would like to establish immediate authority over the project plan.
“I used to work in project management” can mean almost anything.
Perhaps you once chaired a weekly meeting. Perhaps you maintained an action list. Perhaps your job title briefly contained the word “project”. Perhaps you helped organise an office move in 2009.
Whatever happened, it apparently qualifies you to look at a complex programme plan for four minutes and identify exactly where the professional project team has gone wrong.
You then suggest moving a few bars on the Gantt chart and announce that the project can finish three days earlier.
It cannot.
The bars are not decorative. They represent actual work, performed by actual people, constrained by dependencies, availability, budgets, approvals and reality.
Reality check: BSkyB v EDS
The BSkyB and EDS dispute is almost too perfect for this section because it involved confident promises made during the sales process about how quickly a major IT project could be delivered.
BSkyB hired EDS in 2000 to implement a customer relationship management system with a budget of about £48 million. During the bid, an EDS executive said the system could go live within nine months and be completed within 18 months.
The High Court later found that the timescale had been put forward without a proper assessment of how long the work would actually take. BSkyB eventually completed the system itself in 2006 at a reported cost of £265 million.
Source: Pinsent Masons, BSkyB v EDS.
This is the nuclear version of the salesperson leaning over the project manager’s Gantt chart and saying: “I think you’re being a bit conservative. We told the client we could do it by March.”
Optimism is not a delivery method.
3. “It’s only a small change.”
There is no more dangerous word in project management than “only”.
- It is only one additional field.
- It is only a minor amendment to the design.
- It is only one more approval stage.
- It is only a small change to the report.
The person asking for the change is usually describing how long it took them to explain the idea, not how long it will take to assess, design, build, test, document, approve and implement it.
A change that takes 30 seconds to describe may affect six systems, three suppliers, two business processes and a carefully negotiated delivery date.
Reality check: HS2
HS2 shows what can happen when scope, design, commercial arrangements and political decisions continue to change after budgets and schedules have already been presented.
In its 2026 report on the latest HS2 reset, the National Audit Office said the line was expected to cost up to £102.7 billion and could be fully open up to 13 years late. It identified scope change, inefficient delivery and underestimating the time needed as major causes of the cost increase.
HS2 was not derailed by one person asking for an extra field on a form. The useful lesson is cumulative change. Each alteration may be explainable on its own. Taken together, changes affect design, contracts, interfaces, approvals, cost and schedule.
Small changes do exist. Their size should be decided through impact assessment, not optimism. That is why change control exists.
When somebody says, “It’s only a small change,” what they often mean is: “I would like this change to be small because I do not want it to affect the deadline or budget.”
4. “Can’t you just add more people?”
This suggestion is so old that it has its own project management law.
Fred Brooks developed what became known as Brooks’s Law from his experience of large software projects at IBM. His famous observation was that adding people to a late software project can make it later.
New people need to understand the project. Existing team members stop productive work to brief them. Communication and coordination increase. Some work simply cannot be split between more people.
Reality check: IBM System/360
Fred Brooks managed the IBM System/360 programme and later wrote The Mythical Man-Month. His experience became one of software project management’s best known lessons: adding people to a late project can make it later.
The point is not that extra resources never help. They help when the work can be divided, the right skills are available and there is enough time for new people to become productive.
Before “adding more people”, ask three questions:
- Is the remaining work genuinely divisible?
- Are people with the right skills actually available?
- Will their contribution outweigh the cost of onboarding and coordination?
Adding people can accelerate delivery. It can also give the project manager more people to invite to meetings.
It is especially unhelpful when this suggestion arrives late, after months of warnings about insufficient resources have been ignored. By then, the organisation may not be adding capacity. It may be adding witnesses.
5. “Why do we need all this project management? Can’t we just get on with it?”
Yes. Let us remove the plan, the risk register, the action log, the reporting and the change controls.
Different teams can work from different assumptions. Nobody needs to confirm who is responsible for what. Changes can be introduced informally. Risks can remain undocumented until they become expensive problems. Senior leaders can discover the true position shortly before the planned launch.
It will certainly feel faster for a while.
Reality check: the Grand Designs lighthouse
Grand Designs may be one of the best project management programmes on television, despite not being marketed as one.
The famous North Devon lighthouse project, Chesil Cliff House, became an extreme example of an ambitious vision meeting uncertain finance, rising costs, delays and changing circumstances. The build stretched across about 12 years and went several million pounds over budget.
The useful project questions are painfully familiar: What happens if the finance is not available? What is the contingency? Which work stops if funding becomes uncertain? At what point does the original business case no longer work?
Source: Grand Designs Magazine, Lighthouse finally sells after 12 years.
“Getting on with it” can feel decisive. Sometimes it simply means committing more money before answering the questions that might have told you to stop.
Project management can become bureaucratic, and project managers should challenge paperwork that serves no purpose. But good project management is not paperwork for its own sake. It is how a group agrees what it is delivering, who is doing the work, how decisions will be made and what happens when reality starts to diverge from the plan.
What should you say instead?
Most project managers welcome challenge. Schedules can be improved. Assumptions can be wrong. Delivery approaches can change.
The problem is not being questioned. It is being presented with an obvious sounding solution that ignores the work already done and the constraints the project is operating within.
| Instead of saying | Try asking |
|---|---|
| “Can any tasks run in parallel?” | “What would we need to change or invest to bring the delivery date forward?” |
| “It’s only a small change.” | “Can we assess the impact before deciding whether to include it?” |
| “Can’t you just add more people?” | “Is the remaining work divisible, and would extra capacity help at this stage?” |
Those questions create a useful conversation. They are also much less likely to make the project manager quietly update the risk register while you are still speaking.
The common thread
These examples are wildly different: a railway, a software contract, a computing programme and a private house. The common problem was not that nobody worked hard enough.
It was the belief that difficult delivery constraints could be beaten by confidence:
- Compress the schedule.
- Promise the customer an attractive date.
- Accept another change.
- Add more people.
- Stop discussing risks and start building.
That confidence can sound refreshingly decisive in a meeting. It can also be spectacularly expensive.