Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Overcharging the client for redesign?

Last post 08:45 am July 2, 2014 by Justin Parsons
2 replies
11:24 pm July 1, 2014

some time when we have designed completed the design phase of the development cycle, the client would ask to redesign it. Assume the reason is client changed his mind of the current system. Assume this is not due to mistakes made by the System designer but it just the client wants to redesign the system.
This is more into project management but if you could answer the following question i would be grateful.

There is always a time frame in every step of the development cycle, in the above there is time frame to complete teh system design before development begins. Assume the original system design took 10 days. Now the project manager has to figure how long would it take to redesign the system. Assume he calculated it would take 5 days. But the project manager could say to client that it would take 8 days. and he could overcharge the client. what i want to know it in the real industry, does this kind of overcharge happens?


05:33 am July 2, 2014

Hi Andrew,
what you describe is called the "tyranny of waterfall" in the PSM training. You are talking about design phase, System designer, project manager etc all of which do not exist in Scrum.
In the industry there are indeed some cases where this kind of overcharge happens, there are even companies whose business model is based on this (low fix price bid and then expensive change requests). This leads to mistrust of customers, which leads to customers insisting on fix price projects, which in turn leads to companies overcharging for change requests. You see the loop.
This behavior is a harsh violation of the values Scrum is based on. If the contractor and customer follow these values, they will respect each other. The contractor will provide opennes and transparency in his work, which in turn leads to trust by the customer, which allows them to collaborate. The result will be better for both of them.

08:45 am July 2, 2014

HI Andrew,

Although I am new to the SCRUM world, I can definitely relate to the situation you have run into. With my previous projects those types of situations occurred very often. My previous company would find themselves stuck at times because the proposal would be vague and ultimately they knew that the capabilities of our Custom Off the Shelf (COTS) Solution would only be able to be configured to a certain extent. We always seemed to get stuck when they'd request feature changes that would require a lot of redesign and in turn use up a lot of our design hours in the project. We found that it was more beneficial to put the change request in with the required amount of time needed to complete the redesign and wait for their response. If they approved it then it's a win win for both sides. If they denied the request, we would just tell them that the feature was out of scope and that it would be put into the product backlog for our Scrum team.

This is where T&M projects are so much more beneficial when you don't know certain assumptions.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.