Ideas how Release and Change Management work together and versioning…

How far in advance are you putting in a Change Request?

Most of my personal experience with Change Management has seen that Change Requests come to the Change Advisory Board about 14 days to a few hours before the requested date for production. This seems to be the “norm” per discussions on LinkedIn and with other practitioners.

So, where and how then would you engage with Release Management? Certainly it is not possible to work on designs, unit testing, functional testing, user acceptance testing, load testing, deployment planning, and all of that work in just 10 days or so for any project of significance?!?

Also, I can’t see how a CAB could approve a “schedule” for changes to production for a project that will run months, perhaps even over a year. What happens when the date slips? Do you go through the CAB again? A project that is 8 or 9 months long will probably move the exact deployment date more than few times. It doesn’t seem practical to clog up the CAB with these requests.

Demand Management Board? Release Management Board?

So, let’s say you have an idea (or request) for a project. We already know it is much too early to open a Change Request to have it reviewed by the CAB. So, in what vehicle do you open a “request” up and when?

Perhaps having a Demand Management Board would make sense. This is where the idea can be vetted, perhaps some high level (or initial) budget can be allocated, a tentative schedule, and maybe the “green light” to do conduct a “Proof of Concept”

But what happens after the POC? Now you start getting firmer requirements, clearer designs, and maybe even a tighter budget and schedule. What “release vehicle” should you use and who will have oversight of all the “release” work (resource scheduling and so on)?

A Release Management Board seems like it would be beneficial here. Here you will determine what steps will be required for this “project” (will it require a full design document (such as for a new service) or only an update to an existing one, what level(s) of testing, what checkpoints for quality will be required, how involved will operations need to be, etc), the overall schedule for the effort, balance resources for release management, and perhaps look to consolidate efforts or avoid conflict/collision of releases.

Could these two boards be combined? I think so. But that would be for each organization to determine.

Could these boards be the same as the CAB? I don’t think so. The CAB seems to be more focused on the upcoming “operational” impact of changes – not necessarily the approval of concepts, the development model chosen, project scheduling/resource allocation, and transition planning (in detail anyway). Again, the CAB is more about – what is happening to Production next week and are we ready?

Change Management linking to Release Management

Instead of having just a Change ticket then, I think you should have a Release ticket.

The Change ticket will be to approve the release product (as defined/detailed in the release ticket). Perhaps the CAB will feel the need to move the release date (so an update to the transition plan will have to be made) or perhaps the CAB will feel that Operations is not ready at all and have the effort go back through all/parts of  Release Management.

Once the CAB approves the request – Release Management will have the defined plans of what/how the transition will happen – Change Management will confirm the when (start/finish) and results.

Release Management tickets will be opened for weeks (patches? Other small efforts) to months, perhaps over a year. A Change Management ticket will be opened for maybe 1 month – probably just 2 weeks or sometimes even less.

Thoughts on Versioning

In my past, projects I’ve worked on, had versioning levels for applications that included any functionality provided by that application.

For instance, Remedy 7.2 and then Remedy 7.3 – included in that was Incident, Change, Catalog, Asset Tracking and so on. We may update Incident with new workflow and that might be – internally Remedy 7.3.1 or something like that.

A concept I just heard about was actually to separate the “tool” or “technology” or “application” from the “functionality” or “service” being consumed. This would mean you would have Remedy 7.3 but if you did something to Incident it would become Incident 1.0 or 1.1.

Incident 1.1 would then “sit” on or be provided from Remedy 7.3 but not necessarily linked.

In a way, it is like separating Remedy 7.3 from your Windows Server Image. And then separating your Windows Server Image from your Hardware Configuration. So, you actually start “stacking” these “releases” on top of each other.

Example:

  • Incident 1.3 – Details the requirements – features/functions of Incident
  • Remedy  App 7.5 – Essentially the COTS product from the vendor – Vendor patches are applied here…
  • Remedy Application Server Configuration 1.2 — Specific configurations that need to be done to the Server so the Remedy App can work
  • Windows Server Image 3.4 — the Company’s base Windows Server Image
  • Hardware Configuration 6.5 — The Company’s base HW configuration

So, what if you wanted to add more memory? You would update the Remedy Application Server Configuration.

What if you replaced the server? That would be an update to Hardware Configuration.

Now for the really fun part – what if you replaced Remedy with CA Service Desk?

Then that would be this:

  • Incident 1.3 – Details the requirements – features/functions of Incident
  • CA Service Desk 12.5 – Essentially the COTS product from the vendor – Vendor patches are applied here…
  • CA SD Application Server Configuration 1.0 — Specific configurations that need to be done to the Server so the CASD App can work
  • Windows Server Image 3.4 — the Company’s base Windows Server Image
  • Hardware Configuration 6.5 — The Company’s base HW configuration

If you did, as part of this “technology” change update anything to do with Incident – then its version would change accordingly.

I believe this allows for clarity on requirements documents, testing, and release planning. You work on whatever release component you want but the requirements are very specific to that release component.

Instead of having a single project cover each of these release items – you essentially have 5 projects (interrelated) with very specific release models/focus that could be managed under a larger project (or program?).

The Change would really then be a collection of Releases – and not just CA Service Desk with all these specific releases sort of lost in the shuffle.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s