User’s fear of (and frustration with) change is very real, but more often than not, the SPONSOR’s fear of upsetting customers far surpasses the user’s fears.

I’ve worked with dozens of executives, stakeholders and sponsors who sit behind or above very large applications, who have forbidden changing existing features because “users have gotten used to the way things are (broken)”.

9 times out of 10, if you dive into their fears, you’ll find that it’s not actual change they are afraid of, but the lack of *control* over change.  That’s because system change and communication is managed very badly in many (MANY) organizations, and is almost an afterthought in all but the most controlled software environments.  People just don’t have time or funds to staff software groups with change control experts, so people pitch in when they can, with as much as they can offer.

That often results in poorly or highly technical release manifests that excruciatingly detail every tweak and bug-fix, without giving anyone a sense of “what really happened to my product!”

Furthermore, 9/10ths of the development process takes place behind the scenes, and is usually packed to the gills with tons of work getting everything right for the next release.  Even in a very customer-driven agile process, only a few customers are even aware that new changes are coming, and that’s just because they’re heavily involved in the day to day process.  Everyone else is blissfully unaware of the “changes” coming down the pike.

However your SDLC works (with or without direct customer feedback), you won’t change your stakeholders’ minds with statistical evidence about change, because those figures can’t possibly be relevant to your particular system and lifecycle.

Instead, I would probably provide an analysis of how your organization manages change, to your stakeholders.  Identify weaknesses and how you can address them, to make change more acceptable and comfortable both for your users and your stakeholders.

I’ve been told so many times that anything shorter than a six month release cycle would absolutely terrify “the users” (this, coming from executives in charge of customer service).  However, you can improve the change control process so that it a) uses both proactive and passive communication to keep everyone informed, 24/7, b) provides a clear, predictable, transparent release process that everyone understands (e.g. last day of every month), and c) enforces a zero-tolerance policy on bugs making it into production.  If you can do these things, there is no reason whatsoever that you can’t release new features not just every month, but every morning.

You would be amazed at how psychologically uplifting it is to be able to move real business value out to your users every single day.  The weight of all those months of work, building up to one or two monumental releases every year is incredibly demotivating to everyone involved.  I’ve seen it too many times over the past 15 years, and I’ll never go back to the bi-annual or annual release cycle again.