using the power of other stakeholders and sponsors to stop him Saving Changes...
Bipin SavantAsst. Vice President| VALAD InfotechMumbai, Maharashtra, India
Conduct a stakeholder analysis, use the P-I grids and address the issue, depending on his/ her position in the matrix Saving Changes...
Maya KalachHead of PMO, IT| Middle East AirlinesBeirut, Lebanon
The project manager's subject matter expertise about project scope as well as proper requirements management and stakeholder management techniques should help. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Rahul
try first to understand why he is behaving as he is. How he is feeling towards you, the project, the requirements (Guess he is insecure).
Then try to increase his trust in you, increase his security level.
Make sure he feels taken care of by you,
- respect him, acknowledge his status
- explain to him what you are planning to do (e.g. agree with him on a change management procedure)
- give him options to decide
- make sure he feels you are in the same team with him
- be honest and fair with him
Practically, start listing every change and its consequences on the project (a change register), and share it with him. Be careful not to threaten him with that but to use it as a fact base.
You as project manager must make your customer feel safe and secure.
...
1 reply by Rahul Patekar
Feb 05, 2020 12:44 AM
Rahul Patekar
...
Thanks Thomas, this really helps.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Dear Rahul Interesting your question Thanks for sharing
Is it the customer? Is the sponsor?Or is it another stakeholder?
...
1 reply by Rahul Patekar
Feb 05, 2020 1:19 AM
Rahul Patekar
...
It is some other stakeholder. For me, it is easy to manage/handle people who change requirements in the following order 1) customers 2) Project Sponsor 3) Stakeholder (An influential person).
Saving Changes...
Catherine Oliver-WeemsManager, Network OSS Tools Portfolio Management| SprintGa, United States
We have all had those! I am a proponent in locking down requirements [with agreement of the lockdown, of course] and of holding to the original scope/budget of the project. Adding requirements means added time and added costs. It also means shifting dates out which generally no one wants. If the added work is in keeping with your scope and within budget, then adjust dates accordingly and lock them down again. If it's not in keeping with your scope/budget, plan to move ahead with what you have already with plans for a follow-up project to handle the rest. All projects should have a beginning, a middle and an end. With constant additions, you'll never manage to leave the middle part :-) Explaining the added costs and the additional time needed with notation of items for a follow-up project so you can finish what you have started should help. If you work with that stakeholder again, I would be sure they are involved in requirements gathering and they sign off on them prior to locking it all down so expectations are clear up front. Good luck! Saving Changes...
It depends of the power and influence of the stakeholder. If these are high, you may work to convince him of your criteria about changes really needed; if these are low, you may impose your criteria. Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Changing project requirements is very common in projects but to a certain degree. From your question, I sense it’s gone limit.
1) First, try to see what is the power, influence and impact of this stakeholder.
2) Try to understand why they keep changing requirements. It might be that they don’t know what they exactly want and as they inspect and adapt, they get a better understanding. Maybe a prototype could help in this case as it will provide more clarity.
3) Always assess the impact of all changes and present it in a transparent way to all concerned.
Well getting sign off from the start is supposed to stop that, or it will at least provide justification to increase or change scope, which may or may not affect schedule and budget. As Rami said, it depends on how important they are as a stakeholder. Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
Golden rule :- Whoever holds the purse strings on the project has the biggest voice. If it's your sponsor, they are the most powerful .
Where's the project governance? the steering committee and Project Board? Ask this stakeholder to put their change request in writing . Set the expectation that any Change Request would require evaluation and will affect scope, cost, schedule . Inform your sponsor that you will need to invest time and effort to evaluate the change request and get their agreement and endorsement to go ahead to spend time on investigating the change. IF the sponsor feels that such investment of effort is unnecessary , relay that back to the stakeholder. IF the sponsor feels that you should go ahead with evaluating the change , then present the change and ask for formal sign off at the Project Board and Steering committee . And let it be minuted that you have been approved or rejected for the increased scope, time and/or cost.
IN the absence of a project board ... if in the middle of a sprint , set the expectation with the stakeholder {even if they are the product owner} that the change will be evaluated by the team at the end of the sprint . Make sure your Product Owner is fully on-board with this . Get the team to evaluate the change once the sprint is finished. If the change presents a good value proposition after evaluation, present it to your sponsor and seek their endorsement . If sponsor agrees to implement the change , schedule it in with your team in one of the future sprints . If the sponsor rejects , then let your stakeholder know.
IF your sponsor does not back you up , then , Rahul, my friend, dust off the cobwebs from your resume. The market is waiting for you ! :)
...
1 reply by Rahul Patekar
Feb 05, 2020 12:57 AM
Rahul Patekar
...
Thank you so much, Deepesh, for such a detailed answer. I like the idea of seeking endorsement at the end of the sprint. Again challenge would be communicating such suggestions in front of the stakeholder. It seems it is necessary to bring them both i.e. project sponsor and the stakeholder on the same table.
The third solution will always be there if the sponsor himself does not back me up.