The thing is that managing inevitable scope changes is an art and a science. Some changes get accepted as part of the project, others are scoped as fixed price updates and others are very hard to scope so may be hourly. In any case this involves identifying the changes, scoping the work, estimating the work, pricing the work and then negotiating with the client to accept the pricing on the change. All of that takes time, often has little to do with the actual development and adds additional risk. That change control is the delicate balance of pleasing the customer while continuing to make money without taking on too much risk.
I work for a small consulting firm, and we keep bidding on very aggressively-timed projects with technical challenges and high skill requirements. Things like directory system mergers, mail migrations, complex infrastructure builds, etc...
The conversation always goes like this:
"How long would it take your to do it?"
"Physically? 2 weeks of button-pressing time."
"With change control and stuff?"
"6 months."
"What!? That's crazy, the customer won't accept that!"
"Well, tell them to stop adding 2 weeks of change control management paperwork for a no-risk 5 minute task in a green field environment with zero data and zero users and then we can do it in 2 weeks."
"They have processes! You know that!"
"Their processes are stupid, that's why it's going to take a chunk of a year and cost an order of magnitude more."
"Fine, we'll promise we'll do it in 4 weeks and then bill them for anything over that if we're slowed down by change control"
"So now I have to do both the change control paperwork and I'll have to track everything internally so we can charge the overheads back? It'll take one year."
"You're wrong! You'll see! It'll be 6-8 weeks at most."
... one and a half years later...
"I told you."
The customer of course signs off on the 4 week estimate, thinking they got a good deal, and the final bill is like 95% overruns and paperwork overhead, but we make a much bigger profit so we don't care. Why would we? We get paid at consulting rates to sit around and fill in boring, simple paperwork. The customer doesn't care either, because they see the costs as "unavoidable", and it's not their money. It's either the taxpayer footing the bill, or it is some huge department's budget at MegaCorp. The decision maker never gets any personal penalty for this kind of thing.
This is why 90% of larger government IT projects have cost "overruns". It's not really an overrun, it's just how these things play out.
PS: This really does happen this way. At a recent project the minimum lead time for any change of any magnitude was 2 months, which was negotiated down from a proposed 4 months. If anyone forgot a firewall rule somewhere we all had to put tools down and twiddle our thumbs while one guy on the team filled out the paperwork and jumped through the hoops to convince the powers that be that yes, server applications really do need networking.
PPS: I have seen change control stop a bad change going ahead exactly once in twenty years. Once. That's because I rejected the change, and this caused an argument and then eventually they did the change anyway and broke stuff. I'm convinced that change control is 99% pointless. The 1% benefit is dwarfed by the overheads and costs. Change my mind.
> I'm convinced that change control is 99% pointless.
99% of the time their packaging and/or deployment systems can't track changes to the degree their change control setup claims anyway.
Thought experiment: run an "upgrade" command on your package manager. Even with a modest system, there are dozens (possibly hundreds) of "things" (executables, configurations, daemons, modules, etc.) that change. Often those things are rebuilds incorporating updates from their dependencies. So if a change management system wants to track exactly why each update happened, that appropriate stakeholders were in the loop, etc., you're actually stuck.
No [1] release system has that level of detail. You'd need a directed graph of all the reasons for all these changes top to bottom.
[1] Yes, I've seen safety critical situations before. No, the paperwork isn't at that level of detail there either. System-wide requirements (the whole system has to be fast in specific ways) don't map to particular lines of changed code like that. At some point, the paperwork gets to be gratuitous.
My point is actually that it's not possible to do that meaningfully past a certain (rather modest) level of complexity and reuse. How does a library like openssl meaningfully and thoroughly notify all it's downstream users in Debian, Node, Gentoo, etc. what changes to pay attention to?
My experience with CC is not that bureaucratic, where it took weeks/months for a single line change. Simply a discussion and negotiation at the weekly meeting between the stakeholders.
The thing is that managing inevitable scope changes is an art and a science. Some changes get accepted as part of the project, others are scoped as fixed price updates and others are very hard to scope so may be hourly. In any case this involves identifying the changes, scoping the work, estimating the work, pricing the work and then negotiating with the client to accept the pricing on the change. All of that takes time, often has little to do with the actual development and adds additional risk. That change control is the delicate balance of pleasing the customer while continuing to make money without taking on too much risk.