George JucanManaging Partner| Organizational Perfomance Enablers NetworkWoodbridge, Ontario, Canada
Don't be sad, be happy - you actually have engaged stakeholders that care about the project, rather than absent ones that will only wake up at the end (their changes will be more costly than the ones you're getting now!)
Best way to deal with engaged stakeholders is to make them part of the team - so they bring the changes in the team's planning meetings and be part of the impact assessment discussions. Once they actually see the impact of the changes on the final outcome (including the change for achieving success) they will really think how important the changes are before bringing them forth.
However, keeping stakeholders happy by delivering what they truly need (instead of what they thought they want when the scope was signed off) is the true measure of success - so don't fight changes (it's a lost cause) but enable them in a way that is constructive rather than destructive to the project. Bringing the engaged stakeholders inside the team makes them part of the solution, instead of part of the problem.
Speaking of "part of the solution", the assessed changes need approval - including reallocation of resources (a.k.a. funding). If the corresponding stakeholders have approval authority as well it's perfect, they can now make an informed decision. If not, send them to obtain approval - this will really get them thinking hard next time!
Last comment - because they are now part of the team they will have to support and approve the project outcomes - otherwise it would be like negating their own work!
George, how do we know what the client needs if the client doesn't know what they need? I always get stuck here.
Saving Changes...
Krishna PakkiProject Services Manager| Rio TintoGilbert, Az, United States
Having a robust Change Management Process in place would help manage such issues. Any change request should go through the process to get approved or killed.
I am not sure what do you exactly mean by external stakeholder here, but if he could be part of initial scope development that would get his support to the project and may help you in this scenario. Saving Changes...
Anish AbrahamPrivacy Program Manager| University of WashingtonAuburn, Wa, United States
I think the important point is to put effort on understanding stakeholders requirements and evaluate the impact. I think you should see if you can meet on common ground. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Even with a change control system in place, you need to be careful. Evaluating each and every change request takes time and effort. If the request is not approved, you could be left without a way to recover the time spent doing the impact assessment.
That's why I add an additional gate to the change management process. The first thing I do with a change request is provide an estimate of the effort to do the impact analysis. Sometimes, it also means getting the client to pay for that effort. Saving Changes...
Go agile and keep short duration of the sprints. Also educate the customer not to change stories once sprint is initiated.
I hope it helps.
Sonali I agree, I think the ideal sprint length is 2 weeks. Saving Changes...
APOORVA SHARMABHEL | Indian School of Business-MBA | NIT Allahabad- M-Tech | Lean Six Sigma BB| BHARAT HEAVY ELECTRICALS LIMITEDDelhi, Delhi, India
Setting boundaries for scale, size and other dimensions for the presumably well intended improvements requested by stakeholder is equally important for successful delivery of project. Changes are inevitable in a project but needs to be monitored and controlled for the common goal with the stakeholder. Saving Changes...
Document the changes, and prepare a detailed IMS, if you don't already have one. Not every project can go agile, but if you show them the schedule delays of rework and the cost of additional resources to complete, they may be inclined to reconsider some changes. If this is an external stakeholder, but not the sponsor with the purse strings, be sure to bring in them as well.
Also, consider having a discussion about why they make changes? Maybe a technical exchange meeting or IPR could help clear up requirements or issues. Saving Changes...
Michelle CampbellProject Manager/Program ManagerPlano, Tx, United States
My advice is similar to what has been said here. If in a waterfall environment, make e clear the impact to scope, time, cost and quality. If in a agile environment, stop the Sprint and start over. In either environment boundaries and impact need to be clear. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Shadav,
make sure you have some power over the stakeholder.
This power could come from the contract (since it is an external stakeholder), other agreements they committed to, from a give-and-take relationship, from a Board in which the stakeholder reports to, from your capability to take away things from them, or just from your leadership capability. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Keep in mind that, unless you take action, things will get worst as time goes on and precedent has been set . Although it depends on the project, the impact of changes will become more significant as the project advances.
Typically a project has an initial phase where needs/requirements are developed and, hopefully accepted, by the significant stakeholders.At some point this phase has to be closed and the development and implementation phases started in earnest. I am not suggesting that changes or improvements can't be incorporated but late changes will have significant impact in terms of effort and time.
A change authorization process needs to recognize these impacts and someone has to accept the 'costs'.
There are two types of trips: 1) the destination is the objective and constraints recognized at the start, and 2) the opposite where the drive is the objective and you go on impulse responding the the landscape or how you feel at a particular point.
From a project perspective type 2) is high risk - the journey will be challenging (exciting) but your destination most likely will not fulfill anyone's expectation or needs.
...
1 reply by David Portas
Sep 15, 2020 1:21 PM
David Portas
...
Hi Peter,
What you have described is a "phased" piece of work but many projects deliberately avoid that phased approach precisely because of the limitations you are mentioning.
Saying yes to change at any time ought to be a positive thing rather than a negative one. As work proceeds and stakeholders get more familiar with the possibilities open to them it's natural to expect new ideas to surface and old assumptions to be proven erroneous. It's often also the case that as work is delivered over the course of a project it becomes easier to evidence the value of proposed changes. It follows that better decisions about requirements and costs can be made later in a piece of work than can be early on ("cone of uncertainty").
It should not be true that late changes have more significant impact. If you are prioritising work wisely then the most valuable, critical or uncertain things will be delivered first. The things you deliver late should be the least important and/or least risky. When you deliver iteratively/continuously the impact of changes tends to reduce as time goes on rather than increase.
