Overcharging the client for redesign?
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?
thanks
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.
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.