• I don't solicit or dig for the kinds of information that would alert me to project upgrade opportunities.
• "Don't rock the boat" is one of my long-standing mottos.
• I think that putting a significant project change on the table is much more likely to cause Primes to shelve my project than to consider authorizing an in-process upgrade.
• I'm a "just the facts" kind of person who isn't good at selling change via the benefits they will yield.
• Whatever benefit a change might bring will be lost in the time and confusion that my change effort would cause.

Why You Should

You avoid managing projects that yield 'DOA' (Dead On Arrival) outcomes. (DOA outcomes are very bad for a project manager's health.)

You build a reputation as a 'tuned in' project manager who is aware that change happens so quickly that a great project idea can easily become yesterday's news if project modifications aren't made on-the-fly.

You protect your participants and Primes from the demoralizing and costly consequences of investing in a DOA outcome.

You use benefits to make participants and Primes WANT to make the changes rather than either killing a potentially salvageable project or focusing on the enthusiasm-crushing downsides of not making changes.

 

Some Tips On How To

Get enough information to decide whether to sell the change or not as quickly as you possibly can. Project changes are typically inconvenient and costly AND the further you get into the project, the more inconvenient and costly changes become.

Sell the change in terms that are most relevant to the audience you're selling to:

• Prime movers are usually interested in how the change will impact ROI, as in "What value will we get, above and beyond what was already anticipated, by taking on the change-related additional cost and delays?" The strength of your pitch will be directly related to the magnitude of additional profit/productivity and inversely related to the costs of the change.
• Participant enthusiasm for project changes is strongly influenced by (a) the amount of work that they'll have to abandon, (b) the heat they'll have to take from supervisors and co-workers for schedule changes, (c) the additional and either unpaid or inconvenient time they'll have to donate to your project and (d) any learning curves they'll have to climb in order to make the project changes (frequently these changes are the result of emerging technologies). Sound like all downside? It usually is, so be prepared to make a convincing argument for the impact that project changes will have on organizational well being. And do what you can to get some time-relief for them from their supervisors.
• End users want easy to use, powerful, problem-solving project results, so sell these benefits to offset the delay they're likely to experience in getting the result.