FSC vs. FSR

[Debbie]

What is the difference between the Forward Schedule of Change and the Forward Schedule of Release other than the amount of detail that goes into the FSR? How do you keep them synchronized? What level of detail to you go into for each?

[Guerino1]

Hi Debbie,

There really is no difference.

A Product, is made up of one or more Release versions. Each Release gets deployed (or "released") to a target environment, as it moves forward, toward the Production environment. A FSR is to schedule the deployment of a "Release" into a specific environment.

A Release is made up of one or more Changes, where the Changes define everything that has been or will be modified by the Release. Sometimes, rather than deploying an entire Release, it makes sense to deploy one or more Changes that are a subset of the Release. A FSC helps to schedule "Changes" to their targeted environments.

NOTE: ITIL, who is all about not re-inventing the wheel, re-invented the terminology for Release in a way that it is ambiguous to how Developers, Engineers and Architects, since they see a Release as a "group of changes that define a new version of a product." Release Management is one of the areas where ITIL is a big vague and inconsisten, and even contradicts other best practices that have been established long before ITIL. We've found that if you try to implement ITIL Release Management in an enterprise, there will almost immediately be contention with how product design and development resources work.

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[Debbie]

Hi Frank,
Thanks for the feedback. I guess it boils down to who you are talking with. From the ITIL trianing I have received I can't recall anything regarding the FSR...it was always the FSC. However, in talking with others ITIL'ers, I have started to hear more on the FSR and wanted to make sure that I wasn't missing anything. So basically they are the same thing and should be treated as such??

Thanks,
Debbie

[peppermint]

Hi Debbie,

personally I think that Release Management in ITIL is described as bit of an underdog, and they're not going into great detail about it. In real life it's never so clear-cut, and most of the companies use some kind of a development methodology like SDLC. The main difference as I see it is the timespan of a release and a change, and not every change will go through the change management. For example replacing a disk in a server is a change, but not a release. Nevertheless you need to overlay the FSC and FSR to know that you cannot replace that disk on the planned date because a release might go live just on that exact date. It's actually an ISO/IEC 20000 requirement as well.

I hope this made sense.

pep

[Guerino1]

Hi Debbie,

The concept of a "Release" is very weak and almost broken in ITIL.

Traditionally, creating a new "Release" means creating a new version of product that you will take to market (or ultimately to your production environment).

ITIL redefined it to be more along the lines of a "deployment" of the product and now seems to conflict with what Release means in SDLC, RUP, etc. This, in my opinion, is an example of where ITIL actually is part of the problem and not the solution.

Also, by defining a Release to be what it is, in ITIL, the definers have missed a very critical point: "A Release is composed of one or more Changes". ITIL makes the "Change" the primary unit of deployment and this is very inconsistent with what software developers and engineers are taught, as they are taught that a Release is the primary unit of deployment.

If you teach your infrastructure teams to define "Release" the way ITIL does, then you will automatically introduce conflict, as you will be going against everything your development and engineering teams have been taught. This means your infrastructure teams will be speaking a different language than your development and engineering teams. Not good...

I personally recommend you go with the RUP/MSF/SDLC/etc. definitions of a Release. They're more universally accepted and there is a very high probability that they are already in place in your enterprise, as most developers will already speak that language. Therefore, a FSR is nothing more than a calendar/schedule of "Releases", which include one or more Changes per Release.

Anyhow, I hope this helps.

Best Regards,
_________________
[Edited by Admin to remove link]