🛑 Knowing when to say no to a project
“No is a beautiful word, but you have to be the first to say it.” — Hugo Pratt
And yet it is such a difficult word to say in business.
Saying no establishes something that commands respect: protecting a situation — or preventing a problem — instead of simply trying to please.
In several companies I have worked with recently, particularly in engineering and civil engineering, the same issue kept coming up: how do you manage a growing number of projects? How do you prioritise them and meet deadlines?
Each project often seems reasonable when considered in isolation. The problem emerges when you look at them all together.
The same patterns appear time and again:
- more and more projects being run simultaneously;
- no consolidated view of priorities or the resources being committed;
- employees under pressure to deliver, without always being able to alert senior management to the true workload;
- resource conflicts that ultimately turn into interpersonal conflicts.
A governance problem then becomes a people problem.
Bringing different perspectives together
Without an overall view, nobody really knows how many “balls are in the air”, or when two projects will need the same people.
And there is another challenge.
Launching a project is seen as a constructive, positive act. It represents ambition, transformation and a promise of value. By contrast, delaying, suspending or stopping a project often looks like failure.
Yet choosing not to do something — or to stop doing it — can sometimes be THE right decision.
Saying no
Saying no also means taking the risk of disappointing the group. We want to remain part of the team. We want to be useful, dependable and appreciated. So we say yes, even when we know that launching yet another project is risky and the resources are simply not available.
A pat on the back:
“We’ll make it work, right? We’re counting on you!”
So yes, we try to fit square pegs into round holes, even if it means exhausting teams and weakening projects that are already under way.
A “yes” brings immediate recognition. The consequences of overload appear later.
Putting every project on the table
When someone suggests bringing all projects together to compare and prioritise them, everyone generally agrees in principle.
Until the moment a real choice has to be made.
Participants find it relatively easy to question projects owned by other teams. But when a project depends on their own area of expertise, the discussion becomes more difficult. Everyone knows the history of their project, the effort already invested, management’s expectations and the potential consequences of a delay.
Everyone wants to prioritise. But nobody wants to see their own project move down the list.
The risk is that two questions become confused:
- Is this project genuinely a priority for the company?
- Is this project important to my team?
One option is to separate arbitration, as far as possible, from functional ownership. The project sponsor remains accountable for its value and success, but the prioritisation decision can be made by a cross-functional person or body: senior management, a portfolio committee or the PMO.
Another possibility would be to have each project challenged by a sponsor from another team. Their role would not be to replace the relevant business function, but to provide an outside perspective and ask the difficult questions.
The objective is simple: do not let each team be the sole judge of the priority of its own projects.
So, what should be done?
First, put all the projects on the same table.
See what they really consume: time, skills, attention and management capacity.
Then accept that delaying, suspending or abandoning a project can be a sound decision.
This is not just about optimising resources. It is about protecting the expected value of projects — commercially, financially and in terms of the quality of the work.
In Nova Train courses, we place participants in a situation involving several competing projects and limited resources. We work on portfolio prioritisation, teams’ actual workload, and different scenarios in which quality, cost and schedule begin to drift. Their mission is not to make everything fit. It is to choose — and justify those choices using objective facts.
The courage of a project manager does not always lie in pushing a project through. Sometimes, it lies in saying that it will not work.
At least, not under these conditions.
