I'm working in a moderate big organization where GIS is just on part of the IT-platform. The rest of the organization are working with "Change Management" and now they want us GIS-engineers to be better with Change requests and so on.

The problem is, as a GIS Administrator, we do a lot of changes all the time. Start, restart mapservices, create new services, move data, update services and data.

My question is if anyone else have experience with Change Management and GIS in their daily work and how that worked out for you :)

Looking forward to a interesting discussion.

This is a link that explains Change Management concept.

  • 2
    Is Change Management some sort of platform or just a name of some arbitrary workflow/process? Have you got any links that explains it?
    – Martin
    Jan 24 '14 at 13:24
  • added link in original post
    – Andersson
    Jan 24 '14 at 14:10

I also work within an organization that utilizes the Change Management process. For us, change management does not apply to daily data management operations... that would be overwhelming. It generally applies to changes to a [system / database] that may have a downstream impacts on other systems.

At a high-level, ask yourself these questions:

  1. "Do others expect [system / database] that I am working on to be consistently available?"
  2. "Will someone call and ask me what is wrong with [system / database] because of the work I am planning?"
  3. "Would it be beneficial to do work on [system / database] at a planned time when everyone knows it will be unavailable?"

If the answer is "Yes", it probably should be part of Change Management.

So using your examples:

  • Start, restart mapservices = change management
  • Create/update services = change management
  • Move data (assuming it is to a new server/database) = change management
  • Change data schema (table/view name, columns, etc) = change management
  • Update data = not change management because it is unlikely that anyone cares if FeatureID 123 or attribute X is populated. They just need to be able to analyze whatever data exists in the feature class.

Another way to think of it like a delivery service: If you move to a new address, change your name, have you address changed by the municipality, you should notify the Post Office. If you get a new subscription to a magazine, the PO doesn't need to know because the delivery will just show up.


The article for Change control is probably closer to what you are thinking of.

In my organization we have a weekly "operations" meeting during which we go over a list of upcoming changes and ask the key personnel involved for status updates and provide an opportunity for any conflicting operations to be coordinated.

These procedures are generally covered by a standard operating procedure (SOP), service-level agreement (SLA) and/or operational-level agreement (OLA), with individual tasks/workflows documented in a knowledge base (KB). The strategic prioritization of large projects is handled through IT governance.

Any medium to large IT shop should have at least some of these standards implemented already.


It seems to me that Change Management is more about changing the structure of the organization or requirements to a project, not the day-to-day technology maintenance (the restarting of services, for example). From the "Examples" section of the Wikipedia article you linked to:

Strategic changes, Operational changes (including Structural changes), Technological changes, Changing the attitudes and behaviors of personnel, Personality Wide Changes


At a former job in a medium-sized company, we had to put in "change controls" whenever we needed to make changes that affected any major production IT system or component, such as, but not limited to database changes/migrations/connections, ETL jobs, server configurations, etc. Dev and test environments did not require change controls. Luckily, we had (earned) the trust of our IT department, so they gave us freedoms such as full control over our production environment so we could easily deploy our apps and make changes as needed. IT didn't have the staff with knowledge of the inner workings of GIS applications to handle all of the day-to-day management tasks, so they left that to us. Bouncing map services did not require a change control for us, but it was in our SOP and docs, which were internally available to all.

My point: Earn the trust of your IT department, your DBAs and Sys Admins, show them how your procedures impact the systems, and try your best to work with them as much as possible. Try to come up with a SOP and document what requires a change control and what doesn't, and stick to it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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