Decommissioning is what corporate geeks call the controlled retiring of systems - software systems in my area of expertise. You will certainly have your pet peeve, a system that just won't die. Why do those IT guys expect us to use a new system when the old one is still around?
And isn't this applicable to just about everything - from dress codes to org structures? Let's make this about more than software.
... are frustrating for everybody:
Double effort: Not only do you keep paying for something you would much rather see gone, but it also ties up resources that would be better used somewhere else.
Confusion: If the old ways still work - is that a sign that the decision hasn't been final? Will people's investments be rewarded? Do they train others in the old or new ways?
Adoption: James from the other department stubbornly keeps to the old ways - should I help him change or get upset? Why should I change if he doesn't?
... yet sometimes they are very hard to avoid:
Assuming good implementation of a functioning replacement, thought-through and fit for purpose, how do we end up with competing alternatives?
Can't wait: We need an immediate new benefit, even if that means keeping something old around for a bit.
Cost of change: Is the change and its benefits improperly understood?
Incomplete replacement: Do we still need an old system around for parts of what it did?
Trust: Is the change not thoroughly trusted by all?
Change is painful: Is the change perceived as breaking with the past, as uncertain, as a small death? Will people need to give up something they hold dear? Is learning hard?
Cheapness: Why eliminate something if you can keep it for (almost) free?
Cost: Getting rid of something may be expensive.
It's the law: The law may require you to keep something around for a certain time. If you need to play old cassettes, better not throw away the walk-man. The question becomes about "How many walk-mans do we really need?".
The old system is linked to something else: However much we would like to see the old system gone - it would take other integrations with it.
The sunk cost fallacy: Is somebody afraid to lose past "investment"?
Factions: Is the choice to change a statement of political preference?
Influence: Are backers of the old ways in places of power? Does the new way lack prominent backers?
Change fatigue: With so much going on, "help" people by not taking anything away - which ends up creating more complexity.
Laissez-faire: Too much authority for parts to the detriment of the whole.
Other priorities: There may be more important battles to fight.
Being unable to decommission can become a self-fulfilling prophecy: The fact that we haven't made the switch surely must mean something, doesn't it? The danger to projects is so great that we rely on change management experts - something that many specialists have had to learn to embrace, but then were all the better off for it. This was one of the main things I learned at PwC and great change management continues to amaze me when I see it.
Unfortunately, not everything can be solved by change management, so helping others to adapt together is everybody's task - no need to be a leader to do that. Thank you for reading!