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.
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.
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.
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.