Is it common for developers to deal with extensive change control procedures?

Question

This question requires a bit of setup, please bear with me.

Last week my company rolled out a new change management procedure. Any change destined for production requires a change control record; this policy was already in place and I don't disagree with it. The new procedure, however, involves a highly convoluted, server-intensive web app for creating the records. As an added bonus the servers are in Europe (I'm in Seattle), which often results in latency issues.

Any given change record requires (at a minimum) a business justification, requirements document, pre-implementation plan, pre-implementation test plan, execution plan, execution test plan, post-implementation plan and post-implementation test plan. These plans have to be typed manually into the aforementioned web app.

After creating the record, the developer making the change is required to attend an hour-long phone conference with the Change Advisory Board to justify the change. Nevermind that the change request passed through four layers of management before hitting our desks; it's on us to justify the work.

I'm of the opinion that any work that lands on my desk should have been justified long since, preferably by the person/department requesting the work. This may end up being a deal-breaker for me.

My question is, how common is this practice in the programming shops of non-software companies?

Edit: There's a lot of good feedback here. It sounds like the solution is to join a software company that isn't involved in finance, healthcare or government. :) Thanks to everyone for the responses.

Answer 1

It's actually EXTREMELY common in Government/Aerospace/Health industries.

This is actually a safety mechanism to prevent wasted effort and to reduce changes that some guy decides would be cool that go on to break something else that was way more important. You should take a look at CMMI to get some background on what these processes are and why (in theory) they help minimize change and risk. When making even a small change has the potential to risk a person's life or cause massive loss of money, these processes are put in place. Most of the time they are a hindrance to innovation and the ability to adapt and change quickly, however in some cases that is acceptable if you avoid a single change that could bring a company to its knees, kill someone, or cause a huge and expensive lawsuit.

As to developers vs management justification:

Management should justify the change from a business perspective. They should justify and pass the change through the committee before the developer even sees the change. However, the developer should be involved in the sense that they are the only ones qualified to provide a remotely accurate risk analysis. Developers shouldn't be doing the business justification themselves, but should be part of the process to provide analysis of benefits/risk from a technical standpoint. Management should be clearing it to decide if it's even necessary first. Second, you should clear it as (this can be done, this can't be done, this can be done but will put us 4 months behind, this can be done but the kittens will die in the space shuttle on re-entry).

Answer 2

I've encountered this in large companies (financial industry, in my experience). When I started, the process was well-established and everyone was used to it. Some time for dealing with the Change Committee was budgeted into the project. It was annoying to deal with, but somewhat necessary and when I was a member of the committee I saw it happen more than once that changes brought forward would clash in some way - systems affected, or requested scheduling. In such a large company, it was impossible for every dev team to know what everyone else was doing, so this process ensured that there was one point where all changes were managed and scheduled.

As for justifying changes, we usually requested that the lead developer in charge AND their manager present their change. The manager because they knew the business side and were responsible for the change, the developer because they often knew the technical requirements much better.

It sounds like your company is still going through some growing pains for this process, and the tool sounds a bit awkward too (we didn't have to manually type in data; we could attach existing documents). We also had a streamlined process for smaller changes. They may decide to review their process after a couple months of experience with it, or maybe you could suggest that they review it.

Answer 3

I've worked for some Fortune 500 companies and this is quite common. In most cases that I've seen the whole project team is responsible for documenting the change, meaning some of the technical details are provided by the developer but the business justification is provided by the PM or BA. All of the change documentation is then compiled by one of the team members and submitted as a whole.

Answer 4

The change process is about more than just approving the change.

Ideally you have major process owners involved and engaged. When a change is proposed they discuss current processes, any short falls, and try to make a decision as to the scope of the project. Is the change needed just for a small group, location, or should it be and Enterprise level change. This may sound stupid to spend this kind of time but it is much easier to support systems that a common throughout the enterprise.

This group also makes sure that multiple groups are not trying to make the same changes or changes to the same system that may conflict. And if they are to try to coordinate these changes to make sure they work together.

And they have a management responsibility to make sure that the changes are really needed. It may suck to take 5 hours to fix a typo on a web page. But why was it not caught before release? Is it really important to fix it? Are there any risks to making the change? I fixed a typo one time and accidentally deleted the entire contents of our INETPUB Directory. For 3 hours every app on that server was down while we restored. The change control considers things like this. Is that typo fix worth the risk of losing 3 hours worth of online orders?

I know it is painful. I once spent about 80 hours doing documentation and requests and involved my management all to get a virtual server that had a real cost of about $20 a month. The process was painful but there are business reasons that made sure that we needed that server. It only costs $20 a month because the process to get one is controlled and standardized. If the datacenter ballooned the costs would go up costing everyone.