7

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.

Joshua Smith
  • 2,050
  • 18
  • 24
  • 2
    This is something I encountered in almost all large enterprise companies (>10000 employees). –  Jul 06 '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 06 '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 06 '11 at 14:55
  • @Karl Bielefeldt: excellent point. –  Jul 06 '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 06 '11 at 15:15
  • Take a look at "ITIL Change Management" and see how commonly bureaucratic it can be to get a change done. – JB King Jul 06 '11 at 15:47
  • Gosh. The cost of 'preventing errors' ought to outweigh the cost of fixing them. I work on a large government programme, and aerospace in the past, and never had to endure that for each code change. The kind of change management you describe is done at a project level and developers review those types of documents and are consulted for input for those types of documents, but they do not create them (not on large projects). In the programming arena, there isn't much call for anything more than test-driven development and a version control system that makes undo easy. – Lee Kowalkowski Jul 06 '11 at 20:30

4 Answers4

19

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

Ryan Hayes
  • 20,139
  • 4
  • 68
  • 116
  • 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 06 '11 at 15:09
  • Ahh, gotcha. I edited my answer to address that. – Ryan Hayes Jul 06 '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 06 '11 at 15:17
  • @FrustratedWithFormsDesigner - Yep, that's exactly right. – Ryan Hayes Jul 06 '11 at 15:18
  • @Ryan Hayes: +1 for your edit, I agree completely. – Joshua Smith Jul 06 '11 at 15:20
  • +1 for giving things a developer would need to justify. Do both the "business requirement guy" and the developer have to present their cases to the same committee, so they can weigh the development risk agaist the business need? – Michael K Jul 06 '11 at 15:24
  • @Michael - Yes, the ISO standard I believe actually includes them both together in the same change request document. It'll have the business requirement/analysis and then the technical requirement/analysis that goes with it all in one place. Which is good, because risk/cost can make any business requirement a whole new ballgame, so they need to be together to get the full picture. It's a tag team effort. – Ryan Hayes Jul 06 '11 at 15:33
9

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.

Michael K
  • 15,539
  • 9
  • 61
  • 93
FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • 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 06 '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 06 '11 at 15:13
2

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.

Walter
  • 16,158
  • 8
  • 58
  • 95
1

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.

SoylentGray
  • 3,043
  • 1
  • 23
  • 31
  • 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 06 '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 06 '11 at 15:33