Project Management Central

Please login or join to subscribe to this thread

Topics: Change Management, Cost Management, Scope Management
Scope or change management?

You are working on a project. Project is in execution phase. Your customer provide you feedback in one of the demo telling some changes. After analyzing the feedback, you came to conclusion that it is a CR. However, the customer is not accepting it as a CR and telling that it was already a part of original scope.
1. How to handle this situation? How you will handle situation?
2. What if the customer is not at all listening even if scope was signed off? May be the project/revenue is at risk due to this scenario?
3. Will you accept the CR? How to manage budget wrt inclusion of CR?
Sort By:
Page: 1 2 3 next>

1. you should refer to the requirement documentation then you judge weather its cr or not if i am not mistaken.

2. & 3. you need an expert answer :) i will be waiting that also :)

I'd consider these things if faced with a similar situation: How well have I documented requirements and work packages/deliverables? Did the customer specifically sign off on those items? How detailed is the scope in the contract? For due diligence, I'd double-check my traceability matrix to be sure I haven't overlooked anything. I'd also ensure that the demo wasn't providing evidence of failure, and check that all control measures show that we are correctly working to scope/ requirements/ deliverables as outlined. I'd also find out if this customer has a similar history with other projects: I'd research closeout reports for projects with the same customer to look for insights--were there similar issues and how did they get resolved? If there isn't any documentation that can shed light on this customer's history, I'd turn to my change management processes and see the appropriate point at which a key stakeholder or the sponsor should be enlisted to help negotiate with the customer. As to budget impacts, what does the contract say?

Absent any clearer definition of the roles of the project, I will assume that the customer is the sponsor/key stakeholder. When looking at change in a project, its important to drive everything back to cost, schedule or quality (maybe all 3??) Define for the customer what impact the change will have, nothing is free, there is always a 'cost' for changes. It will cost something to make the change, either in time, money or quality of the final product. Also, don't forget the talk about the risks associated with making last minute scope changes.

Also, if the customer is paying the bill, I am always reluctant to flat out tell them "NO". I would say something like..."if we make this change, this is what will happen". Be clear, be honest, and document it.

Pull out the contract, and have the procurement/legal team demonstrate that it is not within the scope.

You have to demonstrate based on the contract documents alongwith your multidisciplinary team that the feedback is not covered in the contract documents and so it is a new feature.
You should first write to the client that this is a CR with implications quantified and seek approval.


You need to demonstrate the difference between requested change and the contract. Your likely have to go in detail.

It should have been a part of requirements doc which were discussed with customer when work began. Did the customer come up with CR during UAT phase or execution phase? It's not clear from your data. There is an opportunity in QA and UAT phase where customer is checking if the product is made as requested.

I think the statement of work (SOW) or agreement should provide a process for addressing the project scope changes. It should spell out who has the authority to raise strategy issues or propose larger changes to a project.

For the first question,

1. First, move away from the emotions about this debate.
2. Review the contract and scope of work
3. Try to assess, to the best of your ability (with the team) is this issue could be a scope development item (not a change) or is indeed a change in scope.

Once you have clarity - you can move forward.

If you still think it is a change, then you need to approach the customer with clear documentation to back your case. A reasonable customer will listen with open mind and if you convince them -- they will agree. If not convinced, or they just want to be difficult, then you have a choice, accept it as a courtesy (a business decision) or file a claim

On point two - I honestly do not understand the question
Page: 1 2 3 next>  

Please login or join to reply

Content ID:

"Man is a game-playing animal, and a computer is another way to play games."

- Scott Adams