How should we deal with a demanding external stakeholder who keeps changing requirements about a specific project you’re working on?

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.

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.

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!

I'll stop here before the response becomes an article - if you'd like more insight related to the comment above please check out https://www.projectmanagement.com/books/42...ders-Engagement in the Reference Library.

If there is no defined requirement/scope then there is no such thing as changing requirements. A change is a change in requirements not a revised approach or a different way of doing things. A change in route is a project authority, a change in requirements is a client authority.

If the scope is to muck around until you come up with a solution then mucking around is the scope. I can see that controlling such an initiative could be a challenge especially when there are constraints such as time and money.