Amy Gallo is a contributing editor at Harvard Business Review, cohost of the Women at Work podcast, and the author of two books: Getting Along: How to Work with Anyone (Even Difficult People) and the HBR Guide to Dealing with Conflict. She writes and speaks about workplace dynamics. Watch her TEDx talk on conflict and follow her on LinkedIn.

Projects would go much more smoothly if we laid out the scope and parameters at the beginning of a project and then never made any changes. But that’s not realistic and certainly not what happens in most real-life situations. Instead, there’s often scope creep — the gradual expansion of a project’s objectives, deliverables, or requirements beyond the initial plan. Handling scope creep is one of the most challenging — and important — aspects of a project manager’s role. This often means saying “no” when stakeholders request additional features or changes.

So how do you do that in a way that maintains your relationship with the requester, whether that’s the project sponsor, a customer, or another stakeholder? And how can you be sure that you don’t give into pressure when it’s not what’s best for the project? After all, if the ultimate goal is to deliver a successful project, you’re going to have to set and maintain boundaries around what’s feasible.

Here’s what to do next time you get a request you’re not sure whether you and your team can pull off.

Ask for more information

Your knee-jerk response may be to say yes, especially if you’re eager to keep everyone happy. Or your first instinct might be to say no, because you’re at your wits’ end trying to keep a project within its timeline and budget. You might also be frustrated if this isn’t the first time the stakeholder has asked for more.

But don’t respond right away, even to someone who is being pushy. Instead, ask questions to understand what they’re requesting and why. You might say, “Before I can give you a satisfying answer, I need to understand more about what you’re envisioning.”

Your questions might include:

• What specifically would you like us to do?
• What’s motivating your request at this time?
• What are you hoping to achieve with this change?
• On a scale of 1 to 10, how critical to the project does this feel to you?
• If we had to make tradeoffs to fulfill your request, is there anything specific you’d be willing to give up?

Then confirm your understanding by repeating back to them what you heard, asking them if you got it right. With the pertinent information in hand, tell them you’ll get back to them as soon as you can. This might be the next day, week, or whenever you meet next. Be responsive but also give yourself enough time to fairly evaluate the request. If they push back, make clear that you need to consider the ramifications of the request before committing. Waiting may also give them time to reflect on their request, and whether it’s something they want to go to bat for.

Consider the request

Use the time you’ve bought yourself to reflect on whether the additional change or feature is possible. The key questions are: Is this within the current scope? (This is where a well-documented project scope comes in handy; it can act as a reference point, making it easier to analyze what’s possible but also justify your decisions if the requested changes fall outside of the agreed-upon parameters.) And, if not, what will the impact be on budget and deadline?

You want to avoid giving what consultant Bruce Tulgan calls a “bad no.” As he writes, “Bad nos happen when you haven’t properly assessed the ask; when you let decisions be driven by personal biases, including dislike of the asker or dismissals of people who don’t seem important enough; or when you decline simply because you’ve said yes to too many other things and don’t have any capacity left.” These types of nos cause problems down the line — for you and for anyone involved in the project.

Carefully weigh the costs — not just the additional resources and time, but the opportunity cost as well. Of course, not all scope changes are created equal. Some may genuinely enhance the project’s value, while others could jeopardize its success. Assess the impact on the project’s goals, timeline, and budget. Also think through what the consequences of saying yes would be. This helps you get clarity on how you want to respond but can also be helpful when you deliver the message to explain what’s at stake and why exactly you can’t say yes to the request.

Decide what you can and can’t do

Once you have a sense of the costs, you can then make the call on what’s doable. Getting input from key players on the project team can be helpful here. It may be that you can safely and comfortably say yes to the request, or that you can fulfill part of the request.

Be creative in thinking through what the team might be able to achieve that would fulfill the same goal for the requester. It may be that you don’t need to incorporate a whole new feature but that you can tweak one that’s already within the scope but will give users the same functionality. Instead of a flat no, it can be easier to explain something like, “No, we can’t do exactly what you’re asking but we can do something else that will help achieve the outcome you’re looking for.”

Deliver the message

Explain your decision clearly and focus on the project’s best interests. When saying no, it’s helpful to explain the rationale. As Joseph Grenny, author of Crucial Conversations, writes, “Share your logic. Share your facts. Share the reasoning behind your decision. And most important, share the values that motivate your conclusion. If you don’t, others will fill the vacuum you leave with their fears and biases.” It can help to explain what will happen to the project if you say yes — in terms of extended timelines, increased costs, or diverted resources. You want to present a clear and fair (not overexaggerated) picture of the consequences.

If possible, offer what you can do instead. Instead of outright rejecting the request, offer alternative solutions that align with the project’s objectives and constraints. This demonstrates your willingness to collaborate and find compromises. You can also suggest prioritizing the change for a future phase or propose a trade-off that allows for the addition of new features while maintaining the project’s scope.

Keep in mind that you may need to educate the stakeholders. Many change requests arise from a lack of understanding about the project’s original objectives or constraints and it’s on you as the project manager to help them understand. Of course, regular communication and status updates before a request comes in can help stakeholders understand the implications of scope creep and ideally preempt unreasonable requests.

Pay attention to how you say no

Saying no doesn’t have to be confrontational or dismissive. You want to strike a balance between maintaining boundaries and being respectful. You can use what communication expert Holly Weeks calls “a neutral no” which she describes this way: “A neutral no is steady, uninflected, and clear. It is mostly notable for what it is not: harsh, combative, apologetic, reluctant, or overly nice.” Weeks likens it to a referee in a game who doesn’t have a stake in either side but calls it like it is. Try to keep your voice even and steady and don’t fidget, which conveys discomfort.

Ideally you can do this in person or over a video call rather than over email or Slack since it’s easier to convey empathy and respond to body language. You can also respond live to any questions or pushback (more on that below) rather than getting into a long, unwieldy back-and-forth.

Document the conversation

As with any decisions related to the project, be sure to document the discussion. It’s not uncommon for a stakeholder to come back and make the same request or to make a similar one. Having a record of the conversation and the rationale for the decision can help reestablish a boundary and manage expectations. Documentation also provides transparency for anyone involved in the project who needs to know the outcome of the conversation but hasn’t been a direct part of it.

If you get pushback…

There’s a chance the stakeholder won’t be happy with the outcome of your decision. This is where you might incorporate advice from journalist and consultant Ruchika Tulshyan on saying no. She suggests you either “reinforce or renegotiate.” Reinforce might include saying something like, “Thanks again for raising the issues. As I said, we won’t be able to accommodate the request because of the impact on the project budget.” Or you might renegotiate with them, and say something like, “If this is an absolute must-have, then let’s renegotiate what can be put on the back burner so the team can prioritize this change without compromising the budget.”

If the same person comes to you several times with change requests, you may want to involve the project sponsor or another key decision maker (if the requester is the project sponsor). They can often help mediate discussions and make final decisions on scope changes to be sure they actually align with the project’s strategic goals.

Your ultimate goal is to deliver a successful project. To do that, you’ll have to say no along the way. The key is to find a balance between accommodating stakeholder needs and preserving project integrity.