Consultant| Canarys Automation LtdBangalore, Karnataka, India
As we know Stakeholders are anyone getting impacted by the Project. Hence, any input, change, or requirement, they give needs to be taken into consideration. Agreeing to implement this is very subjective. Many years ago we had our Customers as the Stakeholders. These Customers were highly educated (few of them were double PHD holders). Their approach to the work was always leaning towards research. Because of this, they kept making changes very often in our Product. Many times we had to call off our release because of the last-minute changes. It took over 2 years for me to gain the authority (considering the Junior cadre I belonged to then) to decline to entertain any change during the release time.
Unfortunately, Agile was not so prevalent at that time. Even if it wasn't I wonder if it would have caused more problems to the project than bringing any benefits.
I am curious to know your experience. Have you faced similar scenarios with the Stakeholders? If you did, please share your strategy of handling them. Saving Changes...
This is a very common scenario, especially in cases were there is no disciplined approach to managing change. Regardless of whether an adaptive or predictive approach is being utilized, "some" discipline is needed for managing changes. The specifics and the level of rigor will depend on the ways of working defined with stakeholders as part of the project inception.
At one end you have rigid change control with potential for change requests to be triaged prior to the team's analysis at the other end you have a more fluid, light weight approach where a backlog of work is regularly reprioritized by one or a few decision makers and release dates are fixed with whatever is ready to be shipped by release date being bundled in. And in between these two extremes are infinite choices.
One starting point is to decide how strict or relaxed you wish to be with scope changes which will be context-driven and then to work with stakeholders to define a scope management process which everyone can live with.
Ashwin, great point. I have fact similar situation quite a few times and it's been challenging to handle especially when the stakeholders are demanding and hold positions of authority. I had tried multiple ways to set expectations at the beginning and have ground rules. They weren't that helpful in practical scenarios. Here’s what helped me.
1 I agree with Kiron's point on how strict and lax one would want to be
2. Have a regular communication on the requirements process so all are aware
3. Talk to the sponsor or senior leader on this and get them to support you.
Hope this helps Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Ashwin,
Consider the following metaphorical proposition:
In a “projects economy,” you transact and do business with “project knowledge.” The lower denomination knowledge (e.g., implicit, tribal, or conceptual knowledge) holds little purchasing power with stakeholders and sponsors; however, as you collect explicit knowledge or can convert lower forms to explicit, you will gain purchasing power (i.e., explicit knowledge equates to higher denominations of currency).
Hence, it’s wise to structure projects as if you are on a mining expedition, wherein the paydirt from the expedition provides explicit knowledge to fuel your project. For instance, you can build an evolutionary prototype to convert the low-denomination knowledge to explicit knowledge before you begin planning/execution or hold challenge-based workshops to refine the current knowledge, sifting out that which is errant and contextually incorrect.
Bottom Line: Managing stakeholder expectations requires currency, and that currency is explicit actionable knowledge.
In my experience, gaining the trust of stakeholders is key in project management. Regardless of the framework being used, establishing trust and effective communication with stakeholders is key to project success. Stakeholders, as you rightly pointed out, can have a significant impact on the project, and their input and requirements must be carefully considered.
I can relate to your experience of dealing with stakeholders who have strong opinions and frequently request changes. In such situations, it's essential to establish clear boundaries and manage expectations early on. Building trust takes time and requires demonstrating competence, reliability, and professionalism in managing project deliverables.
Consultant| Canarys Automation LtdBangalore, Karnataka, India
Thanks, everyone for sharing your thoughts.
So, we can conclude this discussion with the outcome as our agreement to manage stakeholders effectively, depending on their type, for handling this situation. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
For me it is simple. And it is not a matter of using an approach. At the very begining, at the kickoff or before, I always put the ground rules clear. One on this: all change are welcome. Just everybody must take into account they will follow the change request process and the decision about go or no-go will be on hands of the project team or the people who is assigned to it. In case of using agile framework like Scrum is the product owner. Saving Changes...
Community Champion
