AI-Powered Social Media Strategist | Gujranwala, Pakistan
I had a stakeholder approve the requirements, then ask for changes two weeks later, and again after that; each change seemed small on its own, but together they pushed the timeline back by a month.
At what point do you push back on repeated changes, and how do you do it without damaging the relationship?
I don't push back on the stakeholder—I push back on the impact. Every change request goes through a quick impact assessment (scope, timeline, cost, and resources). If changes affect the agreed baseline, I present the trade-offs and let stakeholders make an informed decision. Clear documentation and a formal change control process help maintain both the project and the relationship. Saving Changes...
Projects, by nature, are evolving. It is hard to fix everything in advance. I worked in a company which provides engineering services. This was exactly the issue I encountered almost every day. Right now, I work in a company makes own products and we are the ones who are indecisive about our own requirements.
I see, 3 phases. 0) Requirement Better to have a questionnaire which can force stakeholders to narrow down thier wishes make them solid. It works well at the both side of the table. 1) Requirement -> Specification This phase, I was creating a template specifications document with checklist and block diagram. Once there are unclear points, I was bringing team together to discuss details. This creates new questions for sure but provides a good consensus 2) Specification -> Design/Implementation In IT fields, unit tests makes sense as well as cross check, review milestones with stakeholders. Not only a review within the team but whoever requested it. Again a small checklist to show what has been done and what was asked. 3) Implementation -> Integratino Where system is almost ready and previous parts were agreed and finally system is built with an agreement.
During all these phases, stakeholders may ask for change. Sometimes, they just make more research and hear a cool idea which could be good for their product i.e. More phase you achieved, that hard is the change.
How to communicate this? Transparency and communication is the key. A common frame to discuss is the key. Therefore, block diagrams are helpful to show depedencies and main architecture. ONce everyone are discussing the same point and seeing the same window, it is easier to communicate, then comes the evaluation.
Whatever is requested, team takes it, evaluates it, respond it. what is the complexity? What are the dependencies? What is the impact on schedule, budget, timeline? What value does it bring?
Mostly, after answering these questions, request owners are stepping back regardless satisfaction because no room is left for emotional decision. They know emotions costs money.
In short, I would tell that being systematic, rational and visible solves this floating scope problem without damaging the relationships Saving Changes...
Robert SnyderFounder & President| Innovation Elegance, LLCChicago, Il, United States
More considerations for you ...
Whoever has the authority to approve the changes has the accountability for the changes.
"Execution's two best friends are simplicity and transparency." - Chris McChesney (unless of course, your executives want a workplace culture of VUCA) 😊
Takeaway is that you have to keep informing your manager of the changes.
"Unacknowledged interdependencies are the number one root cause of project slippages." - John Doerr
It sounds like you are keenly aware of the interdependencies! Excellent.
I respect you're worried about relationships. (likely rhetorical question) Who senior to you cares about the relationships? Saving Changes...
"We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again, and that is well; but also she will never sit down on a cold one anymore."
Community Champion
