February 2, 2012 at 9:53 pm
Comments posted to this topic are about the item Change Management
February 2, 2012 at 11:21 pm
Having worked at a bank and retailer(both quite big) we use Change Management all the time. The change team coordinator is one of our close allies and usually assign most of the tasks to do to us.They were all ladies and very very strict. And watch out if you have deployed without approval... you might want to get that CV ready.:angry:
February 3, 2012 at 1:40 am
My company is quite small, and we do not use any Change Management. We are part of the way there by requiring the requests for changes to be logged in our helpdesk, but that isn't done in such a way that there's any real trail to the actual changes.
There's so much to do and so little time, it's hard to initiate something like this by choice. On the other hand, it would be better to do it by choice than to have a situation where a director of the company gets involved and asks why things weren't better documented/controlled.
February 3, 2012 at 2:00 am
We log change "requests" in our in-house change control system. It's good because we have a track of the changes made as Steve mentions. But the system isn't very granular, so it's not like a source control system for example.
February 3, 2012 at 2:00 am
We have formal change mangement procedures and stick to them all the time.
But what sort of organisation pays Change Manager more than it's senior DBAs?
February 3, 2012 at 2:28 am
Being singularly responsible for our in-house SQL estate, I try and follow change control procedures. Nothing too radical, just a document of the change and the scripts used to deploy although on occasions, other people will do deployments and the change control steps are missed. Its quite a small company so the only person enforcing this is myself and to be honest, i can count on one hand where i've retrospectively made use of the documentation (although I'm not saying its a reason not to do it!).
I've also worked at large banks and the change control there is far too restrictive to the point where people would rather not fix an issue due to the red-tape around raising a change request. I know change is risky and banking systems are complex with many stakeholders but for many things the Change process was just far too restrictive.
February 3, 2012 at 2:41 am
I work for a medium-sized company (around 600 employees) where we have never had any formal Change Management.
We have, however, put in a system for automatically recording code changes after the event, so we can roll back if (or when!) things go wrong.
I also created a Change Log database a couple of years back. It seems as if I'm the only one who uses this with any consistency, but I like having a record of what I've done. It saves time whenever I think "I'm sure I've done something like this before", and I like the idea of having something to point to if someone says "Just what have you been doing lately?"
February 3, 2012 at 2:52 am
Small company here < 15 employees. No formal process at all. Change is managed (minimally) though and would take one of two forms depending on the project:
- Incrementing versions married to a document listing the main points about that version (that's the heavy version!)
- Release ad hoc based on change and issue tracking
With the size of the company we are lucky to get anyone beyond the developer to even look at test deployments before they go live. That's how you know it's a big and important change. Fortunately we mostly get it right - I would sometimes like a bit of help with that but what can you do? To be fair I like being fast acting and responsive - I've got used to it now.
February 3, 2012 at 3:09 am
"However I've found that any change management quickly becomes a bottleneck devoid of common sense and full of bureaucratic nonsense."
Oh so true Steve.......'ITIL'd to death. You couldn't do anything without a reference number
Madame Artois
February 3, 2012 at 4:18 am
I have worked in large companies where the change control procedure is beyond ridiculous, it takes up so much time for (as far as I can see) little benefit. The company I work in now is a mid-size firm and while we have formal change control procedures because it is a Canadian company and as such is subject to Canadian Bill 198 auditing requirements it is implemented in a sensible way. Essentially all sign-offs are held in a call system and all code changes in a source control repository. This works very well and seems to me to be a sensible and proportionate implentation of change control for what we do. It enables us to react quickly to problems that arise in the production environment and the ability to implement planned changes on our own timetable, in partnership with the business obviously.
February 3, 2012 at 5:51 am
Working as a freelance developer for over a decade I have worked for differing sized clients from multinationals to small local companies where you can keep your shoes on and still count all the employees. The one thing that has struck me throughout this time is that the quality, applicability or even the existence of change control processes is not defined by the size of the company. Sure a larger company is more likely to have a set of crippling processes and a small company more likely to not have any but I have seen these two extremes in the opposite sized companies too.
The worst factor I have seen in play is when the people in charge of change control do not see themselves as enablers for the business and either see it as their power to wield or as a way of maintaining their job. I always thought that this was counterproductive but what can you do?
Very few places I have worked have not used source control at all which I think, at least in environments using the MS development stack, has been lead initially by MS SourceSafe and then by freeware SCM. In the Unix world there was always something there but occasionally it was deemed by some as too difficult to use (this was back when the console was the only client and training [sic] was a way to get to work). Database artefact source control is less frequently done or poorly implemented. (I'll leave it to someone else to plug any products out there that do that as I suspect everyone here knows of at least one, right?)
There is an additional point eluded to by this editorial; sometimes a project's successful completion criteria excludes a successful deployment. This is handy when the situation makes it hard to manage the convergence of different streams, e.g. user training, 3rd party systems etc., but often leads to software that is never released or the lack of appropriate resources for support once it does get released.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 3, 2012 at 6:19 am
I've seen varying levels of change management during my 28 year career, and most of the time it felt like a productivity drain. However, the company I've been with for the past 5+ years has change management ingrained so deeply into the whole lifecycle of our products, it doesn't feel like it's an additional layer on top of doing my job - it's just part of doing my job. I certainly have an appreciation for CM I didn't have before working here.
Kyle Gress
Database Architect
February 3, 2012 at 6:23 am
I work for a fortune 500 insurance company and we must adhere to a very strict change control process which includes SCC, testing, and multiple sign offs. Change control tickets are opened, reviewed, approved, deployment is scheduled, and finally implementation completed during the required change control window.
February 3, 2012 at 6:45 am
It's difficult to follow Change Management for every process, but it's useful for review. We are following change management every time.
February 3, 2012 at 7:50 am
Working as a freelance developer for over a decade I have worked for differing sized clients from multinationals to small local companies where you can keep your shoes on and still count all the employees. The one thing that has struck me throughout this time is that the quality, applicability or even the existence of change control processes is not defined by the size of the company. Sure a larger company is more likely to have a set of crippling processes and a small company more likely to not have any but I have seen these two extremes in the opposite sized companies too.
The worst factor I have seen in play is when the people in charge of change control do not see themselves as enablers for the business and either see it as their power to wield or as a way of maintaining their job. I always thought that this was counterproductive but what can you do?
So true. I've had perfectly valid change requests denied because I couldn't justify them as well as a business person could. If nothing else we're trying to get code changes tracked so we have a record of them. So in a small department at a big company we sometimes take liberties when it comes to change management.
I know some of our "business critical" systems are locked down to the point where they have to submit a request just to have changes made in a UAT environment.
Ken
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply