It doesn't matter what process you follow, it's whether you can stick to the process/plan/framework or whatever you might call it.
You can spend thousands on project management and change management, produce all the shiny plans, graphs and workflows you like. But if the person managing it can't find their own backside with both hands and an anatomically correct map, then it's going to fail.
The biggest problem I come across in change management, is lack of flexibility, and over abundance of process for no real gain.
In a lot of places now, I hear that to enact a change, a customer has to raise an invoice for a project review to take place, to see what is required and if it requires a project resource to be allocated to make the change.
The change could be "Open the firewall port to the server YOU built and YOU did not complete properly on the project we already paid you to do" but it still requires 3 months, multiple meetings and at least 3 additional costs, just to work out some guy forgot to type 12 words and click half a dozen buttons.
If you've got a fire in your server room, you don't want till Wednesday for your CAB to meet to decide if you should raise a financial purchase order for a project review to allocate a resource to push the halon release (because you're also the BOFH and of course you're still using Halon).
There needs to be a process to deal with some things retrospectively, as part of risk assessment and management, as not everything in life can be processed pro-actively.