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.

closed as too broad by user22815, gnat, user53019, Ixrec, user40980 Apr 21 '15 at 13:13

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    This is something I encountered in almost all large enterprise companies (>10000 employees). – user2567 Jul 6 '11 at 14:50
  • 2
    This sounds horrible and would definitely be a deal-breaker for me. Management should be justifying changes, developers should be implementing them. – Bernard Jul 6 '11 at 14:54
  • 4
    @Pierre, I would agree except for the implementing developer being required to do the justification, unless they actually initiated the change themselves. – Karl Bielefeldt Jul 6 '11 at 14:55
  • @Karl Bielefeldt: excellent point. – user2567 Jul 6 '11 at 15:07
  • 1
    @Karl: I used to work for a large financial services company, as a junior dev. I'm sorry to say I was the one who had to explain why changes had to be implemented on the form. The change request process was pointlessly lengthy, and was often short circuited for minor changes, making a mockery of the process. – Matt Ellen Jul 6 '11 at 15:15

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).

  • I get that. For larger changes that may have a financial impact, I agree that the CAB serves a valuable purpose. My issue is with the devs being required to tap-dance for the CAB regarding changes we didn't initiate (especially the trivial maintenance items). – Joshua Smith Jul 6 '11 at 15:09
  • Ahh, gotcha. I edited my answer to address that. – Ryan Hayes Jul 6 '11 at 15:15
  • 3
    @Joshua Smith: In my experience, the devs are required to give a technical description of the change, technical deployment requirements, and possible technical impacts. They are not required to give the business justification, and CAB is not supposed to judge the business justification. If it gets to CAB, it already has the blessing of the Business, so they should only be asking technical questions. Managers would sometimes be required to give a brief business description, mostly for background. – FrustratedWithFormsDesigner Jul 6 '11 at 15:17
  • @FrustratedWithFormsDesigner - Yep, that's exactly right. – Ryan Hayes Jul 6 '11 at 15:18
  • @Ryan Hayes: +1 for your edit, I agree completely. – Joshua Smith Jul 6 '11 at 15:20

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.

  • 2
    A streamlined process for small changes would ease the sting a bit. Yesterday I fixed a typo on a web page, which took about 15 seconds. After that I had to spend 3 hours writing the 8 plans and justifying the fix on the CAB conference call. I suggested (nicely) to management that this is ridiculous and a gross misallocation of expensive resources. – Joshua Smith Jul 6 '11 at 15:05
  • @Joshua Smith: 3 hours is excessive. I would hope that they plan to do a post-implementation review to work out such bugs. Of course, it's also up to the Business users who wanted the typo correction to go in as a stand-alone change to maybe be patient and bundle it with a more critical change (unless it was a critical typo), or a large batch of small changes. – FrustratedWithFormsDesigner Jul 6 '11 at 15:13

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.


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.

  • It definitely sucks to spend 5 hours fixing a typo. As mentioned above, a change management process isn't the issue. Making developers deal directly with the bureaucracy is the problem. Our productivity grinds to a halt while we listen to a bunch of people on the phone tap-dancing to justify their various changes / bug fixes. – Joshua Smith Jul 6 '11 at 15:30
  • Over time you will learn to predict their questions and proactively justify the changes. Take the time to listen to what they ask and try to figure out what they are trying to find out. There are probably good reasons for asking the questions. There may be a posted agenda you can use to follow along loosely while working on other things too but still be ready when it is your turn. – SoylentGray Jul 6 '11 at 15:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.