> Any significant org is going to have have some process that sounded good at the time, but is now ridiculous.

That most people will be inexplicably attached to emotionally.

Try this experiment if you're in a Unix shop. Get people to sign up to maintain the unpackaged programs in /usr/local, and then delete the ones that nobody signs up for. Bring popcorn and an asbestos suit. Make sure you take a backup before you do it.

Congratulations. You now understand about removing stupid processes from an organization.

"Any significant org is going to have have some process that sounded good at the time, but is now ridiculous."

And yet, it's still there. Understanding why that's the case is a pretty important part of ensuring that it actually changes. In other words, correctly identifying problems is the easy half of the problem. Dealing with the problems behind the problems is where things get tricky.

Fools rush in where angels fear to tread, etc.

sure but there is a different between finding them, knowing how to changed them and executing that change. You need to know way more than what process is not working before knowing how to change it and you will need people on board to achieve a working lasting change. If you go in shooting from the hips you are very unlikely to achieve what you want, even if the problem is clear to everyone. If it were that straightforward they would do it without needing someone new