What is the right approach in pushing back a specific request to the customer? The request might feature a complexity to the project in the long term.

10 Answers 10


Wait, what? Why would you say no? If my customer had a request, I'd gladly sell him a solution. I'd break his request down into requirements, develop a WBS around it, estimate and price it, incorporate it into the original WBS, update my schedule and rebaseline, and get to work.

  • Actually I don't see how it answers the problem. And yes, I can think of a number different situations when we want to say "no" to a client, even if they are willing to pay (good) money for building a feature. Commented Sep 17, 2011 at 17:26
  • A change request is not a problem. So I don't see what has to get resolved. Even if the request has downstream risks, inform the customer, price the mitigation, and let the costomer choose. What examples do you have where you would say no? Commented Sep 17, 2011 at 17:55
  • let us continue this discussion in chat Commented Sep 18, 2011 at 13:38

Whenever I used to conduct PM trainings and the question popped up, I use to say: "The immediate answer is:"

I'll be happy to check.

... And afterwards, record the request, prepare an analysis (impact on schedule, cost etc.), and leave the YES/NO decision to the responsible or requester (depending on whatever tolerances we have).

In other words, you manage scope, you don't say "No". The Customer decides (or rather - the Steering Committee, Project Board etc.).


Don't be a dick.

OK, just kidding. Well, have a good relationship and then just explain. Articulation, articulation, articulation.

Why don't you start by telling us about this complexity? What is it? Why is it complex? Will it cost money? What did you mean by 'might'? Don't you know? Had better find out.

Consider this image: http://ud.vg/blog/wp-content/uploads/2011/01/squareLawOfSpreadsheets1.gif

What is the effect of your 'complex' feature? Does it lead to exponential costs? Linear costs? What are the risks? I think your story needs to be straight and then you tell them customer and they make the decision. You cannot, and should not want to, short circuit this process.

Good luck with it.



I'll focus my answer to this question in the Project Management area.

I think the best way is being honest. In my case, if a customer ask me for doing something new, or not included at the intial scope I always estimate how it impacts in the triple constraint (scope, time cost).

If you have a good Change Management method, it'll help you justify saying no to the customer. However, if it's possible to acomplish new scope, this kind of processes (Change Management) will help you.


I think it all depends on the approach you are taking. I prefer to track everything on a backlog and have the product owner prioritize these features. In that aspect, you really aren't telling him no, you are just capturing the data and allow them to prioritize the importance of this particular item.

I also think due diligence is needed to understand that "complexity" as you scope it out and do your complexity estimation.


The best way I've found to address scope creep like this is to first simply state that X is outside of the current scope of the project and that if it can be accomodated it can/will impact cost, schedule, risk etc. Usually this raises red flags for them and they'll back off. If not, get a clear idea of what the customer wants and go back to your team for a feasibility and impact assessment, then present these back to the customer. It is then up to the customer to decide if the change adds value for money, but at least everyone is going in with their eyes open.

  • Does those red flags are really up? From my experience customer after such disclaimer on risk, cost etc. skips over it, because he's focused on this new feature he wants, no matter the cost. And from there i'm going the way David Espina described. In my experience this is like 9 of 10 cases like that. So scarying customer rarely works. Do You have opposite experiences? Commented Sep 14, 2011 at 7:33
  • We do a lot of gov't work on firm-fixed price contracts. If one of our sub-contractors says "scope creep you need to pay more" we have no appetite to change things since the added cost would come directly out of our profit.
    – Doug B
    Commented Sep 19, 2011 at 16:49

David's correct. This is simply Scope & Change Control.

If the client is asking for changes, well... it's his project. Even if it adds complexity. As long as he pays for it, why wouldn't you do it?

Estimate the additional work and costs, present them to the client, and explain all of the impact the change brings (schedule, risk, complexity, etc.). Then let them decide.


Tell them it increases the long-term, lifecycle cost of the software. The cost may come in the form of higher support, more bug fixes or making it more costly to maintain and build off of in the future.


Don't take this the wrong way but if you're pushing back a request because it "might feature a complexity to the project in the long term" then you're pushing back for the wrong reason.

If, I was your customer and found out that feature x "couldn't be accomplished because it might have caused complexity down the road", I would be telling you to take a hike.

Build what you need, not what you think you need: As David, pointed out break the feature down into requirements / stories / tasks etc... and get an estimate on it.


Rather than pushing back, get the customer involved in the decision process.

1) Outline the costs and risks associated with the change 2) Explain if it will will displace or replace any planned work, especially if there is a fixed delivery schedule for the remaining work and something would have to be moved out of the delivery to accommodate it 3) Discuss that potential impact on later features (in terms of cost or risk)

Then help them make the decision that is right for them. The project exists to solve a problem they are having, so if they truly need this (even if they need it in order to understand that they don't need it) then it is your job to help them figure out how to build it in. Right now you only know they want it, what all of this information will do is give them the ability to make an intelligent decision on how badly they want it.

If they chose to move forward with the addition, document it, determine any delivery changes or deliverable changes that have to occur coming out of this, and move forward knowing you are building something that more closely fits your customers priorities.

  • And to answer Pawel's comment on the current top post in case he comes back wit the same question for me, if adding the feature has the potential for impact on other customers, requires a parallel version of the system or requires different pluggable modules per customer, then these costs and the ongoing costs are part of the decision. The (internal or external) customer will surely argue, but the only way to reduce those costs is to change or reduce the request.
    – Tarwn
    Commented Sep 18, 2011 at 12:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.